Unidad 4: Operacin y mantenibilidad

4.1 Bitcoras de trabajo del DBMS.

En muchos DBMS la bitcora incluye todo tipo de consulta incluyendo aquellas que no modifican los datos. La operacin ROLLBACK est basada en el uso de una bitcora. El DBMS (Sistema Manejador de Bases de Datos) mantiene una bitcora o diario en cinta o en disco, comnmente, en el cual se registran los detalles de todas las operaciones de actualizacin, en particular, los valores iniciales y final del objeto modificado. Por tanto, si resulta necesario anular alguna modificacin especfica, el sistema puede utilizar la entrada correspondiente de la bitcora para restaurar el valor original del objeto restaurado.

4.1.1. Funciones especfica de las bitcoras.

La estructura ms ampliamente usada para grabar las modificaciones de la base de datos es la Bitcora. Cada registro de la bitcora escribe una nica escritura de base de datos y tiene lo siguiente: Nombre de la Transaccin Valor antiguo Valor Nuevo

Es fundamental que siempre se cree un registro en la bitcora cuando se realice una escritura antes de que se modifique la base de datos. Tambin tenemos la posibilidad de deshacer una modificacin que ya se ha escrito en la base de datos, esto se realizar usando el campo del valor antiguo de los registros de la bitcora. Los registros de la bitcora deben residir en memoria estable como resultado el volumen de datos en la bitcora puede ser exageradamente grande. Las operaciones COMMIT y ROLLBACK establecen lo que se le conoce como punto de sincronizacin lo cual representa el lmite entre dos transacciones consecutivas, o el final de una unidad lgica de trabajo, y por tanto al punto en el cual la base de datos esta (o debera estar) en un estado de consistencia. Las nicas operaciones que establecen un punto de sincronizacin son COMMIT, ROLLBACK y el inicio de un programa. Cuando se establece un punto de sincronizacin: Se comprometen o anulan todas las modificaciones realizadas por el programa desde el punto de sincronizacin 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 transaccin, no el programa.

4.1.2 Recuperacin (rollback)

En tecnologas de base de datos, un rollback es una operacin que devuelve a la base de datos a algn 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 despus de que se han realizado operaciones errneas. Son cruciales para la recuperacin de crashes de un servidor de base de datos; realizando rollback(devuelto) cualquier transaccin 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 gestin 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 tambin publicar cualquier savepoint existente que pudiera estar en uso. En muchos dialectos de SQL, ROLLBACKs son especficos de la conexin. Esto significa que si se hicieron dos conexiones a la misma base de datos, un ROLLBACK hecho sobre una conexin 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 tambin estar implementada mediante control de concurrencia multiversin. En el proceso de Rollback, SQL Server comienza a hacer un rollback de todas las transacciones que no fueron confirmadas adems 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 podra decidir que es necesario hacer fallar la transaccin, 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, ms recientemente, se han visto incorporadas a como gestiona un sistema operativo la interaccin con un sistema de archivos (como varias caractersticas de las bases de datos, debido a que son muy similares arquitectnicamente). Una sentencia COMMIT en SQL finaliza una transaccin 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 ms 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 recuperacin) existentes que puedan estar en uso. En trminos de transacciones, lo opuesto de commit para descartar los cambios "en tentativa" de una transaccin, es un rollback.

4.2 Definicin de los modos de operacin de un DBMS. (alta, baja, recovery)

El sistema de gestin de bases de datos es esencial para el adecuado funcionamiento y manipulacin 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 informticos 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 descripcin, manipulacin y utilizacin de los datos. Descripcin: Incluye la descripcin de: Los elementos de datos, su estructura, sus interrelaciones, sus validaciones. Tanto a nivel externo como lgico global e interno esta descripcin es realizada mediante un LDD o Lenguaje de Descripcin de Datos. Manipulacin: Permite: Buscar, Aadir, Suprimir y Modificar los datos contenidos en la Base de Datos. La manipulacin misma supone: Definir un criterio de seleccin, Definir la estructura lgica a recuperar, Acceder a la estructura fsica. Esta manipulacin es realizada mediante un LMD o Lenguaje de Manipulacin de Datos. Utilizacin: La utilizacin permite acceder a la base de datos, no a nivel de datos sino a la base como tal, para lo cual: Rene las interfaces de los usuarios y suministra procedimientos para el administrador. En trminos ideales, un DBMS debe contar con estas funciones, sin embargo, no todos las poseen, as existen algunos manejadores que no cumplen la funcin de respaldo o de seguridad, dejndola 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 organizacin de los datos en una tabla. El propsito de los ndices es acelerar el acceso a los datos mediante operaciones fsicas ms rpidas y efectivas. Para entender mejor la importancia de un ndice pongamos un ejemplo; imagnate que tienes delante las pginas amarillas, y deseas buscar el telfono de Manuel Salazar que vive en Alicante. Lo que hars ser buscar en ese pesado libro la poblacin

