Todo banco de dados SQL Server é mapeado sobre um conjunto de arquivos do sistema operacional. Estes arquivos armazenam dados e log de informações. Arquivos individuais são usados somente por um banco de dados, e dados e log de informações nunca se misturam em um mesmo arquivo. Enquanto os dados são armazenados em um arquivo MDF, todas as transações e banco de dados do SQL Server modificados por cada transação são armazenados em um arquivo LDF –cada arquivo de transaction log é um componente essencial do banco de dados. Conceitualmente, o arquivo de log é uma string de logs gravados. Fisicamente, os logs gravados são armazenados em um ou vários conjuntos de arquivos LDF fisicos que implementam o transaction log.
O objetivo principal do arquivo LDF é proporcionar o conceito ACID – Automaticidade, Consistência, Isolamento e Durabilidade.
Um arquivo LDF armazena informações suficientes para replicar ou desfazer uma alteração ou recuperar o banco de dados a partir de um ponto específico. Portanto, devido à várias auditorias ou requisições de recuperação, há a necessidade de abrir frequentemente o arquivo LDF e visualizar seu conteúdo. Mas visualizar o conteúdo do arquivo LDF não é uma tarefa fácil.
Há diversas funções e comandos no SQL Server (exemplo: fn_dblog, fn_dump_dblog, e DBCC PAGE) que potencialmente fornece um modo de visualizar o conteúdo do arquivo LDF. Entretanto, é requisitado um conhecimento significativo em T-SQL para usá-lo, alguns não são documentadas e os resultados fornecidos são difíceis de se converter para um formato de leitura legível. Abaixo são alguns exemplos para visualizar o conteúdo do arquivo LDF usando as funções e comandos do SQL Server:
Aqui há um exemplo usando fn_dblog para ler um transaction log online, com 129 colunas de resultados (somente 7 são exibidos aqui)
A função fn_dump_dblog é usada para leitura do transaction log nativo ou backup ativamente comprimido. O resultado é similar à este:
Infelizmente, não está disponível um documento oficial para as funções fn_dblog e fn_dump_dblog. Para traduzir as colunas, você precisar estar familiarizado com a estrutura interna e o formato de dados, flags e seu número total em uma linha de dados.
DBCC PAGE é usado para ler o conteúdo dos arquivos online do banco de dados – MDF e LDF. O resultado é uma saída hexadecimal, que a menos que você tenha um editor hex, será difícil de interpretar.
ApexSQL Log é um leitor de transaction log que lê transaction logs online, transaction log desanexado e backup do transaction log – ambos nativos ou nativamente comprimidos. Como um visualizador LDF, ele é focado em operações (ambos DML e DLL, 45 no total) e que foi alterado por execução destas operações.
Fora exibir o conteúdo lógico de um arquivo LDF, o ApexSQL Log também possue algumas caracteríticas adicionais, como criar scripts Undo/Redo, um histórico de linhas para operações DML e mais.
Para abrir e visualizar um arquivo LDF usando o ApexSQL Log:
Conecte o banco de dados da qual o arquivo LDF pertence
O passo seguinte é adicionar qualquer backup de arquivo LDF e/ou arquivos desanexos LDF contendo informações que necessite visualizar. Tenha certeza que formem uma cadeia completa de log. Uma cadeia de log é uma sequência contínua de backups de transaction log. Este se inicia com um backup completo do banco de dados, seguido por um backup completo de log subsequente até o ponto da auditoria. Se iniciar quebrado, somente a transação em log até o ultimo backup antes da perda, pode ser exibido com a informação completa (exemplo: um esquema e um nome de objeto, ou uma linha histórica)
Diferente das operações INSERT e DELETE, na qual são totalmente registradas nos arquivos LDF, UPDATE são operações minimamentes registradas – somente as alterações feitas são registradas, mas valores antigos e novos não são. Quando executadas operações UPDATE, o SQL Server não registra por completo a condição de antes e depois das linhas, mas somente o incremental alterado que ocorreu nas linhas. Por exemplo, se a palavra “log” foi atualizada para a palavra “blog” o SQL Server o fará, em um modo geral, somente registra uma letra adicional “b” no índice 0. Isto é suficiente para o propósito de assegurar o ACID, mas não o suficiente para facilmente mostrar a condição de antes e depois da linha. Então, a fim de entender qual alteração realmente ocorreu, o ApexSQL Log reconstruiu o contexto na qual altera o ocorrido do resto do transaction log e/ou backup e banco de dados online.
Para isso, implantam-se técnicas de condições de linhas complementares mútuas, uma da qual é a reconstrução usando uma cadeia de log completa. Especificando a cadeia de log completa, todos juntos com o backup mais recente, completo e diferencial, permite ao ApexSQL Log a reconstrução do contexto UPDATE iniciando de um linha de condição atualizada até o momento para o último backup e reconstruindo todas as operações afetadas desde então. Em nosso exemplo, o ApexSQL Log localizaria a condição da linha até o momento do último backup, vendo os valores do campo que estava “log” e de lá concluir qual registro foi alterado adicionando o “b” no índice 0, para transformar o valor do campo para “blog”.
Além disso, a cadeia de log habilita a leitura das transações rapidamente usando somente alguns arquivos de backups de transactions log, ao invés de um simples transaction log online que pode ser muitas vezes maior que todos os backups de transaction log usados. Adicionalmente, o arquivo desanexado LDF pode ser usado como fonte de leitura também – ApexSQL Log analisará todas as fontes fornecidas a fim de fornecer informações precisas sobre as transações gravadas nos arquivos LDF.
Para fazer isso, use o botão Add no passo Select SQL logs to analyze.
Use a guia Database backups para fornecer o backup completo do banco de dados, na qual será usado como ponto de partida a partir da qual a cadeia completa de transações começa.
Use a seção Time range nas opções Filter setup, especifique o prazo de quando as operações de interesse foram executadas. Este irá acelerar o processo reduzindo as operações requisitadas.
Todos as transações, de acordo com as fontes fornecidas e filtros configurados, serão exibidos na grade principal do ApexSQL Log quando o processo for finalizado.
Como descrito, há diferentes modos para abrir o arquivo LDF, e muitos fazer somente isso – abrir os arquivos. É complicado obter qualquer leitor de informações legível e fazer uso dele.
Por outro lado, além de simplesmente abrir um arquivo LDF, o ApexSQL Log adiciona valores para o processo. Você poderá ler transaction log para ver o tipo de operação, o esquema e nome do objeto afetado, o tempo quando a operação foi executada, o nome do usuário que realizou a operação e mais.
As principais vantagens no processo de um arquivo LDF com o ApexSQL Log versus somente abri-lo, pode ser:
Além da leitura, o ApexSQL Log também pode fornecer:
Autor: Ivan Stankovic
Tradução: Ricardo Leka Roveri
© 2025 Quest Software Inc. ALL RIGHTS RESERVED. Terms of Use Privacy Cookie Preference Center