You are on page 1of 28

Instituto Tecnológico De Villahermosa

Ing. Sistemas Computacionales
Materia:
Administración de base datos

Proyecto:
Seguridad
Profesora:

Lic. Loyda Sánchez Marín
Alumnos:
Agustín Morales Salvador

Villahermosa Tab. Diciembre De 2014

Índice
5.1 Respaldo y Recuperación............................................................................................................ 3
Qué Respaldar y Cuándo.......................................................................................................... 3
5.1.1 Espejeo (Mirroring) ................................................................................................................. 4
5.1.1.1 Beneficios del Espejeo de Datos en un DBMS .................................................................... 4
5.1.1.2 Activación de Espejeo en un DBMS ................................................................................... 5
5.1.1.3 Creación de Espacios de Disco con Espejo.......................................................................... 5
5.1.2. Réplica (Replication) ............................................................................................................... 7
5.1.2.1 Beneficios de la Réplica de Datos en un DBMS .................................................................. 8
5.1.3 Métodos de Respaldo de un DBMS ........................................................................................ 9
5.1.3.1 Elementos y Frecuencia de Respaldo................................................................................... 9
5.1.3.2 Comandos para Respaldo de Datos ................................................................................... 10
5.1.3.3 Métodos de Recuperación de un DBMS ............................................................................ 12
5.1.4. Comandos para Recuperación ............................................................................................. 16
5.1.4.1 Ventajas y Desventajas de cada Método ........................................................................... 16
5.1.4.2 Aplicación de cada Método................................................................................................. 17
5.2 Migración de la Base de Datos ................................................................................................. 17
5.3 Monitoreo y Auditoría de la Base de Datos ............................................................................ 19
5.3.1 Monitoreo ................................................................................................................................ 19
5.3.1.1 Monitoreo General de un Sistema Manejador de Base de Datos .................................... 20
5.3.1.3 Monitoreo de Logs............................................................................................................... 22
5.3.1.4 Monitoreo de Memoria Compartida ................................................................................. 22
5.3.1.5 Monitoreo de Base de Datos ............................................................................................... 24
5.3.1.7 Monitoreo de Espacios Espejeados .................................................................................... 25
5.3.2 Auditoría ................................................................................................................................. 25
5.3.2.1 Habilitación y Deshabilitar el Modo de Auditoría ........................................................... 26
5.3.2.2 Consultas de las Tablas Vistas con Información de la Auditoría ................................... 26
5.4 Herramientas de Software y Hardware para Monitoreo y Administración Automática ... 27

pág. 2

5.1 Respaldo y Recuperación
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.

Qué Respaldar y Cuándo
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.
Cómo Respaldar
En general, existen dos recursos en los que puedes respaldar tu información: medios físicos o
almacenamiento en la nube. Ejemplos de medios físicos incluyen DVD‟S, dispositivos USB, cintas
magnéticas o discos duros adicionales. Evita respaldar en el mismo dispositivo que contiene los
archivos originales. Cuando uses medios físicos asegúrate de etiquetarlos, tanto interna (en el
nombre del archivo) como externamente (sobre el dispositivo), para que puedas identificar
fácilmente fecha y hora del respaldo.
Puedes almacenar el respaldo en un contenedor con llave, a prueba de fuego y de agua, dependiendo
del medio que elegiste. Una opción más robusta es almacenar copias de tus respaldos fuera de las
instalaciones. Para respaldos personales, puede ser tan simple como almacenarlos en casa de un
miembro de la familia o en una caja de seguridad. Las organizaciones quizá deseen contratar un
servicio profesional para transportar y almacenar los respaldos de forma segura. Dependiendo de
qué tan sensibles sean y dónde se almacenen los respaldos, tal vez convenga cifrarlos.
Muchos de estos problemas se solucionan con respaldos en la nube. Realizar copias de seguridad en
la nube es tan sencillo como instalar o configurar una aplicación en tu computadora. Después de
configurar las opciones de respaldo, archivos nuevos y modificados son respaldados
automáticamente a través de Internet en servidores del centro de datos del proveedor.
Finalmente, necesitas decidir por cuánto tiempo conservarás tus respaldos. Es probable que los
usuarios caseros no necesiten mantenerlos por más de treinta días. Algunas organizaciones cuentan
con políticas o requerimientos legales para resguardar por periodos más largos, así como reglas para
la destrucción de respaldos obsoletos. Si estás respaldando información de tu organización, verifica
con el grupo de TI, legal o de gestión de registros para estar seguro. Respecto a las opciones de

