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ánEquipo #5

Integrantes:Alvarado Arellano ArmandoGaxiola Rojas Carlos MarioHernández Estolano Iván AlonsoOntiveros 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_fixeddrivesA 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_Freeintcreatetable #FreeSpace(Drive char(1), MB_Freeint)insertinto #FreeSpaceexecxp_fixeddrivesselect @MB_Free = MB_Freefrom #FreeSpacewhere Drive = 'C'-- Free Spaceon C drive LessthanThresholdif @MB_Free< 1024execmaster.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.

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.

Desde el analizador de consultas ejecutar el comando DBCC SQLPERF(LOGSPACE).

Utilizando los contadores de SQL Server que se describen a continuación.

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 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:1.- Buffers de BD, Database Buffer Cache2.- Buffer Redo Log3.- Á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 LogLos 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