Plan de acción para estabilización

y afinamiento de bases de datos

Oracle
Elaborado por: Henry Niño – Senior DBA Consultant
Fecha: lunes, 06 de octubre de 2003

El presente documento busca presentar un plan de acción en 4 fases que permita

llevar a las bases de datos Oracle a un punto de operación aceptable. El plan está
basado en las mejores prácticas de administración de bases de datos Oracle. Este
plan podrá tener cambios de acuerdo a la plataforma sobre la cual se está
trabajando.

Algunas acciones podrán ser agregadas dependiendo las necesidades,

características y productos instalados.

Fase 1:

Esta base permite obtener información y realizar ajustes en el producto instalado y

las configuraciones sobre las cuales se espera que funcione adecuadamente.

•Verificar que el producto es compatible de acuerdo a la matriz de

compatibilidad
•Realizar inspección de archivos de alerta, listener, tnsnames, traces
•Realizar inspección de espacio libre suficiente a nivel de tablespaces y
sistema de archivos
• Si la base de datos es sobre Windows optimizar el uso de recursos cd CPU
para Servicios en segundo plano y memoria para caché de sistema
•Si la base de datos es sobre Windows deshabilitar indexing service y excluir
del chequeo de antivirus los directorios de datafiles, redologs, tempfiles,
archivelogs y undo.
•Si la base de datos es sobre HP-UX disminuir el uso de filesystem buffer
cache según configuración del sistema operativo (tunables)
•Seleccionar el subsistema de I/O directo o asíncrono
•Instalar oswatcher

Verificar el comportamiento durante 2 días

Fase 2:

Busca llevar a cabo labores estándar y predecibles que impactan positivamente el

desempeño de la base de datos sin causar indisponibilidad. Esta fase es necesaria
para aislar problemas de origen secundario, por ejemplo demora en CPU ocasionada
por disco debido a la estructura de una tabla. Cubre aspectos de memoria y IO.

•Ajustar parámetros de instancia (memoria, uso de cursores, procesos,

sesiones)
•Llevar a la memoria tablas candidatas a cache
•Llevar a la shared pool unidades de programa candidatos
•Migrar y reparar las filas encadenadas o migradas
 •Reconstruir y cambiar parámetros para índices de fragmentación frecuente
•Reconstruir índices con niveles de fragmentación superior al 20% o blevel >
2
•Colocar algunas tablas en modo nologging con sus respectivos índices
•Separar tablas con índices que están en el mismo tablespace
•Cambiar parámetros para recolección de estadísticas de esquemas y tomar
estadísticas prioritarias
•Definir tablespaces especiales para segmentos con demasiados extents

Monitorear 4 días

Para gestión de las áreas de desarrollo del cliente y sus proveedores de

aplicación se envía un listado de acciones de mejora que tienen incidencia
en dos niveles:

Estético-Funcional:

•Revisar y corregir objetos descompilados

•Eliminar o redefinir sinónimos que apuntan a objetos inexistentes
•Autorizar limpieza de la papelera de reciclaje de la base de datos
•Activar o eliminar jobs rotos
•Analizar solapamiento de jobs
•Eliminar o redefinir dblinks no funcionales

Performance:

•Analizar y redefinir campos de llaves foráneas con tipo de dato

distinto
•Eliminar o redefinir índices similares o redundantes
•Identificar tablas sobreindexadas, monitorear y eliminar índices en
desuso
•Evaluar la creación índices en las llaves foráneas según estadísticas
de IO y movimiento de los datos en la tabla padre
•Evaluar DML y rediseño sobre tablas con más de 180 campos
•Evaluar el diseño de tablas cuyo tamaño de fila es mayor al tamaño
del bloque

El monitoreo deberá ser constante y los cambios realizados por las áreas de
desarrollo del cliente o su proveedor de aplicación deberán ser progresivos y
homogéneos

Fase 3:

El objetivo de esta fase es llevar a cabo las acciones necesarias para corregir los
problemas que se sigan presentando tras la ejecución de la fase 1.
Mayoritariamente cubre aspectos de IO y puede generar intermitencia aislada a
nivel de segmento o datafile, por ejemplo: al mover una tabla puede que los
usuarios tengan que esperar mientras se reconstruyen sus índices

•Ubicar los objetos con altos valores de buffer busy waits en un tablespace
especial con su pool de memoria respectivo (tener en cuenta que esto no
podrá aplicarse a Windows de 32 Bit con AWE)
•Hacer balanceo de IO a nivel de segmento
•Multiplexar UNDO
•Redimensionar parámetros de almacenamiento de tablas que tienen
tamaño de fila mayor al tamaño de bloque
 •Realizar recomendaciones para índices de baja selectividad e índices que
podrían ser de tipo función, reversos o bitmap (tener en cuenta
licenciamiento EE para estos últimos)
•Enviar a las áreas de desarrollo del cliente y sus proveedores de aplicación
los SQL que continúan con alto costo tras la implementación de la fase 2.

Fase 4:

Esta fase va al detalle de situaciones específicas, podrían no generar

indisponibilidad en su mayoría y se basa en los casos residuales que aún persisten
tras la implementación de las dos fases anteriores.

•Identificar segmentos de alta concurrencia (segmentos calientes) y evaluar

parámetros a nivel de bloque como initrans, maxtrans, freelists, pctfree y
pctused
•Identificar sesiones largas y revisar los SQL involucrados
•implementar paralelismo
•implementar partitioning (tener en cuenta licenciamiento EE)
•Realizar afinamiento de búffers de red