4.1 Bitacoras 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íficas 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)
Rollback señala el término no exitoso de la transacción. Le dice al manejador de transacciones que algo salió mal, que la base de datos podría estar en un estado inconsistente y que todas las modificaciones deben retroceder o anularse.
Si una transacción falla, por alguna razón, después de la actualización de la base de datos es necesario “anularla” (rollback o UNDO). Cualquier valor del data ítem que haya sido cambiado por la transacción debe volver a su valor previo
Si una transacción T es anulada (rollback), cualquier transacción S, que es en ínterin, haya leído un valor de un data ítem X modificado por T, entonces S también debe anularse (rollback)
De igual forma, si una transacción R ha leído un valor de un data ítem Y que ha sido modificado por S, entonces R también se debe anular y así sucesivamente.
Este fenómeno se conoce como rollback en cascada. El rollback en cascada puede ser muy costoso y es por ello que los mecanismos de recovery han catalogado a este fenómeno como indeseable o nunca requerido
Uso de rollback
4.1.3 Permanencia (commit)
Commit(acción de comprometer) se refiere a la idea de guardar un conjunto de cambios “tentativos , o no permanentes”. Un uso popular es al final de una transacción de base de datos.
Una sentencia COMMIT en SQL finaliza una transacción de base de datos dentro de un sistema gestor de base de datos relacional y pone visibles todos los cambios a otros usuarios. El formato general es emitir una sentencia BEGIN WORK, una o mas sentencias SQL, y entonces la sentencia COMMIT. Alternativamente, una sentencia ROLLBACK se puede emitir, la cual deshace todo el trabajo realizado desde que se emitio BEGIN WORK. Una sentencia COMMIT publicara cualquiera de los savepoints existentes que puedan estar en uso.
En términos de transacciones, lo opuesto de commit para descartar 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)
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.
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.
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.
Propósito de Backup y Recuperación
Como administrador de copia de seguridad, la tarea principal es diseñar, implementar y gestionar una estrategia de backup y recuperación. En general, el propósito de una estrategia de recuperación de copia de seguridad y es para proteger la base de datos contra la pérdida de datos y reconstruir la base de datos después de la pérdida de datos. Normalmente, las tareas de administración de seguridad son las siguientes:
· Planificación y probar las respuestas a diferentes tipos de fallas.
· Configuración del entorno de base de datos de copia de seguridad y recuperación.
· La creación de un programa de copia de seguridad
· Seguimiento de la copia de seguridad y entorno de recuperación
· Solución de problemas de copia de seguridad
· Para recuperarse de la pérdida de datos en caso de necesidad
Como administrador de copia de seguridad, es posible que se le pida que realice otros deberes que se relacionan con copia de seguridad y recuperación:
· La preservación de datos, lo que implica la creación de una copia de base de datos para el almacenamiento a largo plazo
· La transferencia de datos, lo que implica el movimiento de datos de una base de datos o un host a otro.
Algunas de las situaciones en las que se recomienda tener este respaldo de datos pueden ser alguna de las siguientes:
· De protección de datos
· Fallas de medios
· Errores de los usuarios
· Errores de la aplicación
· Transferencia de datos
4.3 Comandos de Activación para 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: startup nomount
· Fase de montaje: start mount, alter database mount.
· Fase de aperture: startup open.
Comando shutdown
El comando shutdown lo utilizamos para parar una base de datos la cual consiste en varias clausulas
· Shutdown normal
· Shutdown immediate
· Shutdown transactional
· Shutdown abort.
Comando describe
Este comando permite conocer la estructura de una tabla, columnas que la forman y su tipo y restricciones.
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 una tabla.
Comandos de modificación
Para realizar una modificación utilizamos el comando ALTER TABLE. Para usar ALTER TABLE, necesitamos 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.
4.4.1 Tipos de índices
Existen diferentes tipos de índices algunos de ellos son:
● Índices agrupados: Son los que definen el orden en que almacenan las filas de la tabla (nodos hoja/página de datos de la imagen anterior).
● Índices no agrupados: tienen la misma estructura de árbol b que los índices agrupados, con algunos matices.
● Índices compuestos: es un índice de varias columnas de una tabla.
● Índices descendientes: Este tipo de índice almacena los datos en una columna o columnas de concreto en orden descendente.
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.
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
● La Actualización de Estadísticas.
La instrucción DBCC DBREINDEX reorganiza el índice de una tabla o todos los índices definidos para una tabla. La sintaxis de esta instrucción es:
DBCC DBREINDEX (’basededatos.dueño.nombre_de_tabla‘[, índice [, fillfactor] ]) [ WITH NO_INFOMSGS ]
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_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 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 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 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 REBUILD;
Para reconstruir una partición de un Índice podríamos hacer lo siguiente
ALTER INDEX REBUILD PARTITION NOLOGGING;
