Inicio > UNIDAD 5

UNIDAD 5 Seguridad

5.1 Respaldo y Recuperación

Es posible generar periódicamente copias de respaldo y conservar una serie de versiones anteriores. Cada copia de respaldo estará identificada por tiempo y fecha y por la última transacción incluida. Una copia de respaldo debe generarse mientras la base de datos esta en reposo, ya que las actualizaciones durante el copiado pueden provocar que la copia se inconsistente.

RECUPERACIÓN.

A continuación se presentaran una serie de pasos que podrán seguirse cuando se presente una falla en el sistema y se desee recuperar la información:

Detección del error.- el proceso de recuperación se inicia al detectarla existencia de un error. Es posible distinguir una variedad de puntos de entrada en le proceso de recuperación. Se considerarán fallas desistemas detectadas por falta de acción del sistema o por verificaciones irrecuperables de redundancia y salida incorrecta observada por un usuario.

Determinación de la fuente del error.- para decidir cual es la mejor acción correctora es necesario determinar la extensión del daño. Desde luego este esfuerzo es muy relacionado con la determinación del tiempo y la causa del error. Después de una caida o cuando el procesamiento sea interrumpido debido a una señal de error, es necesario determinar tantos aquellas áreas del archivo de datos que sean sospechosas como cuál fue la transacción que no se concluyo.

Ubicación de errores secundarios.- cuando se ha detectado un error que provocó una modificación inadecuada a un archivo un rastreo a traves de las listas de actividad encontrara aquellas transacciones que emplearon el bloque correcto. Entonces es posible volver a introducir automáticamente el bloque correcto de lñas transacciones afectadas y rpoducir resultados correctos. Si se actualizaron bloques mediante transacciones que leyeron bloques incorrectos antes de existir es necesario restaurar a un más el archivo.

Aplicación de correcciones. Si la extensión del daño es limitada, puede utilizarse un proceso de volver a enrollar. Las porciones dañadas del archivo se restauran aplicando primero aquellasimágenes anteriores a los bloques en error reemplazando después de las transacciones incompletas. La salida proveniente de estas trasacciones se suprime de ser posible, para evitar duplicar resusltados que previamente se hayan enviado a los usuarios.

Mirroring SQL Server

El Mirroring (Base de Datos Espejo) proporciona una solución de alta disponibilidad de bases de datos, aumenta la seguridad y la disponibilidad, mediante la duplicidad de la base de datos.

Esta tecnología esta disponible a partir de la versión de SQL Server 2005 (es la evolución del log shipping presente en versiones anteriores)

En el Mirroring tenemos un servidor principal/primario que mantiene la copia activa de la base de datos (bbdd accesible). Otro servidor de espejo quemantiene una copia de la base de datos principal y aplica todas las transacciones enviadas por el Servidor Principal (en el que no se podrá acceder a la bbdd). Y un servidor testigo/arbitro que permite recuperaciones automáticas ante fallos, monitoriza el servidor principal y el de espejo para en caso de caída cambiar los roles (servidor opcional, no es obligatorio).

Existen varios tipos de mirroring:

Ø Alta disponibilidad: Garantiza la consistencia transaccional entre el servidor principal y el servidor de espejo y ofrece Automatic Failover mediante unservidor testigo.

Ø Alta Protección: Garantiza la consistencia transaccional entre el servidor principal y el espejo.

Ø Alto Rendimiento: Aplica las transacciones en el Servidor Espejo de maneraasíncrona ocasionando mejoras significativas en el rendimiento del servidor principal pero no garantiza que dichas transacciones se hallan realizado de manera exitosa en el espejo.

Modo	Recuperación Automática ante Fallos	Posible Pérdida de Datos	Servidor Testigo (Witness)	Transaction Safety
Alta Disponibilidad (High Availability)	SI	NO	SI	ON
Alta Protección (High Protection)	NO	NO	NO	ON
Alto Rendimiento (High Performance)	NO	SI	NO	OFF

5.1.1 Espejeo (mirroring)

Espejeo de Datos en un DBMS.

1.-Base de Datos Espejo (Database Mirroring).

Donde actúan dos servidores o más para mantener copias de la base de datos y archivo de registro de transacciones.
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

Esta característica tiene 3 modalidades que son Alto rendimiento, Alta Seguridad, y Alta Disponibilidad, este caso estamos hablando de las 2 primeras, las cuales el levantamiento es manual.

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

1. Asegúrese de que las versiones de MySQL instalado en el maestro y en el esclavo son compatibles, debe usar la versión más reciente de MySQL en maestro y servidor.

Por favor no reporte bugs hasta que ha verificado que el problema está presente en la última versión de MySQL.

