MONITOREO DEL RENDIMIENTO EN ORACLE
Monitoreo del Rendimiento
1.Alertas generadas por el servidor
Una de las cosas que este CMI y la infraestructura AWR facilita es la habilidad de las bases de datos de generar alertas en situaciones críticas. En respuestas a estas alertas, la base de datos enviará una alerta al DBA junto a una respuesta sugerida
El proceso MMON se centra en el monitoreo de la base de datos, procesar las alertas de la base de datos, y de dar las respuestas que son desencadenadas por estas acciones. Otros procesos de base de datos pueden detectar problemas al enviar mensajes al MMON para causar que ciertas acciones específicas ocurran, como por ejemplo, enviar un mensaje de alerta.
Tipos de alertas generadas por el servidor:
Oracle10g provee dos tipos de alertas generadas por servidor: threshold y nontreshold. Generalmente pueden ser configuradas vía OEM o procedimientos PL/SQL.
a) Alertas Threshold
Para las alertas Threshold, se puede configurar ambos niveles (peligro y crítico) en un número distinto de métricas, como el tiempo de respuesta del servicio SQL. Las alertas threshold son conocidas como alertas de estado. Cuando una métrica monitoreada está en estado de alerta, puede ser vista en la vista DBA_OUTSTANDING_ALERTS. A continuación se presenta un ejemplo de una alerta que indica que el área flash recovery ha violado una threshold crítica:
select reason, suggested_action
from dba_outstanding_alerts;
REASON
---------------------------------------------------------------
SUGGESTED_ACTION
db_recovery_file_dest_size of 2147483648 bytes is 96.25% used
and has 80545280 remaining bytes available.
Add disk space, backup files to tertiary device, delete files
from recovery area using RMAN or consider changing RMAN retention policy.
Una vez que la alerta ha sido revisada, se mueve a la vista DBA_ALERTA_HISTORY.
b) Alertas Nonthreshol
También conocidas como alertas sin-estado son basadas en eventos, tales como que ocurra un mensaje de error o se suspenda una sesión. Estas alertas son almacenadas en la vista DBA_ALERT_HISTORY. Algunas alertas nonthreshold que son provistas por defecto incluyen:
- Cualquier condición snapshot-too-old
- Cualquier caso en el que el área de flashback recovery cuente con poco espacio disponible.
- Cualquier cas en que la sesión usando espacio resumible es suspendida.
2. Monitor automático de diagnóstico de base de datos (ADDM)
El monitor de diagnóstico automático de base de datos (Automatic Database Diagnostic Monitor, ADDM) analiza data en un repositorio automático de carga de trabajo (Automatic Workload Repository, AWR) para identificar potencial cuellos de botella de rendimiento. Para cada problema identificado localiza la raíz y provee recomendaciones para corregir el problema. Una tarea de análisis ADDM es realizada y sus descrubimientos y recomendaciones son almacenados en la base de datos cada v ez que a un AWR snapshot se le provee del parámetro STATISTIS_LEVEL en TYPICAL u ALL. El análisis ADDM incluye lo siguiente:
- CPU load
- Memory usage
- I/O usage
- Resource intensive SQL
- Resource intensive PL/SQL and Java
- RAC issues
- Application issues
- Database configuration issues
- Concurrency issues
- Object contention
Existen distitnas maneras de producir reportes del análisis ADDM, pero todas siguen un mismo formato. Los problemas encontrados son listados en un orden de potencial impacto en el desempeño de la base de datos, junto a las recomendaciones necesarias para resolver los síntomas que nos llevaron a su descubrimiento. Un ejemplo:
FINDING 1: 59% impact (944 seconds)
-----------------------------------
The buffer cache was undersized causing significant additional read I/O.
RECOMMENDATION 1: DB Configuration, 59% benefit (944 seconds)
ACTION: Increase SGA target size by increasing the value of parameter
"sga_target" by 28 M.
SYMPTOMS THAT LED TO THE FINDING:
Wait class "User I/O" was consuming significant database time. (83% impact [1336 seconds])
Entre las recomendaciones se podría incluir:
- Cambios en el hardware
- Cambios en la configuración de base de datos
- Cambios al esquema
- Cambios en la aplicación
- Usar otro "advisor"
3. Métricas de rendimiento
Siempre existe la necesidad de mostrar información de manera gráfica, bien lo dice el dicho "Un dibujo vale más que mil palabras" , por ende , mostrar un gráfico de comportamiento de algún componente de nuestra base de datos, se agradece mucho más que mostrar información de forma plana.
Para ello nos centraremos en la actividad de las vistas relacionadas a las métricas, disponibles desde Oracle10gr1 en adelante
La vista V$SYSMETRIC muestra la métrica de sistema capturada en un intervalo de 15 y 60 segundos , algunos datos importantes en esta vista
V$SYSMETRIC.BEGIN_TIME : Fecha de inicio del intervalo
V$SYSMETRIC.END_TIME : Fecha de término del intervalo
V$SYSMETRIC.INTSIZE_CSEC : Centésimas de segundo en el intervalo
V$SYSMETRIC.METRIC_NAME : Nombre de la métrica
V$SYSMETRIC.VALUE : Valor de la métrica
V$SYSMETRIC.METRIC_UNIT : Descripción de la unidad de medida, en otras palabras , como se calcula el valor de la métrica
¿Qué otra información es útil como métrica?
La verdad muchas otras, como por ejemplo
- CPU Usage Per Sec
- Disk Sort Per Sec
- Host CPU Utilization (%)
- Leaf Node Splits Per Sec
- Library Cache Hit Ratio
- Memory Sorts Ratio
- PGA Cache Hit %
- Physical Reads Per Sec
- Redo Generated Per Sec
- Soft Parse Ratio
- Etc,etc.
Tipos de métricas:
a) Métricas de usuario
METRIC_NAME METRIC_UNIT
---------------------------------------- -----------------
Average Users Waiting Counts Users
Blocked User Session Count Sessions
PGA Memory (Session) Bytes
b) Métricas de Espera
METRIC_NAME METRIC_UNIT
---------------------------------------- -----------------
Database Time Spent Waiting (%) % (TimeWaited /
Total Time Waited CentiSeconds
Total Wait Counts Waits
Number of Sessions Waiting (Event) Sessions
Total Time Waited CentiSeconds
Total Wait Counts Waits
c) Métricas I/O
METRIC_NAME METRIC_UNIT
---------------------------------------- -----------------
Average File Read Time (Files-Long) CentiSeconds Per Read
Average File Write Time (Files-Long) CentiSeconds Per Write
Physical Block Reads (Files-Long) Blocks
Physical Block Writes (Files-Long) Blocks
Physical Reads (Files-Long) Reads
Physical Writes (Files-Long) Writes
Physical Reads (Session) Reads
Physical Reads Ratio (Sess/Sys) % %
Logical Reads Ratio (Sess/Sys) % %
d) Métricas de CPU
METRIC_NAME METRIC_UNIT
---------------------------------------- ----------------------
CPU Time Per User Call Microseconds Per Call
Elapsed Time Per User Call Microseconds Per Call
CPU Time (Session) CentiSeconds
CPU Usage Per Sec CentiSeconds Per
CPU Usage Per Txn CentiSeconds Per Txn
4. Repositorio automático de carga de trabajo (AWR)
El AWR captura automáticamente los datos del área global del sistema (SGA) en forma de instantáneas cada sesenta minutos. El repositorio almacena la información en el disco durante un período predeterminado de siete días.
Puede modificar la instantánea y los intervalos de retención de la RMA.
Mediante el aumento de los intervalos, puede mejorar las recomendaciones del asesor, y por lo tanto el alcance del análisis estadístico.
Al hacerlo, sin embargo, usted debe considerar el costo del espacio necesario para almacenar las instantáneas y el impacto en el rendimiento de la recolección de la información instantánea.
La RMA tiene cientos de tablas que pertenecen a la SYSMAN esquema, y que se almacenan en el SYSAUX tablas.
Para trabajar con el RMA, se utiliza el Administrador corporativo o el DBMS_WORKLOAD_REPOSITORY paquete. No se puede acceder a la RMA directamente con SQL.