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.

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...

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

Agregar

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

Agregar

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
                
            
        
        
        
        
            
        
        
            
            Agregar


                    
    
        
        
        
            
                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
                
            
        
        
        
        
            
        
        
            
            Agregar

Etiquetas más populares

Ver todo

4 Respuestas

Etiquetas más populares

Preguntas más populares

Partners: