Unidad 5: Seguridad

5.1 Respaldo y Recuperación

Respaldo

El respaldo es uno de los pasos más importantes que puedes dar para proteger tu

información. Cuando algo sale mal, como fallas en disco duro, borrado accidental de archivos

o infecciones por malware, son tu último recurso. En esta edición, te explicamos cómo

respaldar tu información y preparar una estrategia adecuada para ti.Existen dos aspectos

fundamentales para decidir qué respaldar: la información que hayas generado o que sea

importante para ti, como documentos, fotografías o videos; o toda, incluyendo tu sistema

operativo y cualquier programa que hayas instalado. El primer aspecto limita el proceso de

respaldo, mientras que el segundo hace que sea más fácil recuperar el sistema en caso de un

fallo completo. Si no estás seguro de qué respaldar, respalda todo. A continuación, tendrás

que decidir qué tan seguido respaldar tu información. Lo más común es hacerlo cada hora,

diariamente, semanalmente, etc. Para usuarios caseros, los programas de respaldo personal

como Time Machine de Apple o Copias de seguridad y restauración de Windows, permitirán

fijar un horario automático de respaldo “prográmalo y olvídate”. Otras soluciones ofrecen

“protección continua”, en la cual los archivos nuevos o modificados son respaldados

inmediatamente tan pronto sean cerrados. Si perteneces a una organización con muchas

computadoras, quizás te gustaría definir tu propio calendario. Sería bueno que consideraras

cuánta información estás dispuesto a perder en el peor de los casos. Por ejemplo, si respaldas

diariamente, puedes perder una jornada de trabajo si tu computadora falla al final del día.
Muchas organizaciones programan respaldos diarios fuera de las horas pico para minimizar

el impacto la operación normal.

Recuperación

Respaldar tu información es sólo la mitad de la batalla; ahora tienes que asegurarte de que

puedes recuperarla fácilmente. Practica regularmente tu proceso de recuperación, tal y como

harías en un simulacro de sismo, esto te ayudará a asegurar que todo funcione correctamente

en caso de necesitarlo. Comprueba por lo menos una vez al mes que el programa de respaldos

está funcionando adecuadamente. Por lo menos trata de recuperar un archivo. Para una

prueba más robusta, sobre todo para las organizaciones, considera hacer la recuperación

completa del sistema y verifica que sea recuperable. Si no cuentas con hardware externo para

la prueba de recuperación completa del sistema, restaura archivos y carpetas importantes en

una ubicación diferente y luego verifica si recuperaste y puedes abrir todo.

5.2 Espejeo (Mirroring)

Base de Datos Espejo (Database Mirroring) es una configuración donde dos o tres

servidores de dase de datos, ejecutándose en equipos independientes, cooperan para mantener

copias de la base de datos y archivo de registro de transacciones (log).

Tanto el servidor primario como el servidor espejo mantienen una copia de la base de datos

y el registro de transacciones, mientras que el tercer servidor, llamado el servidor árbitro, es

usado cuando es necesario determinar cuál de los otros dos servidores puede tomar la

propiedad de la base de datos. El árbitro no mantiene una copia de la base de datos. La

configuración de los tres servidores de base de datos (el primario, el espejo y el árbitro) es
llamado Sistema Espejo (Mirroring System), y el servidor primarioy espejo juntos son

llamados Servidores Operacionales (Operational Servers) o Compañeros (Partners).

5.2.1 Beneficios del Espejeo de Datos en un DBMS

La creación de reflejo de la base de datos es una estrategia sencilla que ofrece las siguientes

ventajas:

Incrementa la disponibilidad de una base de datos. Si se produce un desastre en el modo

de alta seguridad con conmutación automática por error, la conmutación por error pone en

línea rápidamente la copia en espera de la base de datos, sin pérdida de datos. En los demás

modos operativos, el administrador de bases de datos tiene la alternativa del servicio forzado

(con una posible pérdida de datos) para la copia en espera de la base de datos. Para obtener

más información, vea Conmutación de roles, más adelante en este tema.

Aumenta la protección de los datos. La creación de reflejo de la base de datos proporciona

una redundancia completa o casi completa de los datos, en función de si el modo de

funcionamiento es el de alta seguridad o el de alto rendimiento. Para obtener más

información, vea Modos de funcionamiento, más adelante en este tema.

Un asociado de creación de reflejo de la base de datos que se ejecute en SQL Server 2008

Enterprise o en versiones posteriores intentará resolver automáticamente cierto tipo de

errores que impiden la lectura de una página de datos. El socio que no puede leer una página,

solicita una copia nueva al otro socio. Si la solicitud se realiza correctamente, la copia

sustituirá a la página que no se puede leer, de forma que se resuelve el error en la mayoría de

los casos. Para obtener más información, vea Reparación de página automática (grupos de

disponibilidad/creación de reflejo de base de datos).

 Mejora la disponibilidad de la base de datos de producción durante las actualizaciones.

Para minimizar el tiempo de inactividad para una base de datos reflejada, puede actualizar

secuencialmente las instancias de SQL Server que hospedan los asociados de creación de

reflejo de la base de datos. Esto incurrirá en el tiempo de inactividad de solo una conmutación

por error única. Esta forma de actualización se denomina actualización gradual. Para obtener

más información, vea Instalar un Service Pack en un sistema con un tiempo de inactividad

mínimo para bases de datos reflejadas.

5.3 Activación de Espejeo en un DBMS

Para Windows

Para poder crear espejos dentro de Windows debemos asegurarnos que ambos

servidores se encuentren dentro de una red.

Ilustración 1 Servidor 1.
 Ilustración 2 Servidor 2.

Para Linux

 Cambie el comando ipconfig por ifconfig.

 Verificar que el mysql instado en el servidor 1 y 2 es el mismo.

Configuracion servidor 1

1. Localizar el archivo My.ini –Windows (My.cnf-Linux).

2. Buscar y comentar las líneas siguientes.

Ilustración 3 Líneas a comentar.

3. Agregar después de la línea mysqlold lo siguiente

Ilustración 4 Líneas a agregar.

4. Ahora en el Shell de mysql genere una cuenta para el esclavo con privilegio

REPLICATION SLAVE.

Ilustración 5 Cuenta.

5. Seleccionar la base de datos a replicar y realizar lo siguiente

Ilustración 6 Replica de base de datos.

5.4 Creación de Espacios de Disco con Espejo

Discos Espejo

Espejeado de disco significa que se conectan dos unidades de disco al mismo controlador

de disco. Las dos unidades se mantienen idénticas cuando el servidor escribe en una unidad

(la primaria), posteriormente se escribe en (la secundaria). Si durante la operación falla, la

unidad primaria, en su lugar se utiliza la secundaria. Si la secundaria falla, no importa. En

ambos casos los usuarios experimentan una breve pausa mientras el servidor se asegura que

la unidad está muerta, y luego se regresa al servicio normal.

Como sucede con todas las cosas buenas, hay una desventaja. Para contar con este nivel

de confiabilidad, se necesita un segundo disco duro, lo que duplica el costo del

almacenamiento de datos. Pero en lo que concierne a su organización, tal vez valga la pena

el costo relativamente pequeño de una unidad de disco, para evitar lo que de otra manera

seria un desastre. Una de las desventajas de los discos espejos es la perdida de rendimiento.

Dado que un controlador manejados unidades primarias para escribir los datos en la

unidad secundaria. Esto provoca que las escrituras en disco se tarden el doble. En un servidor

con carga ligera esto quizás no sea tan malo desde el punto de vista del usuario, ya que el

caché de disco del servidor hace que el acceso a disco perezca extremadamente rápido. Sin

embargo, la sobrecarga puede llegar a ser significativa en un sistema con carga pesada.

Otra de las desventajas del espejeado es que el controlador de disco duro o los cables de

conexión llegan a fallar. Los datos se pueden leer desde la unidad o matriz duplicada sin que

se produzcan interrupciones. Es una alternativa costosa para los grandes sistemas, ya que las

unidades se deben añadir en pares para aumentar la capacidad de almacenamiento, para los
disco espejos. Los discos espejos también llamado "duplicación" (creación de discos en

espejo).Se basa en la utilización de discos adicionales sobre los que se realiza una copia en

todo momento de los datos que se están modificando. El cual ofrece una excelente

disponibilidad delos datos mediante la redundancia total de los mismos. Administración del

espacio libre en un disco.

Es necesario saber qué bloques están libres. Las opciones son parecidas a las que se

pueden usar para administrar espacio en memoria. Mapa de bits. Un bit por bloque. Es

eficiente si se puede mantener el mapa entero en memoria. Disco de 1 GB, con bloques de

512 KB requiere un mapa de 256 KB. Usado en los MACS. Lista ligada. En un bloque

reservado (fijo) del disco se registran las direcciones de los bloques desocupados. La última

dirección apunta no a un bloque libre, sino a otro bloque con más direcciones de bloques

libres. En MS-DOS se usa la misma FAT para administrar el espacio libre.

Cachés de Disco

Ya que el disco es tan lento comparado con la memoria (unas 10000 veces) resulta

rentable usar un caché para mantener en memoria física parte de la información que hay en el

disco, de manera que, si en el futuro se requiere un bloque que ya está en memoria, se ahorra

el acceso al disco.

Igual que en el caso de memoria virtual, hay que tratar de adivinar qué bloques se van a

acceder en el futuro cercano, para mantener esos bloques en el caché. Pero al contrario de lo

que ocurre con memoria virtual, no se requiere ningún apoyo especial del hardware para

implementar LRU. Ya que todos los accesos a disco pasan por las manos del

sistema operativo. Paradójicamente, LRU no es necesariamente la mejor alternativa

tratándose de bloques de disco. Por otra parte, algunos delos bloques contienen información

crítica respecto del sistema de archivos. Si este bloque es modificado y puesto al final de la

cola LRU, puede pasar un buen tiempo antes de que llegue a ser el menos recientemente

usado, y sea escrito en el disco para ser reemplazado. Si el sistema se cae antes que eso, esa

información crítica se perderá, y el sistema de archivos quedará en un estado inconsistente.

Planificación de Disco

Un disco, mirado desde más bajo nivel, no es simplemente una secuencia de

bloques. Están compuestos de platos, cada uno de los cuales contiene una serie de pistas o

tracks concéntricos. A su vez, las pistas se dividen en sectores. Las pistas exteriores, que

son más grandes, pueden contener más sectores que las interiores. (En un CD, en realidad

hay una espiral de sectores.)Existe un brazo mecánico con un cabezal lector/escritor para

cada plato. El brazo mueve todos los cabezales juntos. Un cilindro se conforma por las pistas

que los cabezales pueden leer cuando el brazo está en una posición determinada. Los bloques

lógicos (secuenciales) que ve el sistema de archivos deben traducirse a un trío (cilindro, plato,

sector). El tiempo requerido para leer un sector depende de:

1. El tiempo de búsqueda (seek time), es decir, el tiempo requerido para mover el brazo al

cilindro apropiado.

2. El retardo rotacional, o sea, el tiempo que hay que esperar hasta que el sector requerido

pase por debajo del cabezal.

3. El tiempo de transferencia de los datos.

 El primero es el que predomina, de manera que conviene reducirlo para aumentar la

eficiencia del sistema. El sistema de archivo puede ayudar (por ejemplo, con asignación

contigua).Obviamente, bloques en el mismo cilindro deben considerarse contiguos. Pero hay

otra cosa que se puede hacer, considerando que en un sistema con muchos procesos la cola

de solicitudes pendientes de un dispositivo suele no estar vacía: atenderlas en un orden que

reduzca los movimientos del brazo.

Algoritmos de Planificación de Disco

FIFO

Es simple, pero no estamos haciendo nada por la eficiencia. Es malo si las solicitudes se

alternan entre cilindros exteriores e interiores.

SSTF (Shortest Seek-Time First)

Se trata de atender primero las solicitudes más cercanas a la posición actual del brazo. El

problema es que, cuando hay muchas solicitudes, es posible que sólo se atiendan las cercanas

al centro. Puede haber inanición para los procesos que solicitan cilindros delos extremos.

Algoritmo del Ascensor

Para evitar inanición, se mantiene la dirección de movimiento del brazo hasta que no

queden solicitudes pendientes en esa dirección. Es lo mismo que hacen los ascensores. Un

pequeño problema es que las solicitudes en los extremos tienen, en promedio, un tiempo

de espera mayor.
Discos RAM

Gracias a la estructuración en capas, podemos usar el mismo sistema de archivos en

cualquier dispositivo de bloques con un driver adecuado, que implemente la interfaz para el

software independiente del dispositivo. Por ejemplo, en los primeros computadores

personales, que tenían sólo una disquetera como medio de almacenamiento, era habitual crear

un disco RAM, es decir reservar un trozo de la memoria para usarlo como un disco virtual,

para almacenar archivos. Un driver de disco RAM es extremadamente simple.

5.5 Réplica (Replication)

La replicación es el proceso de copiar y mantener actualizados los datos en varios nodos

de bases de datos ya sean estos persistentes o no. Éste usa un concepto donde existe un nodo

amo o maestro (master) y otros sirvientes o esclavos (slaves).

La replicación de discos y particiones es la respuesta a una parte importante de esas dos

acciones de mantenimiento. La replicación es el proceso mediante el cual se genera una copia

exacta de parte del sistema. Esa parte puede ser desde un archivo hasta una carpeta, una

partición, un disco o incluso varios discos.

Copia de Seguridad

En condiciones normales, una base de datos replicada de forma correcta es válida como

copia de seguridad.

Además se puede realizar copias de seguridad usando un servidor esclavo para así no

interferir al servidor maestro.

Mejorar la Escalabilidad

Podríamos configurar nuestras aplicaciones para balancear las consultas de lectura

(SELECT) entre los servidores replicados.

Podríamos usar herramientas como MySQL Proxy para balancear las consultas de lectura

entre los servidores replicados y enviar las consultas de actualización de datos al maestro.

Alta Disponibilidad

En aplicaciones y entornos en donde sólo se requieren lecturas, podríamos configurar

nuestras aplicaciones para balancear las consultas de lectura (SELECT) entre los servidores

replicados de manera que si uno se cae se continúe prestando servicio.

El Log Binario

El log binario es un archivo binario gestionado por el servidor de base de datos en el que

se registran todas las sentencias SQL de modificación de datos o estructura.

En el caso de la replicación es importante saber que cada servidor esclavo se conecta al

servidor maestro y le solicita que le envíe las sentencias registradas en los logs binarios a

partir de una posición, para ello, cada esclavo mantiene un archivo a modo de índice en donde

registra la posición actual de la replicación.

Gracias a esto, podemos detener el esclavo (STOP SLAVE), que haya un corte de red,

etc... De manera que cuando se vuelva a iniciar la replicación (START SLAVE) o se

reestablezca la comunicación... Pase el tiempo que pase) el esclavo solicitará al maestro todas

las sentencias a ejecutar desde su estado actual y las irá ejecutando secuencialmente de
manera que en cuestión de segundos ambos servidores tendrán las bases de datos con el

mismo contenido y estructura.

Probando la Replicación

1. En el servidor esclavo ejecute el comando SHOW SLAVE STATUS y observe que el

mensaje que le muestra es un mensaje que indica que está esperando eventos del maestro...

2. Modifique algo en el maestro y verifique que instantáneamente se replica en el esclavo.

3. Detenga el esclavo durante un tiempo, realice cambios (cree tablas, modifique

registros...) en el maestro e inicie el esclavo. En cuestión de milisegundos ambas bases de

datos deberían de ser iguales.

5.5.1 Beneficios de la Réplica de Datos en un DBMS

La replicación se usa mucho en sistema de acceso a datos por varios motivos:

Rendimiento: Normalmente y dependiendo del caso, hay más lectura que escritura en

una base de datos, por lo que tener varios nodos solo procesando la lectura puede traer un

gran beneficio de rendimiento en una base de datos muy consultada.

Prueba de Fallas: Un esclavo estando casi sincrónicamente actualizado puede ser útil en

caso de que el nodo maestro caiga, este puede reemplazarlo y así no detener el servicio.

Fiabilidad: Muchas veces se puede tener una replicación para tener la seguridad de que

los datos están siendo copiados a otro nodo, en caso de sufrir un desperfecto en el maestro.
 Generación de Bloqueos: aunque ésta es más precisa, también se puede usar para

procesos que necesiten leer datos, generando bloqueos, al hacerlo sobre un esclavo esto no

interviene en el funcionamiento de todo el sistema, es muy usado para por ejemplo, hacer

copias de seguridad, o extraer grandes cantidades de datos para generar estadísticas.

5.6 Métodos de Respaldo de un DBMS

En mySQL existen varios métodos para la realización de un backup y esto se debe

principalmente a que mySQL guarda las tablas como archivos y al tipo de tablas que se esté

manejando (InnoDB, MyISAM, ISAM). Así por ejemplo para la presente práctica se utilizó

el tipo de tabla InnoDB y el método de backup utilizado es el que funciona con este tipo de

tablas.

InnoDB es una de las tecnologías de almacenamiento que utiliza mySQL, es de codigo

abierto. Entre sus características principales estan que soporta transacciones con

