Unidad 4: Operación y mantenibilidad4.1 Bitácoras de trabajo del DBMS.

En muchos DBMS la bitácora incluye todo tipo de consulta incluyendo aquellas que no modifican los datos.

La operación ROLLBACK está basada en el uso de una bitácora. El DBMS (SistemaManejador de Bases de Datos) mantiene una bitácora o diario en cinta o en disco, comúnmente, en el cual se registran los detalles de todas las operaciones de actualización, en particular, los valores iniciales y final del objeto modificado. Por tanto, si resulta necesario anular alguna modificación específica, el sistema puede utilizar la entrada correspondiente de la bitácora para restaurar el valor original del objeto restaurado.

4.1.1. Funciones específica de las bitácoras.La estructura más ampliamente usada para grabar las modificaciones de la base de datos es la Bitácora. Cada registro de la bitácora escribe una única escritura de base de datos y tiene lo siguiente:

Nombre de la Transacción Valor antiguo Valor Nuevo

Es fundamental que siempre se cree un registro en la bitácora cuando se realice una escritura antes de que se modifique la base de datos. También tenemos la posibilidad de deshacer una modificación que ya se ha escrito en la base de datos, esto se realizará usando el campo del valor antiguo de los registros de la bitácora.

Los registros de la bitácora deben residir en memoria estable como resultado el volumen de datos en la bitácora puede ser exageradamente grande.

Las operaciones COMMIT y ROLLBACK establecen lo que se le conoce como punto de sincronización lo cual representa el límite entre dos transacciones consecutivas, o el final de una unidad lógica de trabajo, y por tanto al punto en el cual la base de datos esta (o debería estar) en un estado de consistencia. Las únicas operaciones que establecen un punto de sincronización son COMMIT, ROLLBACK y el inicio de un programa. Cuando se establece un punto de sincronización:

Se comprometen o anulan todas las modificaciones realizadas por el programa desde el punto de sincronización anterior.Se pierde todo posible posicionamiento en la base de datos. Se liberan todos los registros bloqueados. Es importante advertir que COMMIT y ROLLBACK terminan las transacción, no el programa.

4.1.2 Recuperación (rollback)

En tecnologías de base de datos, un rollback es una operación que devuelve a la base de datos a algún estado previo. Los Rollbacks son importantes para la integridad de la base de datos, a causa de que significan que la base de datos puede ser restaurada a una copia limpia incluso después de que se han realizado operaciones erróneas. Son cruciales para la recuperación de crashes de un servidor de base de datos; realizando rollback(devuelto) cualquier transacción que estuviera activa en el tiempo del crash, la base de datos es restaurada a un estado consistente.

En SQL, ROLLBACK es un comando que causa que todos los cambios de datos desde la última sentencia BEGIN WORK, o START TRANSACTION sean descartados por el sistema de gestión de base de datos relacional (RDBMS), para que el estado de los datos sea "rolled back"(devuelto) a la forma en que estaba antes de que aquellos cambios tuvieran lugar.

Una sentencia ROLLBACK también publicará cualquier savepoint existente que pudiera estar en uso.

En muchos dialectos de SQL, ROLLBACKs son específicos de la conexión. Esto significa que si se hicieron dos conexiones a la misma base de datos, un ROLLBACK hecho sobre una conexión no afectará a cualesquiera otras conexiones. Esto es vital para el buen funcionamiento de la Concurrencia.

La funcionalidad de rollback está normalmente implementada con un Log de transacciones, pero puede también estar implementada mediante control de concurrencia multiversión.

En el proceso de “Rollback”, SQL Server comienza a hacer un rollback de todas las transacciones que no fueron confirmadas además de las que fueron rechazadas, dejando de esta manera la base de datos en un estado consistente.

4.1.3 Permanencia (commit)En cualquier momento, el programa podría decidir que es necesario hacer fallar la transacción, con lo que el sistema deberá revertir todos los cambios hechos por las operaciones ya hechas. En el lenguaje SQL se denomina COMMIT a aplicar_cambios y ROLLBACK a cancelar_cambios.

Las transacciones suelen verse implementadas en sistemas de bases de datos y, más recientemente, se han visto incorporadas a como gestiona un sistema operativo la interacción con un sistema de archivos (como varias características de las bases de datos, debido a que son muy similares arquitectónicamente).

Una sentencia COMMIT en SQL finaliza una transacción de base de datos dentro de un sistema gestor de base de datos relacional (RDBMS) y pone visibles todos los cambios a otros usuarios. El formato general es emitir una sentencia BEGIN WORK, una o más sentencias SQL, y entonces la sentencia COMMIT. Alternativamente, una sentencia ROLLBACK se puede emitir, la cual deshace todo el trabajo realizado desde que se emitió

BEGIN WORK. Una sentencia COMMIT publicará cualquiera de los savepoints (puntos de recuperación) existentes que puedan estar en uso.

En términos de transacciones, lo opuesto de commit para descartar los cambios "en tentativa" de una transacción, es un rollback.

4.2 Definición de los modos de operación de un DBMS. (alta, baja, recovery)

El sistema de gestión de bases de datos es esencial para el adecuado funcionamiento y manipulación de los datos contenidos en la base. Se puede definir como: "El Conjunto de programas, procedimientos, lenguajes, etc. que suministra, tanto a los usuarios no informáticos como a los analistas, programadores o al administrador, los medios necesarios para describir, recuperar y manipular los datos almacenados en la base, manteniendo su integridad, confidencialidad y seguridad".

Las funciones esenciales de un SGDB son la descripción, manipulación y utilización de los datos.

Descripción: Incluye la descripción de: Los elementos de datos, su estructura, sus interrelaciones, sus validaciones. Tanto a nivel externo como lógico global e interno esta descripción es realizada mediante un LDD o Lenguaje de Descripción de Datos. Manipulación: Permite: Buscar, Añadir, Suprimir y Modificar los datos contenidos en la Base de Datos.

La manipulación misma supone: Definir un criterio de selección, Definir la estructura lógica a recuperar, Acceder a la estructura física. Esta manipulación es realizada mediante un LMD o Lenguaje de Manipulación de Datos.

Utilización: La utilización permite acceder a la base de datos, no a nivel de datos sino a la base como tal, para lo cual: Reúne las interfaces de los usuarios y suministra procedimientos para el administrador.

En términos ideales, un DBMS debe contar con estas funciones, sin embargo, no todos las poseen, así existen algunos manejadores que no cumplen la función de respaldo o de seguridad, dejándola al usuario o administrador; sin embargo un DBMS que sea completo y que deba manejar una base de datos multiusuario grande, es conveniente que cuente con todas estas operaciones.

4.4. Manejo de índices

Los índices son "estructuras" alternativa a la organización de los datos en una tabla. El propósito de los índices es acelerar el acceso a los datos mediante operaciones físicas más rápidas y efectivas. Para entender mejor la importancia de un índice pongamos un ejemplo; imagínate que tienes delante las páginas amarillas, y deseas buscar el teléfono de Manuel Salazar que vive en Alicante. Lo que harás será buscar en ese pesado libro la población

