6 Monitoreo y Auditoría de la Base de Datos

6.1 Monitoreo

Auditoria: Es el proceso que permite medir, asegurar, demostrar,

monitorear y registrar los accesos a la información almacenada en las
bases de datos incluyendo la capacidad de determinar:

Quién accede a los datos

Cuándo se accedió a los datos
Desde qué tipo de dispositivo/aplicación
Desde que ubicación en la Red
Cuál fue la sentencia SQL ejecutada
Cuál fue el efecto del acceso a la base de datos

Objetivos Generales de la Auditoría de BD

Disponer de mecanismos que permitan tener trazas de auditoría completas
y automáticas relacionadas con el acceso a las bases de datos incluyendo
la capacidad de generar alertas con el objetivo de:

Mitigar los riesgos asociados con el manejo inadecuado de los

datos.
Apoyar el cumplimiento regulatorio.
Satisfacer los requerimientos de los auditores.
Evitar acciones criminales.

Evitar multas por incumplimiento.

Monitoreo general de un DBMS

La elección de un buen manejador de base de datos es de vital importancia

ya que puede llegar a ser una inversión tanto en hardware como en
software muy cuantioso pero no solo eso, además va a determinar el centro
de información de la empresa.

Los sistemas orientados a los datos se caracterizan porque los datos no

son de una aplicación sino de una Organización entera que los va a utilizar;
se integran las aplicaciones, se diferencian las estructuras lógicas y físicas.
El concepto de relación cobra importancia. Originalmente las aplicaciones
cubrían necesidades muy específicas de procesamiento, se centraban en una
tarea específica.

Monitoreo de espacio en disco

Uno de los principales indicadores que se tiene que tomar en cuenta como DBA es el
espacio disponible en disco. No es problema cuando se tiene un server o 2 para
monitorear, sin embargo cuando hay una cantidad considerable automatizar un
proceso que lo haga es lo mejor. Dentro de SQL Server (7,2000,2005) hay un
procedimiento no documentado que nos puede ayudar a cumplir este cometido.

El procedimiento es XP_FIXEDDRIVES, no lleva parámetros ni nada y nos regresan

todos los discos a los que tiene acceso SQL Server y su espacio disponible en
Megabytes.
Si esta en cluster mostrara todos los discos aunque los discos no estén en el mismo
grupo que la instancia, lo que puede llegar a confundir.

Dejo a consideración de cada quien como utilizarlo, ya sea mandando un mail con el
resultado u opciones más complejas como el revisar un porcentaje y en base a eso tomar
una acción.

Monitoreo de logs

Las revisiones deben realizarse sobre el archivo de alerta de ORACLE

(alert.log) y sobre los archivos de rastreo de procesos de background y de
usuarios para identificar errores que se presenten a nivel de base de datos
o de sistema operativo.
Los archivos de alerta útiles para el diagnóstico de información que
contiene ORACLE y que se utilizan para la detección de errores en la base
de datos son:

Archivo de Log´s de alerta (alert.log)

El Alert Log registra errores en forma cronológica, provenientes de la

operación diaria de la Base de Datos. La ubicación actual del archivo es la
ubicación por defecto establecida por ORACLE y se verifica mediante el
parámetro BACKGROUND_DUMP_DEST del archivo init.ora:

BACKGROUND_DUMP_DEST = E:\U01\ORACLE\UCBL\ADMIN\bdump.

La revisión de este archivo en forma periódica permite detectar errores

internos (ORA-600) y errores de corrupción de bloques (ORA-1578).
Adicionalmente, permite monitorear las operaciones de la base de datos
(CREATE DATABASE, STARTUP, SHITDOWN, ARCHIVE LOG y
RECOVER) y ver los parámetros que no se muestran por defecto en la
inicialización.

Archivos de rastreo de procesos de Background

Los archivos de rastreo de procesos de Background se generan cuando un

proceso de background (SMON, PMON, DBWn, etc.) emite un error. Estos
archivos se almacenan en BACKGROUND_DUMP_DEST =
E:\U01\ORACLE\UCBL\ADMIN\bdump.

Archivos de rastreo de usuarios

Los archivos de rastreo de usuarios (user trace files) se crean a través de

