PLAN DE TRABAJO ESTRUCTURADO PARA LA ADMINISTRACIÓN DE BASES DE DATOS ORACLE

PRESENTACIÓN DE PLAN DE
TRABAJO ESTRUCTURADO PARA LA ADMINISTRACIÓN DE BASES DE DATOS ORACLE

AUTOR:
DBA ORACLE
Héctor Valenzuela R.




Santiago, Septiembre de 2008


PLAN DE TRABAJO ESTRUCTURADO PARA LA
ADMINISTRACIÓN DE BASE DE DATOS ORACLE

El presente plan de trabajo estructurado para la administración de bases de datos Oracle el cual tiene definido 4 etapas:

I. Levantamiento de estado actual identifica el ambiente en el cual la base de datos se desempeña, la infraestructura tecnológica con la cual se interrelaciona, los servicios relacionados y soportados.

1. Individualización de los servicios y su disponibilidad. Antes de administrar, se debe conocer que se debe administrar. Es de vital importancia conocer las funciones que presta la base de datos, para que es utilizada y como afectaría al negocio si la base de datos dejara de funcionar.
2. Mapa lógico. Identifica como esta estructurada la base de datos, donde se encuentran alojados sus archivos y configuraciones.
3. Servidor. Recolecta información especifica del servidor tales como nombre, configuraciones, características, capacidades de unidades de disco.
4. Red. Identifica el tipo de red, velocidad, topología.
5. Seguridad. Permite identificar si la organización cuenta con políticas de seguridad para gestión de usuarios.
6. Respaldo y recuperación. Establece si existen procedimientos y políticas de respaldo, tecnología utilizada y tipo de medios utilizados.

II. Recomendaciones y sugerencias consiste en analizar la información recolectada en el levantamiento de estado actual y generar un informe con recomendaciones y sugerencias para mejorar estado actual de la base de datos.

III. Definición de actividades de administración establece las tareas de administración que debe realizar el Dba las cuales se subdividen en:

1. Tuning. Señala las áreas que deben ser monitoreadas constantemente para mantener el motor en óptimas condiciones.
2. Tareas cíclicas. Define tareas cíclicas de mantenimiento que deberá realizar el DBA.
3. Definición de alarmas a nivel de Oracle. Establece alarmas sobre objetos de la base de datos, nivel crítico, como será informada (medio) y a quien.
4. Definición de alarmas a nivel de SO. Establece alarmas sobre los recursos del servidor, nivel crítico, como será informada (medio) y a quién.
5. Monitoreo activo de la instancia. Se establecen puntos críticos que serán controlados ONLINE en el motor Oracle para detectar problemas de funcionamiento, sobrecarga, lentitud, cuellos de botella.
6. Generación de informes. Se definen los informes que serán emitidos al cliente, periodicidad de estos y contenido.

IV. Retro alimentación en función de entregar un mejor servicio de administración de bases de datos, se considera un proceso de mejora constante de las actividades, procedimientos y tareas a realizar.


ETAPA I
LEVANTAMIENTO DE ESTADO ACTUAL

1. INDIVIDUALIZACIÓN DE LOS SERVICIOS Y SU DISPONIBILIDAD

En esta etapa se debe crear una idea global del funcionamiento de la base de datos, conocer su fin y como afectaría a la organización si esta dejara de funcionar. Para comprender esta etapa, se deben formular las siguientes preguntas:
• ¿Cuál es el nombre de la base de datos?.
• ¿La base de datos se utiliza en un ambiente de (producción, desarrollo, qa, otro)?.
• Identificar las funciones, tareas y servicios que presta la base de datos a la organización.
• Identificar los sistemas (ERP/Gestion/Otros) que utilizan la base de datos.
• ¿Cómo afecta al negocio de la organización si la base de datos deja de prestar servicios?.
• ¿Quiénes son los dueños y/o responsables de la base de datos?.
• ¿Cuál es la disponibilidad de la base de datos (5x24, 7x24)?
• ¿Existen fechas definidas durante el año para que la base de datos pueda recibir mantención?.
• ¿Existen fechas definidas durante el año para que ingeniería de sistemas realice mantención sobre los servidores donde se encuentra alojada la base de datos?.
• ¿Es requerida la base de datos para ejecutar procesos batch?. ¿En qué horarios?.
• ¿En que horarios la base de datos debe atender usuarios de transacciones?.