características ACID (Atomicidad, Consistencia, Aislamiento y Durabilidad), tiene bloque

de registros e integridad referencial (cosa que no maneja ISAM, ni myISAM). Esta última es

una de sus características más importantes pues una base de datos sin integridad referencial,

es nada más un conjunto de datos que no denotan información.

Este tipo de almacenamiento también ofrece una alta fiabilidad y consistencia. El mismo

gestiona el control de los datos y no se lo deja al sistema operativo, una de sus desventajas

es que no tiene una buena compresión de datos, por lo que ocupa un poco más de espacio que

myISAM.
5.8 Comandos para Respaldo de Datos

A continuación vamos a exponer los pasos y comandos para realizar la replicación de una

base de datos en un único servidor esclavo. Si quisiéramos configurar más esclavos, los pasos

a realizar serían los mismos sobre cada uno de los esclavos.

1. Creamos un usuario MySQL en el servidor maestro con privilegios de replicación.

2. El servidor esclavo se autentificará frente al servidor maestro como un usuario

normal.

3. Para crear el usuario debemos ejecutar desde la consola de comandos de mysql las

siguientes sentencias SQL:

CREATE USER '<replication_user>'@'<slave_address>' IDENTIFIED BY

'<replication_user_password>'

GRANT REPLICATION SLAVE ON *.* TO '<replication_user>'@'<slave_address>'

1. Con la sentencia anterior el usuario sólo tendría permiso de acceso desde la máquina

<slave_address>, en caso de no requerir esta medida de seguridad puedes sustituir el

comodín % por el parámetro <slave_address>.

Configuración del Servidor Maestro

Deberemos agregar las siguientes líneas al final del archivo de configuración del servidor

MySQL, por defecto: <MySQL_HOME>/my.ini

 1. Identificador único del servidor MySQL dentro de todos los servidores implicados en

la replicación.

Server – id = 1

2. Al especificar el parámetro log-bin estamos activando el log binario.

3. No especificamos un valor para el parámetro de configuración (por defecto será

<nombre_maquina > - bin).

Log – bin =

4. El log binario sólo tendrá las actualizaciones realizadas sobre la base de datos

"bd_autentia"

5. Si además quisiéramos replicar otras bases de datos, duplicaríamos este parámetro

para cada base de datos.

Binlog – do – db = bd_autentia

Configuración del Servidor Esclavo

1. Deberemos agregar las siguientes líneas al final del archivo de configuración del

servidor MySQL, por defecto: <MySQL_HOME>/my.ini

2. Identificador único del servidor MySQL dentro de todos los servidores implicados en

la replicación.

Server – id = 2
3. Nombre del archivo binario que almacena las instrucciones pendientes de ejecutar,

por defecto: <host_name> - relay - bin.index

Relay – log =

4. Nombre o dirección IP del maestro.

Master – host = <master_address>

5. El esclavo se conecta a través de un usuario al maestro. Identificador del usuario.

Master – user = <replication_user>

6. El esclavo se conecta a través de un usuario al maestro. Contraseña del usuario.

Master – password = <replication_user_password>

7. Número de segundos que esperará el esclavo para reintentar conectarse al maestro en

caso de una pérdida de conexión.

Master – connect – retry = 50

8. Número de reintentos de reconexión

Master – retry – count = 5000

9. Realizamos una copia de seguridad de la base de datos del maestro sobre el servidor

esclavo.
 Desde la consola ejecutamos los siguientes comandos:

[Maestro]: <MYSQL_HOME>/bin/mysql -u root –password = <contraseña> -e "FLUSH

TABLES WITH READ LOCK"

Para limpiar las caches y bloquear el acceso de cualquier aplicación a la base de datos.

[Maestro]: <MYSQL_HOME>/bin/mysqldump --u root –password = <contraseña> --opt

bd_autentia > backup.sql

Realizamos una copia completa de la base de datos en el archivo backup.sql.

[Esclavo]: <MYSQL_HOME>/bin/mysql --user=root –password = <contraseña>

bd_autentia < backup.sql

Para Restaurar la Copia de Seguridad en el Esclavo

[Esclavo]: <MYSQL_HOME>/bin/mysqladmin -u root –password = <contraseña>

shutdown

Detenemos el Servidor Esclavo

[Maestro]: <MYSQL_HOME>/bin/mysqladmin -u root –password = <contraseña>

shutdown

Detenemos el servidor maestro (Se desbloquearán las tablas de las bases de datos

previamente bloqueadas)
 [Esclavo]: <MYSQL_HOME>/bin/mysqld-nt –defaults

file="<MYSQL_HOME>\my.ini" MySQL

Iniciamos el Servidor, el cual Tomará la Nueva Configuración:

[Maestro]: <MYSQL_HOME>/bin/mysqld-nt --defaults-

file="<MYSQL_HOME>\my.ini" MySQL

5.9 Métodos de Recuperación de un DBMS

Recuperarse al fallo de una transacción significa que la base de datos se restaura al estado

coherente más reciente, inmediatamente anterior al momento del fallo para esto el sistema

guarda las información sobre los cambios de las transacciones esta información se guarda

en el registro del sistema.

1. Si hay un fallo como la caída del disco, el sistema restaura una copia se seguridad del

registro, hasta el momento del fallo.

2. Cuando el daño se vuelve inconsistente, se pueden rehacer algunas operaciones para

restaurar a un estado consistente. En este caso no se necesita una copia archivada.

Actualización Diferida: No se actualiza físicamente la base de datos Hasta que no haya

alcanzado su punto de confirmación.

Actualización Inmediata: La base de datos puede ser actualizada por Algunas

Operaciones antes de que esta última alcance su punto de confirmación.

Tipos de Almacenamiento

Almacenamiento Volátil: no sobrevive a las caídas del sistema.

Almacenamiento no Volátil: disco, cinta...: existen accidentes.