2. Prepare una cuenta en el maestro que pueda usar el esclavo para conectar. Este cuenta debe tener el privilegioREPLICATION SLAVE . Si la cuenta se usa sólo para replicación (lo que se recomienda), no necesita dar ningún privilegio adicional. (Para información sobre preparar cuentas de usuarios y privilegios.

Suponga que su dominio es mydomain.com y que quiere crear una cuenta con un nombre de usuario de replque puedan usar los esclavos para acceder al maestro desde cualquier equipo en su dominio usando una contraseña de slavepass. Para crear la cuenta, use el comando GRANT:

mysql> GRANT REPLICATION SLAVE ON *.*

-> TO 'repl'@'%.mydomain.com' IDENTIFIED BY 'slavepass';

Si quiere usar los comandos LOAD TABLE FROM MASTER o LOAD DATA FROM MASTER desde el servidor esclavo, necesita dar a esta cuenta privilegios adicionales:

Ø De a la cuenta el privilegio global SUPER y RELOAD .

Ø De el privilegio SELECT para todas las tablas que quiere cargar. Cualquier tabla maestra desde la que la cuenta no puede hacer un SELECT se ignoran por LOAD DATA FROM MASTER.

Si usa sólo tablas MyISAM , vuelque todas las tablas y bloquee los comandos de escritura ejecutando un comandoFLUSH TABLES WITH READ LOCK :

mysql> FLUSH TABLES WITH READ LOCK;

Deje el cliente en ejecución desde el que lanza el comando FLUSH TABLES para que pueda leer los efectos del bloqueo. (Si sale del cliente, el bloqueo se libera.) Luego tome una muestra de los datos de su servidor maestro.

La forma más fácil de crear una muestra es usar un programa de archivo para crear una copia de seguidad binaria de las bases de datos en su directorio de datos del maestro. Por ejemplo. use tar en Unix, oPowerArchiver, WinRAR, WinZip, o cualquier software similar en Windos. Para usar tar para crear un archivo que incluya todas las bases de datos, cambie la localización en el directorio de datos del maestro, luego ejecute el comando:

shell> tar -cvf /tmp/mysql-snapshot.tar .

Si quiere que el archivo sólo incluya una base de datos llamada this_db, use este comando:

shell> tar -cvf /tmp/mysql-snapshot.tar ./this_db

Luego copie el archivo en el directorio /tmp del servidor esclavo. En esa máquina, cambie la localización al directorio de datos del esclavo, y desempaquete el fichero usando este comando:

shell> tar -xvf /tmp/mysql-snapshot.tar

Puede no querer replicar la base de datos mysql si el servidor esclavo tiene un conjunto distinto de cuentas de usuario a la existente en el maestro. En tal caso, debe excluírla del archivo. Tampoco necesita incluir ningún fichero de log en el archivo, o los ficheros master.info o relay-log.info files.

Mientras el bloqueo de FLUSH TABLES WITH READ LOCK está en efecto, lee el valor del nombre y el desplazamiento del log binario actual en el maestro:

mysql > SHOW MASTER STATUS;

+---------------+----------+--------------+------------------+

+---------------+----------+--------------+------------------+

+---------------+----------+--------------+------------------+

La columna File muestra el nombre del log, mientras que Position muestra el desplazamiento. En este ejemplo, el valor del log binario es mysql-bin.003 y el desplazamiento es 73. Guarde los valores. Los necesitará más tarde cuando inicialice el servidor. Estos representan las coordenadas de la replicación en que el esclavo debe comenzar a procesar nuevas actualizaciones del maestro.

Una vez que tiene los datos y ha guardado el nombre y desplazamiento del log, puede reanudar la actividad de escritura en el maestro:

mysql> UNLOCK TABLES;

Si está usando tablas InnoDB , debería usar la herramienta InnoDB Hot Backup. Realiza una copia consistente sin bloquear el servidor maestro, y guarda el nombre y desplazamiento del log que se corresponden a la copia para usarlo posteriormente en el esclavo. InnoDB Hot Backup es una herramienta no libre (comercial) que no está incluída en la distribución de MySQL estándar. Consulte la página web de InnoDB Hot Backup enhttps://www.innodb.com/manual.php para información detallada.

Sin la herramienta Hot Backup , la forma más rápida de hacer una copia binaria de los datos de las tablasInnoDB es parar el maestro y copiar los ficheros de datos InnoDB, ficheros de log, y ficheros de definición de tablas (ficheros .frm). Para guardar los nombres de ficheros actual y desplazamientos, debe ejecutar el siguiente comando antes de parar el servidor:

mysql> FLUSH TABLES WITH READ LOCK;

mysql> SHOW MASTER STATUS;

Luego guarde el nombre del log y el desplazamiento desde la salida de SHOW MASTER STATUS como se mostró antes. Tras guardar el nombre del log y el desplazamiento, pare el servidor sin bloquear las tablas para asegurarse que el servidor para con el conjunto de datos correspondiente al fichero de log correspondiente y desplazamiento:

shell> mysqladmin -u root shutdown

Una alternativa que funciona para tablas MyISAM y InnoDB es realizar un volcado SQL del maestro en lugar de una copia binaria como se describe en la discusión precedente. Para ello, puede usar mysqldump --master-data en su maestro y cargar posteriormente el fichero de volcado SQL en el esclavo. Sin embargo, esto es más lento que hacer una copia binaria.

Si el maestro se ha ejecutado previamente sin habilitar --log-bin , el nombre del log y las posiciones mostradas por SHOW MASTER STATUS o mysqldump --master-data están vacíos. En ese caso, los valores que necesita usar posteriormente cuando especifica el fichero de log del esclavo y la posición son una cadena vacía ('') y 4.

Asegúrese que la sección [mysqld] del fichero my.cnf en el maestro incluye una opción log-bin . Esta sección debe también tener la opción server-id=master_id , donde master_id debe ser un entero positivo de 1 a 2^32 - 1. Por ejemplo:

[mysqld]

log-bin=mysql-bin

server-id=1

Si estas opciones no están presentes, añádalas y reinicie el servidor.

Pare el servidor que se vaya a usar como esclavo y añada lo siguiente a su fichero my.cnf :

[mysqld]

server-id=slave_id

El valor slave_id , como el valor master_id , debe ser un entero positivo de 1 a 2^32 - 1. Además, es muy importante que el ID del esclavo sea diferente del ID del maestro. Por ejemplo:

[mysqld]

server-id=2

Si está preparando varios esclavos, cada uno debe tener un valor de server-id único que difiera del maestro y de cada uno de los otros esclavos. Piense en los valores de server-id como algo similar a las direcciones IP: estos IDs identifican unívocamente cada instancia de servidor en la comunidad de replicación.

Si no especifica un server-id, se usa 1 si no ha definido un master-host, de otro modo se usa 2. Tenga en cuenta que en caso de omisión de server-id, un maestro rechaza conexiones de todos los esclavos, y un esclavo rechaza conectar a un maestro. Por lo tanto, omitir el server-id es bueno sólo para copias de seguridad con un log binario.

Si ha hecho una copia de seguridad binara de los datos del maestro, cópielo en el directorio de datos del esclavo antes de arrancar el esclavo. Asegúrese que los privilegios en los ficheros y directorios son correctos. El usuario que ejecuta el servidor MySQL debe ser capaz de leer y escribir los ficheros, como en el maestro.

Si hizo una copia de seguridad usando mysqldump, arranque primero el esclavo (consulte el siguiente paso).

Arranque el esclavo. Si ha estado replicando préviamente, arranque el esclavo con la opción --skip-slave-start para que no intente conectar inmediatamente al maestro. También puede arrancar el esclavo con la opción --log-warnings (activada por defecto en MySQL 5.0), para obtener más mensajes en el log de errores acerca de problemas (por ejemplo, problemas de red o conexiones). En MySQL 5.0, las conexiones abortadas no se loguean en el log de errores a no ser que el valor sea mayor que 1.

Si hace una copia de seguridad de los datos del maestro usando mysqldump, cargue el fichero de volcado en el esclavo:

shell> mysql -u root -p < dump_file.sql

Ejecute los siguientes comandos en el esclavo, reemplazando los valores de opciones con los valores relevantes para su sistema:

mysql> CHANGE MASTER TO

-> MASTER_HOST='master_host_name',

-> MASTER_USER='replication_user_name',

-> MASTER_PASSWORD='replication_password',

-> MASTER_LOG_FILE='recorded_log_file_name',

-> MASTER_LOG_POS=recorded_log_position;

La siguiente tabla muestra la longitud máxima para las opciones de cadenas de caracteres:

MASTER_HOST	60
MASTER_USER	16
MASTER_PASSWORD	32

MASTER_LOG_FILE	255

Arranque el flujo esclavo:

mysql> START SLAVE;

Una vez realizado este procedimiento, el esclavo debe conectar con el maestro y atapar cualquier actualización que haya ocurrido desde que se obtuvieron los datos.

Si ha olvidado asignar un valor para server-id en el maestro, los esclavos no son capaces de conectar.

5.1.1.3 Creación de espacios de disco con espejo

Ø Necesitaras el programa R-Drive Image

Ø Ejecuta el programa R-Drive Image desde la ubicación en la que esté instalado.

Ø Haz clic en el botón "Crear imagen", que se localiza en la sección superior de la ventana principal del programa.

Ø Selecciona la unidad que quieres configurar como espejo de la lista de unidades disponibles y presiona el botón "Siguiente".

Ø Selecciona un destino para el espejo nuevo en la ventaja de navegación y haz clic en el botón "Siguiente". Éste puede colocarse en cualquier medio, como un CD, DVD u otro disco duro, dependiendo del tamaño que elijas para hacerlo.

Ø Presiona nuevamente el botón "Siguiente" de la página "Modo de imagen" y deja marcadas las opciones por defecto. Estas opciones son para usuarios avanzados que quieren crear espejos especializados en arreglos RAID o servidores NAS.

Ø Si lo deseas, introduce una contraseña para el espejo nuevo y haz clic en el botón "Siguiente".

Ø Presiona el botón "Iniciar" para comenzar a crear el espejo del disco duro. Este proceso tomará desde minutos a varias horas dependiendo de la velocidad y cantidad de información del disco duro que se esté configurando. Una ventana de diálogo aparecerá para informarte cuando el proceso haya sido completado exitosamente.

Una vez preparados los discos, para crear el RAID, y si hemos seguido la misma estructura de mi ejemplo, usaremos las siguientes órdenes, suponiendo que los discos nos los ha identificado como sda, sdb, sdc y sdd:

mdadm --create --level=raid1 --raid-devices=2 /dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1

mdadm --create --level=raid5 --raid-devices=4 /dev/sda3 /dev/sdb3 /dev/sdc3 /dev/sdd3

La primera orden nos creará un RAID de tipo RAID1 con sólo 2 componentes activos, empleando para ello la primera partición de cada disco. Como le indicamos menos dispositivos de raid (2) que dispositivos físicos, lo que hace es poner los otros dos como spares.

La segunda orden nos creará un RAID5 con la tercera partición de todos los discos indicados. En este caso, el parámetro --raid-devices=4 es superfluo y se podría omitir, ya que si no decimos nada sobreentiende que queremos usar todos los discos.

Recomendaciones

Ø Use una copia de seguridad completa muy reciente o una copia de seguridad diferencial reciente de la base de datos principal.

Ø Si se programa un trabajo de copia de seguridad de registros para que se ejecute muy a menudo en la base de datos principal, puede que sea necesario deshabilitar el trabajo de copia de seguridad hasta que se haya iniciado la creación de reflejo.

Ø Si es posible, la ruta de acceso (incluida la letra de unidad) de la base de datos reflejada debería ser idéntica a la de la base de datos principal.

Ø Si las rutas de acceso de archivo deben ser diferentes (por ejemplo, si la base de datos principal se encuentra en la unidad 'F:' pero el sistema reflejado no tiene unidad F:), se debe incluir la opción MOVE en RESTORE STATEMENT.

5.1.2.1 Beneficios de la réplica de Datos en un DBMS

Ø El componente encargado de lograr la atomicidad de una transacción se conoce como administrador de transacciones.

Ø Las operaciones COMMIT (comprometer o confirmar) y ROOLBACK (retroceder) son la clave de su funcionamiento.

Ø La operación COMMIT indica el término exitoso de una transacción.

Ø La operación ROLLBACK, en cambio, nos indica el término no exitoso de una transacción.

Fallo en la transacción

Ø Error lógico (violación de restricciones, tipos

Ø incompatibles, etc.).

Ø Error del sistema (interbloqueos, espacio insuficiente,

Ø etc.).

Ø Fallo del sistema

Ø Error en la memoria volátil.

Ø Error en el funcionamiento del DBMS o del SO.

Ø Fallo de disco

Ø Errores de I/O

VOLÁTIL

Memoria principal / caché (ej. RAM)

- Acceso rápido

- No sobrevive a las caídas

NO VOLÁTIL

Memoria secundaria (ej. discos o cintas

magnéticas)

- Acceso más lento

- Sobrevive a las caídas

ESTABLE

Se implementa a través de soluciones

como los sistemas RAID o los Sistemas de

Copia de Seguridad Remota.

La información “nunca” se pierde.

5.1.3 Métodos de respaldo de un DBMS

Archivo de log

Ø Identificador de la transacción

Ø Hora de modificación

Ø Identificador del registro afectado

Ø Tipo de acción

Ø Valor anterior del registro

Ø Nuevo valor del registro

Ø Información adicional

Checkpoint

Técnicas basadas en el registro histórico

Paginación en la sombra o páginas en espejo

Técnica de Recuperación Aries

5.1.3.1 Elementos y frecuencia de respaldo

Secuencia de registros que mantiene un rastro de las actualizaciones realizadas a la BD.

Registros de inicio de Tx, Registros de compromiso de una Tx, Registros de aborto de una Tx, Registros de actualización de una Tx:

Debe estar guardado en almacenamiento estable.

Se clasifican en:

Ø _ Técnica de actualización diferida

Ø _ Técnica de actualización inmediata

Retarda la actualización en la BD hasta que la transacción se compromete (commit) parcialmente.

La base de datos se divide en un número determinado de bloques de tamaño fijo (páginas).

En memoria volátil se mantiene la tabla actual y en memoria estable una tabla doble (sombra).

La idea principal es mantener dos tablas de páginas durante la vida de una transacción.

5.1.3.2 Comandos para respaldo de datos

Para hacer una copia de respaldo de una base de datos se recomienda crear un dump.

Para hacer un dump de todas las bases de datos es necesario ejecutar el comando:

mysqldump --user=****** --password=****** -A > /Ruta/Hacia/archivo_dump.SQL

Para hacer un dump de sólo algunas bases de datos es necesario ejecutar el comando:

mysqldump --user=****** --password=****** db_1 db_2 db_n> /Ruta/Hacia/archivo_dump.SQL

Para hacer un dump de todas las tablas de una base de datos es necesario ejecutar el comando:

mysqldump --user=****** --password=****** db > /Ruta/Hacia/archivo_dump.SQL

Para hacer un dump de sólo ciertas tablas de una base de datos es necesario ejecutar el comando:

mysqldump --user=****** --password=****** db --tablas tab1 tab2 > /Ruta/Hacia/archivo_dump.SQL

Para cada uno de estos comando es necesario indicar un usuario (user) y la contraseña (password) con derechos de administrador en la base de datos.

Restauración

Para restaurar un dump tan sólo hay que ejecutar el comando:

mysql --user=****** --password=****** db_nom < /Ruta/Hacia/archivo_dump.SQL

5.1.3.3 Métodos de recuperación de un DBMS

Técnica de recuperación de aires

Representa a los métodos actuales de recuperación.

Ø Usa números de secuencia del registro histórico (NSR) para implementar varias optimizaciones que reducen el tiempo de recuperación.

Ø Estrategia robar/no forzar para la escritura en disco:

Ø Escritura anticipada en el log.

Ø Repetición de la historia.

Ø Anotación en el log de las modificaciones durante el deshacer

La recuperación consiste en tres pasos principales:

Ø Análisis: Identifica las páginas sucias y el conjunto de transacciones activas en el momento de la caída y el punto del logapropiado para empezar la operación REHACER

Ø Rehacer: se replican las operaciones del log.

Ø Deshacer: Se recorre el log hacia atrás y se deshacen las transacciones activas en el momento de la caída, o iniciadas después, de las que no se ha encontrado confirmación.

5.1.4 Comandos para recuperación

Mantenimiento y monitoreo de la base

Actividad	Comando
Revisar el estado de las tablas	show table status;
Los procesos que están ejecutándose	show processlist;
Variables con las que se está ejecutando la instancia	show variables;
Estado actual de innodb;	show innodb status;

Respaldos

La manera usual de hacer un respaldo es usando el comando mysqldump, que posee muchas opciones que permiten duplicar todas las base, una base en particular, una tabla, solo los datos, solo la estructura, etc.

Para obtener un respaldo completo de una base

[digital@pcproal digital]$ mysqldump --opt -u carlos -p prueba > prueba.bak

Para restaurar un respaldo completo de una base

[digital@pcproal digital]$ mysql -u carlos -p prueba < prueba.bak

Otra manera de hacer respaldos es através del comando "select into" y restaurar los datos con "mysqlimport" o "load data infile".

Redo Log Files: dos o más archivos donde se registra cualquier modificación transacción al de una memoria intermedia de la BD.

Archivos de control: metadatos necesarios para operar en la Base de Datos, incluyendo información sobre copias de seguridad. Guían la recuperación.

Segmento Rollback: guarda las últimas sentencias realizadas sobre la BD y sabe cuándo se ha confirmado o no una transacción.

5.1.4.1 Ventajas y Desventajas de cada método

Procedimiento de Escritura:

1. Cuando se inicia una transacción ambas tablasson iguales.

2. Cuando se actualiza una página, se escribe la página actualizada en una página no usada, y se actualiza la tabla actual para apuntar a ésta (dejando la “sombra” sin modificar).

3. Cuando se confirma la transacción, la tabla depáginas actual pasa a almacenamiento no volátil (se cambian las direcciones de las tablas).

4. Si se produce un fallo, la tabla “sombra” se copia en la “actual”.

5. No es necesario ni rehacer ni deshacer.

5.1.4.2 Aplicación de cada método

Ejemplo de recuperación de aires

En la fase REHACER, empezando desde el mínimo NSD en la tabla de páginas sucias(min(NSD)=1)) se rehacen las actualizaciones del log (en este caso

NSD=1, 2, 6).