2. MAPA LÓGICO

El desarrollo de la etapa del mapa lógico esta dividido en 4 secciones:
• Mapa lógico de la base de datos: información de cómo la base de datos está estructurada.
• Mapa lógico de listener: ubicación de archivos y configuración de servicios.
• Mapa lógico de tnsnames: ubicación de archivo y configuración de servicios.
• Mapa lógico de dblinks: identifica dblinks creados a otras instancias.

2.1 MAPA LÓGICO DE LA BASE DE DATOS

• Se identifican tablespaces, tamaño en Mb, datafiles asociados y tamaño en Mb.
TABLESPACE MB DATAFILES MB
SYSTEM 100 /U01/DATA/SYSTEM01.DBF 50
/U01/DATA/SYSTEM02.DBF 50

• Tamaño total en MB de la base de datos.
• Ubicación de archivos de control.
• Ubicación de instalación del motor Oracle.
• Ubicación de directorios (unix) bdump, udump, cdump
• Ubicación de archivo alert.log
• Ubicación de archivos archivelog.
• Ubicación de archivos de parámetros.
• Listado con los parámetros de inicio del motor Oracle.
• Memoria asignada SGA, PGA, Shared Pool, Buffer Cache, Area Sort.
• Valor para el parámetro de inicio Block size.
• Tamaño máximo por cada datafile. ¿Existe una política que defina un tamaño estándar?
• ¿Los tablespaces están en modo crecimiento automático?
2.2 MAPA LÓGICO DE LISTENER

• Ubicación de archivo listener.log
• Ubicación de archivo listener.ora
• Identificar nombre del listener, número de puerto, servicio asociado.

2.3 MAPA LÓGICO DE TNSNAMES

• Ubicación de archivo tnsnames.ora
• Identificar nombre, servicio y número de puerto.

2.4 MAPA LÓGICO DE DBLINKS

• Identificar dblinks creados que van desde la base de datos anfitrión a otras bases de datos: considerar nombre dblink, bd destino, esquema.


3. SERVIDOR

Se debe identificar las características técnicas y configuraciones del servidor donde reside el motor Oracle.

• Nombre del servidor (host).
• IP del servidor asociada a la base de datos.
• Memoria RAM total del servidor.
• Memoria RAM disponible después de asignación de memoria a Oracle.
• Número de motores de base de datos instalados en el servidor.
• Número de procesadores disponibles y operativos en el servidor.
• Tipo de sistema operativo instalado en el servidor.
• Identificar filesystem asociado a la instalación del motor Oracle, espacio total de la unidad expresado en Gb, porcentaje de espacio, porcentaje de espacio libre, espacio libre expresado en Mb.
• Identificar filesystem asociado a la data del motor Oracle, espacio total de la unidad expresado en GB, porcentaje de espacio, porcentaje de espacio libre, espacio libre expresado en MB.
• Nombre del administrador del servidor.
• Nombre del responsable o dueño del servidor.
• ¿El servidor tiene fechas de mantención programadas durante el año?.
• Marca y modelo del servidor.
• ¿Cuál es la velocidad de las tarjetas de red que son utilizadas para que Oracle se comunique por la red?.


4. RED

Recolectar información de la red y como está segmentada.

• Tipo de topología de red.
• Velocidad de la red.
• Segmento de red asociado a producción, desarrollo y qa.
• Físicamente, ¿existen redes independientes para los servidores de producción, desarrollo y qa?.

5. SEGURIDAD

Se debe recolectar información referente a los usuarios de bases de datos y si existen políticas de gestión de usuarios y seguridad.