Alicante, y guindote por la cabecera de las pginas buscars los apellidos que empiezan por S de Salazar. De esa forma localizars ms rpido 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/pgina de datos de la imagen anterior). La clave del ndice agrupado es el elemento clave para esta ordenacin; el ndice agrupado se implementa como una estructura de rbol b que ayuda a que la recuperacin de las filas a partir de los valores de las claves del ndice agrupado sea ms rpida. Las pginas de cada nivel del ndice, incluidas las pginas de datos del nivel hoja, se vinculan en una lista con vnculos dobles. Adems, el desplazamiento de un nivel a otro se produce recorriendo los valores de claves Indices 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) estn los datos; en los ndices no- agrupados, en el nivel de hoja del ndice, hay un puntero a la localizacin fsica de la fila correspondiente en el ndice agrupado. Adems, la ordenacin 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 organizacin fsica de las pginas de datos corresponda con el ndice.

4.4.2 Reorganizacin 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 tambin incluye la opcin de compactar datos de objetos grandes. Los datos de objetos grandes son datos de tipo image, text, ntext, varchar(max), nvarchar(max), varbinary(max) o xml. La tarea Reorganizar ndice encapsula la instruccin ALTER INDEX de Transact-SQL. Si elige compactar datos de objetos grandes, la instruccin utiliza la clusula 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 Compactacin de las bases. Pero tambin es necesario ejecutar trabajos de mantenimiento cuyos objetivos sean el de mantener la performance de las bases de datos y evitar su degradacin. Esos trabajos son la Reorganizacin de ndices y la Actualizacin de Estadsticas. Estos trabajos son independientes del estado de la base de datos. Puede ocurrir que a la base le falten estudios de optimizacin pero, al menos, mantendremos la performance actual.

Si la base se encuentra optimizada, entonces ms an, son necesarios para evitar la degradacin producto del uso continuo. Cualquiera de estos trabajos deben realizarse fuera de lnea por motivos de: alto consumo de recurso y bloqueo de las tablas en el momento de ejecucin. Las tablas que contienen ndices al ser actualizadas o por insercin de nuevos datos, generan fragmentacin de estos ndices. Estas fragmentaciones conllevan a la prdida de performance al acceder a ellas. La instruccin DBCC DBREINDEX reorganiza el ndice de una tabla o todos los ndices definidos para una tabla. La reorganizacin de realiza dinmicamente 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 adems pertenece a algn ndice, ya que la reorganizacin no necesita eliminar y recrear stas restricciones para realizar su trabajo. La sintaxis de esta instruccin es: DBCC DBREINDEX ( basededatos.dueo.nombre_de_tabla [ , ndice [ , fillfactor ] ] ) [ WITH NO_INFOMSGS ] Fillfactor es el porcentaje de espacio de pgina destinado a ser ocupado. El valor definido reemplaza al que fue generado en el momento de la creacin 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 ejecucin. No es necesario conocer los nombres de todos los ndices de todas las tablas, ya que si utilizamos la instruccin de la siguiente forma: DBCC RBINDEX (Movimientos, , 0). Se reorganizarn todos los ndices que contengan la tabla Movimientos, conservndose 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 peridica mediante un trabajo de mantenimiento dentro de algn horario disponible. Por lo tanto, la recomendacin ser: elegir las tablas ms 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 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 Reconstruccin de ndices

Es importante peridicamente 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 contencin de disco o cuellos de botella en el sistema. Normalmente reconstruimos un ndice con el comando ALTER INDEX. Es importante tener actualizadas las estadsticas de la base de datos. Para saber si las estadsticas se estn 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 estadsticas. SELECT index_name, last_analyzed FROM dba_indexed WHERE table_owner=nb_usuario Nota: Siendo nb_usuario el nombre del esquema del usuario para el que queramos validar las estadsticas. (Lanzar con usuario SYS) Para actualizar las estadsticas utilizamos el paquete DBM_STATS. Podemos actualizar las estadsticas 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 estadsticas 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.
INDEX_NAME INX_CUENTA INX_TRABAJO INX_DINERO BLEVEL 1 0 OK OK BLEVEL OK BLEVEL BLEVEL HIGH

