Monitoreo y Auditoría de la

Base de Datos
Monitoreo
1.- Monitoreo general de un DBMS
2.- Monitoreo de espacio en disco.
3.- Monitoreo de logs.
4.- Monitoreo de Memoria compartida
 Instituto Tecnológico de
Culiacán
 Equipo #5

 Integrantes:
 Alvarado Arellano Armando
 Gaxiola Rojas Carlos Mario
 Hernández Estolano Iván Alonso
 Ontiveros Núñez José Luis
Monitoreo general de un
DBMS
 ¿Qué es la Auditoría de BD?

 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.

Es uno de los procesos fundamentales para apoyar la

responsabilidad delegada a IT por la organización frente a las
regulaciones y su entorno de negocios o actividad.
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.

 La importancia de la auditoría del entorno de bases de

datos radica en que es el punto de partida para poder
realizar la auditoría de las aplicaciones que utiliza esta
tecnología.
La Auditoría de BD es importante
porque:
 – Toda la información financiera de la organización
reside en bases de datos y deben existir controles
relacionados con el acceso a las mismas.
 – Se debe poder demostrar la integridad de la
información almacenada en las bases de datos.
 – Las organizaciones deben mitigar los riesgos
asociados a la pérdida de datos y a la fuga de
información.
 – La información confidencial de los clientes, son
responsabilidad de las organizaciones.
 – Los datos convertidos en información a través de bases
de datos y procesos de negocios representan el negocio.
 – Las organizaciones deben tomar medidas mucho
más allá de asegurar sus datos.
 Deben monitorearse perfectamente a fin de conocer
quién o qué les hizo exactamente qué, cuándo y cómo.
 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.
Monitoreo de espacio libre en
discos
Como DBA una de las responsabilidades es supervisar el espacio en
disco. Siempre hay que asegurarse de que se tiene suficiente para sus
bases de datos, copias de seguridad de bases de datos y cualquier otro
tipo de archivos que va a almacenar en el servidor. Si no controla su
espacio en disco y se asegura de que tienes espacio suficiente, con el
tiempo uno de sus procesos críticos de bases de datos o componentes
va a fracasar porque no se puede asignar el espacio en disco que
necesita.

Dentro de SQL Server 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 regresa todos
los discos a los que tiene acceso SQL Server y su espacio disponible
en Megabytes.

Es muy sencillo utilizarlo, solo basta con ejecutar el comando

xp_fixeddrives de vez en cuando desde el Analizador de consultas para
revisar la cantidad de espacio libre, aunque este método consume
demasiado tiempo para los administradores de bases de datos. Un
método mejor sería automatizar la ejecución de este comando
periódicamente para revisar la cantidad de espacio libre.
Algunas tareas de DBA donde la información
de espacio libre puede ser útil:
- La primera que se alerte al DBA cuando el espacio libre cae por debajo de un umbral
específico en cualquier unidad de SQL Server.
- La segunda sería la de realizar un seguimiento de la historia el espacio libre para la
gestión de la capacidad de espacio en disco.
La forma de construir un proceso para alertar a la DEA, cuando cualquiera de las unidades de
disco de SQL Server cae por debajo de un umbral predeterminado. Para obtener la
información xp_fixeddrives en una tabla temporal que se utiliza el siguiente T- SQL.
createtable #FreeSpace(
Drive char(1),
MB_Freeint)
insertinto #FreeSpaceexecxp_fixeddrives
A continuación, por cada unidad se recupera la información de espacio libre a partir de esta
tabla temporal y se compara con un umbral que se ha fijado para cada unidad. Si la cantidad
de espacio libre cae por debajo del valor umbral determinado para la unidad, enviar alerta al
DBA mediante xp_sendmail. Aquí está una muestra de un código que hace precisamente eso.
declare @MB_Freeint
createtable #FreeSpace(
Drive char(1),
MB_Freeint)
insertinto #FreeSpaceexecxp_fixeddrives
select @MB_Free = MB_Freefrom #FreeSpacewhere Drive = 'C'
-- Free Spaceon C drive LessthanThreshold if
@MB_Free< 1024
execmaster.dbo.xp_sendmail
@recipients ='greg.larsen@netzero.net',
@subject ='SERVER X - FreshSpaceIssueon C Drive',
@message = 'Free spaceon C Drive has droppedbelow 1 gig'
Esta alerta de espacio libre bajo permite tiempo al DBA para
resolver el problema de espacio libre antes de que sea crítico, y
provoque procesos fallidos. Tenga en cuenta que el código
anterior tiene un umbral diferente de espacio libre para cada
unidad.
Otro uso de xp_fixeddrives podría ser la de controlar el uso de
espacio en disco a través del tiempo. Para recopilar la
información de espacio libre a intervalos regulares, por ejemplo,
semanal y lo almacena en una tabla de base de datos.
Mediante la recopilación de información de espacio libre en el
tiempo y almacenarlo en una tabla del servidor SQL permanente
que será capaz de producir un cuadro de tendencias que muestra
el espacio en disco extra de consumo. Al comparar la cantidad de
espacio libre entre dos puntos sobre el gráfico que será capaz de
determinar el espacio de disco consumido entre esos intervalos.
El monitoreo del espacio disponible en disco y las tasas de
crecimiento son un par de cosas que un DBA debe realizar. Sin
vigilancia se corre el riesgo de quedarse sin espacio y causando
graves problemas para su aplicación.
Monitoreo de log.
 Monitorear el log regularmente puede ayudarnos a resolver