Almacenamiento Estable Frente al no Estable: la información no se pierde “nunca”, se

repite en varios medios no volátiles (disco) con modos de fallo independientes.

Almacenamiento en Caché (Búfer) de los Bloques de Disco

El proceso de recuperación se entrelaza con funciones del sistema operativo en particular

con el almacenamiento en caché o en búfer en la memoria principal, Normalmente se reserva

una colección de búferes en memoria, denominados caché DBMS. Se utiliza un directorio

para rastrear los elementos de la base de datos que se encuentra en los búferes.

Bit Sucio: que puede incluirse en la entrada del directorio, para indicar si se ha

modificado o no el búfer.

Pin: Un pin dice que una página en caché se está accediendo actualmente.

Actualización en el Lugar (In Place): Escribe en el búfer la misma ubicación de disco

original.

Shadowing (en la Sombra): Escribe un búfer actualizado en una ubicación diferente.

BFIM (Before Image): Imagen antes de la actualización.

AFIM (After Image): Imagen después de la actualización.

Registro Antes de la Escritura, Robar/No-Robar y Forzar no Forzar

En este caso, el mecanismo de recuperación debe garantizar la grabación de la BFIM de

los datos en la entrada apropiada del registro del sistema y que esa entrada se vuelque en el

disco antes que la BFIM sea sobrescrita con la AFIM de la base de datos del disco.

Puntos de Control en el Registro del Sistema y Puntos de Control Difusos

Otro tipo de entrada en el registro es el denominado punto de control (checkpoint). En este

punto el sistema escribe en la base de datos, en disco, todos los búferes del DBMS que se

han modificado.

No tienen que rehacer sus operaciones, es decir, ESCRIBIR en caso de una caída del

sistema.

El gestor de recuperaciones de un DBMS debe decidir en qué intervalos tomar un punto

de control.

La toma de un punto de control consiste en las siguientes acciones:

1. Suspender temporalmente la ejecución de las transacciones.

2. Forzar la escritura de disco de todos los búferes de memoria que se hayan

modificado.

3. Escribir un registro (checkpoint) en el registro del sistema y forzar la escritura

del registro en el disco.

 4. Reanudar la ejecución de las transacciones.

Diarios para Recuperación

 Se utilizan también los términos log y journal.

 Mantiene un registro de todas las operaciones que afectan a ítems de la base de datos.

 Esta información permite recuperar.

 Se almacena en disco.

 Operaciones posibles a reflejar:

[start, T]

[write, T, X, valor_viejo, valor_nuevo] (Opcional)

[read, T, X]

[commit, T]

[abort, T]

undo, redo
 Técnicas de Recuperación Basadas en la Actualización Diferida

Graba todas las actualizaciones de la BD en el diario, pero aplaza la ejecución de todas las

operaciones de escritura (write) de una transacción hasta que ésta se encuentre parcialmente

cometida.

Solamente requiere el nuevo valor del dato.

Si la transacción aborta (no llega a committed), simplemente hay que ignorar las anotaciones

en el diario.

Para recuperaciones usa el procedimiento: redo (Ti), que asigna los nuevos valores a todos

los datos que actualiza Ti.

Después de ocurrir un fallo, se consulta el diario para determinar que transacciones deben

repetirse y cuales anularse.

Ti debe anularse si el diario contiene el registro start pero no el commit.

Ti debe repetirse si el diario contiene el registro start y el commit.

La operación redo debe ser idempotencia, es decir, ejecutarla varias veces debe producir el

mismo resultado que ejecutarla una sola vez.

Los Redo comienzan a hacerse en el último checkpoint no sabemos si la información está en

disco o en memoria.
Recuperación Mediante la Actualización Diferida en un Entorno Monousuario

El algoritmo RDU se utiliza un procedimiento rehacer, proporcionado con posterioridad.

Para rehacer determinadas operaciones escribir_elemento.

Recuperaciones Basadas en Actualizaciones Inmediatas

Permite que las actualizaciones se graben en la BD mientras la transacción está todavía en

estado activo (actualizaciones no cometidas).

Antes de ejecutar un output (X), deben grabarse en memoria estable los registros del diario

correspondientes a X.

Los registros del diario deben contener tanto el valor antiguo como el nuevo.

El esquema de recuperación utiliza dos procedimientos de recuperación:

undo (Ti): Restaura los datos que Ti actualiza a los valores que tenían antes.

redo (Ti): Asigna los nuevos valores a todos los datos que actualiza Ti.

Después de ocurrir un fallo, el procedimiento de recuperación consulta el diario para

determinar qué transacciones deben repetirse y cuáles deshacerse:

1. Ti debe deshacerse si el diario contiene el registro starts pero no el commit.

2. Ti debe repetirse si el diario contiene el registro starts y el commit.

 3. Las operaciones undo y redo deben ser idempotencias para garantizar la consistencia

de la BD aun cuando se produzcan fallos durante el proceso de recuperación.

Recuperación Hasta un Punto de Validación

1. Examina el diario hacia atrás hasta localizar un registro <checkpoint>.

2. Considera sólo los registros existentes entre este punto y el final del diario.

3. Ejecuta undo (Tj) para las transacciones que no tengan registro <Tj commits>,

partiendo del final del fichero.

4. Ejecuta redo (Ti) para las transacciones que tengan su registro <Ti commits>,

partiendo desde el punto de verificación hasta el final del diario.

Procedimientos de Recuperación

Recuperación Normal

Tiene lugar después de una parada normal de la máquina, en la que se escribe un punto de

verificación como último registro del diario.

Este procedimiento se ejecuta cuando el último registro del diario es un punto de verificación

o recuperación del sistema.

Este tipo de recuperación también tiene lugar cuando aborta una transacción, debido a la

razón que sea.

Recuperación en Caliente

Después de un error del sistema.

Se ejecuta cuando el último registro del diario no es un punto de verificación y el operador

