MANTENIMIENTO DE LA BASE DE DATOS ORACLE

El rendimiento de las sentencias SQL depende en gran medida de las estadísticas que el optimizador tenga. Estas son usadas para la generación de apropiados planes de ejecución.

La recolección de estadísticas puede ser manual o automática.

El monitoreo del rendimiento puede ser pro-activo o re-activo

En 11g el uso de los diagnostic advisors libera al DBA de mucho trabajo manual

Uso y administración de las estadísticas del optimizador

La elección del plan de ejecución es crítica para el rendimiento

El plan de ejecución se arma dinámicamente por el optimizador, el cual confía totalmente en las estadísticas.

Las estadísticas más importantes son las de los objetos. Las estadísticas solo mejoran el rendimiento de los SQL no de los PL/SQL.

Las estadísticas se ven en la vista DBA_TABLES, incluyen:

El numero de registros en la tabla, El número de bloques (usados y no usados) asignados a la tabla, la cantidad de espacio

libre en los bloques que están siendo usados, la longitud promedio del registro, el numero de registros encadenados. Los registros encadenados se dan por que el registro es muy largo o porque los

parámetros del almacenamiento son muy bajos.Además de estadísticas a nivel de tabla, existen estadísticas a nivel de columna (DBA_TAB_COLUMNS), incluyen:

El numero de valores distintos El mayor y menor valor El numero de Nulos La longitud promedio del registro

Cuando una tabla es analizada, también los índices son examinados, las estadísticas de los índices se ven en DBA_INDEXES, incluyen:

La profundidad del árbol del índice El número de valores distintos El Clustering factor – Que tan cerca esta el orden natural de los registros respecto al

orden de los registros en el IndiceEstas estadísticas son vitales para que Oracle sepa como ejecutar las sentencias. Si no son exactas, el rendimiento se vera deteriorado dramáticamente.

También es posible obtener estadísticas explícitamente sobre los índices, estas estadísticas se podrán ver en INDEX_STATS, incluyen:

El numero de entradas en el índice referentes a los registros de la tabla El número de entradas en el índice referentes a registros borrados

Cuando un registro se borra, se conserva la clave de dicho registro en los índices, después de un tiempo, si tenemos muchas entradas de índice correspondientes a registros borrados el performance se deteriorara.

Generando estadísticas Manualmente

Las estadísticas no se general en Línea

Es necesario generarlas regularmente, de tal forma que el optimizador tenga acceso a estadísticas que correspondan al estado actual de la base de datos.

Las estadísticas pueden generarse manualmente, o se puede automatizar el proceso, se puede utilizar el comando ANALYZE o el paquete DBMS_STATS,  o a través del “Database Control”.

El uso de COMPUTE STATISCS indica a oracle que analize toda la tabla.

La instrucción ANALYZE es fácil de usar, sin embargo el paquete DBMS_STATS tiene mas opciones, de hecho, es la herramienta recomendada.

Si las estadísticas se dejan de actualizar por un perido de tiempo largo, entonces diferirán mucho del estado de la base de datos y por consecuente, los planes de ejecución generados por el optimizador no serán los apropiados.

Sin estadísticas, el performances es malo, pero el proceso de generación de estadísticas impacta el rendimiento de la BD, lo cual nos obliga a preguntarlos las siguientes dos coas:

Que tan frecuentemente deben ser generadas las estadísticas. Que porción del objeto debe ser analizado para tener la foto más exacta del mismo.

Por defecto, durante la creación de la base de datos con el DBCA, las estadísticas son configuradas para generarse automáticamente a través de un Job administrado por el Scheduler, los parámetros usados son:

OWNAME: Especifica el esquema que será analizado

CASCADE: Analizara los índices también, además de las tablas por supuesto, este parámetro permitirá a Oracle determinar que índices deberán ser analizados (Si alguno debe ser analizado).

ESTIMATE_PERCENT: Controla la cantidad de la tabla que deberá ser analizada. El parámetro permitirá a Oracle decidir inteligentemente una cantidad significativa para analizar el objeto.

DEGREE: Especifica si el análisis se analizara con paralelismo. Oracle determinara la cantidad de  procesos paralelos de acuerdo a el ambiente y a el tamaño de la tabla.

NO_INVALIDATE: Determina si se deben reparsear todos los SQL con dependencias sobre el objeto analizado. Este parámetro permitirá a Oracle decidir.

GRANULARITY: Se refiere a como el objeto será analizado de acuerdo a la cantidad de sub objetos, por ejemplo, por ejemplo cuando la tabla tiene particionamiento.

METHOD_OPT: Controla la cantidad de histogramas que deberán construirse o cuantos cubos deberán tener. El parámetro permite a oracle decidir de acuerdo al la sentencia SQL que este siendo ejecutada y la distribución de los datos.

OPTIONS: Determina que objetos analizar. Este parámetro indica a Oracle que analice todos los objetos que Oracle considere que tienen las estadísticas que estén desactualizadas.

Bien sea que el procedimiento DBMS_STATS se esté usando desde SQL, o desde el Database Control, hay opciones para analizar tablas e índices individualmente, esquemas completos, o bases de datos completas. Esto a través de los parámetros que pueden ser pasados a los argumentos del procedimiento.

El proceso de generación de estadísticas configurado por el DBCA durante la creación dela base de datos generara las estadísticas todos los días de la ventana de mantemiento. La ventana de mantemiento se ejecuta todos los días de la semana durante 4 horas, iniciando a las 22:00. Tambien se ejecutara por el una ventana de mantemiento  de 20 horas inciando el sábado y el domingo a las 6AM. Normalmente, solo una pequeña cantidad de estas horas son usadas. Normalmente una base de datos funcionara correctamente con las estadísticas generadas por el procedimiento automático, eliminando la necesidad de eliminar las estadísticas manualmente.

El parámetro de la instancia STATISTICS_LEVEL: Este parámetro tiene 3 parámetros posibles. Este parámetro controla el proceso automático de recopilación de estadísticas en dos niveles, unas son las estadísticas acumuladas dentro de la instancia de acuerdo a la actividad, y los otras son las estadísticas de los objetos dentro de la base de datos. (Estadísticas de Instancia – Estadísticas de Objetos).

Las estadísticas de la Instancia son acumuladas en memoria y posteriormente escritas en el AWR por el proceso de fondo MMON (Manageability Monitor).

Las estadísticas de los objetos son recopiladas a través del análisis de los objetos con el procedimiento DBMS_STATS.

BASIC: Des-habilita la autorecopilacion de las estadísticas para el AWR y deshabilita el análisis diario.

TYPICAL: Recopilara las estadísticas para la base de datos y también habilitara la recopilación diaria de estadísticas de los objetos durante las ventanas de mantenimiento.

ALL: Recopila todas las estadísticas posibles. Esto incluye actividad del sistema operativo, información detallada de las sentencias SQL ejecutadas

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 dinamicas $, 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 mas eficiente. Este proceso de escritura a disco se hace aproximadamente cada hora.

Es importante tener en cuenta el uso de paquetes de Tuning de terceros, ya que ningún paquete de terceros tendrá acceso a la memoria (isntancia oracle) tal como lo puede hacer el MMON. El MMON puede bajar la información de la memoria al disco sin necesidad de tener una sesión. El único overead es escribir el snapshot de la memoria al disco. (cada Hora)

Las tablas del AWR estan en el esquema SYSMAN y en el tablespace SYSAUX, no pueden ser reubicadas.

Es posible conectarse a la base de datos con el usuarios SYSMAN, sin embargo, oracle no ofrece soporte para acceder las tablas del AWR, únicamente a través de los paquetes DBMS.

La forma mas sencilla es acceder el AWR a través del EM.

Teniendo en cuenta el el EM accede al esquema de SYSMAN, y este tiene las claves encriptadas en un archivo, el cambiar el password al SYSMAN hara que el EM no pueda acceder, por lo tanto, será necesario lanzar el comando emctl setpasswd console para que podamos seguir teniendo el acceso.

Es importante tener presente que el snapshot del AWR no se arma consultando vistas del diccionario, se hace accediendo directamente las estructuras de memoria que conforman la instancia.

Sin el AWR no se tendrá historia de cómo los objetos han venido cambiando, el histórico de cambios de los objetos no se puede obtener con el DBMS_STATS, solo el AWR puede suministrarnos esto.

Administrando el AWR

Por defecto las estadísticas del AWR son conservadas en disco por 8 dias, este periodo es configurable.

Una idea para el dimensionamiento, si el snapshot es escrito cada hora y el tiempo de retención esta definido en 8 días entonces el AWR necesitara entre 200 y 300 MB de espacio en el tablespace SYSAUX.

Esta medida es altamente variable, y dependerá de la cantidad de sesiones.

Parametros Clave: STATISTICS_LEVEL, RETENTION TIME, INTERVAL

Es importante monitorear:

El crecimiento del tablespace SYSAUX    à Alertas del systema El contenido del AWR                                     à V$SYSAUX_OCCUPANTS

Estadísticas, métricas y líneas base

El AWR contiene estadísticas. Lo que Oracle llama estadísticas es una figura, la cual tiene sentido para si misma, para ser utiles, las estadísticas deben ser convertidas en métricas. Una métrica corresponde a la correlacion de dos o mas estadísticas.

Ejemplo de Estadistica (Lecturas a disco), Ejemplo de Metrica (Lecturas a disco x Segundo, X Sesion X transacción, etc)

Las métricas se deben monitorear en el tiempo y determinar como estan cambiando.

Esto hace necesario el uso de Lineas 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 es configurada con un conjunto de Advisors.

El ADDM genera unos reportes que porporcionana excelenten información útil para la solución de muchso 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 mas 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 dias.

Las recomendaciones del ADDM pueden ser:

Cambios de Hardware Configuracion 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.

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 mas, 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 este 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.

Alerts and Thresholds

Por el sistema de alertas, es que podemos decir que desde Oracle 10g, el motor es auto-administrado, en versiones anteriores el DBA debía gastar una gran cantidad de tiempo imaginando posibles escenarios que pudieran ocurrir.

Las alertas son de dos formas:

Stateful: Son alertas basadas en condiciones que pueden ser fijas y persistentes en el tiempo, por ej. El uso de un tablespace o la cantidad de sesiones, o la cantidad de tiempo promedio para completar la ejecución de una sentencia SQL.

Stateless: Son alertas basadas en eventos, eventos que pasan y se van. Por Ej: un query que falla por Snapshot to old o un deadlock entre dos transacciones.

Para configurar las alertas, se deben definir Umbrales (Thresholds), los thresholds son almacenados en el AWR. EL MMON monitorea la instancia de la base de datos y compara en línea el estado contra los thresholds, si un Threshold se cumple, entonces se genera la alerta. La alerta se monta en una cola, la cual es desencola por el Enterprise manager quien presentara las alertas en una pagina, pero el EM puede ser configurado para que las envié via e-mail o sms. Tambien se pueden consultar las alertas en la vista DBA_OUTSTANDING_ALERTS. También es posible escribir un manejador de alertas que desencole las alertas y ejecute las acciones que el DBA considere.

Definición de Thresholds

Existen alrededor de 200 metricas sobre las cuales se pueden definir alertas, estan documentadas en la vista v$metricname, la cual informa el nombre y la unidad en la cual es medida asi como el Id con el cual es identificada. Existe un API, el paquete DBMS_SERVER_ALERT, con el cual se definen thresholds. (Pag 500)

Descripcion de cada línea:

1. Procedimiento Set_Threshold, crea o actualiza un thershold.2. La métrica es la cantidad de redo generado por segundo en bytes.3. El operador que se usa para la comparación en el Warning.4. La cantidad utilizada para la comparación en el warning.5. El operador que se usa para la comparación el el Critical Alert6. La cantidad utilizada para la comparación en el Crtitical Alert7. El periodo de observación, en minutos8. El numero de ocurrencias consecutivas antes de la generación de la alerta.9. La instancia para la cual la alerta esta siendo configurada.10.El tipo de objeto al cual la alerta se refiere.11.El nombre del objeto al cual la alerta se refiere.

Para definirlas por el EM, vaya a metric and policy.

Notification System

El mecanismo por defecto para la notificación de las alertas Stateful es nada mas que mostar la alerta en el Enterprise manager, y escribir la alerta en la vista DBA_OUTSTANDING_ALERTS. Esta permanecerá visible hasta que ella sea limpiada. Esta puede ser limpiada porque el DBA ha solucionado el problema o en algunos casos porque el problema se fue con el curso natural de los enventos.

Cuando una alerta es limpiada, dentro de la base de datos esta es eliminada de DBA_OUTSTANDING_ALERT y es registrada en DBA_ALERT_HISTORY.

Las alertas stateless van directo a la vista de histórico.

Se pueden usar procedimientos almacenados como métodos de notificación.