Resguardo de la información

De Thubanpedia
Revisión a fecha de 07:16 16 oct 2014; Vivatia (Discusión | contribuciones)

(dif) ← Revisión anterior | Revisión actual (dif) | Revisión siguiente → (dif)
Saltar a: navegación, buscar


Resguardo de la Información

Thuban® posee diversos componentes que deben resguardarse periódicamente con fines de auditoría y recuperación en casos de eventuales desperfectos. La siguiente grilla muestra los componentes que deben ser resguardados para la posterior recuperación del Sistema:


Componentes a Resguardar Requ. Resguardo? Periodicidad Recomendada Recomendaciones
Base de Datos Si Diario Se recomienda un backup diario programado de forma automática y agendado en períodos de baja utilización del sistema.
FileSystem Si Diario Se recomienda un backup diario programado de forma automática y agendado en períodos de baja utilización del sistema.
Configuraciones del Sistema Si Diario Se recomienda un backup diario programado de forma automática y agendado en períodos de baja utilización del sistema.


Resguardo Base de Datos

El backup diario debe realizarse sobre todas las tablas de la base de datos de Thuban®. El proceso de resguardo puede ejecutarse de forma manual o planificarse para su ejecución automática. Se recomienda realizar un backup completo diariamente de la base de datos en distintos niveles de la siguiente manera:

- Realizar un backup diario que se resguarda durante 7 días. El backup que se genera el día lunes será sobreescrito al siguiente lunes.

- Realizar un backup semanal que se resguarda durante 4 semanas. El backup que se genera en el primer ciclo será sobreescrito en el quinto ciclo.

- Realizar un backup mensual que se resguarda durante 1 año. El backup que se genera será sobreescrito a los 12 meses.


Backup Manual

Antes de realizar un resguardo manual de la base de datos, se recomienda detener los servicios de ingreso masivo de documentación al sistema.

Para obtener información sobre como realizar un backup manual, refiérase a la documentación de su base de datos.


Backup Automático

Es posible configurar backups automáticos de base de datos, de forma tal que estos se ejecuten siguiendo una agenda determinada. Es importante asegurarse que estos resguardos se realicen durante períodos de baja utilización del sistema.

Para obtener información sobre como planificar un backup automático, refiérase a la documentación de su base de datos.


Resguardo del Filesystem

Debido a que el Filesystem de Thuban® maneja grandes volúmenes de información y su índice de crecimiento es alto, no se recomienda hacer un backup diario. El filesystem de Thuban® se encuentra organizado de la siguiente manera:

- Se genera una carpeta raíz del filesystem por cada clase documental.

- Dentro de cada carpeta, el sistema genera sub-carpetas (sub-filesystems) donde almacena los documentos hasta una determinada cantidad (paramterizable). Una vez alcanzada, el sistema genera una nueva sub-carpeta y así sucesivamente. De esta manera, se evita la sobrecarga del filesystem.

Para facilitar la tarea de resguardo de datos, Thuban® provee la posibilidad de congelar los sub-filesystems para evitar que sean modificados. Además, es posible configurar el sistema para que cada vez que se complete un sub-filesystem, el mismo pase a estado "congelado".

Así, es posible realizar un resguardo completo de los filesystems y evitar la redundancia en los backups.


Resguardo de Configuraciones del Sistema

Thuban® almacena todas las configuraciones del sistema dentro de la base de datos, por eso deben ser resguardadas cada vez que se realice el backup diario. Además, existen dos carpetas que contienen configuraciones de contexto y seguridad que pueden ser resguardadas:

- Contexto: Almacena las configuraciones de acceso a la base de datos, dominios LDAP y clientes SMTP.

- Seguridad: Almacena las contraseñas de acceso a la base de datos, dominios LDAP y clientes SMTP. Es posible configurar Thuban® para que el contenido de este archivo se encripte.

La ubicación de estas carpetas es configurable mediante variables de entorno del servidor de aplicaciones. Para conocer su ubicación, comuníquese con el administrador del sistema.


El contenido de esta sección presupone la utilización de una base de datos Microsoft SQL Server. Si bien los conceptos explicados aplican para todas las bases de datos relacionales, los comandos utilizados pueden variar para su utilización con otros motores de base de datos.


Reorganización y reconstrucción de índices