En la fase DESHACER, se deshacen las actualizaciones del log de las transacciones no confirmadas (T3) (i.e.NSD=6).

Recuperación postgresql

Ø Recuperación basada en WAL (Write – AheadLogging) con fases de Rehacer y Deshacer similares a Aries.

Ø El directorio pg_xlog contiene los diarios de escritura adelantada (WAL).

Ø Un archivo pg_clog registra el estado actual de cada transacción.

5.2 Migración de la Base de Datos

Los conceptos esenciales de la migración describen cambios realizados en el soporte para el desarrollo de aplicaciones, cambios el soporte de nuevas funciones, funciones no soportadas y funciones en desuso que pueden afectar a las aplicaciones de base de datos, scripts y herramientas.

Migración de aplicaciones de BD dentro de DB2

Cambios en el soporte de los sistemas operativos

Cambios en los controladores de las aplicaciones

Cambios en el soporte del software de desarrollo

Cambios en las API de DB2 y en los mandatos de DB2

Cambios en la sintaxis de las sentencias de SQL

Cambios en las vistas y rutinas administrativas de SQL y en las vistas de catálogo

Paquetes de base de datos

Cambios en el soporte de 32 bits y 64 bits

Cambios en el comportamiento del servidor DB2

Soporte de conectividad de clientes DB2