• ¿Existen políticas de creación y cambio de contraseña para el usuario Oracle a nivel de sistema operativo?.
• ¿Existen políticas de creación y cambio de contraseña para los usuarios SYS, SYSTEM y demás a nivel de base de datos?.
• Levantamiento de auditoria sobre la base de datos para identificar usuarios con rol Dba.
• Levantamiento de auditoria sobre la base de datos para identificar que usuarios (personas) utilizan la cuenta sys y system.
• ¿Existe un registro de las contraseñas de los usuarios sys y system a nivel de base de datos y Oracle a nivel de sistema operativo?, ¿es restringido el acceso a dicha información?.

6. RESPALDO Y RECUPERACIÓN

• ¿La base de datos funciona en modo archivelog?.
• ¿Existen políticas de respaldo de la base de datos?.
• ¿Cuánto tiempo se almacenan los respaldos?.
• ¿Qué tecnología es utilizada para almacenar los respaldos?.
• ¿Existe un procedimiento para realizar respaldo de la base de datos?
• ¿Existe un procedimiento para realizar una recuperación de la base de datos?.
• ¿Existen políticas definidas para realizar pruebas de los respaldos realizados?.
• ¿Existen políticas definidas para realizar simulaciones de fallas y el procedimiento que se debe aplicar ante ellos?
• ¿La base de datos tiene un respaldo en modo standby?, ¿el servidor standby es idéntico en configuración de hardware al de producción?.



ETAPA II.
RECOMENDACIONES Y SUGERENCIAS

La información recolectada durante la primera etapa será analizada y se procederá a documentar la interacción de la base de datos con el medio (servicios y sistemas) cubierto en individualización de los servicios y su disponibilidad, posteriormente se identificarán los posibles puntos débiles y se formularán las recomendaciones y sugerencias para la categoría mapa lógico, servidor, red, seguridad, respaldo y recuperación.


ETAPA III.
DEFINICIÓN DE ACTIVIDADES DE ADMINISTRACIÓN

1. TUNING DEL MOTOR

Para un óptimo rendimiento del motor Oracle, la base de datos debe ser ajustada periódicamente. Para ello es requerido llevar un registro del rendimiento de las diferentes áreas (memoria y disco), analizar estos valores, realizar cambios y monitorear rendimientos.

1.1 MEMORY TUNING

• Tuning de redo log buffer.
• Tuning de buffer cache.
• Tuning de sorts.
o Contabilizar ordenamientos en memoria y en disco.
• Tuning de shared pool.
o Identificar tamaño total shared pool y espacio disponible.
o Tuning Library cache.
o Tuning Data dictionary cache.

1.2 DISK I/O TUNING

• Tuning de rollback segments.
• Identificar si ocurren ordenamientos frecuentes a nivel de disco.
• Identificar queries que realicen full scan sobre tablas.
• Identificar índices perdidos o no disponibles.
• Identificar encadenamiento de filas.
• Identificar fragmentación de tablas.
• Identificar fragmentación de índices.
• Comprobar posible configuración incorrecta de cuentas de usuarios.
o Buscar e identificar cuentas de usuarios creadas en tablespaces diferente a users y que utilicen tablespaces temporal incorrecto.
• Revisar distribución de archivos de base de datos para reducir contención en discos. Identificar datafiles con alto porcentaje de I/O.
Disco 1 Disco 2 Disco 3 Disco 4
SYSTEM USERS INDICES DATA
ROLLBACK TEMPORAL
LOG 1 LOG 2 LOG 3
CONTROL FILE1 CONTROL FILE 2 CONTROL FILE 3



2. TAREAS CÍCLICAS

Se definen como tareas cíclicas aquellas actividades de mantenimiento que se deben realizar de forma periódica sobre la base de datos.