Un factor clave para conseguir una E/S de disco mínima para todas las consultas de bases de datos es asegurarse de que se creen y se mantengan buenos índices. Una vez creados los índices, se debe procurar mantenerlos para asegurarse que sigan trabajando en forma óptima. A medida que se agregan, modifican o borran datos se produce fragmentación. Esta fragmentación puede ser buena o mala para el rendimiento del sistema, dependiendo de las necesidades del trabajo de la base de datos.


Fragmentación de los índices

La fragmentación es consecuencia de los procesos de modificación de los datos (instrucciones INSERT, UPDATE y DELETE) efectuados en la tabla y en los índices definidos en la tabla. Como dichas modificaciones no suelen estar distribuidas de forma equilibrada entre las filas de la tabla y los índices, el llenado de cada página puede variar con el paso del tiempo. Para las consultas que recorren parcial o totalmente los índices de una tabla, este tipo de fragmentación puede producir lecturas de páginas adicionales. Esto impide el recorrido paralelo de los datos. Existen dos tipos de fragmentación:


Interna: Fragmentación dentro de páginas individuales de datos e índices con espacios libres que generan la necesidad de más operaciones de E/S y más memoria para su lectura. Este hecho disminuye el rendimiento en ambientes de lectura, pero en algunos casos puede beneficiar las inserciones, que no requieren una división de páginas con tanta frecuencia.


Externa: Cuando el orden lógico de las páginas no es correcto, porque las páginas no son contiguas. El acceso a los datos es mucho más lento por la necesidad de búsqueda de los datos.


La fragmentación de índices se puede reparar reorganizando un índice o reconstruyéndolo. Para los índices fraccionados que fueron construidos en una estructura partida se puede usar cualquiera de estos métodos o bien en un índice completo o bien en un único fragmento del índice.


Detección de fragmentación

El primer paso para decidir qué método de desfragmentación se va a utilizar consiste en analizar el índice para determinar el nivel de fragmentación. Si se usa la función del sistema sys.dm_db_index_physical_stats, se puede detectar la fragmentación en un índice, tabla o vista. La siguiente sentencia permite conocer el grado de fragmentación de los indices de la base de datos thuban-homologada.



<source lang="sql" > SELECT distinct a.index_id 'ID Indice', sys.tables.name 'Tabla', b.name 'Indice', avg_fragmentation_in_percent '% Fragmentación', fragment_count 'Cantidad de fragments', avg_fragment_size_in_pages 'Promedio de fragmentos por página' FROM

sys.dm_db_index_physical_stats ( DB_ID(N'thuban-homologada'),

OBJECT_ID(N'dbo.*'),

NULL,

NULL,

NULL) AS a JOIN sys.indexes AS b ON a.object_id = b.object_id AND a.index_id = b.index_id, sys.tables WHERE sys.tables.object_id= b.object_id ORDER BY

avg_fragmentation_in_percent desc </source>




La grilla de resultados emitida por la anterior sentencia incluye las siguientes columnas:



Columna Descripción
Id Índice El número de índice dentro de la tabla.
Tabla Nombre de la tabla a la que corresponde el índice.
Índice Nombre del índice.
 % Fragmentación El porcentaje de fragmentación lógica (páginas del índice fuera de orden).
Cantidad de fragmentos La cantidad de fragmentos (páginas físicas consecutivas) en el índice.
Promedio de páginas por fragmentos Promedio de número de páginas en un fragment del índice.


Una vez que se toma conciencia del nivel de fragmentación, se debe utilizar la tabla a continuación para determinar el mejor método para su corrección.



 % Fragmentación Sentencia correctiva
> 5% and < = 30% ALTER INDEX REORGANIZE
> 30% ALTER INDEX REBUILD WITH (ONLINE = ON)*


  • La reconstrucción del índice puede ejecutarse tanto en línea como fuera de línea. La reorganización de los índices debe ejecutarse siempre en línea. Para adquirir una disponibilidad similar a la de la opción de reorganización, los índices deben ser reconstruidos en línea.

Estos valores proveen una estricta guía para determinar el punto en el que se debe cambiar de ALTER INDEX REORGANIZE a ALTER INDEX REBUILD.

Los niveles muy bajos de fragmentación (menores que el 5 porciento) no deben ser corregidos por ninguno de estos comandos porque el beneficio de la remoción de una cantidad tan pequeña de fragmentación es casi siempre superado ampliamente por el costo de reorganización o reconstrucción de índices.


