¡Caminando hacia el éxito!

Aprende en Comunidad

Avalados por :

Como melhorar o desempenho no Oracle 10.2.0.4: Estratégias para otimizar o evento db file parallel write e reduzir logs de redo arquivados.

  • Creado 01/03/2024
  • Modificado 01/03/2024
  • 9 Vistas
0
Cargando...

Olá a todos,

Tenho um caso em que estou um pouco preso. Os usuários finais estão reclamando

que o desempenho está realmente ruim. Dados do sistema: ECC 6.0 / Oracle 10.2.0.4.

Podemos ver facilmente que o evento de espera "db file parallel write" dos

8 processos de DBWR está realmente alto. Também o número de logs de redo arquivados

escritos é muito maior (20-30 por hora em comparação com normalmente 2 por hora).

Ao analisar os dados do ADDM para os períodos com baixo desempenho,

posso encontrar 5 declarações SQL custosas com uma estimativa de benefício

aproximadamente igual:

6tvk271cbac3t DELETE FROM "VAPMA" WHERE "MANDT"=:A0 AND "VBELN"=:A1
6c0pw8gqhbbbf UPDATE "INDX" SET "LOEKZ"=:A0 , "SPERR"=:A1 , "AEDAT"=:A2 , ...
49rc57zc9nc3x UPDATE "USR02" SET "BCODE"=:A0 , "GLTGV"=:A1 , "GLTGB"=:A2 , ...
3cmgznkdm332x INSERT INTO "VBMOD" VALUES(:A0 ,:A1 ,:A2 ,:A3 ,:A4 )
c33yvn1gan03y INSERT INTO "ARFCSDATA" VALUES(:A0 ,:A1 ,:A2 ,:A3 ,:A4 ,:A5 ,:A6 ,:A7...

Existe alguma maneira simples de extrair os tamanhos de logs de redo para essas declarações

a partir dos dados do AWR? Já revisei o kit de recursos da nota 1438410, mas

não consegui encontrar nada que ajudasse com esse problema específico.

Preciso usar o Oracle LogMiner para obter essa informação? Ou essa informação está enterrada

em alguma visualização DBA_HIST_....?

Saudações,

Mark

Pedro Pascal
Se unió el 07/03/2018
Pinterest
Telegram
Linkedin
Whatsapp

4 Respuestas

0
Cargando...

Olá Michael,

Obrigado pelo seu feedback! Os arquivos de log online (redo log) têm 1 GB cada.

ST04 -> O cache de cursores compartilhado não permite pesquisar um SQL_ID, então requer algum trabalho manual.

VAPMA; 345.000 linhas processadas (comprimento médio da linha 174) -> alterações estimadas de 57 MB

INDX: 80.000 linhas processadas (comprimento médio da linha 680) -> alterações estimadas de 51 MB

USR02: 25.000 linhas processadas (comprimento médio da linha 263) -> alterações estimadas de 6 MB

VBMOD: 815.000 linhas processadas (comprimento médio da linha 63) -> alterações estimadas de 50 MB

ARFCSDATA: 115.000.000 linhas processadas (comprimento médio da linha 1850) -> alterações estimadas de 200 GB

Assim, as informações apontam claramente para ARFCSDATA como o responsável.

Não seria aconselhável descartar os arquivos de log online arquivados, seria melhor verificar a coluna REDO_LENGTH de V$LOGMNR_CONTENTS

ou algo semelhante.

Saudações,

Mark

Respondido el 15/04/2024
LUCIANO RIOJA GHIOTTO
Se unió el 13/07/2019
0
Cargando...

Uma abordagem simples inicial poderia ser procurar essas declarações no cache do cursor (ST04 -> Análise de declarações SQL). Procure o número de linhas de processos -> quantas mais linhas -> mais redo (para DML

Qual é o tamanho dos seus registros de redo?

Cumprimentos, Michael

Edit: ou você pode despejar o redolog em um arquivo de rastreamento

SQL> ALTER SYSTEM DUMP LOGFILE u2018/oracle/SID/origlogA/log_g11m1.dbfu2019;

O tamanho do redo pode ser encontrado aqui: ktudb redo: siz: 144

Você pode despejar apenas partes de um arquivo. De qualquer forma, o despejo será grande e você terá que agrupar as entradas de alguma forma, para encontrar a causa do aumento do seu redo.

Respondido el 15/04/2024
LUCIANO RIOJA GHIOTTO
Se unió el 13/07/2019
0
Cargando...

Olá Martín,

Desculpe, mas você é muito modesto! Pode estar certo de que tecnicamente o número de mudanças de blocos não é exatamente o mesmo que o espaço de registro de refazer utilizado. De qualquer forma, seu conselho foi ótimo, com a ajuda do script SegmentStatistics_TopSegmentsForStatisticPerAWRInterval.txt pude identificar que na verdade eram ARFCSDATA e ARFCSSTATE os responsáveis pela alta quantidade de registros de refazer escritos.

Saudações,

Mark

BEGIN_TIME             TOTAL_VALUE       VALUE_PER_S SEGMENT_1      VALUE_1      %_1  SEGMENT_2      VALUE_2      %_2  SEGMENT_3      VALUE_3      %_3  SEGMENT_4      VALUE_4      %_4  SEGMENT_5      VALUE_5      %_5
---------------------- ----------------- ----------- -------------- ------------ ---- -------------- ------------ ---- -------------- ------------ ---- -------------- ------------ ---- -------------- ------------ ----
BEGIN TIME:            10.01.2011        11:00:55
END TIME:              10.01.2011        21:00:38
STAT NAME:             Mudanças de Bloco de BD
AGREGADO POR:         INSTANTÂNEA
FINES DE SEMANA EXCLUIDOS:     NÃO

2011-01-10 20:00:50            21737808      6058.47 ARFCSDATA           6240000   29 ARFCSSTATE~04       3505216   16 ARFCSSTATE~01       3346672   15 ARFCSSTATE~05       2613712   12 ARFCSSTATE          2041456    9
2011-01-10 19:00:08            30306000      8321.25 ARFCSDATA           8799952   29 ARFCSSTATE~04       4765008   16 ARFCSSTATE~01       4621744   15 ARFCSSTATE~05       3665536   12 ARFCSSTATE          2833952    9
2011-01-10 18:00:07            27743216      7704.31 ARFCSDATA           8000832   29 ARFCSSTATE~04       4308880   16 ARFCSSTATE~
        
Respondido el 15/04/2024
LUCIANO RIOJA GHIOTTO
Se unió el 13/07/2019
0
Cargando...

Olá Mark,

Alguns comentários sobre a Nota SAP 1438410: Na verdade, não há um comando disponível que possa fornecer exatamente o que você precisa. Pessoalmente, eu geralmente começaria com os seguintes dois comandos de resumo simples:

1. SegmentStatistics_TopSegmentsForStatisticPerAWRInterval.txt com STAT_NAME = 'DB Block Changes'

--> Isso retorna os segmentos principais em termos de blocos alterados.

2. Segments_Tables_TablesWithTopDMLRate.txt

--> Isso mostra as tabelas com maior quantidade de operações DML (com base em ALL_TAB_MODIFICATIONS).

Sei que ambos não são a verdade absoluta e muitos outros fatores também contribuem, mas para uma visão geral inicial os resultados podem ser úteis.

Atenciosamente

Martin

Respondido el 15/04/2024
LUCIANO RIOJA GHIOTTO
Se unió el 13/07/2019

contacto@primeinstitute.com

(+51) 1641 9379
(+57) 1489 6964

© 2024 Copyright. Todos los derechos reservados.

Desarrollado por Prime Institute

¡Hola! Soy Diana, asesora académica de Prime Institute, indícame en que curso estas interesado, saludos!
Hola ¿Puedo ayudarte?