MANTENIMIENTO DE LA BASE DE DATOS ORACLE

El rendimiento de las sentencias SQL depende en gran medida de las estadsticas que el optimizador
tenga. Estas son usadas para la generacin de apropiados planes de ejecucin.
La recoleccin de estadsticas puede ser manual o automtica.
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 administracin de las estadsticas del optimizador
La eleccin del plan de ejecucin es crtica para el rendimiento
El plan de ejecucin se arma dinmicamente por el optimizador, el cual confa totalmente en las
estadsticas.
Las estadsticas ms importantes son las de los objetos. Las estadsticas solo mejoran el rendimiento
de los SQL no de los PL/SQL.
Las estadsticas se ven en la vista DBA_TABLES, incluyen:

El numero de registros en la tabla,

El nmero de bloques (usados y no usados) asignados a la tabla, la cantidad de espacio
libre en los bloques que estn 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
parmetros del almacenamiento son muy bajos.
Adems de estadsticas a nivel de tabla, existen estadsticas 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, tambin los ndices son examinados, las estadsticas de los ndices se
ven en DBA_INDEXES, incluyen:

La profundidad del rbol del ndice

El nmero de valores distintos
El Clustering factor Que tan cerca esta el orden natural de los registros respecto al
orden de los registros en el Indice
Estas estadsticas son vitales para que Oracle sepa como ejecutar las sentencias. Si no son exactas, el
rendimiento se vera deteriorado dramticamente.
Tambin es posible obtener estadsticas explcitamente sobre los ndices, estas estadsticas se podrn
ver en INDEX_STATS, incluyen:

El numero de entradas en el ndice referentes a los registros de la tabla


El nmero de entradas en el ndice referentes a registros borrados
Cuando un registro se borra, se conserva la clave de dicho registro en los ndices, despus de un
tiempo, si tenemos muchas entradas de ndice correspondientes a registros borrados el performance
se deteriorara.
Generando estadsticas Manualmente
Las estadsticas no se general en Lnea
Es necesario generarlas regularmente, de tal forma que el optimizador tenga acceso a estadsticas que
correspondan al estado actual de la base de datos.
Las estadsticas pueden generarse manualmente, o se puede automatizar el proceso, se puede utilizar
el comando ANALYZE o el paquete DBMS_STATS, o a travs del Database Control.
El uso de COMPUTE STATISCS indica a oracle que analize toda la tabla.
La instruccin ANALYZE es fcil de usar, sin embargo el paquete DBMS_STATS tiene mas opciones, de
hecho, es la herramienta recomendada.
Si las estadsticas se dejan de actualizar por un perido de tiempo largo, entonces diferirn mucho del
estado de la base de datos y por consecuente, los planes de ejecucin generados por el optimizador
no sern los apropiados.
Sin estadsticas, el performances es malo, pero el proceso de generacin de estadsticas impacta el
rendimiento de la BD, lo cual nos obliga a preguntarlos las siguientes dos coas:

Que tan frecuentemente deben ser generadas las estadsticas.