pág. 3

respaldo en la nube, es posible que te cobren con base a la cantidad de datos que respaldes, así que
es importante ser cuidadoso de no acumular una gran deuda.
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.

5.1.1 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.1.1.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.

pág. 4

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.1.1.2 Activación de Espejeo en un DBMS

5.1.1.3 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

pág. 5

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
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,

pág. 6

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.1.2. 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.
La replicación es útil para:
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.

pág. 7

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

pág. 8

5.1.3 Métodos de Respaldo de un DBMS
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
.
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 código abierto.
Entre sus características principales están 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.1.3.1 Elementos y Frecuencia de Respaldo
Normalmente cuando uno plantea que va a respaldar los datos de su PC a una persona en una
compañía uno tiene que definir muy bien cuál es la información crítica para la empresa, por ejemplo
la música que guarde un empleado en su PC no es crítica para las actividades de la empresa ni lo
son las fotos de su última fiesta. En cambio su correo electrónico, proyectos, informes y papeles
administrativos si lo suelen ser y tener un respaldo de estos es clave para el funcionamiento de la
empresa en caso de cualquier eventualidad.
Normalmente lo datos o información que es respaldada por las empresas es:
Archivos creados por aplicaciones, como por ejemplo .doc, .odt, .xls, .mdb, .pdf, .ppt entre otros.







Archivos de correo electrónico
Directorios telefónicos y de contactos
Favoritos de los navegadores como Firefox e Internet Explorer
Base de datos
Configuraciones de los equipos
Archivos de CAD, PSD, XCF, etc.
Imágenes y Fotografías de proyectos
Configuraciones de servicios

Clasificación de Respaldos

pág. 9

Copias de Información (Backups)
Estos respaldos son sólo duplicados de archivos que se guardan en "Tape Drives" de alta capacidad.
Los archivos que son respaldados pueden variar desde archivos del sistema operativo, bases de
datos, hasta archivos de un usuario común. Existen varios tipos de Software que automatizan la
ejecución de estos respaldos, pero el funcionamiento básico de estos paquetes depende del
denominado archive bit.
Este archive bit indica un punto de respaldo y puede existir por archivo o al nivel de "Bloque de
Información" (típicamente 4096 bytes), esto dependerá tanto del software que sea utilizado para los
respaldos así como el archivo que sea respaldado. Este mismo archive bit es activado en los
archivos (o bloques) cada vez que estos sean modificados y es mediante este bit que se llevan a
cabo los tres tipos de respaldos comúnmente utilizados:
Respaldo Completo ("Full")
Guarda todos los archivos que sean especificados al tiempo de ejecutarse el respaldo. El archive bit
es eliminado de todos los archivos (o bloques), indicando que todos los archivos ya han sido
respaldados.
Respaldo de Incremento ("Incremental")
Cuando se lleva a cabo un Respaldo de Incremento, sólo aquellos archivos que tengan el archive bit
serán respaldados; estos archivos (o bloques) son los que han sido modificados después de un
Respaldo Completo. Además cada Respaldo de Incremento que se lleve a cabo también eliminará el
archive bit de estos archivos (o bloques) respaldados.
Respaldo Diferencial ("Differential")
Este respaldo es muy similar al "Respaldo de Incremento", la diferencia estriba en que el archivo bit
permanece intacto.
Frecuencia de Actualización de la Información
Hay dos puntos importantes en cuanto a la actualización de la información:
 Que tan frecuentemente se actualiza la información
 Si queremos guardar un histórico de la información o no