no indica pérdida de memoria secundaria.

El procedimiento de recuperación es el indicado en el apartado referente a los puntos de

verificación en el diario.

Recuperación en Frío

Después de un incidente con la memoria masiva dañada.

Se ejecuta si se pierden datos o la BD ya no es coherente.

Se utiliza:

Copia de seguridad (backup) más reciente de la BD (Debe existir).

Diario de las actividades posteriores.

Se aplican las imágenes posteriores al respaldo.

Puede encadenar una recuperación en caliente.

Se deben realizar copias de seguridad de la BD periódicamente:

Toda la BD debe copiarse en memoria secundaria.

El proceso de transacciones debe pararse durante el procedimiento de copia (Costoso).

Algoritmo de Recuperación ARIES

a) El registro del sistema en el momento de la caída.

b) Las tablas de transacciones y de páginas sucias en el momento de punto de control.

c) Las tablas de transacciones y de páginas sucias después de la fase de análisis.

5.10 Comandos para Recuperación

Hacer una Copia de Seguridad

El comando a utilizar es mysqldump que tiene la siguiente sintaxis:

mysqldump -u [user] -p [dbname] > [backup.sql]

Puesto que se pretende obtener un “foto fija” de la base de datos, es conveniente evitar

que un acceso inoportuno pueda dejar el fichero volcado es un estado inconsistente. Esto se

puede conseguir con varias opciones aunque la recomendada es --single-transaction.

Recuperar la Base de Datos desde un Fichero

Se utiliza el método habitual para ejecutar sentencias SQL desde un fichero. Para el

ejemplo sería:

# mysql -u admin -p drupal < drupal_backup.sql

5.11 Ventajas y Desventajas de cada Método

Ventajas

 Facilidad de manejo de grandes volumen de información.

 Gran velocidad en muy poco tiempo.

 Independencia del tratamiento de información.

 Seguridad de la información (acceso a usuarios autorizados), protección de

información, de modificaciones, inclusiones, consulta.

 No hay duplicidad de información, comprobación de información en el momento de

introducir la misma.

 Integridad referencial el terminar los registros.

Desventajas

 El costo de actualización del hardware y software son muy elevados.

 Costo (salario) del administrador de la base de datos es costoso.

 El mal diseño de esta puede originar problemas a futuro.

 Un mal adiestramiento a los usuarios puede originar problemas a futuro.

 Si no se encuentra un manual del sistema no se podrán hacer relaciones con facilidad.

 Generan campos vacíos en exceso.

 El mal diseño de seguridad genera problemas.

5.12 Aplicación de cada Método

Copia Simple

Puede ser aplicado en situaciones en las que no requiera de varias instancias o datos

duplicados, como una Red de Oficina.

Copia Doble

Cuando requiera de un soporte estable y práctico a la hora de fallos en el sistema.

Ejemplo:

Supóngase que se deterioró físicamente parte del disco, afectando la aplicación. Por lo

cual es necesario recuperarla. Se toma el primer juego de respaldo, se intenta hacer la copia

del respaldo al disco y aparece error de lectura en el respaldo. Se usa entonces el segundo

juego y ocurre lo mismo. Al analizar lo ocurrido se detecta que además de haberse

deteriorado el disco, está dañada la unidad encargada de grabar los respaldos y al tratar de

leer los mismos los daña.

Resultado:

La aplicación en disco no funciona y los dos juegos de respaldo quedaron inutilizados. De

aquí se concluye la necesidad de hacer otra copia del respaldo, antes de intentar la

recuperación.
 Copia Generacional

Cuando este contenga mayores instancias y requiera de un gran rendimiento de los datos,

como los Bancos.

5.13 Migración de la Base de Datos

La migración de bases de datos es generalmente una tarea compleja que no sólo supone

transferir datos entre tipos de almacenaje y formatos de un servidor de base de datos a otro;

sino que también supone reescribir sentencias SQL o incluso procedimientos (SPL) de lógica

de negocio.

En comparación con los esquemas estándares de migración a mano, ofrecemos una

potente gama de herramientas desarrolladas de probada eficacia en complejos módulos de

bases de datos relacionales. Estas herramientas y nuestros especialistas pueden asegurar que

las transiciones de las bases de datos se realicen perfectamente, independientemente de la

naturaleza del sistema.

Desde la experiencia, estamos familiarizados con la complejidad, el coste que supone una

larga migración de bases de datos y los problemas que aparecen durante el proceso cuando

se emplean métodos inapropiados; ya que siempre comprobamos con los clientes potenciales

que el uso de nuestras herramientas y métodos pueda ofrecer una ventaja significativa.

Herramientas de Migración

En comparación con la consultoría estándar de migraciones, la cual puede ofrecer poco

más que soporte a la base de datos, nosotros tenemos gran experiencia en escribir grandes
aplicaciones para empresas en sintaxis de la base de datos nativa y cross. Además, enseñamos

a los equipos de las empresas una metodología y les proporcionamos una potente gama de

herramientas para reducir costes y optimizar el proceso de migración.

Estas herramientas incluyen:

Herramienta de copia multi-bases de datos con conversión automática desde los tipos de

datos (incluyendo tipos de datos geométricos)

Comprobación del esquema multi-base de datos

Gramática SQL XML

Gramática DDL XML

Gramática DML XML

Gramática SPL XML

Gramática Triggers XML

Soporte para la conversión de tipos de datos geométricos

Copia Multi-Base de Datos

La herramienta de copia puede replicar todos los datos desde una base de datos a una

destinación, independientemente del motor, las tablas creadas, los índices, las restricciones y

el mapeo de tipos de datos cuando los motores difieren. Con poco esfuerzo, y después del
tiempo que supone copiar los datos, se puede ver y explorar los datos en la nueva base de

datos. Por supuesto, no se realiza una migración en estos casos.

