Cada base de datos SQL Server está mapeada sobre un conjunto de archivos del sistema operativo. Estos archivos guardan datos e información de registro. Archivos individuales son usados sólo por una base de datos, y los datos y la información de registro nunca son mezclados en el mismo archivo. Mientras los datos son almacenados en un archivo MDF, todas las transacciones y las modificaciones a la base de datos SQL Server hechos por cada transacción son almacenadas en un archivo LDF – un archivo de registro de transacciones que es un componente esencial de la base de datos. Conceptualmente, el archivo de registro es una cadena de entradas de registro. Físicamente, las entradas de registro son almacenadas en uno o el conjunto de archivos LDF físicos que implementan el registro de transacciones.
El propósito primario de un archivo LDF es proveer el concepto ACID – Atomicity (Atomicidad), Consistency (Consistencia), Isolation (Aislamiento) y Durability (Durabilidad).
Un archivo LDF almacena suficiente información para reproducir o deshacer un cambio, o recuperar la base de datos a un punto de tiempo específico. Por lo tanto, debido a varios requerimientos de autoría o recuperación, frecuentemente hay una necesidad de abrir un archivo LDF y ver su contenido. Pero ver el contenido de un archivo LDF no es una tarea fácil.
Hay muchas funciones de SQL Server y comando (por ejemplo, fn_dblog, fn_dump_dblog y DBCC PAGE) que potencialmente proveen una manera de ver el contenido de un archivo LDF. De todas maneras, un conocimiento significativo de T-SQL es requerido para usarlas, algunas no están documentadas, y los resultados que proveen son difíciles de convertir a un formado humanamente legible. Los siguientes son ejemplos de cómo ver el contenido de un archivo LDF usando funciones de SQL Server y comandos:
Aquí está un ejemplo usando fn_dblog para leer un registro de transacciones en línea, con un resultado de 129 columnas (sólo 7 se muestran):
La función fn_dump_dblog es usada para leer el registro de transacciones nativo o copias de seguridad nativamente comprimidas. El resultado es similar:
Desafortunadamente, no hay documentación oficial disponible para las funciones fn_dblog y fn_dump_dblog. Para traducir las columnas, usted necesita familiarizarse con la estructura interna y el formato de datos, banderas y su número total en una fila de datos.
DBCC PAGE es usado para leer el contenido de archivos de la base de datos en línea – MDF y LDF. El resultado es una salida hexadecimal, la cual, a menos que tenga un editor hexadecimal, será difícil de interpretar.
ApexSQL Log es un lector de registros de transacciones de SQL Server que lee registros de transacciones en línea, registros de transacciones sueltos y copias de seguridad de registros de transacciones – tanto nativos y comprimidos nativamente. Como un visor LDF, está enfocado en operaciones (tanto DML como DDL, 45 en total), y lo que fue cambiado por la ejecución de estas operaciones.
Aparte de mostrar el contenido lógico de un archivo LDF, ApexSQL Log también provee algunas características adicionales como crear scripts Deshacer/Rehacer, un historial de filas para operaciones DML, y más.
Para abrir y ver un archivo LDF usando ApexSQL Log:
Conéctese a la base de datos a la cual pertenece el archivo LDF.
El siguiente paso es añadir cualquier copia de seguridad de archivos LDF y/o archivos LDF sueltos que contienen la información que necesita ver. Asegúrese que formen una cadena de registro completa. Una cadena de registro es una secuencia continua de copias de seguridad de registros de transacciones. Comienza con una copia de seguridad de base de datos completa seguida por todas las copias de seguridad de registros subsecuentes hasta el punto de auditoría. Si se rompe, sólo las transacciones en los registros hasta la última copia de seguridad antes de la perdida se pueden mostrar con información completa (por ejemplo, un esquema y nombre de objeto, o un historial de fila).
A diferencia de las operaciones INSERT y DELETE, las cuales son completamente registradas en los archivos LDF, las operaciones UPDATE son registradas mínimamente – sólo los cambios que son hechos son registrados, pero los valores antiguos y nuevos no. Cuando las operaciones UPDATE se están registrando, SQL Server no registra estados de filas de antes y después, sólo el cambio incremental que ocurrió a la fila. Por ejemplo, si una palabra “log” fuera actualizada a la palabra “blog” SQL Server, en un caso general, sólo registra una adición de letra “b” en el índice 0. Esto es suficiente para su propósito de asegurar ACID pero no es suficiente para entender qué cambio realmente ocurrió, ApexSQL Log tiene que reconstruir el contexto en el cual el cambio ocurrió desde el resto del registro de transacciones y/o copia de seguridad y datos de la base de datos en línea.
Para lograra esto despliega varias técnicas de reconstrucción de estados de fila complementarias, una de las cuales es reconstrucción usando una cadena completa de registro. Especificar la cadena de registro completa, junto con las más recientes copias de seguridad completas y diferenciales, permite a ApexSQL Log reconstruir el contexto de UPDATE comenzando por el estado de filas actualizado al tiempo de la última copia de seguridad y reconstruyendo todas las operaciones que afectaron desde entonces. En nuestro ejemplo, ApexSQL Log encontraría el estado de filas al tiempo de la última copia de seguridad, vería que el valor de los campos era “log” y desde ahí concluiría que el cambio registrado de adición de “b” en el índice 0 ha transformado el valor del campo a “blog”.
Por otra parte, una cadena de registros permite leer las transacciones más rápidamente usando varios archivos de copias de seguridad de registros de transacciones en lugar de un solo registro de transacciones en línea que puede ser muchas veces más grande que todas las copias de seguridad de registros de transacciones usados. Adicionalmente, un archivo LDF suelto puede ser usado como una fuente de lectura también – ApexSQL Log analizará todas las fuentes provistas para facilitar información precisa acerca de las transacciones grabadas en los archivos LDF.
Para hacer eso use el botón Add en el paso Select SQL logs to analyze.
Usar la pestaña Database backups provee la copia de seguridad completa de la base de datos que será usada como punto de inicio desde el cual la cadena de transacciones completa comienza.
Usando la sección Time range en el paso Filter setup, especifique el espacio de tiempo cuando las operaciones en las que está interesado fueron ejecutadas. Esto acelerará el proceso reduciendo las operaciones requeridas.
Como se describió, hay diferentes maneras de abrir un archivo LDF, y la mayor parte de ellas hacen sólo eso – abrir el archivo. Es difícil obtener alguna información legible para un humano y hacer uso de ella.
Por otro lado, además de simplemente abrir un archivo LDF, ApexSQL Log añade valor al proceso. Usted podrá leer registros de transacciones para ver el tipo de operación, el esquema y nombre del objeto afectado, el tiempo cuando la operación fue ejecutada, el nombre del usuario que ejecutó la operación, y más.
Las principales ventajas de procesar un archivo LDF con ApexSQL Log vs. sólo abrirlo son que puede:
Además de lectura, ApexSQL Log también proporciona:
