recolectar y usar métricas de referencia

2
RECOLECTAR Y USAR MÉTRICAS DE REFERENCIA RECOLECTAR Y USAR METRICAS DE REFERENCIA USO Y ADMINISTRACIÓN AUTOMATIC WORKLOAD REPOSITORY Las estadísticas de rendimiento y actividad son recopiladas en la memoria y son periódicamente escritas periódicamente al disco por el MMON, en las tablas que componen el AWR. Estas tablas están en el Tablespace SYSAUX. Este conjunto de tablas están relacionadas con el diccionario de datos, pero no son esenciales para el funcionamiento del motor. Las estadísticas recopiladas en memoria, y escritas al disco y conservadas por un tiempo, eventualmente serán sobre escritas con información más reciente. El proceso de recopilación y uso de las estadísticas del AWR y las discutidas anteriormente son totalmente diferentes. RECOPILANDO ESTADÍSTICAS PARA EL AWR El parámetro STATISTICS_LEVEL indica al motor como recopilar las estadísticas, ALL recopila todas las posibles estadísticas, son muy detalladas, TYPICAL, recupera la información suficiente para un buen tuning, por supuesto generando un trabajo adicional sobre el motor, pero no impacta el rendimiento. Sin embargo, BASIC, prácticamente no recopila estadísticas, y en realidad no es que se libere mucho trabajo sobre el motor, es decir no se percibe una ganancia de rendimiento considerable. En anteriores versiones, la forma de ver estas estadísticas, era a través de las vistas dinámicas $, las cuales extraían información de la memoria y le eran presentadas al dba a través de la ejecución de consultas. Ahora, con. Ahora el AWR extrae esta información a disco y lo hace de manera más eficiente. Este proceso de escritura a disco se hace aproximadamente cada hora. - Ejemplo de Estadística (Lecturas a disco), Ejemplo de Métrica (Lecturas a disco x Segundo, X Sesión X transacción, etc) Las métricas se deben monitorear en el tiempo y determinar como están cambiando. Esto hace necesario el uso de Líneas base, una línea base es un conjunto de estadísticas y métricas almacenadas, las cuales pueden ser usadas a través del tiempo. El MMON, además de grabar los snapshots al disco, genera automáticamente gran cantidad de métricas. El proceso de generación de líneas base es una labora manual que debe realizar el DBA. Los snapshots son borrados cada x tiempo (8 dias), toda línea base que se cree asociara snapshots, estos snapshots no serán eliminados hasta tanto no se borren las líneas base explícitamente. Las líneas base se deberían crear para la operación normal, tanto como para los eventos específicos, tales como un cierre de mes. Paquete DBMS_WORKLOAD_REPOSITORY Este paquete es quien en el fondo gestiona todo lo relacionado con las estadísticas del AWR, con el se puede ajustar la frecuencia de grabado de snapshots, la retención de los snapshots o generar un snapshot explícitamente, crear y manipular líneas base y generar reportes de actividad entre dos snapshots. El primer ejemplo crea un snapshot manualmente, este forza al MMON para escribir en disco, la creación de snapshots adhoc generalmente se hace antes y después de lanzar un proceso, de tal forma que se pueda comparar como el proceso impacto el motor. USO DEL ADVISORY FRAMEWORK Las BD por default son configuradas con un conjunto de Advisors. El ADDM genera unos reportes que proporcionan excelente información útil para la solución de muchos problemas, siempre y cuando el AWR exista. Sin embargo, en algunos casos el ADDM recomienda ejecutar algunos advisors, los cuales en algunos casos proporcionan información mucho más detallada que el ADDM. En este momento es importante la existencia de los advisor. AUTOMATIC DATABASE DIAGNOSTIC MONITOR El ADDM es ejecutado automáticamente por el MMON cuando un snapshot es generado. Igual que los Advisor, este toma información del AWR Los reportes del ADDM son almacenados por default por 30 días. Las recomendaciones del ADDM pueden ser: Cambios de Hardware Configuración de la base de datos Cambios en el esquema Cambios en la aplicación Entre otros… (aquí) Memory Advisors: Hacen referencia a los ajustes de las estructuras de memoria para reducir procesamiento y acceso a disco. Si el manejo de la memoria se definió como automático definido el parámetro MEMORY_TARGET, habar un único Advisor para toda la SGA. Página 1 de 2 ORACLE: MANTENIMIENTO PROACTIVO: RECOLECTAR Y USAR MÉTRI... 30/08/2015 http://agutierrezabdmantenimientoproact.blogspot.com.es/2012/06/recolectar-y-usar-...

