- Este tópico contém 6 respostas, 3 vozes e foi atualizado pela última vez 9 anos, 5 meses atrás por
ithigvo.
-
AutorPosts
-
27 de fevereiro de 2015 às 5:59 pm #107396
armandoveloso
ParticipantePrezados,
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.,
Armando27 de fevereiro de 2015 às 7:57 pm #107397rman
Participante@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.
27 de fevereiro de 2015 às 10:40 pm #107398armandoveloso
Participantecaro 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…
27 de fevereiro de 2015 às 11:54 pm #107399rman
Participante@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.
2 de março de 2015 às 6:36 pm #107400ithigvo
Participante@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_LOGMNR5 de março de 2015 às 4:40 pm #107401armandoveloso
ParticipanteCaro 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,
Armando24 de março de 2015 às 6:48 pm #107435ithigvo
Participante@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.
-
AutorPosts
- Você deve fazer login para responder a este tópico.