Alicante, y guiándote por la cabecera de las páginas buscarás los apellidos que empiezan por S de Salazar. De esa forma localizarás más rápido el apellido Salazar. Pues bien, enhorabuena, has estado usando un índice.

4.4.1 Tipos de índices

En MySQL se tienen dos tipos de índices, los cuales son:Índices agrupados

Los índices agrupados, definen el orden en que almacenan las filas de la tabla (nodos hoja/página de datos de la imagen anterior). La clave del índice agrupado es el elemento clave para esta ordenación; el índice agrupado se implementa como una estructura de árbol b que ayuda a que la recuperación de las filas a partir de los valores de las claves del índice agrupado sea más rápida. Las páginas de cada nivel del índice, incluidas las páginas de datos del nivel hoja, se vinculan en una lista con vínculos dobles. Además, el desplazamiento de un nivel a otro se produce recorriendo los valores de clavesIndices no agrupados

Los índices no agrupados tienen la misma estructura de árbol b que los índices agrupados, con algunos matices; como hemos visto antes, en los índices agrupados, en el último nivel del índice (nivel de hoja) están los datos; en los índices no- agrupados, en el nivel de hoja del índice, hay un puntero a la localización física de la fila correspondiente en el índice agrupado. Además, la ordenación de las filas del índice está construida en base a la(s) columna(s) indexadas, lo cual no quiere decir (a diferencia de los índices agrupados), que la organización física de las páginas de datos corresponda con el índice.

4.4.2 Reorganización de índices

Un paquete puede usar la tarea Reorganizar índice para reorganizar los índices de una base de datos individual o de varias bases de datos. Si la tarea solo reorganiza los índices de una base de datos individual, puede elegir las vistas o las tablas cuyos índices reorganiza la tarea. La tarea Reorganizar índice también incluye la opción de compactar datos de objetos grandes. Los datos de objetos grandes son datos detipo image, text, ntext, varchar(max), nvarchar(max), varbinary(max) o xml.

La tarea Reorganizar índice encapsula la instrucción ALTER INDEX de Transact-SQL. Si elige compactar datos de objetos grandes, la instrucción utiliza la cláusula REORGANIZE WITH (LOB_COMPACTION = ON); en caso contrario, se establece LOB_COMPACTION en OFF

Dentro de las tareas habituales de Mantenimiento de las Bases de Datos se encuentran aquellas destinadas al control y respaldo de las mismas como ser: Control de Integridad, Chequeo de Consistencia, Copias de Seguridad o Compactación de las bases.

Pero también es necesario ejecutar trabajos de mantenimiento cuyos objetivos sean el de mantener la performance de las bases de datos y evitar su degradación.

Esos trabajos son la Reorganización de Índices y la Actualización de Estadísticas. Estos trabajos son independientes del estado de la base de datos. Puede ocurrir que

a la base le falten estudios de optimización pero, al menos, mantendremos la performance actual.

Si la base se encuentra optimizada, entonces más aún, son necesarios para evitar la degradación producto del uso continuo. Cualquiera de estos trabajos deben realizarse fuera de línea por motivos de: alto consumo de recurso y bloqueo de las tablas en el momento de ejecución.

Las tablas que contienen índices al ser actualizadas o por inserción de nuevos datos, generan fragmentación de estos índices. Estas fragmentaciones conllevan a la pérdida de performance al acceder a ellas.

La instrucción DBCC DBREINDEX reorganiza el índice de una tabla o todos los índices definidos para una tabla. La reorganización de realiza dinámicamente sin necesidad de conocer la estructura de la misma o las restricciones que ella tenga. Por lo tanto no es necesario conocer si una tabla tiene clave primaria o si esta clave es única y además pertenece a algún índice, ya que la reorganización no necesita eliminar y recrear éstas restricciones para realizar su trabajo.

La sintaxis de esta instrucción es: DBCC DBREINDEX

( ‟basededatos.dueño.nombre_de_tabla„[ , índice

[ , fillfactor ]]

) [ WITH NO_INFOMSGS ]

Fillfactor es el porcentaje de espacio de página destinado a ser ocupado. El valor definido reemplaza al que fue generado en el momento de la creación del índice. Si se quiere mantener el valor original, entonces se utiliza el valor 0.WITH NO_INFOMSGS se suprimen los mensajes generados en la ejecución.

No es necesario conocer los nombres de todos los índices de todas las tablas, ya que si utilizamos la instrucción de la siguiente forma:

DBCC RBINDEX (Movimientos, „‟, 0).

Se reorganizarán todos los índices que contengan la tabla Movimientos, conservándose el fillfactor original de cada índice en particular.

Una de las formas de utilizarlo es, escribir un script con una sentencia DBCC RBINDEX por cada tabla que necesitemos reorganizar y agendarlas en forma periódica mediante un trabajo de mantenimiento dentro de algún horario disponible.

Por lo tanto, la recomendación será: elegir las tablas más accedidas y/o actualizadas, y reorganizarlas una vez entre semana. Para reorganizar todas las tablas que contengan índices se utiliza el mismo concepto, pero dentro de un procedimiento que recorra todas la tablas de la base y las reorganice, sin necesidad que escribamos todas la tablas que

INDEX_NAME BLEVEL OK

INX_CUENTA 1 OK BLEVEL

INX_TRABAJO 0 OK BLEVEL

INX_DINERO BLEVEL HIGH

contiene la base de datos. Estos procedimientos se pueden encontrar en el Forum bajo el nombre de Tips, y la idea es generar un trabajo de mantenimiento que se ejecute.

4.4.3 Reconstrucción de índices

Es importante periódicamente examinar y determinar qué índices son susceptibles de ser reconstruidos. Cuando un Índice está descompensado puede ser porque algunas partes de Éste han sido accedidas con mayor frecuencia que otras. Como resultado de este suceso podemos obtener problemas de contención de disco o cuellos de botella en el sistema. Normalmente reconstruimos un Índice con el comando ALTER INDEX.

Es importante tener actualizadas las estadísticas de la base de datos. Para saber si las estadísticas se están lanzando correctamente podemos hacer una consulta sobre la tabla dba_indexes y ver el campo last_analyzed para observar cuando se ejecutaron sobre ese Índice las estadísticas.

SELECT index_name, last_analyzedFROM dba_indexedWHERE table_owner=’nb_usuario’

Nota: Siendo nb_usuario el nombre del esquema del usuario para el que queramos validar las estadísticas. (Lanzar con usuario SYS) Para actualizar las estadísticas utilizamos el paquete DBM_STATS. Podemos actualizar las estadísticas de todos los objetos de un esquema de la siguiente forma:

Execute DBMS_STATS.gather_schema_stats(‘Esquema’);

Nota: Sustituimos esquema por el nombre de nuestro esquema a actualizar (lanzar con usuario SYS)

Una vez actualizadas las estadísticas de los Índices de la base de datos lanzamos la siguiente consulta:

SELECT index_name, blevel, DECODE(blevel,0,'OK BLEVEL',1,'OK BLEVEL',2,'OK BLEVEL',3,'OK BLEVEL',4,'OK BLEVEL','BLEVEL HIGH') OK FROM dba_indexes where table_owner='Propietario';