Tareas a nivel de base de datos Periodicidad
Envió de informe diario de estado de la base de datos (respaldos realizados, disponibilidad de tablespaces, errores detectados en archivo alert.log, problemas con procesos nocturnos). Diario
Registro y seguimiento de errores producidos en el motor. Que causo el problema y como se solucionó. Diario
Control de actualización y ejecución de proceso de estadísticas sobre esquemas y tablas. Semanal
Registro y corrección de objetos inválidos. Diario
Asignación de espacio a tablespaces. Diario
Corrección de next extent de segmentos de índices y tablas. Diario
Corrección de max extent de segmentos de índices y tablas. Diario
Reconstrucción programada de índices particionados / no particionados. Semanal
Identificar segmentos de tablas e índices con más de 20 extensiones y programar desfragmentación. Semanal
Control e identificación de índices creados en tablespaces de data y programar mudanza. Semanal
Control e identificación de tablas creadas en tablespaces de índices y programar mudanza. Semanal
Control de fragmentación de espacio libre en tablespaces y programar desfragmentación. Semanal
Registro de crecimiento de tablespaces. Semanal
Realizar tareas de memory Tuning. Diario
Realizar tareas de disk i/o Tuning. Diario
Revisar crecimiento de tablespace de statpack, generar informes del periodo y purgar tablas para liberar espacio. Semanal
Identificar conexiones de usuarios en estado inactivo y sniped. Diario

Tareas a nivel de S.O Periodicidad
Registro espacio disponible en filesystem. Diario
Control de crecimiento de archivos log, trace, core (alert.log – listener.log – bdump – cdump – udump) para programar respaldo y purga. Semanal
Revisar conexiones a nivel de S.O que estén conectados a la base de datos y estén generando alto consumo a nivel de CPU. Diario
Revisar conexiones a nivel de S.O que estén generando alto consumo de CPU. Diario


3. DEFINICIÓN DE ALARMAS A NIVEL DE ORACLE INFORMADAS POR CORREO ELECTRÓNICO.
• Tablespaces que superen 90% de uso.
• Sesiones que estén provocando bloqueos.
• Segmentos con next extent inadecuados.
• Segmentos con max extent por alcanzar.
• Tablespaces en estado offline.


4. DEFINICIÓN DE ALARMAS A NIVEL DE SISTEMA OPERATIVO INFORMADAS POR CORREO ELECTRÓNICO.
• Filesystem de data supere 90% de uso.
• Filesystem de instalación del motor que supere un 90% de uso.
• Errores ORA-XXX encontrados en archivo alert.log de Oracle.
• Estado de listener.


5. MONITOREO

Monitoreo activo de la instancia
Monitorear disponibilidad de la instancia.
Control de estado de índices (disponible / no disponible).
Control de estado de tablespaces (disponible / no disponible)
Control de next extent de segmentos de índices y tablas.
Control de espacio en tablespaces.
Control de objetos inválidos.
Control de max extent de segmentos de índices y tablas.
Control online disponibilidad de la instancia.
Control online número de usuarios activos/inactivos de la instancia v/s número máximo de conexiones.
Eventos wait.
Detección de bloqueos de objetos de la base de datos.
Identificar sesiones de usuarios en estado inactive que tengan asignado segmento de rollback.
Monitoreo de métrica para Row Cache, Library Cache, Buffer Cache.

6. INFORMES

Se entrega un informe de gestión mensual de:
• Actividades relevantes realizadas durante el periodo.
• Actividades agendadas a realizar en el siguiente periodo.
• Informe de crecimiento tablespaces.
• Informe de decrecimiento de filesystem.
• Informe de crecimiento de usuarios.
• Informe de rendimiento de la base de datos.
• Recomendaciones.


ETAPA IV.
RETRO ALIMENTACIÓN

Se definirá un calendario de actividades semestral para revisar las 4 etapas definidas anteriormente, con ello se persigue mejorar de forma constante el servicio y agregar nuevas tareas y funciones a la administración, para ello se realizará:

• Se revisará que las recomendaciones y sugerencias anteriores se hayan aplicado.
• Se generará un nuevo levantamiento de estado actual.
• La información recolectada será analizada para generar un nuevo informe con recomendaciones y sugerencias.
• Se revisarán las actividades de administración para agregar nuevas tareas que mejoren la gestión del motor.
• Se evaluarán nuevas tecnologías disponibles para ser aplicadas.