Upload: alberto-hernandez-hernandez

Post on 10-Dec-2015

214 views

Category:

Documents


0 download

DESCRIPTION

oracle

TRANSCRIPT

Page 1: Recolectar y Usar Métricas de Referencia

RECOLECTAR Y USAR MÉTRICAS DE REFERENCIA

RECOLECTAR Y USAR METRICAS DE REFERENCIA

USO Y ADMINISTRACIÓN AUTOMATIC WORKLOAD REPOSITORY

Las estadísticas de rendimiento y actividad son recopiladas en la memoria y son periódicamente escritas periódicamente al disco por el MMON,

en las tablas que componen el AWR. Estas tablas están en el Tablespace SYSAUX.

Este conjunto de tablas están relacionadas con el diccionario de datos, pero no son esenciales para el funcionamiento del motor.

Las estadísticas recopiladas en memoria, y escritas al disco y conservadas por un tiempo, eventualmente serán sobre escritas con información

más reciente. El proceso de recopilación y uso de las estadísticas del AWR y las discutidas anteriormente son totalmente diferentes.

RECOPILANDO ESTADÍSTICAS PARA EL AWR

El parámetro STATISTICS_LEVEL indica al motor como recopilar las estadísticas, ALL recopila todas las posibles estadísticas, son muy

detalladas, TYPICAL, recupera la información suficiente para un buen tuning, por supuesto generando un trabajo adicional sobre el motor, pero

no impacta el rendimiento. Sin embargo, BASIC, prácticamente no recopila estadísticas, y en realidad no es que se libere mucho trabajo sobre el

motor, es decir no se percibe una ganancia de rendimiento considerable. En anteriores versiones, la forma de ver estas estadísticas, era a través

de las vistas dinámicas $, las cuales extraían información de la memoria y le eran presentadas al dba a través de la ejecución de consultas. Ahora,

con. Ahora el AWR extrae esta información a disco y lo hace de manera más eficiente. Este proceso de escritura a disco se hace

aproximadamente cada hora.

- Ejemplo de Estadística (Lecturas a disco), Ejemplo de Métrica (Lecturas a disco x Segundo, X Sesión X transacción, etc)

Las métricas se deben monitorear en el tiempo y determinar como están cambiando.

Esto hace necesario el uso de Líneas base, una línea base es un conjunto de estadísticas y métricas almacenadas, las cuales pueden ser usadas a

través del tiempo.

El MMON, además de grabar los snapshots al disco, genera automáticamente gran cantidad de métricas. El proceso de generación de líneas base

es una labora manual que debe realizar el DBA.

Los snapshots son borrados cada x tiempo (8 dias), toda línea base que se cree asociara snapshots, estos snapshots no serán eliminados hasta

tanto no se borren las líneas base explícitamente.

Las líneas base se deberían crear para la operación normal, tanto como para los eventos específicos, tales como un cierre de mes.

Paquete DBMS_WORKLOAD_REPOSITORY

Este paquete es quien en el fondo gestiona todo lo relacionado con las estadísticas del AWR, con el se puede ajustar la frecuencia de grabado de

snapshots, la retención de los snapshots o generar un snapshot explícitamente, crear y manipular líneas base y generar reportes de actividad entre

dos snapshots.

El primer ejemplo crea un snapshot manualmente, este forza al MMON para escribir en disco, la creación de snapshots adhoc generalmente se

hace antes y después de lanzar un proceso, de tal forma que se pueda comparar como el proceso impacto el motor.

USO DEL ADVISORY FRAMEWORK

Las BD por default son configuradas con un conjunto de Advisors.

El ADDM genera unos reportes que proporcionan excelente información útil para la solución de muchos problemas, siempre y cuando el AWR

exista. Sin embargo, en algunos casos el ADDM recomienda ejecutar algunos advisors, los cuales en algunos casos proporcionan información

mucho más detallada que el ADDM.

En este momento es importante la existencia de los advisor.

AUTOMATIC DATABASE DIAGNOSTIC MONITOR

El ADDM es ejecutado automáticamente por el MMON cuando un snapshot es generado.

Igual que los Advisor, este toma información del AWR

Los reportes del ADDM son almacenados por default por 30 días.