Nota: Sustituimos Propietario por el esquema o propietario que queramos verificar (lanzar con usuario SYS) Con esta sentencia obtendremos el nombre del Índice, el blevel y si es correcto.

Los Índices que deberíamos de reconstruir son los que en la columna ok aparecen como BLEVEL HIGH.Blevel (branch level) es parte del formato del B-tree del Índice e indica el número de veces que ORACLE ha tenido que reducir la búsqueda en ese Índice. Si este valor está por encima de 4 el Índice deberá de ser reconstruido.

Comando ALTER INDEXComo hemos comentado esta sentencia se utiliza para cambiar o reconstruir un Índice existente en la base de datos.

Para poder ejecutar este comando el Índice debe de estar en el propio esquema donde intentes ejecutarlo o deberías de tener el privilegio alter any index. También tenemos que tener en cuenta que para realizar la reconstrucción de un Índice deberíamos de tener cuota suficiente sobre el tablespace que lo lanzamos.

Para reconstruir un Índice bastaría con lazar la siguiente sentencia:

ALTER INDEX <index_name> REBUILD;

Para reconstruir una partición de un Índice podríamos hacer lo siguiente

ALTER INDEX <index_name> REBUILD PARTITION <nb_partition> NOLOGGING;

Nota: En algunos casos cuando alguno de los Índices tiene algún tipo de corrupción no es posible reconstruirlo. La solución en este caso es borrar el Índice y recrearlo.

Unidad 5: Seguridad5.1 Respaldo y Recuperación

Recuperación

Un sistema de recuperación consiste en restaurar la BD a un estado que se sepa correcto, tras cualquier fallo que la haya dejado en un estado incorrecto.Recuperación de BD: “devolver la BD a un estado consistente”

La recuperabilidad significa que, si se da algún error en los datos, hay un bug de programa o de hardware, el DBA (Administrador de base de datos) puede traer de vuelta la base de datos al tiempo y estado en que se encontraba en estado consistente antes de que el daño se causara. Las actividades de recuperación incluyen el hacer respaldos de la base de datos y almacenar esos respaldos de manera que se minimice el riesgo de daño ó pérdida de los mismos, tales como hacer diversas copias en medios de almacenamiento removibles y almacenarlos fuera del área en antelación a un desastre anticipado. La recuperación es una de las tareas más importantes de los DBA’s.

La recuperabilidad, frecuentemente denominada “recuperación de desastres”, tiene dos formas primarias. La primera son los respaldos y después las pruebas de recuperación.La recuperación de las bases de datos consiste en información y estampas de tiempo junto con bitácoras los cuales se cambian de manera tal que sean consistentes en un momento y fecha en particular. Es posible hacer respaldos de la base de datos que no incluyan las estampas de tiempo y las bitácoras, la diferencia reside en que el DBA debe sacar de línea la base de datos en caso de llevar a cabo una recuperación.

Respaldo

Es la obtención de una copia de los datos en otro medio magnético, de tal modo que a partir de dicha copia es posible restaurar el sistema al momento de haber realizado el respaldo. Por lo tanto, los respaldos deben hacerse con regularidad, con la frecuencia preestablecida y de la manera indicada, a efectos de hacerlos correctamente. Es fundamental hacer bien los respaldos. De nada sirven respaldos mal hechos (por ejemplo incompletos). En realidad, es peor disponer de respaldos no confiables que carecer totalmente de ellos.

Suele ocurrir que la realización de respaldos es relegada a un plano secundario.Existen varias maneras de respaldar base de datos MySQL, en este post únicamente mostraré una manera de hacerlo utilizando mysqldump() y PHP.

Básicamente lo que se realiza es un respaldo de todas las bases de datos, por lo que el script debe ejecutarse como un usuario que tenga permisos sobre todas las bases. Adicionalmente se mantiene en disco las últimas 3 copias de los respaldos.

5.1.1 Espejo (mirroring).

Se conoce como copia espejo (en inglés data mirroring) al procedimiento de protección de datos y de acceso a los mismos en los equipos informáticos implementado en la tecnología de RAID1. Consiste en la idea básica de tener dos discos duros conectados. Uno es el principal y en el segundo se guarda la copia exacta del principal, almacenando cualquier cambio que se haga en tiempo real en las particiones, directorios, etc, creando imágenes exactas, etc. De esta forma se consigue tener 2 discos duros idénticos y que permiten, si todo está bien configurado, que ante el fallo del disco principal, el secundario tome el relevo, impidiendo la caída del sistema y la pérdida de los datos almacenados.5.1.1.1 Beneficios del espejeo de Datos en un DBMS.

Además de proporcionar una copia adicional de los datos con el fin de redundancia en caso de fallo de hardware, la duplicación de disco puede permitir que cada disco se acceda por separado para los propósitos de lectura. En determinadas circunstancias esto puede mejorar significativamente el rendimiento ya que el sistema puede elegir para cada lectura que disco puede buscar más rápidamente a los datos requeridos. Esto es especialmente importante cuando hay varias tareas que compiten por los datos en el mismo disco, y el "trashing" (donde el cambio entre tareas ocupa más tiempo que la tarea en sí) se puede reducir. Esta es una consideración importante en las configuraciones de hardware que frecuentemente tienen acceso a los datos en el disco.

En algunas implementaciones, el disco reflejado se puede dividir fuera y se utiliza para la copia de seguridad de datos, permitiendo que el primer disco para permanecer activos. Sin embargo, la fusión de los dos discos se puede requerir un período de sincronización en su caso escribir la actividad I/O ha ocurrido con el disco duplicado.5.1.1.2 Activación de espejeo en un DBMS.

MySQL. Lo primero que debemos hacer es checar si ambos servidores se encuentran en red Caso Windows

SoftwareVerifque que el MySQL instalado en el maestro y en el esclavo son iguales. En este casp MySQL Server 5.6Configuración del Maestro

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

2. Buscar y comentar las siguientes lineas si es que se encuentran:

#skip-networking

#bind-address = 127.0.0.1

3. Agregar después de la línea [mysqld] lo siguiente:

log-bin =mysql-bin.log

binlog-do-db=dolar

server-id=1

Nota: El server-id en el servidor siempre será 1, y los esclavos serán 2, 3… n según

sea el caso en binlog-do-db se pone el nombre de la base de datos que replicara

después de signo =

4. Desde el panel de control entramos en Herramientas administrativas, Servicios y

reanudamos MySQL. Este paso se omite en Linux

5. Ahora en el shell de mysql genere una cuenta para el esclavo con el

privilegio REPLICATION SLAVE:

GRANT REPLICATION SLAVE ON *.* TO 'esclavo1'@'%' IDENTIFIED BY

'bingo';

FLUSH PRIVILEGES;

Nota: esclavo1 es el usuario identificado por el passwword bingo.Los posteriores

replicadores deberán ser esclavo2, ..., esclavo-n.

6. Seleccione la base de datos a replicar y realice lo siguiente:

USE dolar;

FLUSH TABLES WITH READ LOCK;

SHOW MASTER STATUS;

El resultado será algo similar a la figura

La columna File muestra el nombre del log, mientras que Position muestra el

desplazamiento. En este ejemplo, el valor del log binario es BARBANEGRA-

bin.000004 y el desplazamiento es 1057. 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.