5.3 Monitoreo y Auditoría de la Base de Datos

La auditoría y la protección de bases de datos (DAP) representa un avance evolutivo importante con respecto a anteriores herramientas de monitoreo de actividad en bases de datos (DAM). Los gerentes de seguridad, los administradores de bases de datos (DBAs) y otros interesados, que estén preocupados con proteger datos sensibles en las bases de datos, deben evaluar estas herramientas.

5.3.1 Monitoreo

El término Monitoreo es un término no incluido en el diccionario de la Real Academia Española (RAE). Su origen se encuentra en monitor, que es un aparato que toma imágenes de instalaciones filmadoras o sensores y que permite visualizar algo en una pantalla. El monitor, por lo tanto, ayuda a controlar o supervisar una situación.

Esto nos permite inferir que monitoreo es la acción y efecto de monitorear, el verbo que se utiliza para nombrar a la supervisión o el control a través de un monitor. Por extensión, el monitoreo es cualquier acción de este tipo, más allá de la utilización de un monitor.

5.3.1.1 Monitoreo general de un DBMS

DAP— un término que Gartner desarrolló para remplazar el anterior concepto de DAM —se refiere a las suites de herramientas que se utilizan para apoyar la identificación y reportar comportamiento inapropiado, ilegal o de otra forma indeseable en las RDBMSs, con mínimo impacto en las operaciones y la productividad del usuario. Estas suites han evolucionado de herramientas DAM — que ofrecían análisis de la actividad del usuario en las RDBMSs y alrededor de ellas— para abarcar un conjunto más integral de capacidades, que incluyen:

Ø Descubrimiento y clasificación.

Ø Gestión de vulnerabilidades.

Ø Análisis al nivel de aplicación.

Ø Prevención de intrusión.

Ø Soporte de seguridad de datos no estructurados.

