Menu de navegação

[mpvargasParticipante]

Caros amigos,
Uso o spotlight para monitar o banco e estou recebendo alarme, constantemente, do LGWR1 (Redo Log Writer) sinalizando o seguinte:
“Average redo log write time is 550 ms (Averaged over 30 seconds)”

Estou na dúvida com relação a qtde de redos que devo configurar, tenho 8 X 500MB, e o sistema está funcionando blz… não sei se devo aumentar ou diminuir… nas verificações que fiz utilizando o ADDM, recebo alertas para aumentar a SGA, mas não é possível (não tenho RAM disponível).

Alguém sabe se existe alguma recomendação com relação ao tempo médio do Redo Log Write e se é possível configurar no spotlight?

[hudsonaParticipante]

Fala Amigo,

Tirando os alertas do spotlight, você realmente esta tendo problemas de performace no seu banco ?
Se realmente esta, você já verificou o tempo de espera que o banco tem aguardando a gravação nos archives, para poder regravar os redo logs ?

[mpvargasParticipante]

Fala Hudson,
Ando recebendo algumas reclamações de lentidão no sistema, mas isso deve-se a grande quantidade de processos simultaneos… trabalho com ERP Microsiga, os processos geram muito I/O e as queries são um lixo.
Apesar dessa grande qtde de processos, hoje só gravou um log… não sei se isso tem a ver com a lentidão… talvez eu deva reduzir o tamanho ou qtde de redos…
Sobre o tempo de espera de gravação nos archives, como posso fazer o calculo desse tempo?
Obrigado pela ajuda

[VitorLeandroParticipante]

Fala Vargas…

Esse alerta pode ter relação com a velocidade de gravação dos Redos e não necessariamente é um problema. Redos grandes ou muitos, não são o problema, o problema é quando eles são muito pequenos e o LGWR tem que esperar o DBRW finalizar o checkpoint redo corrente…

Verifique :

Está aparecendo no seu alert log mensagens de check point incompletos?
EX: (Thread 1 cannot allocate new log, sequence 6)
Checkpoint not complete

Você usa ASM? Com redundancia?

Qual RAID você usa?

Existem execuções pesadas que manipulam milhares de linhas em um curto espaço de tempo?

Pesquise os session_events dessas sessões se aparece com grande valor o evento

Vou pesquisar sobre o tempo médio de gravação nas bases que eu tenho acesso, daí agente compara!

• Detalhe, não é a gravação dos archives, mas dos redo log files!!

[mpvargasParticipante]

Fala Vitor,

Verifiquei no alert log e não tem nenhuma mensagem de checkpoint incompleto.
Eu não uso ASM.
Eu uso RAID 10.

Existem execuções pesadas que manipulam milhares de linhas em um curto espaço de tempo? SIM

O Session_events que eu não sei como te informar…

[VitorLeandroParticipante]

Dê uma olhada nessa query que pesquisa os eventos de ‘Configuração’ mais demorados…

Se possível, poste as 10 primeiras linhas:

SELECT WAIT_CLASS,
B.NAME,
TO_CHAR(A.BEGIN_TIME,’DD/MON/YYYY HH24:MI:SS’) DATA_INICIO,
TO_CHAR(A.END_TIME, ‘HH24:MI:SS’ ) AS FIM,
A.NUM_SESS_WAITING,
A.TIME_WAITED,
A.WAIT_COUNT
FROM V$EVENTMETRIC A, V$EVENT_NAME B
WHERE A.EVENT_ID = B.EVENT_ID
AND B.WAIT_CLASS =’Configuration’
ORDER BY TIME_WAITED DESC

Se mostrar altas esperas em “log file switch”, você tem problemas com seus redos!!

[mpvargasParticipante]

Um exemplo da causa do problema

Recomendações ADDM

Benefício 53,4%
Ação Investigue a lógica da aplicação envolvendo entrada/saída em TABLE PARTITION “MSIGA.CT2010.PT03” com o id de objeto 133304.
Objeto de Banco de Dados MSIGA.CT2010

Motivo As estatísticas de uso de E/S para o objeto são: 0 varreduras completas de objetos, 663562 leituras físicas, 0 gravações físicas e 0 leituras diretas.
Motivo A instrução SQL com SQL_ID “66m1kwacvzyg7” despendeu um tempo significativo aguardando a Entrada/Saída do Usuário no objeto dinâmico.
Texto SQL SELECT /*+ FIRST_ROWS(260) */ R_E_C_N_O_, D_E_L_E_T_, CT2_FILIAL FROM CT2010 WH…
SQL ID 66m1kwacvzyg7

Particionei essa tabela, roda estatísticas diárias, etc
Não sei mais o que fazer
Gera muito I/O

[PetersonParticipante]

Mpvargas,

