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.
- Automaticidade: se uma parte da transação falhar, toda a transação falha e a condição do banco de dados é mantido como inalterado.
- Consistência: qualquer transação leva o banco de dados de uma condição válida para outra.
- Isolamento: a execução de uma transação concorrente leva o banco de dados para uma condição como se a transação fosse executada em série, uma por uma.
- Durabilidade: uma vez executada, a transação permanece assim, mesmo em caso de erros, queda de energia ou conflitos.
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.
Usando ApexSQL Log como um leitor de arquivos LDF
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.
- Quando todos esses forem configurados, use o botão Open para iniciar o processo de leitura dos arquivos LDF
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.
Conclusão sobre o leitor de arquivo LDF
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:
- Exibir informações legíveis ligando e interpretando dados (converter dados hex e binários) de 129 colunas nativas.
- Cadeia de diferentes arquivos LDF juntos em um
- Combinar arquivos online e backup (ambos bancos de dados e arquivos LDF), a fim de fornecer mais detalhes sobre cada transação.
- Reconstruir completamente operações UPDATE, incluindo os campos de valores antigos (antes) e novos (depois).
- Exibir um histórico completo de linhas alteradas para operações DML, incluindo o login do usuário que realizou cada operação e o tempo de execução da transação.
- Pré-filtrar a informação que será lida a fim de salvar recursos e acelerar o processo.
- Mapear os IDs das tabelas antigas (desanexadas) permitindo a recuperação de dados de tabelas não mais existentes.
- Processar e mostrar o conteúdo de um arquivo LDF sem necessitar ter conhecimento em T-SQL.
Além da leitura, o ApexSQL Log também pode fornecer:
- Ordenar tabela, agrupar, filtrar e habilitar localização avançada para manipular os dados de maneiras diferentes.
- Além disso, para renderizar uma grade – o ApexSQL Log pode converter dados para CSV, HTML, XML ou SQL e ajudá-lo a gerenciar a exportação e salvar o conteúdo da grade para uma análise posterior.
- Criar scripts SQL para reverter ou replicar transações – este pode ser usual para um cenário de recuperação de banco de dados quando dados perdidos precisam ser restaurados ou um dado/esquema alterado precisa ser revertido sem utilizar a restauração completa do banco de dados.
- Documento Oficial para todas as funcionalidades
- Suporte técnico, e mais
Autor: Ivan Stankovic
Tradução: Ricardo Leka Roveri
September 2, 2015