Ø Integración de gestión de identidad y acceso.

Ø Soporte de gestión de riesgos.

5.3.1.2 Monitoreo de espacio en disco

El espacio en disco.

El abaratamiento de los discos ha reducido considerablemente la incidencia del espacio ocupado por los usuarios. No obstante, los discos requieren administración: hay que instalarlos, darles formato, montarlos en otras máquinas, respaldarlos, monitorearlos. Aunque el espacio en disco sea suficiente, es preciso insistir ante los usuarios para hacer un uso racional del recurso.

Comandos para el monitoreo del espacio en disco

quot

El comando

da un resumen del uso de disco en una rama de directorios.

du -s /export/home/*

Muestra el total para cada rama de subdirectorio bajo /export/home;

Esto no es efectivo para ver el consumo total de cada usuario si los usuarios tienen archivos en otras partes del sistema.

El comando

da un resumen del uso del espacio a nivel de todo el sistema:

Muestra el espacio utilizado en cada sistema de archivos, incluso a veces en los que están montados vía NFS. Si se indica uno en particular, da el espacio utilizado en ese sistema de archivos: df /dev/hda2.

El comando

quot

informa sobre el espacio en disco consumido por los usuarios en cada sistema de archivos: quot -f /dev/hda2

Proporciona una lista de la cantidad de bloques y archivos a nombre de cada usuario.

5.3.1.3 Monitoreo de logs

Monitorear el log de transacciones es una de las actividades más importantes para los administradores de bases de datos, ya que en caso de que este llegara a llenarse, no podrían llevarse a cabo más transacciones sobre esta base de datos quedando fuera de servicio.

Monitoreando el log de transacciones(SQL SERVER)

Monitorear el log regularmente puede ayudarnos a resolver varios problemas dentro de nuestros sistemas, ya que este puede indicarnos si existen demasiadas transacciones realizadas por una sola aplicación, que podría resultar en un mal diseño o simplemente la necesidad de planear mejor los recursos de log en nuestro servidor de base de datos.

Monitoreo de Logs

Una de ellas es mediante un comando desde el analizador de consultas:

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

Monitoreo de Logs

La otra utilizando los contadores de SQL Server desde el sistema operativo.

Monitoreo de Log transacciones

5.3.1.4 Monitoreo de Memoria compartida

SGA de Oracle (Sistema de Área Global)

Es un conjunto de áreas de memoria compartida "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.

La SGA se divide en varias partes:

Buffers de BD, 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 clusters. Los bloques modificados se llamas bloques sucios. El tamaño de buffer caché se fija por el parámetro DB_BLOCK_BUFFERS del fichero init.ora.

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 guardar cambios en los ficheros redo log, son escritos en un caché de la SGA llamado redo log buffer.

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

5.3.1.5 Monitoreo de Base de Datos

Procedimiento Monitoreo de la Base

de Datos Oracle10g

Se establece que se debe realizar una revisión periódica mensual de la base de datos institucional (Oracle10g), con la finalidad de identificar oportunamente cualquier anomalía que pueda afectar el rendimiento de la misma. El encargado de realizar este proceso es el Administrador de la Base de Datos, en la Unidad de Informática del CATIE.

Revisión de las Tablas del Esquema APLIC

A. Verificar que el tablespace este asignado correctamente a uno válido para el Esquema.

B. Que no se encuentre particionada.

D. Que el número de registros no exceda el tamaño según la funcionalidad de cada tabla.

Revisión de los Índices del Esquema APLIC

A. Verificar que el tablespace este asignado correctamente a uno válido para el Esquema

B. Que no se encuentre particionado

C. Que el estado sea válido.

Revisión de los Procedimientos del Esquema APLIC

A. Verificar que el estado sea válido

Revisión de los Tablespaces en Almacenamiento

A. Verificar el estado sea ONLINE

B. Que el espacio usado no sobre pase el 85%, si no debe asignársele más espacio en disco.

Revisión de los Archivos de Datos en Almacenamiento

A. Verificar el estado sea ONLINE

B. Si el espacio usado no sobre pase el 85%, debe asignársele más espacio en disco, creando un nuevo archivo de datos.

Revisión de los Segmentos de RollBack en Almacenamiento

A. Verificar el estado sea ONLINE

5.3.1.6 Monitoreo de modos de operación

MONITOREO DE BASE DE DATOS

Revisión del espacio físico desde el S.O. del servidor ADMIN. (root)

A. Ejecutar el comando:

$ df -k | grep dsk

5.3.1.6 MONITOREO DE MODOS DE OPERACION

Varios Consejos técnicos y libros se han escrito en los últimos años sobre la modalidad de operaciones continua para garantizar copias de seguridad adecuadas en la Base de Datos.

Sin embargo, poco se ha dicho acerca de la supervisión en este modo de operacion,por ello se ha escrito este consejo tecnico para saber como hacer copias de seguridad mas fluidas.

¿CUAL ES EL MODO DE FUNCIONAMIENTO CONTINUO?

*Es un modo especial en las bases de datos especializadas.

*Permite realizar copias de seguridad instantanea en su entorno.

*Se puede realizar en cualquier momento del dia.

*Escribe un archivo fisico independiente llamado

"archivo delta"

*Se obtiene una copia de seguridad que incluye el estado de la base de datos

en un solo momnto en el tiempo.

5.3.1.7 Monitoreo de espacios espejeados

Una de las tareas de un DBA es monitorear el espacio de la base de datos, debido a que esto consume mucho tiempo cuando se tienen varias DB’s es bueno automatizar tareas repetitivas y tediosas. Una manera de realizar la automatización del monitoreo de DB’s en UNIX es por medio del crontab, el siguiente es un ejemplo de como usar el crontab para monitorear los tablespaces.

Los siguientes scripts permiten obtener el espacio utilizado y libre de los tablespaces, uno lo obtiene en base el porcentaje libre de espacio y el otro obtiene el espacio en base a los MB libres. Estos scripts reciben dos parametros: &1 .- es el directorio y archivo donde se va a crear el reporte(spool) y &2 que es el limite ya sea porcentaje (99) o Mb(99999).

tablespace_size_pct.sql

SET line 132

SET pages 50

SET pause OFF

SET feedback OFF

SET echo OFF

SET verify OFF

COLUMN c1 heading "Tablespace|Name"

COLUMN c2 heading "File|Count"

COLUMN c3 heading "Allocated|in MB"

COLUMN c4 heading "Used|in MB"

COLUMN c5 heading "%|free" format 99.99

COLUMN c6 heading "Free|in MB"

COLUMN c7 heading "%|used" format 99.99

spool &1;

SELECT c1,ROUND(c3,2) c3,ROUND(c4,2) c4,ROUND(c6,2) c6,ROUND(c7,2) c7,ROUND(c5,2) c5,c2

FROM(

SELECT NVL (b.tablespace_name, NVL (a.tablespace_name, 'UNKOWN')) c1,

mbytes_alloc c3, mbytes_alloc - NVL (mbytes_free, 0) c4,

NVL (mbytes_free, 0) c6,

((mbytes_alloc - NVL (mbytes_free, 0)) / mbytes_alloc) * 100 c7,

100

- (((mbytes_alloc - NVL (mbytes_free, 0)) / mbytes_alloc) * 100) c5,

b.files c2

FROM (SELECT SUM (BYTES) / 1024 / 1024 mbytes_free, tablespace_name

FROM SYS.dba_free_space

GROUP BY tablespace_name) a,

(SELECT SUM (BYTES) / 1024 / 1024 mbytes_alloc, tablespace_name,

COUNT (file_name) files

FROM SYS.dba_data_files

GROUP BY tablespace_name) b

WHERE a.tablespace_name(+) = b.tablespace_name

UNION ALL

SELECT f.tablespace_name,

SUM (ROUND ((f.bytes_free + f.bytes_used) / 1024 / 1024, 2)

) "total MB",

SUM (ROUND (NVL (p.bytes_used, 0) / 1024 / 1024, 2)) "Used MB",

SUM (ROUND ( ((f.bytes_free + f.bytes_used) - NVL (p.bytes_used, 0)

)

/ 1024

/ 1024,

)

) "Free MB",

(SUM (ROUND (NVL (p.bytes_used, 0) / 1024 / 1024, 2)) * 100)

/ (SUM (ROUND ((f.bytes_free + f.bytes_used) / 1024 / 1024, 2))),

100

- (SUM (ROUND (NVL (p.bytes_used, 0) / 1024 / 1024, 2)) * 100)

/ (SUM (ROUND ((f.bytes_free + f.bytes_used) / 1024 / 1024, 2))),

COUNT (d.file_name)

FROM SYS.v_$temp_space_header f,

dba_temp_files d,

SYS.v_$temp_extent_pool p

WHERE f.tablespace_name(+) = d.tablespace_name AND f.file_id(+) = d.file_id

AND p.file_id(+) = d.file_id

GROUP BY f.tablespace_name)

WHERE C1 NOT IN('USERS')

AND C7 >= &2

ORDER BY c6 ASC;

spool off;

exit;

tablespace_size_spc.sql

SET line 132

SET pages 50

SET pause OFF

SET feedback OFF

SET echo OFF

SET verify OFF

COLUMN c1 heading "Tablespace|Name"

COLUMN c2 heading "File|Count"

COLUMN c3 heading "Allocated|in MB"

COLUMN c4 heading "Used|in MB"

COLUMN c5 heading "%|free" format 99.99

COLUMN c6 heading "Free|in MB"

COLUMN c7 heading "%|used" format 99.99

spool &1;

SELECT c1,ROUND(c3,2) c3,ROUND(c4,2) c4,ROUND(c6,2) c6,ROUND(c7,2) c7,ROUND(c5,2) c5,c2

FROM(

SELECT NVL (b.tablespace_name, NVL (a.tablespace_name, 'UNKOWN')) c1,

mbytes_alloc c3, mbytes_alloc - NVL (mbytes_free, 0) c4,

NVL (mbytes_free, 0) c6,

((mbytes_alloc - NVL (mbytes_free, 0)) / mbytes_alloc) * 100 c7,

100

- (((mbytes_alloc - NVL (mbytes_free, 0)) / mbytes_alloc) * 100) c5,

b.files c2

FROM (SELECT SUM (BYTES) / 1024 / 1024 mbytes_free, tablespace_name

FROM SYS.dba_free_space

GROUP BY tablespace_name) a,

(SELECT SUM (BYTES) / 1024 / 1024 mbytes_alloc, tablespace_name,

COUNT (file_name) files

FROM SYS.dba_data_files

GROUP BY tablespace_name) b

WHERE a.tablespace_name(+) = b.tablespace_name

UNION ALL

SELECT f.tablespace_name,

SUM (ROUND ((f.bytes_free + f.bytes_used) / 1024 / 1024, 2)

) "total MB",

SUM (ROUND (NVL (p.bytes_used, 0) / 1024 / 1024, 2)) "Used MB",

SUM (ROUND ( ((f.bytes_free + f.bytes_used) - NVL (p.bytes_used, 0)

)

/ 1024

/ 1024,

)

) "Free MB",

(SUM (ROUND (NVL (p.bytes_used, 0) / 1024 / 1024, 2)) * 100)

/ (SUM (ROUND ((f.bytes_free + f.bytes_used) / 1024 / 1024, 2))),

100

- (SUM (ROUND (NVL (p.bytes_used, 0) / 1024 / 1024, 2)) * 100)

/ (SUM (ROUND ((f.bytes_free + f.bytes_used) / 1024 / 1024, 2))),

COUNT (d.file_name)

FROM SYS.v_$temp_space_header f,

dba_temp_files d,

SYS.v_$temp_extent_pool p

WHERE f.tablespace_name(+) = d.tablespace_name AND f.file_id(+) = d.file_id

AND p.file_id(+) = d.file_id

GROUP BY f.tablespace_name)

WHERE C1 NOT IN('USERS')

AND C6 <= &2

ORDER BY c6 ASC;

SPOOL OFF;

exit;

Con el siguiente script podemos ejecutar los SQL scripts anteriores dependiendo los parametros que le enviemos. La forma de ejecutar el script es la siguiente:
- Para reportar en base al espacio, despues del parametro -d debe seguir el nombre de la instancia (SID), despues del parametro -s sigue la cantidad minima que puede tener libre un tablespace:
  - tbs_monitor.ksh -d DEVELOPMENT -s 500

§ Connected.

§ Instance: DEVELOPMENT

§ Tablespaces with usage < 500 MB.

§ Tablespace Allocated Used Free % % File

§ Name in MB in MB in MB used free Count

§ ------------------------------ ---------- ---------- ---------- ------ ------ ----------

§ SYSTEM 600 403.13 196.88 67.19 32.81 1

IDX1 11741 11363 378 96.78 3.22 3

Para reportar en base al porcentaje, en lugar de utilizar el parametro -s se utiliza el parametro -p seguido del porcentaje maximo que puede tener un tablespace:
- tbs_monitor.ksh -d DEVELOPMENT -p 80

o Connected.

o Instance: DEVELOPMENT

o Tablespaces with usage >= 80%.

o Tablespace Allocated Used Free % % File

o Name in MB in MB in MB used free Count

o ------------------------------ ---------- ---------- ---------- ------ ------ ----------

o IDX1 11741 11363 378 96.78 3.22 3

o IDX2 3201 2696 505 84.22 15.78 2

o IDX5 18385 17394 991 94.61 5.39 3

o DATA02 13312 11520.13 1791.88 86.54 13.46 2

o DATA03 33797 31709.13 2087.88 93.82 6.18 4

o DATA01 56629 46606.38 10022.63 82.30 17.70 7

tbs_monitor.ksh

#!/bin/ksh

#######################################################################

# SCRIPT : tbs_monitor.ksh

# DESCRIPTION : This script will monitor usage in tablespaces of a database.

# If the usage is >= 90% it will send an email to the DBA group.

# INPUT FILES : [oracle_sid] only one database is processed

# OUTPUT FILES : NONE

# CALLED OBJECT: $SCRIPTS/switchdb.ksh

# ASSUMPTIONS : NONE

# SETUP INSTRUCTIONS : NONE

# COMMAND LINE EXECUTION: tbs_monitor.ksh -d [oracle_sid] [-s sizeinMB] [-p pct]

# EXAMPLE: tbs_monitor.ksh -d DEV -s 300

# EXAMPLE: tbs_monitor.ksh -d DEV -p 85

# RESTART INSTRUCTIONS: rerun script

# SPECIAL CONSIDERATIONS: NONE

#######################################################################

# Modification Log:

# Version Date Name Description

#######################################################################

# 1.0 04-Jul-2006 Delfino Nunez Initial Creation

#######################################################################

########################################################################

# FUNCTION : showHelp

# DESCRIPTION: Print the help for using the script

########################################################################

function showHelp {

echo " Argument Description"

echo " ------------ ----------------------------------------------"

echo " -d [sid] Oracle sid to check."

echo " -p xx Report on percentage usage(pct > xx)."

echo " -s xxxxxx Report on MB size usage(sizeMB < xxxxxx)."

echo " -h This help."

echo " \n\n EXAMPLE: "

echo " Report tablespaces that have more than 95% space used"

echo " tbs_monitor.ksh -s EDS2TSDE -p 95"

echo " Report tablespaces that have less than 300Mb space"

echo " tbs_monitor.ksh -s EDS2TSDE -s 300"

}

########################################################################

# Main Program start here

########################################################################

# Verify input paramtter and set environment variables

#parm_list=$@

. $DBA_BASE/init

#set -- $parm_list

#check parameters

if [ "$1" != "" ]

then

while [ "$#" != "0" ]

case $1 in

-s)

shift

if [ "$1" != "" ]; then

export RPTTYPE="SIZE"

export PSIZE=$1

shift

;;

-d)

shift

if [ "$1" != "" ]; then

export ORACLE_SID=$1

shift

;;

-p)

shift

if [ "$1" != "" ]; then

export RPTTYPE="PCT"

export PSIZE=$1

shift

;;

-h)

showHelp

exit 0;

;;

echo "Bad argument: $1"

showHelp

exit 1;

;;

esac

done

else

showHelp

exit 1

. $SCRIPTS/switchdb.ksh $ORACLE_SID

BOXNAME=`uname -n`

MAILIDS=`cat $DBA_BASE/.forward`

# point to where the rpt file will go

export RPTFILE=$TMP/${ORACLE_SID}_tablespace_rpt.txt

export EMAILMSG=$TMP/tbs_email.txt

export dbpass=`cat $PWDFILE`

# should not need to be changed

export DATE=$(date +%y-%m-%d.%H:%M:%S)

#remove any previous file

if [ -a $RPTFILE ]

then

rm $RPTFILE

if [ -a $EMAILMSG ]

then

rm $EMAILMSG

#Run the status report.

case "$RPTTYPE" in

"PCT")

MESSAGE="Tablespaces with usage >= $PSIZE%."

sqlplus -s /nolog <

connect $dbpass

prompt Instance: $ORACLE_SID

prompt Tablespaces with usage >= $PSIZE%.

@$SQL/tablespace_size_pct.sql $RPTFILE $PSIZE

EOF

;;

"SIZE")

MESSAGE="Tablespaces with usage <= $PSIZE Mb."

sqlplus -s /nolog <

connect $dbpass

prompt Instance: $ORACLE_SID

prompt Tablespaces with usage < $PSIZE MB.

@$SQL/tablespace_size_spc.sql $RPTFILE $PSIZE

EOF

;;

esac

#tablespace with problems

if [[ -s $RPTFILE ]]; then

echo "The following database have problems with the size of their tablespaces:\n" >> $EMAILMSG

echo "Instance: $ORACLE_SID" >> $EMAILMSG

echo $MESSAGE >> $EMAILMSG

cat $RPTFILE >> $EMAILMSG

mailx -s "ALERT!!! Tablespace Usage Problems - $BOXNAME:$ORACLE_SID $DATE" $MAILIDS < $EMAILMSG

Y el ultimo script nos permite obtener el reporte para todas las bases que se encuentran en el servidor. Este script lee el archivo ORATAB y saca todas las bases de datos registradas en el servidor. Este script se puede poner en el crontab de la siguiente manera:
00 00-01,06-23 * * * /home/oracle/dba/scripts/all.tbs_monitor -p >/dev/null 2>&1
Aqui le estamos diciendo al crontab que ejecute el script cada hora excepto de 2am-5am, esto por cuestiones de respaldos.
Si no se quiere procesar todas las bases de datos y solo se quiere verificar algunas entonces es necesario de calendarizar el script tbs_monitor.ksh por cada una de las bases de datos.

all.tbs_monitor

#!/bin/ksh

#######################################################################

# SCRIPT : all.tbs_monitor

# DESCRIPTION : This script will call tbs_monitor script for all databases

# INPUT FILES : $DBA_BASE/init - configuration file

# -a all databases are processed

# -p production (*PD) databases are processed

# OUTPUT FILES : NONE

# CALLED OBJECT: tbs_monitor

# ASSUMPTIONS : NONE

# SETUP INSTRUCTIONS : Need to switchdb first to a default.

# COMMAND LINE EXECUTION:

# EXAMPLE:

# RESTART INSTRUCTIONS: rerun script

# SPECIAL CONSIDERATIONS: NONE

#######################################################################

# Modification Log:

# Version Date Name Description

#######################################################################

# 1.0 04-Jul-2006 Delfino Nunez Initial Creation

#######################################################################

############################################################################

# MAIN PROGRAM STARTS HERE

############################################################################

. $HOME/dba/init

priority=1

########################################################################

# FUNCTION : showHelp

# DESCRIPTION: Print the help for using the script

########################################################################

function showHelp {

echo " Argument Description"

echo " ------------ ----------------------------------------------"

echo " -p Only production databases."

echo " -a All databases."

echo " -h This help."

echo " \n\n EXAMPLE: all.tbs_monitor -a"

echo " all.tbs_monitor -p"

}

########################################################################

# Main Program start here

########################################################################

if [ -f /var/opt/oracle/oratab ]

then

export ORATAB='/var/opt/oracle/oratab'

elif [ -f /etc/oratab ]

then

export ORATAB='/etc/oratab'

else

# following code from Steve Larson

FOUND_ORATAB=$( find / -name oratab 2>/dev/null | head -1 )

if [ "$FOUND_ORATAB" ] && [ -f "$FOUND_ORATAB" ]

then

ORATAB="$FOUND_ORATAB"

else

exit 1

#check parameter

if [ "$1" != "" ]

then

while [ "$#" != "0" ]

case $1 in

-p)

export INSTANCES=`awk -F: '$1 !~ /\#/ && $1 !~ /\*/ {print $1}' $ORATAB|grep "PD"`