Que porcin del objeto debe ser analizado para tener la foto ms exacta del mismo.
Por defecto, durante la creacin de la base de datos con el DBCA, las estadsticas son configuradas
para generarse automticamente a travs de un Job administrado por el Scheduler, los parmetros
usados son:
OWNAME: Especifica el esquema que ser analizado
CASCADE: Analizara los ndices tambin, adems de las tablas por supuesto, este parmetro permitir
a Oracle determinar que ndices debern ser analizados (Si alguno debe ser analizado).
ESTIMATE_PERCENT: Controla la cantidad de la tabla que deber ser analizada. El parmetro permitir
a Oracle decidir inteligentemente una cantidad significativa para analizar el objeto.
DEGREE: Especifica si el anlisis se analizara con paralelismo. Oracle determinara la cantidad de
procesos paralelos de acuerdo a el ambiente y a el tamao de la tabla.
NO_INVALIDATE: Determina si se deben reparsear todos los SQL con dependencias sobre el objeto
analizado. Este parmetro 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 debern construirse o cuantos cubos debern
tener. El parmetro permite a oracle decidir de acuerdo al la sentencia SQL que este siendo ejecutada
y la distribucin de los datos.
OPTIONS: Determina que objetos analizar. Este parmetro indica a Oracle que analice todos los
objetos que Oracle considere que tienen las estadsticas que estn 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 travs de los parmetros que pueden ser pasados a los argumentos del
procedimiento.
El proceso de generacin de estadsticas configurado por el DBCA durante la creacin dela base de
datos generara las estadsticas todos los das de la ventana de mantemiento. La ventana de
mantemiento se ejecuta todos los das 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 sbado y el domingo a las
6AM. Normalmente, solo una pequea cantidad de estas horas son usadas. Normalmente una base de
datos funcionara correctamente con las estadsticas generadas por el procedimiento automtico,
eliminando la necesidad de eliminar las estadsticas manualmente.
El parmetro de la instancia STATISTICS_LEVEL: Este parmetro tiene 3 parmetros posibles.
Este parmetro controla el proceso automtico de recopilacin de estadsticas en dos niveles, unas son
las estadsticas acumuladas dentro de la instancia de acuerdo a la actividad, y los otras son las
estadsticas de los objetos dentro de la base de datos. (Estadsticas de Instancia Estadsticas de
Objetos).
Las estadsticas de la Instancia son acumuladas en memoria y posteriormente escritas en el AWR por
el proceso de fondo MMON (Manageability Monitor).
Las estadsticas de los objetos son recopiladas a travs del anlisis de los objetos con el procedimiento
DBMS_STATS.
BASIC: Des-habilita la autorecopilacion de las estadsticas para el AWR y deshabilita el anlisis diario.
TYPICAL: Recopilara las estadsticas para la base de datos y tambin habilitara la recopilacin diaria de
estadsticas de los objetos durante las ventanas de mantenimiento.
ALL: Recopila todas las estadsticas posibles. Esto incluye actividad del sistema operativo, informacin
detallada de las sentencias SQL ejecutadas
Uso y administracin Automatic Workload Repository
Las estadsticas de rendimiento y actividad son recopiladas en la memoria y son peridicamente
escritas peridicamente al disco por el MMON, en las tablas que componen el AWR. Estas tablas estn
en el Tablespace SYSAUX.
Este conjunto de tablas estn relacionadas con el diccionario de datos, pero no son esenciales para el
funcionamiento del motor.
Las estadsticas recopiladas en memoria, y escritas al disco y conservadas por un tiempo,
eventualmente sern sobre escritas con informacin ms reciente. El proceso de recopilacin y uso de
las estadsticas del AWR y las discutidas anteriormente son totalmente diferentes.

Recopilando estadsticas para el AWR

El parmetro STATISTICS_LEVEL indica al motor como recopilar las estadsticas, ALL recopila todas las
posibles estadsticas, son muy detalladas, TYPICAL, recupera la informacin suficiente para un buen
tuning, por supuesto generando un trabajo adicional sobre el motor, pero no impacta el rendimiento.
Sin embargo, BASIC, prcticamente no recopila estadsticas, 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 estadsticas, era a travs de las vistas dinamicas $, las cuales
extraan informacin de la memoria y le eran presentadas al dba a travs de la ejecucin de consultas.
Ahora, con . Ahora el AWR extrae esta informacin 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 ningn paquete de
terceros tendr acceso a la memoria (isntancia oracle) tal como lo puede hacer el MMON. El MMON
puede bajar la informacin de la memoria al disco sin necesidad de tener una sesin. 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 travs de los paquetes DBMS.
La forma mas sencilla es acceder el AWR a travs 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 cmo los objetos han venido cambiando, el histrico 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 estadsticas 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 retencin esta
definido en 8 das 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

El contenido del AWR

Alertas del systema

V$SYSAUX_OCCUPANTS

Estadsticas, mtricas y lneas base