Las recomendaciones del ADDM pueden ser:

• Cambios de Hardware

• Configuración de la base de datos

• Cambios en el esquema

• Cambios en la aplicación

• Entre otros… (aquí)

Memory Advisors: Hacen referencia a los ajustes de las estructuras de memoria para reducir procesamiento y acceso a disco. Si el manejo de la

memoria se definió como automático definido el parámetro MEMORY_TARGET, habar un único Advisor para toda la SGA.

Página 1 de 2ORACLE: MANTENIMIENTO PROACTIVO: RECOLECTAR Y USAR MÉTRI...

30/08/2015http://agutierrezabdmantenimientoproact.blogspot.com.es/2012/06/recolectar-y-usar-...

Page 2: Recolectar y Usar Métricas de Referencia

SQL ADVISORS: EXISTEN 3 SQL ADVISORS

SQL Access Advisor: Monitorea la carga de trabajo de las sentencias SQL y hace recomendaciones referentes a los segmentos que harían que el

trabajo se ejecutara mas rápido. La carga de trabajo puede ser hipotética o real, de acuerdo a las sentencias SQL que se estén ejecutando durante

cierto periodo de tiempo. Las recomendaciones pueden ser crear o borrar índices, vistas materializadas, o hacer uso del particionamiento.

SQL Tuning Advisor: Analiza individualmente las sentencias SQL y hace recomendaciones como las del SQL ACCESS ADVISOR, puede

recomendar obtener mas estadísticas sobre la sentencia SQL que le permitan al optimizador generar un mejor plan de ejecución, o sobre escribir

la sentencia para que sea más eficiente.

SQL Repair Advisor: Algunas sentencias pueden fallar en la ejecución cuando siguen determinado plan de ejecución, esto es reportado como un

error ORA-600, Este consejero puede generar un parche para la sentencia el cual forzara a que la sentencia utilice un diferente plan de ejecución,

en cambio del plan de ejecución que tiene el problema.

AUTOMATIC UNDO ADVISOR

Recomienda tamaños para el UNDO Tablespace de acuerdo a la cantidad de UNDO generado y los tiempos de las consultas largas.

Mean Time to Recover:

Estima cuando tiempo se tardaría un Crash recovery de la base de datos. El realizado por el SMON.

Data Recovery Advisor: En el evento de daño de datafiels o bloques, el DBA debe tomarse su tiempo para determinar exactamente el problema.

Este Advisor asiste al DBA en estos procesos.

SEGMENT ADVISOR

Los segmentos crecen automáticamente, de acuerdo a como va ingresando información a la base de datos, oracle adiciona extents, los llena y

luego agrega más, sin embargo, Los segmentos no son unidos (shrink) automáticamente cuando se ejecutan deletes o updates. Esto solo sucede

cuando el segmento es explícitamente reorganizado. Este Advisor monitorea tablas e índices. Hace recomendaciones de acuerdo a la

reorganización que sea necesaria.

AUTOMATIC MAINTENANCE JOBS

Para que la base de datos corra bien, es necesario que el optimizador obtenga información exacta de las estadísticas de los objetos; que las tablas

e índices esté operando eficientemente si una cantidad de espacio desperdiciado o fragmentado y que las sentencias SQL estén afinadas.

Por default, existen tres tareas configuradas como Jobs, se montan en la creación de la base de datos con el DBCA, son denominadas

AUTOTASKS, estas son ejecutadas por el Scheduler (Introducido en 10g), estas son:

• Obtener estadísticas para el optimizador

• Ejecutar el Segment Advisor

• Ejecutar el SQL Advisor

Estas auto tareas se ejecutan dentro del Scheduler en la ventana de manteniemto (Anteriormente definimos cuales son los tiempos de las

ventanas de mantenimiento).

EL SCHEDULER es vinculado con otra facilidad de la base de datos, la cual se denomina Resource Manager. Este asegura que no mas del 25%

de los recursos de la maquina sean asociados a estas ventanas de mantenimiento.

Para que las autotareas se ejecuten el parámetro STATISTICS_LEVEL deberá estar definido en TYPICAL o ALL.

Página 2 de 2ORACLE: MANTENIMIENTO PROACTIVO: RECOLECTAR Y USAR MÉTRI...

30/08/2015http://agutierrezabdmantenimientoproact.blogspot.com.es/2012/06/recolectar-y-usar-...