Menu de navegação

[mpvargasParticipante]

Caros Amigos,
Após migração de nosso ERP estou recebendo mensagens do ADDM a respeito de I/O… já alterei redo log, parametros de cursor, etc… Meu banco está no modo noarchivelog, mas mesmo assim tem processos que estão muito lentos

Abaixo relatório ADDM

FINDING 1: 72% impact (2097 seconds)
————————————
As esperas pelo evento “sincronização de arquivo de log” ao executar operações de COMMIT e ROLLBACK estavam consumindo um tempo de banco de dados significativo.

RECOMMENDATION 1: Application Analysis, 72% benefit (2097 seconds)
ACTION: Investigue a lógica da aplicação para uma possível redução no número de operações de COMMIT aumentando o tamanho das transações.
RATIONALE: A aplicação estava executando 5860 transações por minuto com um tamanho médio de redo de 1350 bytes por transação.

RECOMMENDATION 2: Host Configuration, 72% benefit (2097 seconds)
ACTION: Investigue a possibilidade de melhorar o desempenho de
entrada/saída nos arquivos de redo log on-line.
RATIONALE: O tamanho médio de gravações nos arquivos de redo log on-line era 2 K e o tempo médio por gravação era 17 milissegundos.

SYMPTOMS THAT LED TO THE FINDING:
SYMPTOM: A classe de espera “Commit” estava consumindo um tempo de banco de dados significativo. (72% impact [2097 seconds])

FINDING 2: 20% impact (582 seconds)
———————————–
O tempo gasto na CPU pela instância foi responsável por parte substancial do tempo de banco de dados.

RECOMMENDATION 1: Application Analysis, 20% benefit (582 seconds)
ACTION: As instruções SQL submetidas a parse usaram bastante CPU. Para obter mais detalhes, consulte as outras descobertas desta tarefa sobre como efetuar parse.

ADDITIONAL INFORMATION:
A instância utilizou um tempo significativo da CPU. No entanto, não
havia instruções SQL predominantes responsáveis pela carga da CPU.

[CleitonHanzenParticipante]

Opá…

Pois entaum, isso geralmente está associado as aplicações que estão fazendo excessivo commits ou discos aonde estão os Redo Logs muito lentos, para resolver isso vejo que duas soluções são aplicáveis:

1. Investigar a aplicação e determinar a causa/motivo de estar sendo realizados tantos commit’s…

2. Colocar os arquivos de redo nos discos mais rápidos do servidor.

O processo de commit é bastante “pesado” para o banco, pois força a gravação das informações do Redo Buffer para o Redo Log (assim existe a garantia q todos os dados comitados efetivamente estejam OK, mesmo que não haja gravação para os DataFiles, caso ocorrer alguma falha no meio do caminho, na inicialização da Instance ocorrerá o processo de Instance Recovery e todos os dados que estão nos Redo mas não estiverem nos DataFiles, serão gravados nos Datafiles)…

[mpvargasParticipante]

Fala Cleiton,

O excesso de commit é da aplicação e como é um ERP não temos como alterar…
Os arquivos de redo ficam num disco separado, sendo que são 2 discos em espelhamento (RAID)
Coloquei meu banco no modo noarchivelog, mas mesmo assim não adiantou muita coisa…
Minha dúvida é se coloca vários grupos de redo com arquivos grandes ou faço o contrário… antes da migração eu usava 6 grupos de 400Mb e funcionava blz

[CleitonHanzenParticipante]

Opá..

Existe uma recomendação que haja no máximo 4/5 switches de log por hora (ou seja, de 15 em 15 minutos), mas esse não é o teu problema….o teu problema é o commit mesmo…

Entendo que o ERP possa gerar este tipo de situação, mas a pergunta é: Você começou a observar isso a partir de quando? Foi somente hoje? Ou desde sempre está assim??

Qual o nível da RAID em que o discos dos Redos estão?? O recomendado é ser RAID 0 (maior velocidade de gravação, visto que estes sofrem constantes gravações)…

[mpvargasParticipante]

Comecei a observar esse problema hoje…
Os redos estão no RAID 1, mas já estavam assim antes…