El AWR contiene estadsticas. Lo que Oracle llama estadsticas es una figura, la cual tiene sentido para
si misma, para ser utiles, las estadsticas deben ser convertidas en mtricas. Una mtrica corresponde
a la correlacion de dos o mas estadsticas.
Ejemplo de Estadistica (Lecturas a disco), Ejemplo de Metrica (Lecturas a disco x Segundo, X Sesion X
transaccin, etc)
Las mtricas se deben monitorear en el tiempo y determinar como estan cambiando.
Esto hace necesario el uso de Lineas base, una lnea base es un conjunto de estadsticas y mtricas
almacenadas, las cuales pueden ser usadas a travs del tiempo.
El MMON, adems de grabar los snapshots al disco, genera automticamente gran cantidad de
mtricas. El proceso de generacin de lneas base es una labora manual que debe realizar el DBA.
Los snapshots son borrados cada x tiempo (8 dias), toda lnea base que se cree asociara snapshots,
estos snapshots no sern eliminados hasta tanto no se borren las lneas base explcitamente.
Las lneas base se deberan crear para la operacin normal, tanto como para los eventos especficos,
tales como un cierre de mes.
Paquete DBMS_WORKLOAD_REPOSITORY
Este paquete es quien en el fondo gestiona todo lo relacionado con las estadsticas del AWR, con el se
puede ajustar la frecuencia de grabado de snapshots, la retencin de los snapshots o generar un
snapshot explcitamente, crear y manipular lneas 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
creacin de snapshots adhoc generalmente se hace antes y despus 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 informacin til para la solucin 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 informacin mucho
mas detallada que el ADDM.
En este momento es importante la existencia de los advisor.
Automatic Database Diagnostic Monitor
El ADDM es ejecutado automticamente por el MMON cuando un snapshot es generado.
Igual que los Advisor, este toma informacin 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 aplicacin

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 automtico definido el
parmetro 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 haran que el trabajo se ejecutara mas rpido. La carga de trabajo
puede ser hipottica o real, de acuerdo a las sentencias SQL que se estn 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 estadsticas sobre la sentencia SQL que le
permitan al optimizador generar un mejor plan de ejecucin, o sobre escribir la sentencia para que sea
ms eficiente.
SQL Repair Advisor: Algunas sentencias pueden fallar en la ejecucin cuando siguen determinado
plan de ejecucin, 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 ejecucin, en cambio
del plan de ejecucin que tiene el problema.
Automatic UNDO Advisor
Recomienda tamaos 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 tardara un Crash recovery de la base de datos. El realizado por el SMON.
Data Recovery Advisor: En el evento de dao 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 automticamente, de acuerdo a como va ingresando informacin a la base de
datos, oracle adiciona extents, los llena y luego agrega mas, sin embargo, Los segmentos no son
unidos (shrink) automticamente cuando se ejecutan deletes o updates. Esto solo sucede cuando el
segmento es explcitamente reorganizado. Este Advisor monitorea tablas e ndices. Hace
recomendaciones de acuerdo a la reorganizacin que sea necesaria.
Automatic Maintenance Jobs

Para que la base de datos corra bien, es necesario que el optimizador obtenga informacin exacta de
las estadsticas de los objetos; que las tablas e ndices este operando eficientemente si una cantidad
de espacio desperdiciado o fragmentado y que las sentencias SQL estn afinadas.
Por default, existen tres tareas configuradas como Jobs, se montan en la creacin de la base de datos
con el DBCA, son denominadas AUTOTASKS, estas son ejecutadas por el Scheduler (Introducido en
10g), estas son:

Obtener estadsticas 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 parmetro 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 deba 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
ejecucin 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 lnea 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. Tambin es posible escribir un manejador de alertas que
desencole las alertas y ejecute las acciones que el DBA considere.
Definicin 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 lnea:

1. Procedimiento Set_Threshold, crea o actualiza un thershold.

2. La mtrica es la cantidad de redo generado por segundo en bytes.
3. El operador que se usa para la comparacin en el Warning.
4. La cantidad utilizada para la comparacin en el warning.
5. El operador que se usa para la comparacin el el Critical Alert
6. La cantidad utilizada para la comparacin en el Crtitical Alert
7. El periodo de observacin, en minutos
8. El numero de ocurrencias consecutivas antes de la generacin 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 notificacin 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 histrico.
Se pueden usar procedimientos almacenados como mtodos de notificacin.