¡Caminando hacia el éxito!

Aprende en Comunidad

Avalados por :

Cómo mejorar el rendimiento en Oracle 10.2.0.4: Estrategias para optimizar el evento db file parallel write y reducir logs de redo archivados.

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

Hola a todos,

Tengo un caso en el que estoy algo atascado. Los usuarios finales se están quejando

de que el rendimiento es realmente malo. Datos del sistema: ECC 6.0 / Oracle 10.2.0.4.

Podemos ver fácilmente que el evento de espera "db file parallel write" de los

8 procesos de DBWR es realmente alto. También el número de logs de redo archivados

escritos es mucho mayor (20-30 por hora en comparación con normalmente 2 por hora).

Al analizar los datos de ADDM para los períodos con mal rendimiento,

puedo encontrar 5 declaraciones SQL costosas con una estimación de ajuste

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

¿Hay alguna manera sencilla de extraer los tamaños de logs de redo para estas declaraciones

a partir de los datos de AWR? Ya revisé el kit de recursos de la nota 1438410, pero

no pude encontrar nada que ayudara con este problema específico.

¿Tengo que usar Oracle LogMiner para obtener esta información? ¿O esta información está enterrada

en alguna vista DBA_HIST_....?

Saludos,

Mark

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

4 Respuestas

0
Cargando...

Hola Michael,

¡Gracias por tu retroalimentación! Los archivos de registro en línea (redo log) son de 1 GB cada uno.

ST04 -> La caché de cursores compartida no permite buscar un SQL_ID, por lo que requiere algo de trabajo manual.

VAPMA; 345,000 filas procesadas (longitud promedio de fila 174) -> cambios estimados de 57 MB

INDX: 80,000 filas procesadas (longitud promedio de fila 680) -> cambios estimados de 51 MB

USR02: 25,000 filas procesadas (longitud promedio de fila 263) -> cambios estimados de 6 MB

VBMOD: 815,000 filas procesadas (longitud promedio de fila 63) -> cambios estimados de 50 MB

ARFCSDATA: 115,000,000 filas procesadas (longitud promedio de fila 1850) -> cambios estimados de 200 GB

Entonces, la información apunta claramente a que ARFCSDATA es el culpable.

No querría volcar los archivos de registro en línea archivados, sería mejor revisar la columna REDO_LENGTH de V$LOGMNR_CONTENTS

o algo similar.

Saludos,

Mark

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

Una primera aproximación simple podría ser buscar estas declaraciones en la caché del cursor (ST04 -> Análisis de declaraciones SQL). Busca el número de filas de procesos -> cuantas más filas -> más redo (para DML

¿Cuál es el tamaño de tus registros de redo?

Saludos cordiales, Michael

Edit: o puedes volcar el redolog a un archivo de rastreo

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

El tamaño del redo se puede encontrar aquí: ktudb redo: siz: 144

Puedes volcar solo partes de un archivo. De todos modos, el volcado será grande y tendrás que agrupar las entradas de alguna manera, para encontrar la causa de tu aumento de redo.

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

Hola Martín,

¡Lo siento, pero eres demasiado modesto! Puede que tengas razón en que técnicamente el número de cambios de bloques no es exactamente el mismo que el espacio de registro de rehacer utilizado. De todas formas, tu consejo fue genial, con la ayuda del script SegmentStatistics_TopSegmentsForStatisticPerAWRInterval.txt pude identificar que en realidad eran ARFCSDATA y ARFCSSTATE los que causaban la alta cantidad de registros de rehacer escritos.

Saludos,

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:             Cambios de Bloque de BD
AGREGADO POR:         INSTANTÁNEA
FINES DE SEMANA EXCLUIDOS:     NO

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

Hola Mark,

Algunos comentarios sobre la Nota SAP 1438410: De hecho, no hay un comando disponible que pueda darte exactamente lo que necesitas. Personalmente, generalmente comenzaría con los siguientes dos comandos de resumen simples:

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

--> Esto devuelve los segmentos principales en términos de bloques cambiados.

2. Segments_Tables_TablesWithTopDMLRate.txt

--> Esto muestra las tablas con la mayor cantidad de operaciones DML (basado en ALL_TAB_MODIFICATIONS).

Sé que ambos no son la verdad absoluta y muchos otros factores también contribuyen, pero para una primera visión general los resultados pueden ser útiles.

Saludos cordiales

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?