Documente Academic
Documente Profesional
Documente Cultură
SQL Server registra cada evento en una base de datos en mayor o menor grado.
alter database bbdd set recovery simple -- Pone el modelo de recuperación del log a simple
go
alter database bbdd set recovery full -- Pone el modelo de recuperación del log a completa.
go
Si cambias al modelo de recuperación simple, interrumpirá la cadena de copias de
seguridad de registros. Por lo tanto, es muy recomendable realizar una copia de seguridad
del registro inmediatamente antes de realizar el cambio. De esta manera, podrá recuperar
la base de datos hasta ese momento. Tras el cambio, necesitará realizar copias de seguridad
completas y periódicas para proteger sus datos y para truncar la parte inactiva del registro
de transacciones.
Si no se quieren sobrescribir los ficheros de backup. Muestro un ejemplo, de cómo crear los
backups, teniendo en cuenta el nombre de los ficheros, de esta forma mantendremos una
secuencia en los nombres:
Las copias de seguridad del log de transacciones son un aspecto fundamental de los
modelos de recuperación completa o bulk-logged. Las copias de seguridad de registros
permiten que se trunque el registro de transacciones. Si no realiza la copia de seguridad con
la frecuencia suficiente, el registro de transacciones se puede expandir hasta quedarse sin
espacio en disco. Muestro un ejemplo, de cómo crear los backups del log de transacciones,
teniendo en cuenta el nombre de los ficheros, de esta forma mantendremos una secuencia
en los nombres, por si fuera necesario restaurar, en un punto en el tiempo.
SQL Server ofrece muchos métodos que pueden ser implementados como medidas
preventivas para evitar la necesidad de usar el registro de transacciones SQL Server para
auditar una base de datos. Esto incluye a SQL Server Auditing (SQL 2008 +), los rastros y los
eventos extendidos, por mencionar algunos. La mayoría de estos con excepción del rastro
por defecto, requieren implementación previa a la ocurrencia de un evento.
De todos modos, el registro de transacciones SQL Server siempre está presente y como tal
puede ofrecer información valiosa después de que ocurrió un evento a pesar del hecho de
que no se hizo ninguna configuración avanzada.
En la ausencia de todas las medidas preventivas, poder leer el registro de Transacciones SQL
Server ofrece la habilidad de descubrir quién realizó una transacción específica después del
hecho, así como la habilidad de obtener los valores que han sido modificados con la opción
para retrotraerlos.
Recuperación:
Ya que cada acción es registrada en el registro de transacciones de tal modo que una
transacción puede arrastrarse o retrotraerse, el registro de transacciones SQL Server puede
ser usado para recuperar datos perdidos. Dado que sólo los cambios son registrados y los
datos en el registro no están almacenados en un formato legible para humanos, obtener
esta información del registro no es fácil, pero los datos están disponibles si usted sabe
dónde buscar y cómo leerlos. Más acerca de esto más adelante en este artículo en la sección
acerca de interpretar los datos en fn_dblog y fn_dump_dblog.
Cuando se trata de tener que restaurar una copia de seguridad, sabiendo el punto exacto
en el tiempo en que la base de datos puede ser restaurada para obtener los datos dañados
o perdidos es una enorme ventaja. En lugar de restaurar múltiples copias de seguridad hasta
que encuentre cuál tiene los datos relevantes intactos, usted puede leer el registro de
transacciones para determinar cuándo ocurrió el evento y restaurar al momento preciso
justo antes de que el evento ocurriera.
El registro de transacciones SQL Server es un archivo que usualmente tiene la extensión
.LDF. Aunque es posible tener múltiples archivos de registro para una base de datos, el
registro de transacciones es siempre escrito secuencialmente y múltiples archivos físicos de
registros son tratados como un archivo continuo circular.
SQL Server usa el registro de transacciones para asegurarse de que todas las transacciones
mantienen su estado en caso de una falla de la base de datos o el servidor. Todas las
transacciones son escritas en el Registro de Transacciones antes de ser escritas en los
archivos de datos. Esto es conocido como registro de escritura adelantada.