Los ndices que deberamos 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 nmero de veces que ORACLE ha tenido que reducir la bsqueda en ese ndice. Si este valor est por encima de 4 el ndice deber de ser reconstruido. Comando ALTER INDEX Como 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 deberas de tener el privilegio alter any index. Tambin tenemos que tener en cuenta que para realizar la reconstruccin de un ndice deberamos de tener cuota suficiente sobre el tablespace que lo lanzamos. Para reconstruir un ndice bastara con lazar la siguiente sentencia: ALTER INDEX <index_name> REBUILD; Para reconstruir una particin de un ndice podramos hacer lo siguiente ALTER INDEX <index_name> REBUILD PARTITION <nb_partition> NOLOGGING; Nota: En algunos casos cuando alguno de los ndices tiene algn tipo de corrupcin no es posible reconstruirlo. La solucin en este caso es borrar el ndice y recrearlo.

Unidad 5: Seguridad
5.1 Respaldo y Recuperacin
Recuperacin Un sistema de recuperacin consiste en restaurar la BD a un estado que se sepa correcto, tras cualquier fallo que la haya dejado en un estado incorrecto. Recuperacin de BD: devolver la BD a un estado consistente La recuperabilidad significa que, si se da algn 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 dao se causara. Las actividades de recuperacin incluyen el hacer respaldos de la base de datos y almacenar esos respaldos de manera que se minimice el riesgo de dao prdida de los mismos, tales como hacer diversas copias en medios de almacenamiento removibles y almacenarlos fuera del rea en antelacin a un desastre anticipado. La recuperacin es una de las tareas ms importantes de los DBAs. La recuperabilidad, frecuentemente denominada recuperacin de desastres, tiene dos formas primarias. La primera son los respaldos y despus las pruebas de recuperacin. La recuperacin de las bases de datos consiste en informacin y estampas de tiempo junto con bitcoras 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 bitcoras, la diferencia reside en que el DBA debe sacar de lnea la base de datos en caso de llevar a cabo una recuperacin. Respaldo Es la obtencin de una copia de los datos en otro medio magntico, 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 realizacin 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. Bsicamente 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 ingls data mirroring) al procedimiento de proteccin de datos y de acceso a los mismos en los equipos informticos implementado en la tecnologa de RAID1. Consiste en la idea bsica 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 imgenes exactas, etc. De esta forma se consigue tener 2 discos duros idnticos y que permiten, si todo est bien configurado, que ante el fallo del disco principal, el secundario tome el relevo, impidiendo la cada del sistema y la prdida de los datos almacenados.

5.1.1.1 Beneficios del espejeo de Datos en un DBMS.

Adems de proporcionar una copia adicional de los datos con el fin de redundancia en caso de fallo de hardware, la duplicacin de disco puede permitir que cada disco se acceda por separado para los propsitos de lectura. En determinadas circunstancias esto puede mejorar significativamente el rendimiento ya que el sistema puede elegir para cada lectura que disco puede buscar ms rpidamente 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 ms tiempo que la tarea en s) se puede reducir. Esta es una consideracin 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 fusin de los dos discos se puede requerir un perodo de sincronizacin en su caso escribir la actividad I/O ha ocurrido con el disco duplicado.

5.1.1.2 Activacin de espejeo en un DBMS.

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

