Unidad 3 y 4

Unidad 3:Configuración y administración del espacio en disco 


Unidad 4: Operación y Mantenibilidad

4.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 (Sistema Manejador 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: Nombre de la transacción que realizó la operación de escritura.
-  Nombre del dato: El nombre único del dato escrito.
-  Valor antiguo: El valor del dato antes de la escritura.
-  Valor nuevo: El valor que tendrá el dato después de la escritura.
No se requiere hacer cambios en los sistemas de producción o de desarrollo o en una simple instalación para la implementación de la bitácora.  A través de la parametrización se generan las pantallas de consulta y reportes sin necesidad de programar.  Acceso a la bitácora a través de una aplicación Web. Control de Acceso a la información de la bitácora a través de Roles. Se puede implementar en los sistemas de información que utilicen las principales bases de datos: Oracle, SQL Server, Informix, Sybase. Permite hacer el seguimiento de todos los cambios que ha tenido un registro.

En la bitacora podemos encontrar distintos tipos de mensajes que se pueden clasificar en:

4.1.2 Recuperación (rollback)

                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.
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. Los ROLLBACK son específicos de la conexión. Esto significa que si se hicieron dos conexiones a la misma base de datos.
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.
 Este proceso de recuperación en algunos casos puede tardar mucho tiempo debido a la gran cantidad de información que tienen que replicar desde el log de transacciones. Es por eso que la frecuencia con la que se hacen los checkpoints dentro de la base de datos es crucial para el tiempo que tardara el servidor en ejecutar el proceso de recuperación.

4.1.3 Permanencia (commit)

                La gestión de datos, commit se refiere a la idea de consignar un conjunto de cambios "tentativos, o no permanentes".
Las transacciones suelen verse implementadas en sistemas de bases de datos
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.
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)
                La vida de todo archivo comienza cuando se crea y acaba cuando se borra. Durante su existencia es objeto de constante procesamiento, que con mucha frecuencia incluye acciones de consulta o búsqueda y de actualización. En el caso de la estructura archivos, entenderemos como actualización, además de las operaciones, vistas para vectores y listas enlazadas, de introducir nuevos datos (altas) o de eliminar alguno existente (bajas), la modificación de datos ya existentes, (operación muy común con datos almacenados). En esencia, es la puesta al día de los datos del archivo.

Una operación de alta en un archivo consiste en la adición de un nuevo registro. En un archivo de empleados, un alta consistirá en introducir los datos de un nuevo empleado. Para situar correctamente un alta, se deberá conocer la posición donde se desea almacenar el registro correspondiente: al principio, en el interior o al final de un archivo.

El algoritmo de ALTAS debe contemplar la comprobación de que el registro a dar de alta no existe previamente. Una baja es la acción de eliminar un registro de un archivo. La baja de un registro puede ser lógica o física. Una baja lógica supone el no borrado del registro en el archivo. Esta baja lógica se manifiesta en un determinado campo del registro con una bandera, indicador o “flag” -carácter *. $, etc.,-, o bien con la escritura o rellenado de espacios en blanco en el registro dado de baja.
Altas
La operación de dar de alta un determinado registro es similar a la de añadir datos a un archivo. Es importante remarcar que en un archivo secuencial sólo permite añadir datos al final del mismo.
En otro caso, si se quiere insertar un registro en medio de los ya presentes en el archivo, sería necesaria la creación nueva del archivo.
El algoritmo para dar de alta un registro al final del fichero es como sigue:
algoritmo altas
leer registro de alta
inicio
abrir archivo para añadir
mientras haya más registros hacer {algunos lenguajes ahorran este bucle}
leer datos del registro
fin_mientras
escribir (grabar) registro de alta en el archivo
cerrar archivo
fin

Bajas
Existen dos métodos para dar de baja a un registro en un archivo secuencial, donde no es fácil eliminar un registro situado en el interior de una secuencia: Para ello podemos seguir dos métodos:

1) Utilizar y por tanto crear un segundo archivo auxiliar transitorio, también secuencial, copia del que se trata de actualizar. Se lee el archivo completo registro a registro y en función de su lectura se decide si el registro se debe dar de baja o no. En caso afirmativo, se omite la escritura en el archivo auxiliar. Si el registro no se va a dar de baja, este registro se reescribe en el archivo auxiliar
Tras terminar la lectura del archivo original, se tendrán dos archivos: original (o maestro) y auxiliar.
El proceso de bajas del archivo concluye borrando el archivo original y cambiando el nombre del archivo auxiliar por el del inicial.

2) Guardar o señalar los registros que se desean dar de baja con un indicador o bandera que se guarda en un array; de esta forma los registros no son borrados físicamente, sino que son considerados como inexistentes.

4.3 Comandos de activación de los modos de operación

Para ser uso de los diferentes comandos para un modo de operación debemos estar como administrador o asuma un rol que incluya el perfil de derechos Service Management.
Comando STARTUP
Para el arranque de una base de datos hay tres fases de arranque, para realizar estas fases podemos utilizar startup más un comando, las tres fases son las siguientes:
-  Fase de no Montaje: se leen los parámetros del sistema, se inician las estructuras de memoria y los procesos de segundo plano. La instancia se arranca sin asociarla a la base de datos. Normalmente se utiliza cuando se modifica o se necesita crear el archivo de control:
startup nomount ;
-  Fase de Montaje: se asocia la instancia con la base de datos. Se usa el archivo de parámetros para localizar los archivos de control, que contienen el nombre de los archivos de datos y los registros rehacer. Los archivos de datos y los registros de rehacer no están abiertos, así que no son accesibles por usuarios finales para tareas normales. Para realizar esta fase se pueden utilizar dos comandos:
startup mount;
alter database mount;