Genera estructuras de tablas acorde con los tipos de datos objetivo

Desactiva automáticamente triggers y secuencias durante el proceso de copia

Instala automáticamente la secuencia asociada después de copiar una tabla

Soporta la generación de bases de datos cruzadas rowid

Soporta la conversión de tipos de datos geométricos permitiendo una fácil migración de

motores espaciales

Soporta la construcción de índices post-copia y foreign keys

Soporta la compilación de triggers post-copia y SPL

Comprobación del Esquema Multi-Bases de Datos

Una vez se empieza una migración, se puede generar un esquema XML desde la base de

datos original. Esto permite traducir el modelo de base de datos a cualquier motor.

Sin embargo, ¿qué pasa si el sistema continúa operando e incluso sufre cambios

estructurales durante el proceso de migración? La comprobación del esquema compara las

bases de datos de tipos diferentes y muestra las diferencia entre estructuras de tablas, claves

primarias, foreign keys, índices y restricciones. También, se puede hacer una comparación
con el modelo de esquema maestro en XML. En ambos casos, se aplicará una propuesta de

cambios para asegurar que se muestra la misma estructura física.

Soporte al Desarrollo, Test, Pre-Producción y Producción

Las herramientas de migración están construidas alrededor de un diccionario de base de

datos. El diccionario permite a los programadores almacenar su código (sentencias DML,

queries SQL, código SPL, datos de tablas iniciales, etc.), el cual constituye la base de datos

de las aplicaciones. Una vez almacenado en el diccionario, un grupo de comandos web o

comandos shell permite la compilación, el chequeo o la salida de nuevas actualizaciones para

una base de datos o un grupo.

Sintaxis Xml-Xsql

El motor de traducción de triggers DDL, DML, SPL proporciona una estructura con una

sintaxis común XML, en la cual los desarrolladores pueden escribir aplicaciones en una

sintaxis independiente de la propia del motor de base de datos.

XML-XSQL Syntax Available

DDL

El proceso de copia de una base de datos puede crear automáticamente un modelo XML

que genera el Data Definition Language (DDL) de la base de datos. Se pueden ver todas las

tablas y objetos definidos en una definición natural XML que permitirá la traducción on-line

a la base de datos deseada.

DDL - XML Transformation Sample

 DML

Una gramática XML permite escribir sentencias SQL independientes de la base de datos.

Procedimientos (Spl)

La lógica de negocio escrita en procedimientos (SPL), funciones o triggers debe ser

reescrita manualmente en XML. Nosotros ofrecemos este servicio o enseñamos como

hacerlo. A partir de entonces, se podrá traducir automáticamente la lógica al motor que se

desee.

Este paso tiene una mayor ventaja sobre la codificación manual convencional, ya que el

motor de traducción Axional XSQL validará y generará el código apropiado sin errores

humanos.

El manager de procedimientos (SPL) se encargará del status de compilación en las bases

de datos deseadas (desarrollo, test y producción).

Triggers

Si tiene triggers, quizás es conocedor de la complejidad y las diferencias que supone

escribir triggers independientes de la base de datos. Como en el caso de los procedimientos

(SPL), se puede utilizar gramática XML y el motor de de traducción generará los triggers

apropiados para la base de datos deseada.

Tipos de Datos Geométricos

 Cuando la base de datos tiene tipos de datos geométricos, constituye un caso especial.

Ofrecemos transportabilidad entre Oracle Spatial, DB2 Spatial Extender, Informix Spatial

DataBlade y Postgres PostGIS. La gramática DML ofrece una amplia gama de funciones

para escribir queries independientes de SQL y el motor de copia DB transferir los datos de

forma segura.

5.14 Monitoreo y Auditoría de la Base de Datos

Mediante la auditoría se intenta monitorizar y registrar acciones en la base de datos con el

fin de:

 Investigar actividades maliciosas (borrado de tablas,..)

 Detectar privilegios incorrectamente otorgados a usuarios (que permiten realizar

acciones inapropiadas, las cuales son detectadas).

 Recoger datos sobre actividades concretas (tablas que se actualizan, usuarios

concurrentes,…)

 Detectar problemas con la implementación de políticas de seguridad (puntos débiles

que generan registros).

5.3.1.1 Monitoreo General de un Sistema Manejador de Base de Datos

Ventajas del monitoreo de un sistema manejador de base de datos:

· Incrementa la Disponibilidad de una Base de Datos: Si se produce un

desastre en el modo de alta seguridad con conmutación automática por error, la

conmutación por error pone en línea rápidamente la copia en espera de la base de

datos, sin pérdida de datos. En los demás modos operativos, el administrador de bases
 de datos tiene la alternativa del servicio forzado (con una posible pérdida de datos)

para la copia en espera de la base de datos. Para obtener más información, vea

Conmutación de roles, más adelante en este tema.

· Aumenta la Protección de los Datos: La creación de reflejo de la base de datos

proporciona una redundancia completa o casi completa de los datos, en función de si

el modo de funcionamiento es el de alta seguridad o el de alto rendimiento. Para

obtener más información, vea Modos de funcionamiento, más adelante en este tema.

Un asociado de creación de reflejo de la base de datos que se ejecute en SQL Server 2008

Enterprise o en versiones posteriores intentará resolver automáticamente cierto tipo de

errores que impiden la lectura de una página de datos. El socio que no puede leer una página,

solicita una copia nueva al otro socio. Si la solicitud se realiza correctamente, la copia

sustituirá a la página que no se puede leer, de forma que se resuelve el error en la mayoría de

los casos. Para obtener más información, vea Reparación de página automática (grupos de

disponibilidad/creación de reflejo de base de datos).

· Mejora la Disponibilidad de la Base de Datos de Producción Durante las

Actualizaciones: Para minimizar el tiempo de inactividad para una base de datos reflejada,

puede actualizar secuencialmente las instancias de SQL Server que hospedan los asociados