procesos de servidor cuando se generan errores o cuando se solicita el
rastreo por el usuario o a nivel de parámetros de la base de datos.
Su ubicación actual definida por el parámetro USER_DUMP_DEST y
actualmente es:

E:\U01\ORACLE\UCBL\ADMIN\udump.

Las normas de revisión de los archivos mencionados se definen en el

documento Procedimientos de Administración de Base de Datos.

El principal riesgo que se menciona en las observaciones es la posibilidad

que se realicen operaciones no autorizadas y que éstas no sean identificadas
en la base de datos; sin embargo los archivos de log´s de usuarios no
permiten identificar con facilidad estas operaciones y en todo caso requieren
de una gran cantidad de tiempo de revisión y espacio de almacenamiento.
Por este motivo, se utilizan tablas de auditoria para todos los sistemas y para
aquellas tablas relevantes de cada uno, las tablas de auditoria tienen las
siguientes características:

Almacenan datos obligatorios (transacción, fecha y usuario) y datos

relacionados con la tabla a la que hacen el monitoreo.
Los registros a las tablas de auditoria se activan mediante un
disparador cada vez que se realizan cambios en la tabla base.
Se consultan estas tablas cuando se quiere identificar una
transacción, un usuario o una fecha de transacción.

El contenido de estas tablas permite mantener un registro constante sobre

las operaciones que se realizan en la base de datos y las mismas pueden ser
consultadas en cualquier momento.

Monitoreo de Memoria compartida

PGA DE ORACLE (ÁREA GLOBAL DE PROGRAMA)

Un PGA es una región de memoria que contiene datos e información de
control para un proceso de servidor. Es la memoria no compartida creada por
la base de datos Oracle cuando un proceso de servidor se ha iniciado. El
acceso a la PGA es exclusivo para el proceso del servidor. Hay un PGA para
cada proceso de servidor. Procesos en segundo plano también se asignan
sus propios PGA. La memoria total utilizada por todos los PGAs individuales
se conoce como el ejemplo total de memoria PGA, y la recogida de
PGAs individuales se refiere como el ejemplo total de la PGA, o simplemente
instancia de la PGA. Puede utilizar los parámetros de inicialización de base
de datos para definir el tamaño de la instancia de la PGA, no PGA
individuales.

El PGA puede ser crítico para el rendimiento, especialmente si la aplicación

está haciendo un gran número de clases. Operaciones de ordenación se
produce si utiliza ORDER BY y GROUP BY comandos en las sentencias SQL.

SGA de oracle (Sistema de Área Global)

Es un conjunto de áreas de memoria compartida que se dedican a un Oráculo

"instancia" (un ejemplo es los programas de bases de datos y la memoria
RAM).

Sirve para facilitar la transferencia de información entre usuarios y también

almacena la información estructural de la BD más frecuentemente
requerida.

En los sistemas de bases de datos desarrollados por la Corporación Oracle

, el área global del sistema (SGA) forma parte de la memoria RAM
compartida por todos los procesos que pertenecen a una sola base de
datos Oracle ejemplo. El SGA contiene toda la información necesaria para
la operación de la instancia.

La SGA se divide en varias partes:

Buffers de BD, Database Buffer Cache

Es el caché que almacena los bloques de datos leidos de los segmentos de

datos de la BD, tales como tablas, índices y clusters. Los bloques modificados
se llamas bloques sucios. El tamaño de buffer caché se fija por el parámetro
DB_BLOCK_BUFFERS del fichero init.ora.

Plan de ejecución de la sentencia SQL.

Texto de la sentencia.

Lista de objetos referenciados.

Comprobar si la sentencia se encuentra en el área compartida.

Comprobar si los objetos referenciados son los mismos.

Comprobar si el usuario tiene acceso a los objetos referenciados.

Como el tamaño del buffer suele ser pequeño para almacenar todos los
bloques de datos leidos, su gestión se hace mediante el algoritmo LRU.

2. Buffer Redo Log

Los registros Redo describen los cámbios realizados en la BD y son