[David SiqueiraParticipante]

Vargas isso é um monstro exponencial.

A medida que tua volumetria de dados for aumentando você vai precisar de cada vez mais area para que esse erros de commit ou essas lentidões não ocorram.

A sugestão mais adequada seria um PATCH da sua aplicação corrigindo este problema, se possivel levante as querys que tem este comportamento, leve seus reports de AWR e de ADDM, e use como argumento para que seja realizado uma revisão nesses processos antes que eles venham a lhe causar mais dor de cabeça.

Abraço

[CleitonHanzenParticipante]

[quote=”mpvargas”:3ce8yl2k]Comecei a observar esse problema hoje…
Os redos estão no RAID 1, mas já estavam assim antes…[/quote]

Eu trabalharia em cima das rotinas que estão executando hj (por exemplo, se for um processo batch, muito provávelmente existe a possibilidade de “segmentar” fazer commit de 10 mil em 10 mil registros)…

Trabalho com sistemas de Nota Fiscal eletrônica e isso também é uma tristeza (uma nota que é autorizada no Sefaz, precisa fazer o commit no banco, não tem como não funcionar assim), logo clientes que emitem uma grande quantidade de notas por minuto, acabam tendo gargalo e até hj não descubri uma forma de eliminar isso…

Mas vá por mim, coloque dois volumes em RAID 0 para os redos (cada membro de cada grupo em cada volume ) que este problema vai reduzir bastante…..

[mpvargasParticipante]

Valeu amigos
Obrigado pela ajuda

[mpvargasParticipante]

Um outro detalhe…
Tenho uma tablespace com 35Gb… será que isso pode atrapalhar, quero dizer, pode causar lentidão?

[Rodrigo AlmeidaParticipante]

EU só tenho uma dúvid.

Porque o banco de dados do seu ERP está em NOARCHIVELOG?

Abraços,

[souzaParticipante]

Teus REDOS são multiplexados no mesmo disco ? Se sim também é um agravante grande e se não forem multiplexados também – ainda mais em RAID1 ! Outro ponto é o uso de RAID 1 , o ideal seria 0 , porém se tu usar 0 deve multiplexar teus redos para outro conjunto de discos. Pois se tu perder todos ali e teu banco não tá em archivelog daí é complicado.

[CleitonHanzenParticipante]

[quote=”alphamek”:2w4hbcu3]EU só tenho uma dúvid.

Porque o banco de dados do seu ERP está em NOARCHIVELOG?

Abraços,[/quote]

Opá…

Por incrível que pareça, isso é mais comum do q se imagina….ainda tem muuuuuuuuuita empresa que vê informática como “custo” não como investimento…mas a opinião só muda quando o banco dá um crash e existe perda de dados (às vezes até dias de trabalho inteiro de perdas), daí começam a se preocupar com as coisas……com certeza não é a primeira nem será a ultima vez q vejo isso…. rsrsrs

[CleitonHanzenParticipante]

Ahhh…Outra coisa que já ia esquecendo, hj estava lendo um note no metalink (que achei por acaso…. 🙂 ) sobre Asyncronous Commit que é uma feature nova do 10gR2 (nem sabia q isso existia, vivendo e aprendendo….kkkkk)

Pra quem estiver interessado: Note #336219.1

[Rodrigo AlmeidaParticipante]

Bacana heimmmmm esse note….

A parte que mais me chamo atenção foi essa:

WARNING SUMMARY:
The COMMIT NOWAIT feature also has serious implications for database consistency in the event of an instance crash or hardware fault occurring while COMMIT NOWAIT is enabled. Backup and recovery strategies must be up to date and readily available if the COMMIT NOWAIT feature is enabled due to the nature of the affects during failures.

Abraços,

[CleitonHanzenParticipante]

Opá..

Pois entaum, esse é o ponto negativo de ser utilizada essa feature…Tava até discutindo com o pessoal aqui do trabalho, isso daí é interessante em processos de carga de dados e só.. (caso dê falha, poderá ser reinicializado)

Não me arrisco a colocar isso numa base de produção, podendo gerar falhas de integridade… e possívelmente até perda de dados…. 🙂

[Autor]

Posts