de creación de reflejo de la base de datos. Esto incurrirá en el tiempo de inactividad de solo

una conmutación por error única. Esta forma de actualización se denomina actualización

gradual. Para obtener más información, vea Instalar un Service Pack en un sistema con un

tiempo de inactividad mínimo para bases de datos reflejadas.

5.3.2 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 regresan 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 pueden ser útiles:

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

create table #FreeSpace(

Drive char(1),

MB_Free int)

insert into #FreeSpace exec xp_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_Free int

create table #FreeSpace(

Drive char(1),

MB_Free int)

insert into #FreeSpace exec xp_fixeddrives

select @MB_Free = MB_Free from #FreeSpace where Drive = 'C'

 -- Free Space on C drive Less than Threshold

if @MB_Free < 1024

exec master.dbo.xp_sendmail

@recipients ='greg.larsen@netzero.net',

@subject ='SERVER X - Fresh Space Issue on C Drive',

@message = 'Free space on C Drive has dropped below 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.

5.3.1.3 Monitoreo de Logs

Log

Registro oficial de eventos durante un periodo de tiempo en particular. Para los

profesionales en seguridad informática un log es usado para registrar datos o información

sobre quién, que, cuando, donde y por qué de un evento que ocurre para un dispositivo en

particular o aplicación.

La mayoría de los logs son almacenados o desplegados en el formato estándar ASCII. De

esta forma logs generados por un dispositivo en particular puede ser leído y desplegado en

otro diferente.

Propósito de los Logs

Todos los sistemas pueden verse comprometidos por un intruso, de manera local o remota.

La seguridad no sólo radica en la prevención, sino también en la identificación. Entre

menos tiempo haya pasado desde la identificación de intrusión, el daño será menor; para

lograr esto es importante hacer un constante monitoreo del sistema.

De cualquier forma que se realice una protección de Unix debe incluir el monitoreo y

revisión de LOGS de una forma comprensiva, precisa y cuidadosa.

 Los logs tienen numerosos propósitos:

· Ayudar a resolver problemas de todo tipo

· Proveer de avisos tempranos de abusos del sistema.

· Después de una caída del sistema, proporcionan datos de forensia.

· Como evidencia legal

Monitoreo en Bitácoras

Generalmente no deseamos permitir a los usuarios ver los archivos de bitácoras de un

servidor, y especialmente no queremos que sean capaces de modificarlos o borrarlos.

Normalmente la mayoría de los archivos de bitácoras serán poseídos por el usuario y grupo

root, y no tendrán permisos asignados para otros, así que en la mayoría de los casos el único

usuario capaz de modificar los archivos de bitácoras será el usuario root.

Debido a la cantidad de información que se genera en la bitácoras, siempre es bueno

adoptar algún sistema automático de monitoreo, que levante las alarmas necesarias para

cuando algún evento extraño suceda.

El sistema operativo Debian utiliza LogCheck para realizar el análisis y monitoreo de

bitácoras, RedHat emplea LogWatch, etc.

5.3.1.4 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:

1. Buffers de Base de Datos, Database Buffer Cache

Es el caché que almacena los bloques de datos leídos de los segmentos de datos de la BD,

tales como tablas, índices y clústeres. 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 cambios 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 análisis

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 mantiene en memoria. De esta manera se premia la uniformidad en la

programación de las aplicaciones. La igualdad se entiende que es lexicográfica, 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 tamaño viene

determinado por el parámetro SHARED_POOL_SIZE.

5.3.1.5 Monitoreo de Base de Datos

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 Base de Datos

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.

Importancia de la Auditoría de Base de Datos

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

Datos a Evaluar por Medio de la Auditoría de la Base de Datos:

· 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

o Soportar diferentes esquemas de auditoría.

o Se debe tomar en cuenta el tamaño de las bases de datos a auditar y los

posibles SLA establecidos.

· Segregación de Funciones
 o 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

o Información para auditoría y seguridad.

o Información para apoyar la toma de decisiones de la organización.

o Información para mejorar el desempeño de la organización.

· Auditoría Completa y Extensiva

o Cubrir gran cantidad de manejadores de bases de datos.

o Estandarizar los reportes y reglas de auditoría.

5.3.1.6 Monitoreo de Modos de Operación

Las operaciones forman parte de las actividades diarias relacionadas con el hardware y

software utilizado en las organizaciones. Esta función es particularmente importante cuando

se ejecutan tares de cómputos centralizados y destacan las siguientes:

1. Administración de Recursos: La administración es responsable de asegurar que

los recursos necesarios estén disponibles para realizar las actividades.

2. Normas y Procedimientos: La administración es responsable por establecer las

normas y los procedimientos necesarios para todas las operaciones en conformidad

con las estrategias y políticas generales del negocio.

3. Monitoreo de los Procesos de Operación: La administración es responsable de

monitorear y medir la efectividad y eficiencia de los procesos de operación. La

administración es responsable de monitorear y medir la efectividad y eficiencia de los

procesos de operación, de modo que los procesos sean mejorados a través del tiempo.

4. Operaciones de Plataforma de Hardware

5. Soporte Técnico

6. Cronogramas de Ejecución de Trabajos

7. Control de Entrada/Salida de Datos

8. Aseguramiento de Calidad

9. Control de Cambios

10. Administración de la Configuración

11. Función de Bibliotecario

12. Procedimientos de Administración de Problemas

13. Procedimientos para Monitorear el Uso Eficaz y Eficiente de los Recursos

14. Administración de la Seguridad Física y del Ambiente

15. Administración de la Seguridad de Información

 Bibliografía

 Pons Capote, Olga, Introducción a las bases de datos. El modelo relacional,

Thomson Paraninfo, S.A., 2005

 G.W. Hansen, J.V. Hansen (2007), Diseño y Administración de Bases de Datos.

Segunda Edición , Prentice Hall