UNIDAD 4: OPERACIÓN Y MANTENIMIENTO.

Identifica en los archivos log el funcionamiento de SGBD para prevenir cualquier problema del mismo.

4.1 Archivos log del SGBD

¿Qué es un log?

Los logs son archivos de texto normales. Como su nombre indica, estos ficheros registran todos los procesos que han sido definidos como relevantes por el programador de la aplicación. Por ejemplo, en el caso de los archivos log de una base de datos se registran todos los cambios de aquellas transacciones completadas exitosamente. Así, en caso de que un fallo del sistema elimine información de la base de datos, el log será la clave para la restauración completa de la base de datos correspondiente.

Dependiendo de su programación, los ficheros log se generan automáticamente. Sin embargo, si se cuenta con los conocimientos necesarios, también será posible crear archivos de registro propios. En general, la línea de un log contiene:

·         Evento recopilado (p. ej., inicio de programa)

·         Marca de tiempo, que le asigna fecha y hora

Por lo general, la marca de tiempo se genera primero, con el fin de reflejar la secuencia cronológica de los eventos.

Todas las bases de datos de SQL Server tienen un registro de transacciones que registra todas las transacciones y las modificaciones que cada transacción realiza en la base de datos. El registro de transacciones es un componente esencial de la base de datos. Si hay un error del sistema, ese registro será necesario para devolver la base de datos a un estado coherente. El registro de transacciones se debe truncar periódicamente para evitar que se llene.

El registro de transacciones permite las siguientes operaciones:

·         Recuperación de transacciones individuales.

·         Recuperación de todas las transacciones incompletas cuando se inicia
SQL Server.

·         Puesta al día de una base de datos, un archivo, un grupo de archivos o una página restaurados hasta el momento exacto del error.

·         Permitir replicación transaccional.

·         Compatibilidad con soluciones de alta disponibilidad y recuperación ante desastres: Grupos de disponibilidad AlwaysOn, creación de reflejo de la base de datos y trasvase de registros.

Cuando trabajas frente al ordenador, navegas en tu Tablet u operas una página web desde un servidor, tienen lugar numerosos procesos que pasan inadvertidos ante cualquier usuario. En caso de que se presenten problemas, se produzcan errores o quieras conocer exactamente qué acciones ejecutan los sistemas operativos o los diferentes programas o servicios, puedes acceder a los llamados archivos log, en español ficheros de registro. Estos “logs” son gestionados por prácticamente todas las aplicaciones, servidores, bases de datos y sistemas de manera automática y permiten controlar (de forma centralizada) todos los procesos relevantes.

En general, los ficheros log no suelen evaluarse frecuentemente, pues cumplen una función similar a la de un registrador de vuelo que es inspeccionado solo en caso de emergencia. Como consecuencia del registro detallado de datos de los logs, estos son una fuente primordial a la hora de analizar errores de programa o del sistema, así como para determinar el comportamiento de los usuarios. Esto no solo resulta interesante para los fabricantes de software, sino también para propietarios de páginas web, quienes pueden acceder a información interesante desde los archivos de registro del servidor web.

4.2 Definición de los modos de operación de un SGBD. (alta, baja, recovery) y comandos de Activación.

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
Copias de seguridad lógicas contienen datos lógicos, como tablas y procedimientos almacenados. Puede utilizar Oracle Data Pump para exportar los datos a archivos lógicos binarios, que posteriormente puede importar a la base de datos. Clientes de línea de comandos La bomba datos expdp y impdp utilizan el DBMS_DATAPUMP y DBMS_METADATA PL / SQL paquetes.
A menos que se especifique lo contrario, la copia de seguridad término tal como se utiliza en la copia de seguridad y la documentación de recuperación se refiere a una copia de seguridad física. Copia de seguridad de una base de datos es el acto de hacer una copia de seguridad física. El enfoque en la copia de seguridad y recuperación de documentación está casi exclusivamente en copias de seguridad físicas.

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.

Inevitablemente, cada cierto tiempo, habrá que crear un nuevo archivo secuencial con el mismo nombre, en el que los registros marcados no se grabarán.

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:

v  Planificación y probar las respuestas a diferentes tipos de fallas.

v  Configuración del entorno de base de datos de copia de seguridad y recuperación.

v  La creación de un programa de copia de seguridad

v  Seguimiento de la copia de seguridad y entorno de recuperación

v  Solución de problemas de copia de seguridad

v  Para recuperarse de la pérdida de datos en caso de necesidad

v  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:

v  La preservación de datos, lo que implica la creación de una copia de base de datos para el almacenamiento a largo plazo

v  La transferencia de datos, lo que implica el movimiento de datos de una base de datos o un host a otro.

De Protección de Datos

Como administrador de copia de seguridad, su trabajo principal es hacer copias de seguridad y vigilancia para la protección de datos. Una copia de seguridad es una copia de los datos de una base de datos que se puede utilizar para reconstruir los datos. Una copia de seguridad puede ser una copia de seguridad física o una copia de seguridad lógica.

Copias de seguridad físicas son copias de los archivos físicos utilizados en el almacenamiento y la recuperación de una base de datos. Estos archivos incluyen archivos de datos, archivos de control y los registros de rehacer archivados. En última instancia, cada copia de seguridad física es una copia de los archivos que almacenan información de base de datos a otra ubicación, ya sea en un disco o en medios de almacenamiento fuera de línea, tales como cinta.

Copias de seguridad físicas son la base de cualquier estrategia de recuperación de copia de seguridad sólida y. Copias de seguridad lógicas son un complemento útil de las copias de seguridad físicas en muchas circunstancias, pero no son suficiente protección contra la pérdida de datos y sin respaldos físicos.

 

4.3 Índices, reorganización y reconstrucción.

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.

 

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.

Esos trabajos son la Reorganización de Índices y la Actualización de Estadísticas.

Estos trabajos son independientes del estado de la base de datos. Puede ocurrir que a la base le falten estudios de optimización, pero, al menos, mantendremos la performance actual.

Si la base se encuentra optimizada, entonces más aún, son necesarios para evitar la degradación producto del uso continuo.

Cualquiera de estos trabajos debe realizarse fuera de línea por motivos de: alto consumo de recurso y bloqueo de las tablas en el momento de ejecución.

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

La instrucción DBCC DBREINDEX reorganiza el índice de una tabla o todos los índices definidos para una tabla.

La sintaxis de esta instrucción es:

DBCC DBREINDEX

   (   ’basededatos.dueño.nombre_de_tabla‘

           [ , índice

               [ , fillfactor ]

           ]

   )   [ WITH NO_INFOMSGS ]

 

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)

 

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;

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.

 

 

Referencia Bibliográficas:

UNIDAD 4 :: Administracion Bases de Datos. (2014). Webnode.mx. https://proyecto359.webnode.mx/unidad4/

‌