shift

;;

-a)

export INSTANCES=`awk -F: '$1 !~ /\#/ && $1 !~ /\*/ {print $1}' $ORATAB`

shift

;;

-h)

showHelp

exit 0;

;;

echo "Bad argument: $1"

echo ""

showHelp

exit 1;

;;

esac

done

else

showHelp

exit 1

if [ "$#" != "0" ]

then

ORACLE_SID=$1

shift

export ORACLE_SID

else

for ORACLE_SID in $INSTANCES

swdb $ORACLE_SID

tbs_monitor.ksh -d $ORACLE_SID -s 300

done

Los scripts utilizan otros scripts o archivos que no estan incluidos aqui y que voy a ir publicando, pero estos scripts pueden usarse como base para crear unos personalizados.

5.3.2 Auditoría

Es la actividad consistente en la emisión de una opinión profesional sobre si el objeto sometido a análisis presenta adecuadamente la realidad que pretende reflejar y/o cumple con las condiciones que le han sido prescritas.

5.3.2.1 Habilitación y deshabilitar el modo de auditoría

Funcionamiento comando audit (Oracle):

El 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 dejará constancia, para que funcione correctamente es necesario que la auditoría esté activada.

Sintaxis:

AUDIT

{ sql_statement_clause | schema_object_clause | NETWORK }