escritos en los ficheros redo log para que puedan ser utilizados en las
operaciones de recuperación hacia adelante, roll-forward, durante las
recuperaciones de la BD. Pero antes de ser escritos en los ficheros redo log
son escritos en un caché de la SGA llamado redo log buffer. El servidor
escribe periódicamente los registros redo log en los ficheros redo log.
El tamaño del buffer redo log se fija por el parámetro LOG_BUFFER.
3. Área de SQL Compartido, Shared SQL Pool

En esta zona se encuentran las sentencias SQL que han sido analizadas. El
analisis sintáctico de las sentencias SQL lleva su tiempo y Oracle mantiene
las estructuras asociadas a cada sentencia SQL analizada durante el
tiempo que pueda para ver si puede reutilizarlas. Antes de analizar una
sentencia SQL, Oracle mira a ver si encuentra otra sentencia exactamente
igual en la zona de SQL compartido. Si es así, no la analiza y pasa
directamente a ejecutar la que mantinene en memoria. De esta manera se
premia la uniformidad en la programación de las aplicaciones. La igualdad
se entiende que es lexicografica, espacios en blanco y variables incluidas.
El contenido de la zona de SQL compartido es:

Los pasos de procesamiento de cada petición de análisis de una sentencia

SQL son:

Si no, la sentencia es nueva, se analiza y los datos de análisis se

almacenan en la zona de SQL compartida.

También se almacena en la zona de SQL compartido el caché del diccionario.

La información sobre los objetos de la BD se encuentra almacenada en las
tablas del diccionario. Cuando esta información se necesita, se leen las tablas
del diccionario y su información se guarda en el caché del diccionario de la
SGA. Este caché también se administra mediante el algoritmo LRU. El
tamaño del caché está gestionado internamente por el servidor, pero es parte
del shared pool, cuyo manaño viene determinado por el parámetro
SHARED_POOL_SIZE.

Monitoreo de Base de Datos

Mediante la auditoría de bases de datos se evaluará:

 Definición de estructuras físicas y lógicas de las bases de datos.

 Control de carga y mantenimiento de las bases de datos.
 Integridad de los datos y protección de accesos.
 Estándares para análisis y programación en el uso de bases de datos.
 Procedimientos de respaldo y de recuperación de datos.

Aspectos Claves

 No se debe comprometer el desempeño de las bases de datos

 Soportar diferentes esquemas de auditoría.
 Se debe tomar en cuenta el tamaño de las bases de datos a auditar y
los posibles SLA establecidos.

Segregación de funciones

El sistema de auditoría de base de datos no puede ser administrado por los

DBA del área de IT.

Proveer valor a la operación del negocio

 Información para auditoría y seguridad.

 Información para apoyar la toma de decisiones de la organización.
 Información para mejorar el desempeño de la organización.

Auditoría completa y extensiva

 Cubrir gran cantidad de manejadores de bases de datos.

 Estandarizar los reportes y reglas de auditoría.

DB Audit Expert es un Auditor Multiplataforma y solución de Monitoreo

Proactivo para Bases de Datos - Oracle, SQL Server, Sybase, MySQL y
DB2
Vivimos en una economía de información; las empresas están hoy en día
dependientes de las tecnologías de bases de datos que hacen funcionar su
negocio. Con datos activos de misión crítica son almacenados en bases de
datos de SQL, entre otras y es cuando surgen las preguntas: “Quien está
teniendo acceso a nuestra base de datos, quien y cuando se hacen los
cambios?” la mayor parte de la información financiera de una organización
también se almacena y se mantiene en las bases de datos, el DBA trabaja
para compañías públicas en donde se requiere que proporcione un rastro
de intervención exacto, auditorias inmutable de todos los accesos de bases
de datos y cambios en permisos de seguridad.

Componentes de DB Audit Expert Empresarial

Monitoreo de modos de operación

Definición y diseño de monitoreo.

Una vez identificados los riesgos, se puede realizar el modelo conceptual

del monitoreo, a partir de las debilidades identificadas y contemplando los
controles existentes en el proceso.

Posteriormente, se diseña el monitoreo en sí, analizando el procesamiento

y la arquitectura de la información, así como el registro informático de las
operaciones. A partir de todo lo anterior, se desarrollan los procedimientos
automatizados, determinando las consultas a realizar y los parámetros a
cumplir.