No toda la información se actualiza con la misma frecuencia, hay información que puede durar años
sin ser modificada y otra que se actualice constantemente todos los días, es importante definir qué
información se actualiza y en qué momento para hacer una política de respaldo más eficiente.
La mayoría de las aplicaciones de respaldos hacen esto automáticamente fijándose en la fecha de
modificación del archivo y comparándola con la que tiene en el respaldo.
El otro punto es si queremos hacer un respaldo con históricos o duplicados, en este caso tenemos
que indicarle al programa que no queremos que nos borre o sobrescriba ningún archivo y que vaya
guardando los archivos con su respectiva fecha y con qué frecuencia queremos hacer el respaldo.
En caso de que haya información que se pueda sobrescribir o actualizar, se realiza un respaldo
incremental donde sólo se actualiza lo que ha cambiado del archivo lo que mejora la eficiencia de
nuestro sistema. Esto realmente va a depender del tipo de información y varía de empresa a empresa
pero es algo importante que tengamos que tomar en cuenta ya que toda la información no es igual.

5.1.3.2 Comandos para Respaldo de Datos

pág. 10

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>'
4.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
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 = 1
3. Al especificar el parámetro log-bin estamos activando el log binario.
4. No especificamos un valor para el parámetro de configuración (por defecto será
<nombre_maquina > - bin).
Log – bin =
5. El log binario sólo tendrá las actualizaciones realizadas sobre la base de datos "bd_autentia"
6. 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

pág. 11

9.
esclavo.

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

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

pág. 12

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.

pág. 13

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.