[ BY { SESSION | ACCESS } ]

[ WHENEVER [ NOT ] SUCCESSFUL ] ;

•

sql_statement_clause

: activa la auditoría para una sentencia SQL concreta.

•

schema_object_clause

: activa la auditoría para un objeto concreto de la base de datos.

•

WHENEVER SUCCESSFUL

: activa la auditoría sólo para operaciones e instrucciones SQL en objetos de esquema que se completen con éxito.

•

WHENEVER NOT SUCCESSFUL

: activa la auditoría sólo para operaciones e instrucciones SQL en objetos de esquema que originen error.

Funcionamiento comando noaudit:

La instrucción noaudit se utiliza para detener la actividad de auditoría que se había activado previamente con la instrucción audit. Esta instrucción no influye en el parámetro audit_trail.

Sintaxis:

NOAUDIT

{ sql_statement_clause | schema_object_clause | NETWORK}

[WHENEVER [NOT] SUCCESSFUL];

•

sql_statement_clause

: detiene la auditoria de una sentencia SQL concreta.

•

schema_object_clause

: detiene la auditoría para un objeto concreto de la base de datos.

•

WHENEVER SUCCESSFUL

: detiene la auditoría sólo para operaciones e instrucciones SQL en objetos de esquema que se completen con éxito.