Software Verifque que el MySQL instalado en el maestro y en el esclavo son iguales. En este casp MySQL Server 5.6 Configuracin 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 despus de la lnea [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 sern 2, 3 n segn sea el caso en binlog-do-db se pone el nombre de la base de datos que replicara despus 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 debern 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 BARBANEGRAbin.000004 y el desplazamiento es 1057. Guarde los valores. Los necesitar ms tarde cuando inicialice el servidor. Estos representan las coordenadas de la replicacin 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. Configuracin 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 despus 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 direccin 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 Creacin 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/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 slo 2 componentes activos, empleando para ello la primera particin de cada disco. Como le indicamos menos dispositivos de raid (2) que dispositivos fsicos, lo que hace es poner los otros dos como spares. La segunda orden nos crear un RAID5 con la tercera particin de todos los discos indicados. En este caso, el parmetro --raid-devices=4 es superfluo y se podra omitir, ya que si no decimos nada sobreentiende que queremos usar todos los discos.

5.1.2 Replica (replication).

La replicacin es un mecanismo utilizado para propagar y diseminar datos en un ambiente distribuido, con el objetivo de tener mejor performance y confiabilidad, mediante la reduccin de dependencia de un sistema de base de datos centralizado. Para garantizar que una aplicacin distribuida sea altamente disponible (es decir, que pueda proporcionar servicio de manera continua) se deben instanciar mltiples rplicas de sta en distintos ordenadores. Se debe conseguir que cada uno de los ordenadores que mantenga una rplica de la aplicacin sea independiente del resto ante la ocurrencia de fallos. El objetivo principal para la distribucin de datos es proveer un acceso sencillo a la informacin por parte de los usuarios de mltiples localidades o nodos de trabajo de una red de computadoras. Para alcanzar este objetivo, los sistemas de BDD deben proveer transparencia de ubicacin, que significa que el usuario no necesita conocer la localizacin fsica de cada dato dentro de la red. Idealmente, la informacin 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 replicacin de la informacin en una BDD apunta a aumentar la disponibilidad de la informacin. Esta disponibilidad puede observarse desde dos perspectivas: Aumentar el paralelismo en las consultas, dado que la misma informacin residir en ms de una localidad de la red. Mejorar la disponibilidad de los datos ante eventuales cadas de nodos de la red. El concepto de replicacin es muy amplio e involucra muchos aspectos que hacen al diseo de datos de la BDD. Los protocolos de aseguramiento de integridad de la informacin y los protocolos de actualizacin de las rplicas son los puntos ms interesantes para ser tenidos en cuenta.

5.1.2.1 Beneficios de la rplica de Datos en un DBMS

Disponibilidad: El modo en que la replicacin incrementa la disponibilidad de los datos para los usuarios y aplicaciones. Fiabilidad: Al haber mltiples copias de los datos disponibles en el sistema, se dispone un mecanismo excelente de recuperacin cuando existan fallos en nodos. Rendimiento: Se mejora para las transacciones de consulta cuando se introduce la replicacin en un sistema que estuviera aquejado de sobrecarga de recursos centralizados. Reduccin de la carga: Modo en que se utiliza la replicacin para distribuir datos en ubicaciones remotas. Procesamiento Desconectado: Modo en que la replicacin puede implementarse mediante mecanismos instantneas. Soporta muchos usuarios: se puede crear mltiples instantneas 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 Mtodos de respaldo de un DBMS

En mySQL existen varios mtodos para la realizacin 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 prctica se utiliz el tipo de tabla InnoDB y el mtodo de backup utilizado es el que funciona con este tipo de tablas. InnoDB es una de las tecnologas de almacenamiento que utiliza mySQL, es de cdigo abierto. Entre sus caractersticas principales estn que soporta transacciones con caractersticas 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 caractersticas ms importantes pues una base de datos sin integridad referencial, es nada ms un conjunto de datos que no denotan informacin. Este tipo de almacenamiento tambin 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 compresin de datos, por lo que ocupa un poco ms de espacio que myISAM..

5.1.3.1 Elementos y frecuencia de respaldo

5.1.3.2 Comandos para respaldo de datos

Respaldo y Restauracin 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"contrasea" nombre-de-la-base-de-datos > nombredel-respaldo.sql NOTA: Las comillas deben omitirse tanto en el usuario como en la contrasea. Para restaurar un respaldo de una base de datos MySQL usamos el siguiente comando Comando: mysql -u "usuario" -p"contrasea" nombre-de-la-base-de-datos < nombre-delrespaldo.sql NOTA: Al igual que en el ejemplo anterior las comillas deben omitirse tanto en el usuario como en la contrasea. Respaldo y Restauracin 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 opcin "-h" con la cual especificaremos el nombre o direccin del host en donde se encuentra nuestra base. Para Respaldar usamos: Comando: mysqldump -u "usuario" -p"contrasea" -h"nombre-o-direccin-del-host" nombre-de-la-base-de-datos > nombre-del-respaldo.sql Para restaurar usamos: Comando: mysql -u "usuario" -p"contrasea" -h"nombre-o-direccin-del-host" nombre-dela-base-de-datos < nombre-del-respaldo.sql

5.1.3.3 Mtodos de recuperacin de un DBMS

Copias de seguridad de la base de datos Para poder efectuar cualquier tipo de restauracin de una base de datos, es necesaria la realizacin de copias de seguridad (Backus) de la base de datos de forma peridica. Este proceso consiste en la escritura de una copia exacta de la base de datos en un dispositivo magntico separado del que contiene a la propia base de datos. En los sistemas ms grandes, este dispositivo suele ser una cinta magntica. En los sistemas basados en microordenadores, puede tratarse de un cartucho de cinta de casete, o de uno o ms discos flexibles. Habitualmente, mientras se est generando una copia de seguridad es preciso detener todas las dems actividades de la base de datos. Un mtodo sencillo de recuperacin El mtodo ms simple de recuperacin de una base de datos es el expuesto a continuacin. Peridicamente, quiz una vez cada da, 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 fsica, o diario (log), de todos los cambios subsiguientes que se efectan en la base de datos. Si la base de datos es daada o destruida, para recuperarla es preciso seguir la secuencia de pasos siguiente: Reparar el problema de hardware o software que caus la cada del sistema. Restaurar la base de datos a partir de la copia de seguridadmsreciente. Esto no restaura la base de datos a su estado en el instante en el que tuvo lugar el dao. Volver a introducir manualmente en la base de datos los cambiosrealizadosdesde que se hizo la copia, usando la lista fsica.

Diarios de transacciones y restauracin/reejecucin 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 transaccin. Para cada transaccin de la base de datos, el diario contiene marcas de comienzo de transaccin y final de transaccin, adems de una grabacin de los cambios individuales realizados en la base de datos para dicha transaccin. La marca de final de transaccin se graba en el diario slo despus de la conclusin con xito de la transaccin. As, si una cada del sistema interrumpe el procesamiento de una transaccin, no aparecer ninguna marca de final de transaccin en el diario. Cuando se realice un proceso de restauracin/reejecucin, slo se restaurarn 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 tcnica de restauracin/reejecucin 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 tcnicas de restauracin.

Recuperacin por retroceso La recuperacin 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 daada de forma alguna. Un ejemplo de esto podra ser algn tipo de fallo que produzca una terminacin anormal de la ejecucin del SGBD. Las transacciones en marcha podran ser abortadas antes de su finalizacin, y los registros asociados a las mismas quedaran en estados desconocidos, aunque el resto de la base de datos no se vera afectada. La tcnica de recuperacin por retroceso requiere que el diario de transacciones contenga imgenes 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 transaccin, es decir, justo antes del inicio de dicha transaccin. Para que la recuperacin por retroceso pueda funcionar, el diario de transacciones debe contener marcas de comienzo de transaccin y de final de transaccin para cada transaccin. Cuando se realiza un proceso de recuperacin, las transacciones incompletas se detectan por la ausencia de una marca de final de transaccin. Recuperacin por adelanto El adelanto es otro tipo de mecanismo de recuperacin, que se usa a menudo cuando una base de datos ha sido daada y debe, por tanto, ser restaurada a partir de una copia de seguridad. Se parece a la tcnica del retroceso, y comparte con sta la ventaja de que es mucho ms rpida que el mtodo de restauracin/reejecucin. 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 despus de haber sido modificado como parte de una transaccin, es decir, en el estado en que se encuentra al finalizar dicha transaccin. En su forma ms simple, esta tcnica consta de dos etapas: Despus de un fallo que produce un dao 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 transaccin completada anotada en el diario, se sustituye la versin actual del registro de la base de datos por la imagen final correspondiente.

Esta tcnica es considerablemente ms rpida que la de restauracin/reejecucin, ya que la sustitucin de un registro por su imagen final lleva mucho menos tiempo que el proceso de recreacin de la base de datos completa a partir de la copia de seguridad.

5.1.4 Comandos para recuperacin

Servicios de Respaldo y Recuperacin para Bases de Datos (BD) Es de suma importancia tener algn sistema de respaldo/recuperacin 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 modificacin, es decir: - INSERT - UPDATE - DELETE Cambiamos su estado, llevndolo a uno nuevo. No se considera SELECT, pues no provoca cambios. Recordemos que es una operacin de seleccin. Al momento de realizar un respaldo, se guarda el estado en que se encuentra la BD al momento de realizar dicha operacin de respaldo. Al momento de realizar la operacin de recuperacin, puede ser de varias formas, ya sea a travs de las operaciones (en orden) que han dejado la BD en el estado actual u otras formas. La gran mayora de Motores de BD cuentan con funciones de este tipo: SQL Dump pg_dump Esta funcin 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 vaca, es decir, en el mismo estado inicial. Su sintaxis es: pg_dump dbname > archivo_salida Y se usa desde la linea de comandos. Para realizar la restauracin se utiliza: psql dbname < archivo_entrada Donde archivo_entrada corresponde al archivo_salida de la instruccin pg_dump.

5.1.4.1 Aplicacin de cada mtodo

Recuperacin Fsica La utilizacin de una copia de backup de ficheros de datos siempre necesita de una recuperacin fsica. Tambin es as cuando un fichero de datos se pone offline sin un checkpoint. Existen tres opciones para realizar una recuperacion fsica. La primera es una recuperacin de BD donde se restaura la BD entera. La segunda es una recuperacin de tablespace donde, mientras una parte de la BD est abierta, se puede recuperar un tablespace determinado. Esto significa que sern recuperados todos los ficheros de datos asociados al

tablespace. El tercer tipo es la recuperacin de un fichero de datos especfico mientras el resto de la BD est abierta. Requisitos para Utilizar Recuperacin Fsica La primera condicin que se ha de poner para poder recuperar fsicamente una BD es que sta se est utilizando en modo ARCHIVELOG. De otro modo, una recuperacin 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 debera 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 contendran 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. Recuperacin de la BD La BD debe estar montada pero no abierta. El comando de recuperacin 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 recuperacin se haga automticamente sin preguntar al DBA por el nombre de los ficheros redo log. Tambin se puede utilizar para este cometido el comando set autorecovery on/off. Los ficheros redo log deben estar en la localizacin 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 estn los ficheros redo log, si es distinto del fijado en LOG_ARCHIVE_DEST. UNTIL sirve para indicar que se desea realizar una recuperacin 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 recuperacin 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 recuperacin: 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 recuperacin.

Recuperacin de un tablespace La BD debe estar abierta, pero con el tablespace a recuperar offline. El comando de recuperacin es el siguiente: RECOVER [AUTOMATIC] [FROM 'localizacion'] TABLESPACE nombre_tablespace [, nombre_tablespace] Recuperacin 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 recuperacin es el siguiente: RECOVER [AUTOMATIC] [FROM 'localizacion'] DATAFILE nombre_fichero [, nombre_fichero] Creando un Fichero de Control Si el fichero de control ha resultado daado y se ha perdido se puede utilizar una copia de seguridad del mismo o crear uno nuevo. El comando de creacin de un nuevo fichero de control es CREATE CONTROLFILE. Este comando se puede ejecutar slo con la BD en estado nomount. La ejecucin del comando produce un nuevo fichero de control y el montaje automtico 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.trc Oracle7 Server Release 7.3.2.3.0 - Production Release With the distributed, replication and Spatial Data options PL/SQL Release 2.3.2.3.0 - Production ORACLE_HOME = /opt/app/oracle/product/7.3.2 System name: SunOS Node name: cartan Release: 5.5 Version: Generic Machine: sun4m Instance name: demo

Redo thread mounted by this instance: 1 Oracle process number: 7 Unix process pid: 515, image: oracledemo Fri May 15 11:41:19 1998 Fri 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 NOMOUNT CREATE CONTROLFILE REUSE DATABASE "DEMO" NOARCHIVELOG MAXLOGFILES 16 MAXLOGMEMBERS 2 MAXDATAFILES 30 MAXINSTANCES 1 MAXLOGHISTORY 100 LOGFILE 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 2M DATAFILE '/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; Recuperacin Lgica 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 exportacin y ejecuta las sentencias que almacenan creando las tablas y llenndolas de datos. Parmetros del Import

NORESETLOGS

Parmetro USERID BUFFER FILE SHOW IGNORE GRANTS INDEXES ROWS FULL FROMUSER TOUSER TABLES RECORDLENGTH INCTYPE COMMIT PARFILE

Defecto indefinido dependiente del SO expdat.dmp No Yes Yes Yes Yes No Indefinido Indefinido indefinido dependiente del SO indefinido No indefinido

Descripcin el username/password del usuario que efectua el import. El tamao en bytes del buffer utilizado. el nombre del fichero de exportacin a importar. indica si se muestran los contenidos del fichero de exportacin, sin importar ningn dato. indica si ignorar los errores producidos al importar un objeto que ya existe en la BD. indica si se importan tambin los derechos. indica si se importan tambin los ndices. indica si se importan tambin las filas de las tablas. indica si se importan el fichero entero. una lista de los usuarios cuyos objetos se han exportado. una lista de los usuarios a cuyo nombre se importan los objetos. la lista de tablas a importar. la longitud en bytes del registro del fichero. el tipo de import incremental (SYSTEM o RESTORE). indica si se efectua un commit despus de importar cada fila. Por defecto, import efectua un commit despus de cargar cada tabla. el fichero de parmetros.

Para importar un export incremental se puede efectuar la siguiente secuencia de pasos: 1. 2. 3. 4. 5. 6. Utilizar la copia ms reciente del import para restaurar las definiciones del sistema: $ imp userid=sys/passwd inctype=system full=Y file=export_filename Poner los segmentos de rollback online. Importar el fichero de exportacin completa ms reciente: $ imp userid=sys/passwd inctype=restore full=Y file=filename Importar los ficheros de exportacin en modo acumulacin desde la exportacin completa ms reciente, en orden cronolgico: 7. $ imp userid=sys/passwd inctype=restore full=Y file=filename

8. Importar los ficheros de exportacin en modo incremental desde la exportacin completa o acumulativa ms reciente, en orden cronolgico: 9. $ imp userid=sys/passwd inctype=restore full=Y file=filename

5.2 Migracin de la base de datos

Migracin de datos Hablamos de migracin de datos cuando nos referimos al traspaso de informacin entre bases de datos. Si tenemos una aplicacin 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 ms seguro es que nos decantemos por Oracle, DB2, Informix, SQLServer o similares. En este caso, los datos, que estarn en formato "access" debern pasar a formato "sqlserver" o formato para "oracle". La migracin de los datos consiste en convertir los datos desde un sistema de base de datos a otro. Esta migracin conlleva la creacin de tablas o modificacin de las existentes, cambios en algunos tipos de datos que existen en una base de datos pero no en otras, etc. Tcnicas de Migracin de Datos Planeacin Lo ms importante al migrar una Base de Datos es llevar a cabo un proceso de planeacin y anlisis del trabajo, puesto que aunque pareciera tomarse algn tiempo adicional, ste ser retribuido en el xito de la operacin y menos costos por errores de datos. Es importante que esto sea aplicado cuando la Base de Datos destino est en produccin. Contador de registros Si la migracin se realiza de forma manual, mediante alguna consulta de insercin 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 Monitoreo 5.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 mtodo consume demasiado tiempo para los administradores de bases de datos. Un mtodo mejor sera automatizar la ejecucin de este comando peridicamente para revisar la cantidad de espacio libre. Algunas tareas de DBA donde la informacin de espacio libre puede ser til: - La primera que se alerte al DBA cuando el espacio libre cae por debajo de un umbral especfico en cualquier unidad de SQL Server. - La segunda sera la de realizar un seguimiento de la historia el espacio libre para la gestin 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

informacin 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 continuacin, por cada unidad se recupera la informacin 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 cdigo que hace precisamente eso. declare @MB_Free int create table #FreeSpace( Drive char(1), MB_Free int) insert into #FreeSpace exec xp_fixeddrives select @MB_Free = MB_Free from #FreeSpace where Drive = 'C' -- Free Space on C drive Less than Threshold if @MB_Free < 1024 exec master.dbo.xp_sendmail @recipients ='greg.larsen@netzero.net', @subject ='SERVER X - Fresh Space Issue on C Drive', @message = 'Free space on C Drive has dropped below 1 gig'

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 aplicacin, que podra resultar en un mal diseo 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 ms 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 continuacin. Contador Log Flushed/sec Log Flushes/sec Nmero de vaciados del log de transacciones Descripcin Bytes Nmero total de bytes del log de transacciones vaciados

Log Flush Waits/sec Nmero 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) Tamao total del log de transacciones de la base de datos Log Cache Hit Ratio Lecturas realizadas a travs 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 podra presentarse mucha actividades en el log de transacciones y saturarlo son:

Cargar informacin 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 transaccin. 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 aplicacin y no solo por el echo de asignar ms 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 compartida

PGA DE ORACLE (REA GLOBAL DE PROGRAMA) Un PGA es una regin de memoria que contiene datos e informacin 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 tambin 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 parmetros de inicializacin de base de datos para definir el tamao de la instancia de la PGA, no PGA individuales. El PGA puede ser crtico para el rendimiento, especialmente si la aplicacin est haciendo un gran nmero de clases. Operaciones de ordenacin 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 Orculo "instancia" (un ejemplo es los programas de bases de datos y la memoria RAM). Sirve para facilitar la transferencia de informacin entre usuarios y tambin almacena la informacin estructural de la BD ms frecuentemente requerida. En los sistemas de bases de datos desarrollados por la Corporacin 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 informacin necesaria para la operacin de la instancia. La SGA se divide en varias partes: Buffers de BD, Database Buffer Cache Es el cach que almacena los bloques de datos leidos de los segmentos de datos de la BD, tales como tablas, ndices y clusters. Los bloques modificados se llamas bloques sucios. El tamao de buffer cach se fija por el parmetro DB_BLOCK_BUFFERS del fichero init.ora. Plan de ejecucin 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 tamao del buffer suele ser pequeo para almacenar todos los bloques de datos leidos, su gestin se hace mediante el algoritmo LRU. 2. Buffer Redo Log Los registros Redo describen los cmbios realizados en la BD y son escritos en los ficheros redo log para que puedan ser utilizados en las operaciones de recuperacin 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 peridicamente los registros redo log en los ficheros redo log. El tamao del buffer redo log se fija por el parmetro LOG_BUFFER. 3. rea de SQL Compartido, Shared SQL Pool En esta zona se encuentran las sentencias SQL que han sido analizadas. El analisis sintctico 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 programacin 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: Tambin se almacena en la zona de SQL compartido el cach del diccionario. La informacin sobre los objetos de la BD se encuentra almacenada en las tablas del diccionario. Cuando esta informacin se necesita, se leen las tablas del diccionario y su informacin se guarda en el cach del diccionario de la SGA. Este cach tambin se administra mediante el algoritmo LRU. El tamao del cach est gestionado internamente por el servidor, pero es parte del shared pool, cuyo manao viene determinado por el parmetro SHARED_POOL_SIZE.

