Menu de navegação

[armandovelosoParticipante]

Prezados,

Tenho uma base que está gerando archivelogs demais, a carga de trabalho não justifica tanto archive assim, chega a passar de 5GB de archives por dia. Até de madrugada, quando a utilização do sistema cai consideravelmente, a geração de archives continua no mesmo rítmo.

Gostaria de tentar descobrir se há algum processo específico no banco que esteja causando isso, mas não sei como posso rastrear, talvez analisando o processo LGWR…

Att.,
Armando

[rmanParticipante]

@armandoveloso

Archivelog nada mais é que um backup do redolog. O redolog é uma lista circular, quando o redolog é preenchido por completo é feito a troca de redolog, antes de fazer a troca no caso de ARCHIVELOG MODE o conteudo do redolog é arquivado em forma de archivelog, então o redolog é limpo e começa novamente o preechimento.

Talvez não tenha nada de errado, é a carga de trabalho que o banco recebe.

[armandovelosoParticipante]

caro rman,

Sei q o archive é o arquivamento dos redologs, mas desconfio ter algo estranho nessa base, gerencio bases bem maiores, com muito mais sessoes simultaneas, e nao gera isso tudo.

Pensei em alguma implementação equivocada na aplicação. Mas é so uma desconfiança de algo estranho, pode estar tudo normal mesmo…

[rmanParticipante]

@armandoveloso

Existe uma forma de controlar de forma indireta a geração de archivelog, isso se a preocupação é a quantidade de archivelog. Ajustando o tamanho do redolog você pode fazer como que demore mais ou menos para encher o redolog, ou seja, quanto maior o redolog mais tempo levará para ser preenchido por completo, e quanto menor o redolog mais rapido para ser preenchido, isso de forma indireta aumenta ou diminuiu o número de archivelog.

Para ter um parâmetro verifique o tamanho do redolog nos ambientes que você administra e compare a geração de archivelog. Lembre-se que a carga de trabalho é um fator importante na sua analise.

[ithigvoParticipante]

@armandoveloso

Vi que você desconfia de problemas de implementação. Já vi certa vez um desenvolvedor que utilizava uma tabela fisica como temporária.. a aplicação inseria os dados, e truncava essa tabela quase 3 vezes por segundo… o causava uma geração muito alta de archives.

Uma forma de descobrir o que pode estar ocorrendo em seu ambiente é utilizando o LogMiner..
Com ele você consegue abrir um archive para “consulta”, e ver o conteúdo dele.. pesquise pela package DBMS_LOGMNR

[armandovelosoParticipante]

Caro ithigvo, agradeço pela dica, eu desconfio disso mesmo.

Fiz algumas análises com o log miner. Encontrei duas situações:

1) Há update que num log só se repetiu quase 4 mil vezes, para alterar 3 campos e em todas as ocorrências setendo p/ o mesmo valor. Acredito que esse update esteja num loop e esteja assim sendo enviado um a um, update por update, assim, gerando muitos logs. TALVEZ seja caso em que tudo isso possa ser enviado ao banco como um único update. Passei pros desenvolvedores analisarem.

2) Há uma ocorrência muito estranha, no lugar do comando, aparece apenas “Unsupported”. Isso aparece milhares de vezes por log! Não tenho a mínima idéia do que se trata. Talvez no comando tenha campo LOB, não sei se é isso.

De toda forma, agradeço pela valiosa dica!

Abraço,
Armando

[ithigvoParticipante]

@armandoveloso

Cara, acho que esse unsupported podem ser referente a objetos que não existem mais no dicionário de dados. Por exemplo, em tempo de execução, a aplicação pode ter criado uma tabela, e dropado.

Ao fazer o logminer, o banco não tem informações para exibir o “Nome” dos objetos envolvidos.

att.

[Autor]

Posts