Reorganización de un índice

Para reorganizar uno o más índices se debe usar la sentencia ALTER INDEX con la cláusula REORGANIZE. Por ejemplo:

<source lang="sql"> Alter index PK_LOGS ON THUBAN_LOGS REORGANIZE </source>

El proceso de reorganización de indices se realiza siempre en línea y el consumo de recursos es bajo por lo que no mantiene bloqueos por mucho tiempo.


Reconstrucción de un índice

La reconstrucción de un índice lo descarta y genera uno nuevo. Esto provoca la eliminación de la fragmentación, el reclamo de lugar en el disco a través de la compactación de páginas por la configuración de fill factor y el reordenamiento de filas de índices en páginas continuas (asignación de nuevas páginas). Esto puede mejorar la ejecución del disco a través de la reducción del número de páginas requerido para obtener la información solicitada.

Los siguientes métodos pueden utilizarse para reconstruir índices agrupados y no agrupados:

  • ALTER INDEX con la cláusula REBUILD.
  • CREATE INDEX con la cláusula DROP_EXISTING.


Por ejemplo:

<source lang="sql"> Alter index PK_LOGS ON THUBAN_LOGS REBUILD </source>

Registro (log) de transacciones

Mantenimiento

Los registros de transacciones pueden presentar problemas porque muy a menudo son dejados de lado hasta que surge un problema. El registro crece a medida que las operaciones se efectúan en la base de datos. Mientras el registro crece, el espacio disponible en el disco disminuye. A menos que se realice una acción de rutina para prevenirlo, es probable que el registro de transacciones consuma todo el espacio disponible. Si el registro se configura de modo que crezca indefinidamente como por defecto, ocupará todo el espacio físico en disco en el que está almacenado.

Las copias de seguridad regulares de los registro de transacciones ayudan a prevenir el consumo del espacio en disco. Los procesos de respaldo (backup) truncan los viejos registros que ya no se necesitan para la recuperación. El proceso de truncamiento supone marcar viejos registros como inactivos de forma que puedan ser reescritos, lo que previene el crecimiento exagerado del registro de transacciones. Si los procesos de respaldo no se ejecutan frecuentemente, la base de datos debe ser configurada con la opción “modelo de restablecimiento simple”. Este modelo supone el truncamiento automático de los registros de transacción cada vez que se procesa un checkpoint.

El proceso de truncamiento que sucede como un resultado del backup o checkpoint, marcará los registros de logs viejos como inactivos. Esto permite la superposición de archivos pero no reduce el espacio en disco asignado al registro de transacción. Los registros mantienen el espacio asignado incluso si no es utilizado. Entonces, entra en escena la reducción (shrink). La acción de reducir el registro elimina los registros inactivos y reduce el tamaño físico del archivo de log.

El registro de log se reduce cuando una sentencia DBCC SHRINKDATABASE se ejecuta contra la base de datos, o una DBCC SHRINKFILE se ejecuta contra un registro de transacción específico, o una operación de auto-reducción se ejecuta en la base de datos. Cuando se reduce el log, primero se trunca para marcar los registros inactivos y luego removerlos. De acuerdo a cómo se busca reducir el registro, es posible visualizar (o no) resultados inmediatos. Idealmente, la reducción debe ser planificada para ser ejecutada en momentos donde la utilización de la base de datos es más baja.


Optimización del rendimiento

Los registros de transacciones juegan un papel fundamental en la base de datos. Como resultado, pueden tener un impacto directo en la totalidad del rendimiento del sistema. Hay ciertas configuraciones que pueden ser llevadas a cabo para optimizar el rendimiento de los registros de transacciones. Los registros de transacciones son escritos secuenciales en el disco físico, y no hay lecturas que ocurran como parte del proceso de logging. Por consiguiente, si los registros se aíslan en un disco separado, se optimizará el rendimiento puesto que nada interferirá con la escritura del registro.

Otra optimización refiere al crecimiento de los registros de transacciones. El registro puede ser configurado para crecer como un porcentaje del tamaño total o de acuerdo con un índice físico fijado. A pesar de la opción de crecimiento, el tamaño debe ser lo suficientemente amplio para prevenir la necesidad del registro de crecer continuamente. Si el índice de crecimiento está configurado como low, el registro puede estar obligado a expandirse continuamente, lo que lentificará las operaciones de la base de datos.