5.3.1.5 Monitoreo de Base de Datos

Qu es la Auditora de BD? Es el proceso que permite medir, asegurar, demostrar, monitorear y registrar los accesos a la informacin almacenada en las bases de datos incluyendo la capacidad de determinar: Quin accede a los datos. Cundo se accedi a los datos. Desde qu tipo de dispositivo/aplicacin. Desde que ubicacin en la Red. Cul fue la sentencia SQL ejecutada. Cul 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 organizacin frente a las regulaciones y su entorno de negocios o actividad.

Objetivos Generales de la Auditora de BD Disponer de mecanismos que permitan tener trazas de auditora completas y automticas 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 auditora del entorno de bases de datos radica en que es el punto de partida para poder realizar la auditora de las aplicaciones que utiliza esta tecnologa. La Auditora de BD es importante porque: Toda la informacin financiera de la organizacin reside en bases de datos y deben existir controles relacionados con el acceso a las mismas. Se debe poder demostrar la integridad de la informacin almacenada en las bases de datos. Las organizaciones deben mitigar los riesgos asociados a la prdida de datos y a la fuga de informacin. La informacin confidencial de los clientes, son responsabilidad de las organizaciones. Los datos convertidos en informacin a travs de bases de datos y procesos de negocios representan el negocio. Las organizaciones deben tomar medidas mucho ms all de asegurar sus datos. Deben monitorearse perfectamente a fin de conocer quin o qu les hizo exactamente qu, cundo y cmo. Mediante la auditora de bases de datos se evaluar: Definicin de estructuras fsicas y lgicas de las bases de datos. Control de carga y mantenimiento de las bases de datos. Integridad de los datos y proteccin de accesos. Estndares para anlisis y programacin en el uso de bases de datos. Procedimientos de respaldo y de recuperacin de datos. Aspectos Claves No se debe comprometer el desempeo de las bases de datos Soportar diferentes esquemas de auditora. Se debe tomar en cuenta el tamao de las bases de datos a auditar y los posibles SLA establecidos. Segregacin de funciones

 El sistema de auditora de base de datos no puede ser administrado por los DBA del rea de IT. Proveer valor a la operacin del negocio Informacin para auditora y seguridad. Informacin para apoyar la toma de decisiones de la organizacin. Informacin para mejorar el desempeo de la organizacin. Auditora completa y extensiva Cubrir gran cantidad de manejadores de bases de datos. Estandarizar los reportes y reglas de auditora.