varios problemas dentro de nuestros sistemas, ya que este
puede indicarnos si existen demasiadas transacciones
realizadas por una sola aplicación, que podría resultar en
un mal diseño o simplemente la necesidad de planear
mejor los recursos de log en nuestro servidor de base de
datos.
 Es muy importante tener en cuenta que si el log de
transacciones llegara a saturarse, SQL Server no podrá
realizar más cambios dentro de nuestra base de datos.
 La manera de monitorear un log de transacciones, puede
llevarse a cabo de 2 maneras, una de ellas es mediante un
comando desde el analizador de consultas y la otra
utilizando los contadores de SQL Server desde el sistema
operativo.
 Desde el analizador de consultas ejecutar el comando
DBCC SQLPERF(LOGSPACE).
 Utilizando los contadores de SQL Server que se
describen a continuación.
Contador Descripción

Log Bytes Flushed/sec Número total de bytes del log de transacciones vaciados

Log Flushes/sec Número de vaciados del log de transacciones

Log FlushWaits/sec Número de confirmaciones (commit) en espera al momento de

vaciar el log de transacciones.

Percent Log Used Porcentaje del log de transacciones usado.

Log File(s) Size(KB) Tamaño total del log de transacciones de la base de datos

Log Cache Hit Ratio Lecturas realizadas a través de la caché del administrador de
registro.

Situaciones en las que se produce mucha actividad en el log de transacciones

 Algunas de las situaciones por la que podría presentarse mucha
actividades en el log de transacciones y saturarlo son:

 Cargar información en una tabla que tiene indices. SQL Server

almacena en el log todos los inserts y cambios en los índices.
Cuando se carga en tablas que no tienen indices SQL Server
solo reserva extents para el log.
 Transacciones que realizan muchas modificaciones (INSERT,
UPDATE,DELETE) a una tabla en una sola transacción. Esto
generalmente occurre cuando la sentencia WHERE es muy
general, causando que muchos registros sean modificados.
 Expandiendo el log de transacciones
 Expandir un log de transacciones debe de realizarse solamente
si en verdad es requerido por la aplicación y no solo por el echo
de asignar más espacio, ya que para ello existen los respaldos
del log de transacciones en donde se vacia el espacio ocupado
del log.
 Para asignar espacio de log a una base de datos pues
realizarse mediante el SQL Server Enterprise Manager o la
sentencia ALTER DATABASE, en esta caso hablaremos
solamente de la sentencia ALTER DATABASE
Ejemplo:
 Agregar dos archivos de log a una base de datos

 El ejemplo siguiente agrega dos archivos de log de 5 MB a una base de datos.

 USE master
 GO
 ALTER DATABASE Test1
 ADD LOGFILE
 ( NAME = test1log2,
 FILENAME = 'c:\Program Files\Microsoft SQL Server\MSSQL\Data\test2log.ldf',
 SIZE = 5MB,
 MAXSIZE = 100MB,
 FILEGROWTH = 5MB),
 ( NAME = test1log3,
 FILENAME = 'c:\Program Files\Microsoft SQL Server\MSSQL\Data\test3log.ldf',
 SIZE = 5MB,
 MAXSIZE = 100MB,
 FILEGROWTH = 5MB)
 GO
Monitoreo de Memoria
compartida

 PGA DE ORACLE (ÁREA GLOBAL

DE PROGRAMA)

 SGA de oracle (Sistema de Área

Global)
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
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:
1.- Buffers de BD, Database Buffer Cache
2.- Buffer Redo Log
3.- Área de SQL Compartido, Shared SQL Pool
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.
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.
Á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.
Gracias por su atención