-  Fase de Apertura: se abren los archivos de datos y los registros rehacer. La base de datos queda disponible para las operaciones normales. Es necesario que existan registros rehacer de lo contrario si no hay registros usamos el comando resetlogs, que crea registros nuevos. Para esta fase se pueden usar dos comandos:
startup open;
alter database open;
Si es necesario utilizar resetlogs:
startup open resetlogs;
alter database open resetlogs;
startup restrict (sólo permite la conexión de usuarios con el privilegio restricted sesion).
startup force (hace shutdown abort y arranca la BD).

Comando SHUTDOWN.- El comando SHUTDOWN lo utilizamos parar una base de datos la cual consiste en varias cláusulas.
-  Shutdown Normal: Este es el valor por defecto, durante el proceso de parada no admite nuevas conexiones y espera que las conexiones actuales finalicen. En el próximo arranque la base datos no requiere procedimientos de recuperación.
-  Shutdown Immediate: Se produce una parada inmediata de la base de datos, durante el proceso de parada no permite nuevas conexiones y las actuales la desconecta, las transacciones que no estén commit se hara roolback de ellas. En el próximo arranque la base datos no requiere procedimientos de recuperación.
-  Shutdown Transactional: Se produce una parada hasta que hayan terminado las transacciones activas, no admite nuevas conexiones y tampoco nuevas transacciones, una vez que las transacciones activas van terminando va desconectando a los usuarios. En el próximo arranque la base datos no requiere procedimientos de recuperación.
-  Shutdown Abort: Aborta todos los procesos de una base de datos, durante el proceso de parada no permite nuevas conexiones y las actuales la desconecta, las transacciones que no estén commit se hará roolback de ellas. En el próximo arranque la base datos puede requerir procedimientos de recuperación.
Comando Describe.- Este comando permite conocer la estructura de una tabla, las columnas que la forman y su tipo y restricciones.
DESCRIBE f1;
Comando SHOW TABLES y SHOW CREATE TABLE.- El comando SHOW TABLES muestra las tablas dentro de una base de datos y SHOW CREATE TABLES muestra la estructura de creación de la tabla.
Modificación.- Para realizar una modificación utilizamos el comando ALTER TABLE. Para usar ALTER TABLE, necesita permisos ALTER, INSERT y CREATE para la tabla.

4.4. Manejo de índices
El índice de una base de datos es una estructura alternativa 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. En pocas palabras, se mejoran las operaciones gracias a un aumento de la velocidad, permitiendo un rápido acceso a los registros de una tabla en una base de datos. Al aumentar drásticamente la velocidad de acceso, se suelen usar sobre aquellos campos sobre los cuáles se hacen búsquedas frecuentes.

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

Consideraciones para usar índices agrupados
-  Columnas selectivas
-  Columnas afectadas en consultas
-  Columnas accedidas "secuencialmente"
-  Columnas implicadas en JOIN, GROUP BY
-  Acceso muy rápido a filas: lookups

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


Consideraciones para usar índices agrupados


En Base de Datos Oracle ofrece varias combinaciones de indexación, que proporcionan una funcionalidad complementaria sobre el rendimiento. Los índices se pueden clasificar de la siguiente manera:
-  Los Índices de Árbol B
Estos índices son el tipo de índice estándar. Son excelentes para la clave principal y los índices altamente selectivos. Utilizado como índices concatenados, B-tree índice pueden recuperar los datos ordenados por las columnas de índice. Índices B-tree tienen los siguientes subtipos:
-  Índice de Tablas Organizadas
Una tabla de índice-organizada difiere de un montón-organizado porque los datos es en sí mismo el índice.
En este tipo de índice, los bytes de la clave de índice se invierten, por ejemplo, 103 se almacena como 301. La inversión de bytes extiende inserta en el índice durante muchos bloques.
-  Índices Descendentes
Este tipo de índice almacena los datos en una columna o columnas de concreto en orden descendente.
-  Índices B-Tree de Racimo
Este tipo de índice se utiliza para indexar una clave de clúster tabla. En lugar de apuntar a una fila, los puntos clave para el bloque que contiene filas relacionadas con la clave de clúster.

-  Mapa de Bits y los Índices Bitmap Join
En un índice de mapa de bits, una entrada de índice utiliza un mapa de bits para que apunte a varias filas. En cambio, los puntos de entrada de un índice B-tree en una sola fila. Un índice de combinación de mapa de bits es un índice de mapa de bits para la unión de dos o más tablas. Consulte "Indicadores de mapa de bits".

-  Índices Basados ​​en Funciones
Este tipo de índice incluye columnas que, o bien se transforman por una función, tales como la función UPPER, o incluidos en una expresión. Índices B-tree o mapa de bits puede ser basado en las funciones.

-  Índices de Dominio de Aplicación
Este tipo de índice se crea por un usuario para los datos en un dominio específico de la aplicación. El índice físico no tiene que utilizar una estructura de índice tradicional y se puede almacenar ya sea en la base de datos Oracle como tablas o externamente como un archivo. Consulte "Indicadores de dominio de aplicación".

- Índices B-Tree
Árboles B, abreviatura de árboles balanceados, son el tipo más común de índice de base de datos. Un índice B-tree es una lista ordenada de valores dividida en rangos. Mediante la asociación de una tecla con una fila o rango de filas, los árboles B proporcionan un excelente rendimiento de la recuperación para una amplia gama de consultas, incluyendo coincidencia exacta y búsquedas por rango.


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 de tipo 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
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 fil factor 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.

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.
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.
ALTER INDEX <index_name> REBUILD;
Para reconstruir una partición de un índice podríamos hacer el 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.