Obtención de herramientas informáticas. Una vez concluido el diseño, se

puede identificar la herramienta a utilizar de manera individual o combinada.

Monitoreo de espacios espejeados

La optimización en MySQL pasa por tres componentes, a saber:

Optimización del servidor MySQL

Optimización de la base de datos
Optimización de las consultas

Optimización de la configuración del servidor MySQL

La optimización del servidor puede incluir una multitud de enfoques y

métodos, lo que intentaremos presentar en lo que sigue es una introducción
a los enfoques de base, a saber:

Compilación del servidor

Afinamiento de los parámetros del servidor
Afinamiento de otros parámetros

Para hacer una buena optimización, es necesario proceder con una

metodología empírica a saber hacer las modificaciones una por una y
probar cada vez la reacción del sistema para ver el resultado. Una medida
del rendimiento antes y después de haber efectuado la optimización permite
ver si el sistema ha sido optimizado o no.

Compilación del servidor

Es recomendado utilizar la versión del código fuente del servidor MySQL y

compilarla teniendo en cuenta los diferentes parámetros del sistema a saber
el conjunto de caracteres a utilizar, el microprocesador sobre el que va a
correr y utilizar un compilador adaptado (por ejemplo: pgcc para los
microprocesadores Pentium).

Afinamiento de los parámetros del servidor

Es posible optimizar el funcionamiento de MySQL cambiando los valores de

los parámetros del servidor.

Como recordarás para mostrar los parámetros se debe utilizar el comando:

show variables;

Para ver el efecto de los parámetros sobre el servidor es necesario ejecutar

el comando:

show status;

Existen numerosas herramientas de monitoreo que permiten ver los efectos

de los cambios efectuados en los parámetros en el servidor MySQL, por
ejemplo Mytop equivalente al comando top de Linux.
El fichero my.cnf contiene todos los parámetros que deben ser
optimizados.
Inicialmente, es posible comenzar con los parámetros que gestionan la
memoria. Se debe tener en cuenta que cuanta más memoria disponga el
servidor, más rápido será, sin embargo, hay que asegurarse de que la
memoria esté disponible.
MySQL contiene un conjunto de buffers y cachés internos, en el que es
posible configurar el espacio asignado a cada uno a partir de las variables del
fichero my.cnf. Las dos variables más importantes son key_buffer_size y
table_cache ya que son compartidas por todos los threads que corren sobre
el servidor e influyen de manera considerable en el rendimiento. Un
ejemplo de variables:

key_buffer_size: memoria utilizada para las copias de seguridad de

los índices MyISAM.
table_cache: numero de tablas que pueden ser abiertas
simultáneamente.
read_buffer_size: memoria utilizada para la copia de respaldo de los
datos salidos de los full scan de las tablas.
sort_buffer: memoria utilizada para la copia de respaldo de los datos
de las tablas que serán ordenadas con un ORDER BY

Afinamiento de otros parámetros

El servidor MySQL obtiene un funcionamiento óptimo en SOLARIS, sin

embargo, es posible optimizarlo en otros SO para aproximarse a su
rendimiento ideal.
El uso de RAID-RAID 0 es recomendado para la optimización de las
operaciones de lectura escritura. Así como el uso de discos SCSI en vez de
IDE.
El uso de redes rápidas optimiza el tiempo de respuesta y optimiza la
comunicación entre cliente/servidor y amo/esclavo para la replicación.
Optimización de la base de datos

Generalmente para la optimización de las bases de datos lo recomendado

es hacer uso de las buenas prácticas y las metodologías de concepción de
base de datos que permitan implementar esquemas de bases de datos
eficaces y normalizados. Sin embargo para ello es necesario:

Saber lo que está lento en las bases de datos

Elegir la metodología correcta
Utilizar índices
Utilizar OPTIMIZE TABLE

Qué es lo que ralentiza las bases de datos

Generalmente, un cierto número de factores son la causa de la lentitud de las

bases de datos. Entre los más frecuentes:

Insuficiente numero de índices: La primera causa de la lentitud es el