7. Salir de MySQL usando el comando exit o quit.

8. Ahora desde la terminal o en el cmd haremos un Backup de la Base de Datos que se

encuentra en el Maestro para tener el mismo esquema y datos en los esclavos:

mysqldump -u root -p -dolar > dolar.sql

9. Por últino desbloqueamos la base de datos

mysql -u root -p

UNLOCK TABLES;

quit;1. Configuración del esclavo

1. Crear la base de datos que queremos replicar:

mysql -u root -p

CREATE DATABASE dolar;

quit;

2. Ejecutar desde la consola o a terminal el siguiente comando para copiar la base de

datos del archivo que generamos:

mysql -u root -p dolar < dolar.sql

3. Localizar el archivo My.cnf (en caso de windows My.ini) y después del [mysqld]

agregamos lo siguiente:

server-id=2

replicate-do-db=nombre_base_de_datos

En nuesto caso

server-id=2

replicate-do-db=dolar

4. Reiniciamos el servicio de MySql y comprobamos el server-id,

mysql -u root -p

SHOW VARIABLES LIKE "server-id";

5. Ahora le indicaremos al esclavo la dirección del maestro, el usuario, password y

directivas de control (master_log_file y master_log_pos)

CHANGE MASTER TO master_host = '192.168.1.65', master_user='esclavo1',

master_password='bingo', master_log_file='barbanegra-bin.000004',

master_log_pos=1057;

Nota: Si olvido las directivas de control. Desde la consola del maestro use la

sentencia SHOW MASTER STATUS;

6. Ahora iniciamos el esclavo y comprobamos su estado

START SLAVE; SHOW SLAVE STATUS\G;

5.1.1.3 Creación de espacios de disco con espejo.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/sdd1mdadm --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.

5.1.2 Replica (replication).La replicación es un mecanismo utilizado para propagar y diseminar datos en un ambiente distribuido, con el objetivo de tener mejor performance y confiabilidad, mediante la reducción de dependencia de un sistema de base de datos centralizado.Para garantizar que una aplicación distribuida sea altamente disponible (es decir, que pueda proporcionar servicio de manera continua) se deben instanciar múltiples réplicas de ésta en distintos ordenadores. Se debe conseguir que cada uno de los ordenadores que mantenga una réplica de la aplicación sea independiente del resto ante la ocurrencia de fallos.El objetivo principal para la distribución de datos es proveer un acceso sencillo a la información por parte de los usuarios de múltiples localidades o nodos de trabajo de una red de computadoras. Para alcanzar este objetivo, los sistemas de BDD deben proveer transparencia de ubicación, que significa que el usuario no necesita conocer la localización física de cada dato dentro de la red. Idealmente, la información en la red

aparece como si fuera parte de una BD no distribuida almacenada en un sitio "central", hacia donde todos los usuarios convergen.La replicación de la información en una BDD apunta a aumentar la disponibilidad de la información. Esta disponibilidad puede observarse desde dos perspectivas: Aumentar el paralelismo en las consultas, dado que la misma información residirá en

más de una localidad de la red. Mejorar la disponibilidad de los datos ante eventuales caídas de nodos de la red.El concepto de replicación es muy amplio e involucra muchos aspectos que hacen al diseño de datos de la BDD. Los protocolos de aseguramiento de integridad de la información y los protocolos de actualización de las réplicas son los puntos más interesantes para ser tenidos en cuenta.

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

Disponibilidad: El modo en que la replicación incrementa la disponibilidad de los datos para los usuarios y aplicaciones.

Fiabilidad: Al haber múltiples copias de los datos disponibles en el sistema, se dispone un mecanismo excelente de recuperación cuando existan fallos en nodos.

Rendimiento: Se mejora para las transacciones de consulta cuando se introduce la replicación en un sistema que estuviera aquejado de sobrecarga de recursos centralizados.

Reducción de la carga: Modo en que se utiliza la replicación para distribuir datos en ubicaciones remotas.

Procesamiento Desconectado: Modo en que la replicación puede implementarse mediante mecanismos instantáneas.

Soporta muchos usuarios: se puede crear múltiples instantáneas personalizadas que satisfagan los requisitos de cada usuario o grupo de usuarios del sistema.

Soporta aplicaciones avanzadas: para OLPT(Online transaction processing),OLAP(Online analitical processing).

5.1.3 Métodos de respaldo de un DBMS

En mySQL existen varios métodos para la realización de un backup y esto se debe principalmente a que mySQL guarda las tablas como archivos y al tipo de tablas que se este 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

5.1.3.2 Comandos para respaldo de datos

Respaldo y Restauración MySQL de Manera Local. Para hacer un respaldo de una base de datos MySQL desde nuestro consola o mediante comandos shell podemos usar el comando mysqldump como lo ejemplificamos en la siguiente liga.Comando: mysqldump -u "usuario" -p"contraseña" nombre-de-la-base-de-datos > nombre-del-respaldo.sqlNOTA: Las comillas deben omitirse tanto en el usuario como en la contraseña.Para restaurar un respaldo de una base de datos MySQL usamos el siguiente comandoComando: mysql -u "usuario" -p"contraseña" nombre-de-la-base-de-datos < nombre-del-respaldo.sql NOTA: Al igual que en el ejemplo anterior las comillas deben omitirse tanto en el usuario como en la contraseña.Respaldo y Restauración MySQL de Manera Remota. Para Respaldar o Restaurar una Base de datos remota usamos los mismos comandos que de manera local, con la única diferencia de agregar la opción "-h" con la cual especificaremos el nombre o dirección del host en donde se encuentra nuestra base.Para Respaldar usamos: Comando: mysqldump -u "usuario" -p"contraseña" -h"nombre-o-dirección-del-host" nombre-de-la-base-de-datos > nombre-del-respaldo.sql Para restaurar usamos: Comando: mysql -u "usuario" -p"contraseña" -h"nombre-o-dirección-del-host" nombre-de-la-base-de-datos < nombre-del-respaldo.sql 5.1.3.3 Métodos de recuperación de un DBMSCopias de seguridad de la base de datos

Para poder efectuar cualquier tipo de restauración de una base de datos, es necesaria la realización de copias de seguridad (Backus) de la base de datos de forma periódica. Este proceso consiste en la escritura de una copia exacta de la base de datos en un dispositivo magnético separado del que contiene a la propia base de datos. En los sistemas más grandes, este dispositivo suele ser una cinta magnética. En los sistemas basados en microordenadores, puede tratarse de un cartucho de cinta de casete, o de uno o más discos flexibles. Habitualmente, mientras se está generando una copia de seguridad es preciso detener todas las demás actividades de la base de datos.

Un método sencillo de recuperación

El método más simple de recuperación de una base de datos es el expuesto a continuación. Periódicamente, quizá una vez cada día, se realiza una copia de seguridad de la base de datos. Comenzando a partir del momento en el que se hace cada copia, se lleva manualmente una lista física, o diario (log), de todos los cambios subsiguientes que se efectúan en la base de datos. Si la base de datos es dañada o destruida, para recuperarla es preciso seguir la secuencia de pasos siguiente:

- Reparar el problema de hardware o software que causó la caída del sistema.- Restaurar la base de datos a partir de la copia de seguridadmásreciente. Esto no

restaura la base de datos a su estado en el instante en el que tuvo lugar el daño.- Volver a introducir manualmente en la base de datos los cambiosrealizadosdesde

que se hizo la copia, usando la lista física.

Diarios de transacciones y restauración/reejecución

La clave para el uso con éxito de un diario de transacciones radica en la capacidad del SGBD para reconocer el comienzo y el final de cada transacción. Para cada transacción de la base de datos, el diario contiene marcas de “comienzo de transacción” y “final de transacción”, además de una grabación de los cambios individuales realizados en la base de datos para dicha transacción. La marca de “final de transacción” se graba en el diario sólo después de la conclusión con éxito de la transacción. Así, si una caída del sistema interrumpe el procesamiento de una transacción, no aparecerá ninguna marca de “final de transacción” en el diario. Cuando se realice un proceso de restauración/reejecución, sólo se restaurarán a partir del diario las transacciones completadas, y se generará un informe impreso, que indicará qué transacciones no se han completado y, por tanto, no han sido introducidas en la base de datos.

Para bases de datos extremadamente activas, la técnica de restauración/reejecución puede resultar inadecuada, ya que el reprocesamiento del diario puede llevar varias horas, durante las cuales la base de datos no puede ser usada con normalidad. Si una base de datos es muy activa, esta no disponibilidad puede revelarse intolerable, y será preciso emplear otras técnicas de restauración.

Recuperación por retroceso

La recuperación por retroceso resulta útil en situaciones en las que el procesamiento de la base de datos se ve interrumpido, pero la base de datos en sí no resulta dañada de forma alguna. Un ejemplo de esto podría ser algún tipo de fallo que produzca una terminación anormal de la ejecución del SGBD. Las transacciones en marcha podrían ser abortadas antes de su finalización, y los registros asociados a las mismas quedarían en estados desconocidos, aunque el resto de la base de datos no se vería afectada.

La técnica de recuperación por retroceso requiere que el diario de transacciones contenga imágenes iniciales de cada registro de la base de datos que haya sufrido modificaciones desde la última copia de seguridad. Una imagen inicial es una copia de un registro tal como se encontraba inmediatamente antes de ser modificado como parte de una transacción, es decir, justo antes del inicio de dicha transacción.

Para que la recuperación por retroceso pueda funcionar, el diario de transacciones debe contener marcas de “comienzo de transacción” y de “final de transacción” para cada transacción. Cuando se realiza un proceso de recuperación, las transacciones incompletas se detectan por la ausencia de una marca de “final de transacción”.

Recuperación por adelantoEl adelanto es otro tipo de mecanismo de recuperación, que se usa a menudo cuando una base de datos ha sido dañada y debe, por tanto, ser restaurada a partir de una copia de seguridad. Se parece a la técnica del retroceso, y comparte con ésta la ventaja de que es mucho más rápida que el método de restauración/reejecución. Requiere que el diario de transacciones contenga una imagen final de cada registro de la base de datos que ha sido modificado desde la última copia. Una imagen final es una copia de un registro, inmediatamente después de haber sido modificado como parte de una transacción, es decir, en el estado en que se encuentra al finalizar dicha transacción.En su forma más simple, esta técnica consta de dos etapas:

- Después de un fallo que produce un daño en la base de datos, se utiliza la última copia de seguridad para restaurarla.

- Se procesa el diario, a partir del punto en que se efectuó la última copia de seguridad. Para cada transacción completada anotada en el diario, se sustituye la versión actual del registro de la base de datos por la imagen final correspondiente.

Esta técnica es considerablemente más rápida que la de restauración/reejecución, ya que la sustitución de un registro por su imagen final lleva mucho menos tiempo que el proceso de recreación de la base de datos completa a partir de la copia de seguridad.

5.1.4 Comandos para recuperaciónServicios de Respaldo y Recuperación para Bases de Datos (BD)

Es de suma importancia tener algún sistema de respaldo/recuperación de datos, pues esto permite:

- Tener sistemas con cierto nivel de seguridad y estabilidad ante posibles fallos.- Poder volver a un punto seguro en el estado de la BD, debido a cambios peligrosos.

Su funcionamiento está basado en estados. En cada momento la BD se encuentra en un estado definido. Cuando realizamos operaciones de modificación, es decir:

- INSERT- UPDATE- DELETE

Cambiamos su estado, llevándolo a uno nuevo.

No se considera SELECT, pues no provoca cambios. Recordemos que es una operación de selección.Al momento de realizar un respaldo, se guarda el estado en que se encuentra la BD al momento de realizar dicha operación de respaldo. Al momento de realizar la operación de recuperación, puede ser de varias formas, ya sea a través de las operaciones (en orden) que han dejado la BD en el estado actual u otras formas. La gran mayoría de Motores de BD cuentan con funciones de este tipo:SQL Dump¶pg_dump¶

Esta función genera un archivo de texto con comandos SQL que, cuando son reintroducidos (bajo cierto contexto ) al servidor, se deja a la BD en el mismo estado en el que se encontraba al momento de ejecutar este comando.

Esto ocurre siempre y cuando la BD esté vacía, es decir, en el mismo estado inicial. Su sintaxis es:

pg_dump dbname > archivo_salidaY se usa desde la linea de comandos.

Para realizar la restauración se utiliza:psql dbname < archivo_entradaDonde archivo_entrada corresponde al archivo_salida de la instrucción pg_dump.

5.1.4.1 Aplicación de cada métodoRecuperación Física

La utilización de una copia de backup de ficheros de datos siempre necesita de una recuperación física. También es así cuando un fichero de datos se pone offline sin un checkpoint.

Existen tres opciones para realizar una recuperacion física. La primera es una recuperación de BD donde se restaura la BD entera. La segunda es una recuperación de tablespace donde, mientras una parte de la BD está abierta, se puede recuperar un tablespace determinado. Esto significa que serán recuperados todos los ficheros de datos asociados al tablespace. El tercer tipo es la recuperación de un fichero de datos específico mientras el resto de la BD está abierta.

Requisitos para Utilizar Recuperación Física

La primera condición que se ha de poner para poder recuperar físicamente una BD es que ésta se esté utilizando en modo ARCHIVELOG. De otro modo, una recuperación completa puede que no sea posible. Si trabajamos con la BD en modo NOARCHIVELOG, y se hace una copia semanal de los ficheros de la BD, se debería estar preparado para perder, en el peor de los casos, el trabajo de la última semana si sucede un fallo. Ya que los ficheros de redo log contendrían un agujero y no se podia avanzar la BD hasta el intante anterior al fallo. En este caso el único medio para reconstruir la BD es hacerlo desde un export completo, recreando el esquema de la BD e importando todos los datos.

Recuperación de la BD

La BD debe estar montada pero no abierta. El comando de recuperación es el siguiente:

RECOVER [AUTOMATIC] [FROM 'localizacion'] [BD] [UNTIL CANCEL] [UNTIL TIME fecha] [UNTIL CHANGE entero][USING BACKUP CONTROLFILE]

Las opciones entre corchetes son opcionales:

AUTOMATIC hace que la recuperación se haga automáticamente sin preguntar al DBA por el nombre de los ficheros redo log. También se puede utilizar para este cometido el comando set autorecovery on/off. Los ficheros redo log deben estar en la localización fijada en LOG_ARCHIVE_DEST y el formato del nombre de los ficheros debe ser el fijado en LOG_ARCHIVE_FORMAT.

FROM se utiliza para determinar el lugar donde están los ficheros redo log, si es distinto del fijado en LOG_ARCHIVE_DEST.

UNTIL sirve para indicar que se desea realizar una recuperación incompleta, lo que implica perder datos. Solo se dará cuando se han perdido redo log archivados o el fichero de control. Cuando se ha realizado una recuperación incompleta la BD debe ser abierta con el comando alter database open resetlogs, lo que produce que los redo log no aplicados no se apliquen nunca y se inicialice la secuencia de redo log en el fichero de control. Existen tres opciones para parar la recuperación:

o UNTIL CANCEL permite recuperar un redo log cada vez, parando cuando se teclea CANCEL.

o UNTIL TIME permite recuperar hasta un instante dado dentro de un fichero de redo log

o UNTIL CHANGE permite recuperar hasta un SCN dado. o USING BACKUP CONTROLFILE utiliza una copia de seguridad del

fichero de control para gobernar la recuperación.

Recuperación de un tablespace

La BD debe estar abierta, pero con el tablespace a recuperar offline. El comando de recuperación es el siguiente:

RECOVER [AUTOMATIC] [FROM 'localizacion'] TABLESPACE nombre_tablespace [, nombre_tablespace]

Recuperación de un Fichero de Datos

La BD debe estar abierta o cerrada, dependiendo del fichero a recuperar. Si el fichero a recuperar es de un tablespace de usuario la BD puede estar abierta, pero con el fichero a recuperar offline. Si el fichero es del tablespace SYSTEM la BD debe estar cerrada, ya que no puede estar abierta con los ficheros del SYSTEM offline. El comando de recuperación es el siguiente:

RECOVER [AUTOMATIC] [FROM 'localizacion'] DATAFILE nombre_fichero [, nombre_fichero]

Creando un Fichero de Control

Si el fichero de control ha resultado dañado y se ha perdido se puede utilizar una copia de seguridad del mismo o crear uno nuevo. El comando de creación de un nuevo fichero de control es CREATE CONTROLFILE. Este comando se puede ejecutar sólo con la BD en estado nomount. La ejecución del comando produce un nuevo fichero de control y el montaje automático de la BD.

Un comando interesante que ayuda a mantener los ficheros de control a salvo es el siguiente:

SVRMGR> alter database backup controlfile to trace;

que produce un script que puede ser utilizado para generar un nuevo fichero de control y recuperar la BD, en caso necesario. El fichero de traza generado es el siguiente:

Dump file /opt/app/oracle/admin/demo/udump/demo_ora_515.trcOracle7 Server Release 7.3.2.3.0 - Production ReleaseWith the distributed, replication and Spatial Data optionsPL/SQL Release 2.3.2.3.0 - ProductionORACLE_HOME = /opt/app/oracle/product/7.3.2System name: SunOSNode name: cartanRelease: 5.5Version: GenericMachine: sun4mInstance name: demoRedo thread mounted by this instance: 1Oracle process number: 7

Unix process pid: 515, image: oracledemo Fri May 15 11:41:19 1998Fri May 15 11:41:19 1998*** SESSION ID:(6.2035) 1998.05.15.11.41.19.000# The following commands will create a new control file and use it# to open the database.# No data other than log history will be lost. Additional logs may# be required for media recovery of offline data files. Use this# only if the current version of all online logs are available.STARTUP NOMOUNTCREATE CONTROLFILE REUSE DATABASE "DEMO" NORESETLOGS NOARCHIVELOG MAXLOGFILES 16 MAXLOGMEMBERS 2 MAXDATAFILES 30 MAXINSTANCES 1 MAXLOGHISTORY 100LOGFILE GROUP 1 '/export/home/oradata/demo/redodemo01.log' SIZE 2M, GROUP 2 '/export/home/oradata/demo/redodemo02.log' SIZE 2M, GROUP 3 '/export/home/oradata/demo/redodemo03.log' SIZE 2MDATAFILE '/export/home/oradata/demo/system01.dbf', '/export/home/oradata/demo/rbs01.dbf', '/export/home/oradata/demo/rbs02.dbf', '/export/home/oradata/demo/rbs03.dbf', '/export/home/oradata/demo/temp01.dbf', '/export/home/oradata/demo/tools01.dbf', '/export/home/oradata/demo/users01.dbf';# Recovery is required if any of the datafiles are restored backups,# or if the last shutdown was not normal or immediate.RECOVER DATABASE# Database can now be opened normally.ALTER DATABASE OPEN;

Recuperación Lógica

Oracle dispone de la herramienta import para restaurar los datos de una BD a partir de los ficheros resultados de un export. Import lee los datos de los ficheros de exportación y ejecuta las sentencias que almacenan creando las tablas y llenándolas de datos.

Parámetros del Import

Parámetro Defecto Descripción

USERID indefinidoel username/password del usuario que efectua el import.

BUFFERdependiente del SO

El tamaño en bytes del buffer utilizado.

FILE expdat.dmpel nombre del fichero de exportación a importar.

SHOW Noindica si se muestran los contenidos del fichero de exportación, sin importar ningún dato.

IGNORE Yesindica si ignorar los errores producidos al importar un objeto que ya existe en la BD.

GRANTS Yes indica si se importan también los derechos.

INDEXES Yes indica si se importan también los índices.

ROWS Yesindica si se importan también las filas de las tablas.

FULL No indica si se importan el fichero entero.

FROMUSER Indefinidouna lista de los usuarios cuyos objetos se han exportado.

TOUSER Indefinidouna lista de los usuarios a cuyo nombre se importan los objetos.

TABLES indefinido la lista de tablas a importar.

RECORDLENGTHdependiente del SO

la longitud en bytes del registro del fichero.

INCTYPE indefinidoel tipo de import incremental (SYSTEM o RESTORE).

COMMIT Noindica si se efectua un commit después de importar cada fila. Por defecto, import efectua un commit después de cargar cada tabla.

PARFILE indefinido el fichero de parámetros.

Para importar un export incremental se puede efectuar la siguiente secuencia de pasos:

1. Utilizar la copia más reciente del import para restaurar las definiciones del sistema: 2. $ imp userid=sys/passwd inctype=system full=Y file=export_filename3. Poner los segmentos de rollback online. 4. Importar el fichero de exportación completa más reciente: 5. $ imp userid=sys/passwd inctype=restore full=Y file=filename6. Importar los ficheros de exportación en modo acumulación desde la exportación

completa más reciente, en orden cronológico: 7. $ imp userid=sys/passwd inctype=restore full=Y file=filename8. Importar los ficheros de exportación en modo incremental desde la exportación

completa o acumulativa más reciente, en orden cronológico: 9. $ imp userid=sys/passwd inctype=restore full=Y file=filename

5.2 Migración de la base de datosMigración de datos