Os datafiles e arquivos de logs estão bem distribuídos e multiplexados? Será que não está havendo concorrência em alguma área de disco por escrita de dados ou de logs? O tamanho dos logs parece estar legal (visto a maioria das aplicações), mas se há concorrência por disco a coisa pode ficar estranha.

[mpvargasParticipante]

Fala Peterson,
A arquitetura é da seguinte forma:
8 discos sendo 4 X 2 em RAID 10, sendo 4 filesystem

/
/Dados
/Indices
/logs

Sendo que os logs ficam “completamente” separados, coloquei entre aspas porque tem o gargalo da controladora

[hudsonaParticipante]

[quote=”VitorLeandro”:1an9vm6g]Fala Vargas…

• Detalhe, não é a gravação dos archives, mas dos redo log files!![/quote]

Complementado um detalhe

Enquanto o archiver (ARCH) não terminar de ler os Redo Log Files para gerar os archives, o Redo Log File não é reescrito. Agora com mais detalhes que o Mpvargas passou acredito que não seja esse o problema, porém a principio no primeiro diagnóstico que ele passou poderia existir um problema em um número pequeno de Redo Log Files, e LGWR poderia estar esperando a geração dos archives para poder regravar os Redo Log Files.

Quanto ao problema :

I/O não é causa de um problema é consequência de um. Então a principio o primeiro passo é verificar o que o nosso amigo Peterson falou,
a má distribuição dos datafiles e Redo Logs, geralmente são as principais causas de I/O.

[VitorLeandroParticipante]

Bem, isso é outra coisa…

O ADDM está lhe informando que o SQL_ID “66m1kwacvzyg7”, possui muitas leitoras físicas em uma partição… Daí você precisa primiero descobrir qual este select…

A qual tabela, pertence esta partição:
select * from DBA_TAB_PARTITIONS WHERE PARTITION_NAME LIKE ‘MSIGA.CT2010.PT03’

Procurando o SQL:


SELECT COUNT(*), p.sql_id c1,
p.cost c2,
DBMS_LOB.SUBSTR(s.sql_text,4000,1) c3
FROM DBA_HIST_SQL_PLAN p,
DBA_HIST_SQLTEXT s
WHERE p.id = 0
AND p.sql_id = s.sql_id
AND p.cost IS NOT NULL
AND p.SQL_ID = '66m1kwacvzyg7'
GROUP BY p.sql_id,
p.cost,
DBMS_LOB.SUBSTR(s.sql_text,4000,1)
ORDER BY,
p.cost DESC

Se for muito grande, use o Entreprise Manager para encontrar a query.

Depois verifique o plano de execução dessa query, veja se não existe algum jeito do Oracle não precisar ler esta quantidade de dados da partição acima…. Seja criando um index, ou criando uma subpartição…

Voçê pode usar o “Tunning Advisor” tambem, que pode sujerir algum plano melhor ou o “Acces Advisor” que sujere novas estruturas..

[mpvargasParticipante]

Hudson,

Observei agora em Sessões Bloqueadoras

Classe de Espera Evento de Espera
System I/O log file parallel write
Commit log file sync

[hudsonaParticipante]

Isso quer dizer …..

log file parallel write___> O processo está esperando para escrever blocos para um grupo de arquivos de log ativos.
log file sync____> O processo está esperando que processo responsável
pela escrita de log termine de escrever os buffers para
o disco.

Um bom artigo ….

https://profissionaloracle.com.br/blogs/ … o/2008/10/

[mpvargasParticipante]

Fala Hudson,
Li o artigo (muito bom)
Mas estou em dúvida qto a solução…
Não tenho para onde mover os redo logs…
Seria interessante aumentar a qtde ou tamanho dos arquivos?

[VitorLeandroParticipante]

[quote=”VitorLeandro”:36l81yyb]

Enquanto o archiver (ARCH) não terminar de ler os Redo Log Files para gerar os archives, o Redo Log File não é reescrito. Agora com mais detalhes que o Mpvargas passou acredito que não seja esse o problema, porém a principio no primeiro diagnóstico que ele passou poderia existir um problema em um número pequeno de Redo Log Files, e LGWR poderia estar esperando a geração dos archives para poder regravar os Redo Log Files.
[/quote]

hudsona,

Existe o Processo citado por você, o (ARCH), que sua função é arquivar os redo log files… Neste caso, bastaria melhorar a performance da flash_recovery_area, se fosse este mesmo o problema.

Eu estava querendo dizer é a espera do LGWR na escrita de novos redos no caso em que o DBWR(escrita em Datafile), não ter efetuado a escrita dos dados em datafile do redo passado.

A escrita do LGWR é muito mais rápida do que a do DBWR pela arquitetura do Oracle, sendo assim o tipo de espera mais comum relativos a redo.

[Autor]

Posts