•

WHENEVER NOT SUCCESSFUL

: detiene la auditoría sólo para operaciones e instrucciones SQL en objetos de esquema que originen error.

5.3.2.2 Consultas de las tablas vistas con información de la auditoría

Dependiendo del tipo de auditoría que queramos consultar utilizaremos una u otra consulta SQL.

Para el caso de la auditoría de inicio de sesión utilizaremos la siguiente consulta SQL:

selectOS_UsernameUsuario_SO,

UsernameUsuario_Oracle, Terminal ID_Terminal,

DECODE (Returncode, '0', 'Conectado', '1005', 'Fallo - Null',

1017, 'Fallo', Returncode) Tipo_Suceso,

TO_CHAR(Timestamp, 'DD-MM-YY HH24:MI:SS') Hora_Inicio_Sesion,

TO_CHAR(Logoff_Time, 'DD-MM-YY HH24:MI:SS') Hora_Fin_Sesion

from DBA_AUDIT_SESSION;

Para el caso de la auditoría de acción utilizaremos la siguiente consulta SQL:

selectOS_UsernameUsuario_SO,

UsernameUsuario_Oracle, Terminal ID_Terminal,

OwnerPropietario_Objeto,

Obj_NameNombre_Objeto,

Action_NameAccion,

DECODE (Returncode, '0', 'Realizado', 'Returncode') Tipo_Suceso,

TO_CHAR (Timestamp, 'DD-MM-YY HH24:MI:SS') Hora

from DBA_AUDIT_OBJECT;

5.4 Herramientas de software y hardware para monitoreo y administración automática

Herramientas de Microsoft SQL Server

Estas herramientas son el Profiler y el Performance monitor.

*Permiten ver los procesos en ejecucion del servidor

*Ayudan a ver como esta el rendimiento del sistema

PROFILER

-Permite crear trace para dar seguimiento a las ejecuciones y consultas que se ejecutan en el servidor

-Podemos tener acceso en la dirección Start>Program Files > Microsoft SQL Server >Profiler.

-Se pueden filtar traces especificando el nombre de la aplicacion a la que se le quiere dar seguimiento.

PERFORMANCE MONITOR

-Con esta herramienta se visualiza como se esta comportando el disco duro

-A demas de como la base de datos utiliza la memoria y el procesador del servidor los cuales deberían mantenerse por debajo de un 20%

Herramientas de MySql

MySQL-Proxy

es una herramienta para monitorear y optimizar consultas y búsquedas.

1.- Hacer un Log de todas las consultas que recibe el Servidor

2.- Denegar consultas peligrosas que puedan dañar nuestra base de datos

3.- Generar Alias de comandos comunes por ejemplo SLE se podría convertir en SELECT

4.- Balancear la carga entre varios servidores de MySQL en un esquema de Master/Slave

5.- Dar prioridad a ciertas consultas para acelerar la respuesta del servidor

Mirroring SQL Server

Buscar en el sitio

Contacto