Hablamos de migración de datos cuando nos referimos al traspaso de información entre bases de datos. Si tenemos una aplicación sobre una base de datos como por ejemplo Access y posteriormente "crecemos" de manera que nos hace falta un sistema gestor de bases de datos potente, lo más seguro es que nos decantemos por Oracle, DB2, Informix, SQLServer o similares.

En este caso, los datos, que estarán en formato "access" deberán pasar a formato "sqlserver" o formato para "oracle". La migración de los datos consiste en convertir los datos desde un sistema de base de datos a otro. Esta migración conlleva la creación de tablas o modificación de las existentes, cambios en algunos tipos de datos que existen en una base de datos pero no en otras, etc.

Técnicas de Migración de Datos PlaneaciónLo más importante al migrar una Base de Datos es llevar a cabo un proceso de planeación y análisis del trabajo, puesto que aunque pareciera tomarse algún tiempo adicional, éste será retribuido en el éxito de la operación y menos costos por errores de datos. Es importante que esto sea aplicado cuando la Base de Datos destino está en producción.

Contador de registrosSi la migración se realiza de forma manual, mediante alguna consulta de inserción es recomendable inicializar un contador para cada registro insertado con éxito y otro para los no insertados, así obviamente, la suma de ambos debe ser igual a los registros originales.

5.3.1 Monitoreo5.3.1.2 Monitoreo de espacio en disco.Es muy sencillo utilizarlo, solo basta con ejecutar el comando xp_fixeddrives de vez en cuando desde el Analizador de consultas para revisar la cantidad de espacio libre, aunque este método consume demasiado tiempo para los administradores de bases de datos. Un método mejor sería automatizar la ejecución de este comando periódicamente para revisar la cantidad de espacio libre. Algunas tareas de DBA donde la información de espacio libre puede ser útil:- La primera que se alerte al DBA cuando el espacio libre cae por debajo de un umbral específico en cualquier unidad de SQL Server.- La segunda sería la de realizar un seguimiento de la historia el espacio libre para la gestión de la capacidad de espacio en disco.

La forma de construir un proceso para alertar a la DEA, cuando cualquiera de las unidades de disco de SQL Server cae por debajo de un umbral predeterminado. Para obtener la información xp_fixeddrives en una tabla temporal que se utiliza el siguiente T-SQL.create table #FreeSpace(Drive char(1),

MB_Free int)insert into #FreeSpace exec xp_fixeddrives

A continuación, por cada unidad se recupera la información de espacio libre a partir de esta tabla temporal y se compara con un umbral que se ha fijado para cada unidad. Si la cantidad de espacio libre cae por debajo del valor umbral determinado para la unidad, enviar alerta al DBA mediante xp_sendmail. Aquí está una muestra de un código que hace precisamente eso.declare @MB_Free intcreate table #FreeSpace(Drive char(1), MB_Free int)insert into #FreeSpace exec xp_fixeddrivesselect @MB_Free = MB_Free from #FreeSpace where Drive = 'C'-- Free Space on C drive Less than Thresholdif @MB_Free < 1024exec 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'

5.3.1.3 Monitoreo de logs.Monitoreando el log de transacciones

Monitorear el log regularmente puede ayudarnos a resolver varios problemas dentro de

nuestros sistemas, ya que este puede indicarnos si existen demasiadas transacciones

realizadas por una sola aplicación, que podría resultar en un mal diseño o simplemente la

necesidad de planear mejor los recursos de log en nuestro servidor de base de datos.

Es muy importante tener en cuenta que si el log de transacciones llegara a saturarse, SQL

Server no podrá realizar más cambios dentro de nuestra base de datos.

La manera de monitorear un log de transacciones, puede llevarse a cabo de 2 maneras, una

de ellas es mediante un comando desde el analizador de consultas y la otra utilizando los

contadores de SQL Server desde el sistema operativo.

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

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

Contador Descripción

Log Bytes

Flushed/sec

Número total de bytes del log de transacciones vaciados

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

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

vaciar el log de transacciones.

Percent Log Used Porcentaje del log de transacciones usado.

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

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

registro.

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

Algunas de las situaciones por la que podría presentarse mucha actividades en el log de

transacciones y saturarlo son:

Cargar información en una tabla que tiene indices. SQL Server almacena en el log todos los

inserts y cambios en los índices. Cuando se carga en tablas que no tienen indices SQL

Server solo reserva extents para el log.

Transacciones que realizan muchas modificaciones (INSERT, UPDATE,DELETE) a una

tabla en una sola transacción. Esto generalmente occurre cuando la sentencia WHERE es

muy general, causando que muchos registros sean modificados.

Expandiendo el log de transacciones

Expandir un log de transacciones debe de realizarse solamente si en verdad es requerido por

la aplicación y no solo por el echo de asignar más espacio, ya que para ello existen los

respaldos del log de transacciones en donde se vacia el espacio ocupado del log.

Para asignar espacio de log a una base de datos pues realizarse mediante el SQL Server

Enterprise Manager o la sentencia ALTER DATABASE, en esta caso hablaremos

solamente de la sentencia ALTER DATABASE

Ejemplo:

Agregar dos archivos de log a una base de datos

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

USE master

GO

ALTER DATABASE Test1

ADD LOG FILE

( NAME = test1log2,

FILENAME = 'c:\Program Files\Microsoft SQL Server\MSSQL\Data\test2log.ldf',

SIZE = 5MB,

MAXSIZE = 100MB,

FILEGROWTH = 5MB),

( NAME = test1log3,

FILENAME = 'c:\Program Files\Microsoft SQL Server\MSSQL\Data\test3log.ldf',

SIZE = 5MB,

MAXSIZE = 100MB,

FILEGROWTH = 5MB)

GO

5.3.1.4 Monitoreo de Memoria compartidaPGA DE ORACLE (ÁREA GLOBAL DE PROGRAMA)Un PGA es una región de memoria que contiene datos e información de control para un proceso de servidor. Es la memoria no compartida creada por la base de datos Oracle cuando un proceso de servidor se ha iniciado. El acceso a la PGA es exclusivo para el proceso del servidor. Hay un PGA para cada proceso de servidor. Procesos en segundo plano también se asignan sus propios PGA. La memoria total utilizada por todos los PGAs individuales se conoce como el ejemplo total de memoria PGA, y la recogida de PGAs individuales se refiere como el ejemplo total de la PGA, o simplemente instancia de la PGA. Puede utilizar los parámetros de inicialización de base de datos para definir el tamaño de la instancia de la PGA, no PGA individuales.

El PGA puede ser crítico para el rendimiento, especialmente si la aplicación está haciendo un gran número de clases. Operaciones de ordenación se produce si utiliza ORDER BY y GROUP BY comandos en las sentencias SQL.

SGA de oracle (Sistema de Área Global)

