Menu de navegação

[mpvargasParticipante]

Caros Amigos,
Estou fazendo alguns trabalhos “pesados” na base teste e gostaria de tirar uma dúvida:
É possível realizar alguns processos sem utilizar a tablespace de undo?
Não sei se a pergunta está bem formulada, mas a base teste funciona no modo noarchivelog e mesmo assim fica lenta devido ao DBWR e LGWR.
Verifiquei também que ele usa muito a tablespace de undo.
Estou fazendo um insert numa tabela, transferindo os dados da base de produção para base teste (tem que ser insert porque a estrutura é diferente, pois não consigo usando o impdp) e como são muitas linhas, no caso, mais de 3 milhões, a tablespace de undo vai aumentando de forma excessiva… nesse processo por exemplo, a undo estava com 5GB e auto extent de 100M… mas já está com 9GB.
Existe alguma forma de melhorar esse processo?
Obrigado.

[IshiiParticipante]

Olá,

Nesses casos acho melhor criar um bloco PL para a inserção com o commit a cada 100.000 linhas ou a cada 10.000 como achar melhor. Se não houver problemas de acesso a disco, pode-se até reduzir esse número para não aumentar tanto o UNDO…

[]s Ishii

[mpvargasParticipante]

Blz ishii, valeu pela dica
Posso utilizar o próprio insert que tenho pronto e implementar num bloco PL/SQL… não tinha pensado nisso.
Obrigado pela dica.

[IshiiParticipante]

Olá,

Outra dica seria verificar se a tabela destino tem triggers e se tiver desabilitá-las…

🙂

[]s Ishii

[mpvargasParticipante]

OK Ishii
Obrigado.

[mpvargasParticipante]

Ishii
Dá um help nesse assunto.
Criei a procedure, está rodando blz com o commit, conforme sua dica… fiz algumas alterações no banco para agilizar o processo, tipo: aumentei a PGA, aumentei os redologs, etc
Ele trava as vezes pra fazer o checkpoint.
Tem como evitar isso ou não tem jeito?
O banco está no modo noarchivelog, mas sempre ocorrerá o checkpoint?
Obrigado mais uma vez.

[IshiiParticipante]

Olá,

O Checkpoint sempre ocorrerá pois há um DML, mesmo que esteja no modo noarchive, isso apenas grava os dados no banco “limpando” os redos.

Pode ser que tenha um problema nos seus redos então…. diminua o valor do commit para uns 1000 ou 5000 no máximo e veja se isso ainda ocorre. Se ocorrer ainda melhor olhar o alert.log e ver se não há nada sobre problemas no redo…

[]s Ishii

[mpvargasParticipante]

Ishii,
Tem alguma forma de acompanhar o processo?
Tipo, saber quantas linhas foram inseridas na nova tabela?

[IshiiParticipante]

Olá,

Isso você pode acompanhar em outra sessão com um select count mesmo, mas a cada commit da sua rotina é que será possível saber mesmo… porém se a qtde de linhas for pequena (1000 por exemplo) e estiver demorando, pode ser que tenha algum outro problema como extend da tabela ou dos índices… ai é melhor analisar caso a caso…ou gerar um trace somente de uma parte da inserção e ver o que está ocorrendo no BD.

[]s Ishii

[mpvargasParticipante]

Ishii,

A tabela tem 3.500.000 linhas
Coloquei o commit a cada 50.000 e tentei acompanhar com o SELECT COUNT conforme a sua sugestão…
O tamanho da tabela é 6GB
O SELECT COUNT estava dando 0 (zero) mas observei na tablespace que o tamanho da tabela já estava em quase 4GB
Está parecendo que o commit não está sendo realizado, mas fiquei na dúvida porque o tablespace de undo não está mais enchendo como antes.

Obs.: Não completei o processo porque estourou o tamanho da tablespace mas já resolvi esse problema e vou reiniciar o processo.

[IshiiParticipante]

Olá,

Diminua o commit para cada 10000 linhas… acho que com isso dá para acompanhar… o I/O será um pouco alto mas compensa a velocidade.

[]s Ishii

[mpvargasParticipante]

Valeu Ishii
Obrigado pela ajuda.

[Autor]

Posts