Actualización Diferida con Ejecución Concurrente en un Entorno Multiusuario
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:
(Ti): Restaura los datos que Ti actualiza a los valores que tenían antes.
(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.
·
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.

pág. 14

·
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
1. 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.
Respaldos de Bases de Datos
Siempre es necesario tener un respaldo de nuestras bases de datos, pero que pasa cuando nuestras
bases de datos están tan pesadas que el phpMyAdmin se queda colgado. Para eso nos sirve
mysqldump un comando que nos trae MySQL para hacer respaldos de nuestras bases de datos su
sintaxis es la siguiente:
mysqldump [OPTIONS] database [tables]
O mysqldump [OPTIONS] –databases [OPTIONS] DB1 [DB2 DB3...]
O mysqldump [OPTIONS] –all-databases [OPTIONS]
Algunos de sus parámetros más utilizados son los siguientes:
-A, –all-databases Dump all the databases. This will be same as –databaseswith all databases
selected.
add-drop-database Add a „DROP DATABASE‟ before each create.
add-drop-table Add a „drop table‟ before each create.
add-locks Add locks around insert statements.
allow-keywords Allow creation of column names that are keywords.
create-options Include all MySQL specific create options.
e, –extended-insert Allows utilization of the new, much faster INSERT syntax.
p, –password[=name] Password to use when connecting to server. If password is not given it‟s
solicited on the tty.
u, –user=name User for login if not current user.
Bien, ahora colocamos un ejemplo de su uso:
#Respaldando una única base de datos
mysqldump -uroot -p –all –add-locks -e mibase > bkmibase.sql;
#Respaldar todas mis bases de datos
mysqldump -uroot -p –all –all-databases –add-locks -e > bkmisbases.sql;
#Nos conectamos a mysql
mysql -uroot -p
USE mibase;

pág. 15

source /path/TO/mibase.sql;
Como comentario para importar tablas tipo innodb se recomienda agregar:
SET FOREIGN_KEY_CHECKS=0;
Al inicio del archivo y al final con el fin de no obtener errores.
SET FOREIGN_KEY_CHECKS=1;
Soporte para Control de Transacciones y Recuperación de Fallas
Se conoce como transacción toda operación que se haga sobre la base de datos. Las transacciones
deben por lo tanto ser controladas de manera que no alteren la integridad de la base de datos. La
recuperación de fallas tiene que ver con la capacidad de un sistema DBMS de recuperar la
información que se haya perdido durante una falla en el software o en el hardware.

5.1.4. 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.1.4.1 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.

pág. 16

5.1.4.2 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.2 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.

pág. 17

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

pág. 18

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.3 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 Monitoreo
La expresión monitoreo es bastante difundida en el lenguaje cotidiano y la encontramos a menudo
en las noticias de prensa en relación con fenómenos de interés colectivo tales como, por ejemplo, la
medición de la calidad del aire en las ciudades, el medioambiente, el tráfico urbano, las
enfermedades, etc. Podemos fácilmente constatar que en las sociedades contemporáneas se está

pág. 19

afirmando la tendencia a someter a monitoreo fenómenos complejos que atañen a la vida de los
ciudadanos.
En Bogotá, para citar un caso, existe un proyecto, denominado “Bogotá Cómo Vamos”, definido
como “un ejercicio ciudadano de seguimiento periódico y sistemático a los cambios en la calidad de
vida de la ciudad. Esta observación tiene como énfasis el cumplimiento de la Administración
Distrital al Plan de Desarrollo y se realiza en términos de mayor acceso a bienes y servicios de
mejor calidad, teniendo en cuenta tanto indicadores técnicos como la percepción ciudadana.
El Proyecto, producto de la Alianza Interinstitucional entre la Casa Editorial El Tiempo, la
Fundación Corona y la Cámara de Comercio de Bogotá, se gestó durante la campaña electoral de
1997, ante la ausencia de un ejercicio ciudadano de rendición de cuentas que verificara el
cumplimiento de las promesas electorales del candidato, ya elegido como alcalde, y su impacto en
la calidad de vida de la ciudad.” El proyecto analiza indicadores relativos a pobreza y equidad,
finanzas públicas, educación, salud, servicios públicos, responsabilidad ciudadana, entre otros.
En el campo que nos ocupa en este curso, en cambio, el monitoreo o seguimiento cumple la función
de recolectar, registrar y procesar informaciones útiles para describir sistemáticamente el estado de
avance de un proyecto con el doble fin de documentar su desempeño y adquirir conocimientos
indispensables para orientar su gestión y trayectoria. Se trata de una función cuya centralidad nadie
pone en duda y que se está asentando como práctica en la mayoría de las administraciones públicas,
sobre todo a partir de la afirmación del enfoque de la „gestión basada en resultados‟.
De acuerdo con un reciente manual del PNUD3, “se puede definir el seguimiento como un proceso
continuo por el que las partes interesadas obtienen regularmente una retroalimentación sobre los
avances que se han hecho para alcanzar las metas y objetivos. A diferencia de muchas definiciones
que tratan el seguimiento simplemente como la revisión.

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

pág. 20

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

pág. 21

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

pág. 22

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:

pág. 23

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.
pág. 24

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

5.3.1.7 Monitoreo de Espacios Espejeados
La administración de espejeado protege la integridad de los datos mediante el almacenamiento de
copias de los datos en varios discos. El tipo e grupo de discos determina los niveles de creación de
reflejo con el que se crean los archivos en un grupo de discos.
Cuando se crea un grupo de discos, se especifica un tipo de grupo de discos ASM basado en los
siguientes 3 niveles de redundancia.
·
Normal de 2 vías de reflejo
·
Alta de 3 vías de reflejo
·
Externa a no utilizar la creación de reflejos ASM

5.3.2 Auditoría
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
La auditoría se ha convertido en una herramienta importante en los últimos 10 años, para el análisis
de las violaciones de datos.
La auditoría es el control y registro de las acciones de la base de datos de usuarios seleccionados,
tanto de los usuarios de bases de datos y no usuarios de la base de datos.
Normalmente se utiliza la auditoría para realizar las siguientes actividades:
·
Activar la Rendición de Cuentas de las Acciones: Estas incluyen acciones tomadas de un
determinado esquema, tabla o fila, o que afecten a un contenido específico.
·
Disuadir a los usuarios (o los otros, como intrusos) de acciones inapropiadas basadas en la
rendición de cuentas.
·
Investigar actividades sospechosas.

pág. 25

5.3.2.1 Habilitación y Deshabilitar el Modo de Auditoría
La activación de la auditoría en Oracle Database viene definida por el valor del parámetro:
audit_trail. Para comprobar si la auditoría de la base de datos está activada ejecutaremos el siguiente
comando SQL:
select name, value
from v$parameter
where name like 'audit_trail'
Posibles valores del parámetro AUDIT_TRAIL:
Para activar la auditoría:
ALTER SYSTEM SET audit_trail = "DB" SCOPE=SPFILE;
Para desactivar la auditoría ejecutaremos el siguiente comando:
ALTER SYSTEM SET audit_trail = "NONE" SCOPE=SPFILE;
·
DBA_AUDIT_TRAIL: Muestra la auditoría estándar (de la tabla AUD$) relativa al usuario
actual. Es una lista de todas las entradas en la tabla SYS.AUD$ colectada por el comando audit.
·
DBA_AUDIT_OBJECT: Lista las opciones de entrada de auditorías para auditar objetos de
la base de datos.
·
DBA_AUDIT_EXISTS: Es una lista de entradas de auditoría generadas por la opción
EXISTS en el comando AUDIT.
·
DBA_AUDIT_SESSION: Muestra las entradas de auditoría generadas por conexiones o
desconexiones de sesiones.
·
DBA_AUDIT_STATEMENT: Es una lista de entradas de auditorías, con la información
recolectada de las opciones de sentencias en el comando audit.
Las principales vistas para obtener resultados de la auditoría, son las siguientes:
Funcionamiento del Comando AUDIT
Permite iniciar los tipos de auditoría que a continuación se detallan. Este comando puede funcionar
aunque no esté activada la auditoría de la base de datos, pero no dejara constancia, para que
funcione correctamente es necesario que la auditoría esté activada.
Sintaxis:
AUDIT
{sql_statement_clause \ schema_object_clause | NETWORK}
[BY {SESSION \ ACCES}]
[WHENEVER [NOT] SUCCESFUL];
Funcionamiento del Comando NOAUDIT
Se utiliza para detener la actividad de auditoría que se había activado previamente con la
instrucción AUDIT.
Sintaxis:
NOAUDIT
{sql_statement_clause | schema_object_clause | NETWORK}
[WHENEVER [NOT] SUCCESFUL];

5.3.2.2 Consultas de las Tablas Vistas con Información de la Auditoría
El diccionario de la BD contiene una tabla llamada SYS.AUD$ que puede contener información
sobre las operaciones realizadas por los usuarios.
Para más fácil manejo de esta tabla, existen una serie de vistas que se crean ejecutando el script de
SQL CATAUDIT.SQL que son de mucha utilidad a la hora de visualizar la información recogida.
Esas vistas se borran con el script CATNOAUD.SQL

pág. 26

Dependiendo de los objetos auditados se recoge distinto tipo de información. En cualquier caso,
siempre se recoge sobre el usuario, sesión, terminal, objeto accedido, operación realizada y
finalización de la operación.

5.4 Herramientas de Software y Hardware para Monitoreo y
Administración Automática
Monitorizar es una tarea imprescindible del administrador. Obviamente no podemos monitorizar en
todo momento y debemos hacerlo con cierta regularidad y de la manera más automatizada posible.
Existen multitud de programas que permiten monitorizar, no solo nuestro servidor de base de datos,
si no múltiples servicios en redes de toda clase.

Herramientas:

1. Consolas Administrativas Ilimitadas.
2. Consultas Personalizadas para agregar dentro de la Interfaz en forma Ilimitada.
3. Base de datos Abierta para integraciones personalizadas de otros dispositivos (equipos de
comunicación, servidores etc.
 Control de Activos Tangibles y no Tangibles.
 Capacidad de cruzar información automática recolectada con la información
insertada en forma manual.
Creación y personalización en forma ilimitada por consultas Editables que nos permitirá adaptar
necesidades reales que requiera la CMDB.
4. Bitácora de Uso de software por Día y Mes de los aplicativos brindado los minutos y horas de su
utilización por PC.
La investigación nos llevó a adquirir o reforzar un poco más los conocimientos de los temas que
fueron de gran utilidad. Ahora nos queda claro el porqué de la importancia de la seguridad de la
base de datos, ya que en la base de datos acceden varios usuarios y hacen diferentes operaciones en
ella por eso se necesita de ayuda del monitoreo general de la base de datos para corregir las fallas.
No olvidando también que la auditoría es de gran apoyo ya que es el proceso que permite asegurar,
monitorear y hacer registros de los accesos a la información almacenada en la base de datos

pág. 27

Bibliografía

https://sites.google.com/site/itjabd23/home/asignatura/plan-deestudios/unidad-5-seguridad
http://www.postgresql.org/docs/8.2/static/libpq-async.html
http://www.estructurayprogramacion.com/materias/administrac
ion-de-base-de-datos/

pág. 28