Es un conjunto de áreas de memoria compartida que se dedican a un Oráculo "instancia" (un ejemplo es los programas de bases de datos y la memoria RAM).Sirve para facilitar la transferencia de información entre usuarios y también almacena la información estructural de la BD más frecuentemente requerida.En los sistemas de bases de datos desarrollados por la Corporación Oracle , el área global del sistema (SGA) forma parte de la memoria RAM compartida por todos los procesos que pertenecen a una sola base de datos Oracle ejemplo. El SGA contiene toda la información necesaria para la operación de la instancia.La SGA se divide en varias partes:Buffers de BD, Database Buffer CacheEs el caché que almacena los bloques de datos leidos de los segmentos de datos de la BD, tales como tablas, índices y clusters. Los bloques modificados se llamas bloques sucios. El tamaño de buffer caché se fija por el parámetro DB_BLOCK_BUFFERS del fichero init.ora.Plan de ejecución de la sentencia SQL.Texto de la sentencia.Lista de objetos referenciados.Comprobar si la sentencia se encuentra en el área compartida.Comprobar si los objetos referenciados son los mismos.Comprobar si el usuario tiene acceso a los objetos referenciados.

Como el tamaño del buffer suele ser pequeño para almacenar todos los bloques de datos leidos, su gestión se hace mediante el algoritmo LRU.2. Buffer Redo Log

Los registros Redo describen los cámbios realizados en la BD y son escritos en los ficheros redo log para que puedan ser utilizados en las operaciones de recuperación hacia adelante, roll-forward, durante las recuperaciones de la BD. Pero antes de ser escritos en los ficheros redo log son escritos en un caché de la SGA llamado redo log buffer. El servidor escribe periódicamente los registros redo log en los ficheros redo log.El tamaño del buffer redo log se fija por el parámetro LOG_BUFFER.

3. Área de SQL Compartido, Shared SQL PoolEn esta zona se encuentran las sentencias SQL que han sido analizadas. El analisis sintáctico de las sentencias SQL lleva su tiempo y Oracle mantiene las estructuras asociadas a cada sentencia SQL analizada durante el tiempo que pueda para ver si puede reutilizarlas. Antes de analizar una sentencia SQL, Oracle mira a ver si encuentra otra sentencia exactamente igual en la zona de SQL compartido. Si es así, no la analiza y pasa directamente a ejecutar la que mantinene en memoria. De esta manera se premia la uniformidad en la programación de las aplicaciones. La igualdad se entiende que es lexicografica, espacios en blanco y variables incluidas. El contenido de la zona de SQL compartido es:

También se almacena en la zona de SQL compartido el caché del diccionario. La información sobre los objetos de la BD se encuentra almacenada en las tablas del diccionario. Cuando esta información se necesita, se leen las tablas del diccionario y su información se guarda en el caché del diccionario de la SGA.

Este caché también se administra mediante el algoritmo LRU. El tamaño del caché está gestionado internamente por el servidor, pero es parte del shared pool, cuyo manaño viene determinado por el parámetro SHARED_POOL_SIZE.

5.3.1.5 Monitoreo de Base de Datos¿Qué es la Auditoría de BD?Es el proceso que permite medir, asegurar, demostrar, monitorear y registrar los accesos a la información almacenada en las bases de datos incluyendo la capacidad de determinar:– Quién accede a los datos.– Cuándo se accedió a los datos.– Desde qué tipo de dispositivo/aplicación.– Desde que ubicación en la Red.– Cuál fue la sentencia SQL ejecutada.– Cuál fue el efecto del acceso a la base de datos.

Es uno de los procesos fundamentales para apoyar la responsabilidad delegada a IT por la organización frente a las regulaciones y su entorno de negocios o actividad.

Objetivos Generales de la Auditoría de BDDisponer de mecanismos que permitan tener trazas de auditoría completas y automáticas relacionadas con el acceso a las bases de datos incluyendo la capacidad de generar alertas con el objetivo de:

– Mitigar los riesgos asociados con el manejo inadecuado de los datos.– Apoyar el cumplimiento regulatorio.– Satisfacer los requerimientos de los auditores.– Evitar acciones criminales.– Evitar multas por incumplimiento.

La importancia de la auditoría del entorno de bases de datos radica en que es el punto de partida para poder realizar la auditoría de las aplicaciones que utiliza esta tecnología.

La Auditoría de BD es importante porque:– Toda la información financiera de la organización reside en bases de datos y deben existir controles relacionados con el acceso a las mismas.– Se debe poder demostrar la integridad de la información almacenada en las bases de datos.– Las organizaciones deben mitigar los riesgos asociados a la pérdida de datos y a la fuga de información.– La información confidencial de los clientes, son responsabilidad de las organizaciones.– Los datos convertidos en información a través de bases de datos y procesos de negocios representan el negocio.– Las organizaciones deben tomar medidas mucho más allá de asegurar sus datos.  Deben monitorearse perfectamente a fin de conocer quién o qué les hizo exactamente qué, cuándo y cómo.Mediante la auditoría de bases de datos se evaluará:– Definición de estructuras físicas y lógicas de las bases de datos.– Control de carga y mantenimiento de las bases de datos.– Integridad de los datos y protección de accesos.– Estándares para análisis y programación en el uso de bases de datos.– Procedimientos de respaldo y de recuperación de datos.

Aspectos Claves• No se debe comprometer el desempeño de las bases de datos– Soportar diferentes esquemas de auditoría.– Se debe tomar en cuenta el tamaño de las bases de datos a auditar y los posibles SLA establecidos.

• Segregación de funciones– El sistema de auditoría de base de datos no puede ser administrado por los DBA del área de IT.• Proveer valor a la operación del negocio– Información para auditoría y seguridad.– Información para apoyar la toma de decisiones de la organización.

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

• Auditoría completa y extensiva– Cubrir gran cantidad de manejadores de bases de datos.– Estandarizar los reportes y reglas de auditoría.

5.3.1.7 Monitoreo de espacios espejeados.La optimización en MySQL pasa por tres componentes, a saber:

Optimización del servidor MySQL Optimización de la base de datos Optimización de las consultas

Optimización de la configuración del servidor MySQL

La optimización del servidor puede incluir una multitud de enfoques y métodos, lo que intentaremos presentar en lo que sigue es una introducción a los enfoques de base, a saber:

Compilación del servidor Afinamiento de los parámetros del servidor Afinamiento de otros parámetros

Optimización de la base de datos

Generalmente para la optimización de las bases de datos lo recomendado es hacer uso de las buenas prácticas y las metodologías de concepción de base de datos que permitan implementar esquemas de bases de datos eficaces y normalizados. Sin embargo para ello es necesario:Saber lo que está lento en las bases de datos

- Elegir la metodología correcta - Utilizar índices- Utilizar OPTIMIZE TABLE

Para hacer una buena optimización, es necesario proceder con una metodología empírica a saber hacer las modificaciones una por una y probar cada vez la reacción del sistema para ver el resultado. Una medida del rendimiento antes y después de haber efectuado la optimización permite ver si el sistema ha sido optimizado o no.

Optimización de las consultas

MySQL permite analizar las consultas y conocer el tiempo y plan de ejecución. Esta información permite comprender lo que hace que las consultas sean lentas y optimizar la ejecución de éstas.Detectar las consultas lentas

Para detectar las consultas lentas es posible:- observar las consultas lentas durante su ejecución y los tiempos de respuesta anormales.

- hacer un benchmark: testear las aplicaciones para ver qué componentes son los más lentos.- verificar el Slow query log: es posible activar esta opción en MySQL configurando la variable --log-

slow-queries