uso de tablas sin índices o sin índices en las columnas relativas a las
búsquedas. Esto no quiere decir que todas las tablas deben tener
índices, sino que hay que estudiar bien las necesidades de indexación.
Uso excesivo de índices: para optimizar las consultas y búsquedas,
los índices son la solución, sin embargo, el aumento de índices
afecta el rendimiento en lo relativo a las actualizaciones. En la
actualización de una tabla, las operaciones de inserción,
modificación y eliminación repercuten generalmente sobre los
índices.
 Uso de privilegios en las tablas y columnas de las tablas: en cada
acceso MySQL debe verificar los derechos sobre las tablas y las
columnas de las tablas lo que ralentiza considerablemente el
rendimiento.
No hacer la elección correcta en la concepción de la base de datos.

Modelización de la base de datos

El uso de las buenas prácticas de modelización y concepción de bases de

datos así como la elección de la metodología apropiada permite
implementar bases de datos eficaces.
Es necesario tener en cuenta un cierto número de consideraciones:

Apropiada elección de los tipos de campos: siempre procurar elegir

las variables más adaptadas a las necesidades (por ejemplo para
almacenar un numero con no más de 10 dígitos, lo mejor es utilizar
un tipo TINYINT). El uso de campos de menor tamaño permite cargar
en memoria más columnas.
Uso de campos de longitud fija: el uso de longitudes
predeterminadas permite optimizar el acceso a las columnas ya que
sus posiciones son predefinidas. Esto implica disminuir el uso de
VARCHAR, TEXT y BLOB (para TEXT y BLOB, se recomienda romper
la normalización del esquema de la base de datos y hacer una copia
de respaldo de estos campos en otras tablas).
Aumentar el uso de las restricciones NON NULL cuando sea posible
para optimizar el espacio de almacenamiento.
Elegir el tipo correcto para las tablas: MySQL permite tener en un
mismo esquema tablas de diferente tipo.
Hacer una buena indexación de las tablas.
Utilizar los índices

Un índice es una tabla de búsqueda que nos permite encontrar rápidamente

líneas en una tabla. El índice permite determinar la posición del registro
buscado en una tabla.
Si una tabla no tiene índice, todos los registros serian recorridos durante la
búsqueda.
Los índices en MySQL son almacenados como de b-trees (árboles
binarios), que representa una estructura de datos fácil y rápida de recorrer.
El índice puede incluir una o varias columnas, el índice será llamado
durante una búsqueda hecha sobre las columnas indexadas.
En MySQL, la indexación es automática en las tablas con campos teniendo
las restricciones PRIMARY, KEY, UNIQUE.
La idea principal a tener en cuenta es que si una búsqueda es frecuente y
ésta incluye una o varias columnas, será necesario crear el índice
correspondiente para optimizar el tiempo de respuesta vía el comando
CREATE INDEX

Uso del comando OPTIMIZE TABLE

Equivalente a la defragmentación del disco duro, el comando OPTIMIZE

TABLE permite defragmentar las tablas.

Optimización de las consultas

MySQL permite analizar las consultas y conocer el tiempo y plan de

ejecución. Esta información permite comprender lo que hace que las
consultas sean lentas y optimizar la ejecución de éstas.
 Detectar las consultas lentas

Para detectar las consultas lentas es posible:

1. observar las consultas lentas durante su ejecución y los tiempos

de respuesta anormales.
2. hacer un benchmark: testear las aplicaciones para ver qué
componentes son los más lentos.
3. verificar el Slow query log: es posible activar esta opción en
MySQL configurando la variable --log-slow-queries

Una vez detectadas las consultas lentas, la ejecución del comando

EXPLAIN permite comprender la ejecución y por lo tanto conocer o
intervenir para optimizar.

6.2 Auditoría

Habilitación y deshabilitar el modo de auditoría

 Mediante la auditoría se intenta monitorizar y registrar acciones en la base

de datos con el fin de:
 Investigar actividades maliciosas.
 Detectar privilegios incorrectamente otorgados a usuarios.
 Recoger datos sobre actividades concretas.
 Detectar problemas con la implementación de políticas de seguridad.

Observen que el Monitoreo y la auditoria se hacen a la vez.

Ing. Luz Elvira Luna Ayala