5.3.1.7 Monitoreo de espacios espejeados.

La optimizacin en MySQL pasa por tres componentes, a saber:

Optimizacin del servidor MySQL Optimizacin de la base de datos Optimizacin de las consultas

Optimizacin de la configuracin del servidor MySQL La optimizacin del servidor puede incluir una multitud de enfoques y mtodos, lo que intentaremos presentar en lo que sigue es una introduccin a los enfoques de base, a saber:

Compilacin del servidor Afinamiento de los parmetros del servidor Afinamiento de otros parmetros

Optimizacin de la base de datos Generalmente para la optimizacin de las bases de datos lo recomendado es hacer uso de las buenas prcticas y las metodologas de concepcin 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 metodologa correcta - Utilizar ndices - Utilizar OPTIMIZE TABLE Para hacer una buena optimizacin, es necesario proceder con una metodologa emprica a saber hacer las modificaciones una por una y probar cada vez la reaccin del sistema para ver el resultado. Una medida del rendimiento antes y despus de haber efectuado la optimizacin permite ver si el sistema ha sido optimizado o no. Optimizacin de las consultas MySQL permite analizar las consultas y conocer el tiempo y plan de ejecucin. Esta

informacin permite comprender lo que hace que las consultas sean lentas y optimizar la ejecucin de stas. Detectar las consultas lentas Para detectar las consultas lentas es posible:
observar las consultas lentas durante su ejecucin y los tiempos de respuesta anormales. hacer un benchmark: testear las aplicaciones para ver qu componentes son los ms lentos. verificar el Slow query log: es posible activar esta opcin en MySQL configurando la variable --logslow-queries