Ao longo de minha carreira como profissional de dados, tanto dentro da Microsoft quanto como consultor, descobri que uma das partes mais incompreendidas de um banco de dados SQL Server é o log de transações. A falta de conhecimento de como o log de transações funciona e precisa ser gerenciado, ou apenas simples equívocos, podem levar a todos os tipos de problemas de produção, incluindo:
- O log de transações ficando fora de controle e possivelmente ficando sem espaço
- Problemas de desempenho devido à redução repetida do log de transações
- Problemas de desempenho de um problema conhecido como fragmentação VLF , que discuti neste post
- A incapacidade de recuperar para um ponto no tempo desejado usando backups de log de transações
- A incapacidade de realizar um backup de log final durante a recuperação de desastres (consulte aqui para obter uma explicação sobre backups de log final)
- Vários problemas relacionados a failovers e restauração de desempenho
Com este post, estou iniciando uma série ocasional sobre o log de transações e como ele funciona e deve ser gerenciado, e abordarei todos os problemas acima ao longo do curso. Neste post, explicarei o que é o registro e por que ele é necessário.
Terminologia básica sobre registro
Quando estou falando sobre qualquer mecanismo no SQL Server, descubro que há um problema de galinha e ovo em que preciso usar uma palavra ou frase antes de explicar. Para evitar esse problema nesta série, vou começar explicando algumas terminologias que precisam ser usadas ao discutir o registro em log, e expandirei muitos desses termos à medida que a série avança.
Transação, confirmação e reversão
Uma transação engloba uma mudança ou um conjunto de mudanças em um banco de dados. Tem um início definido e um fim definido. O início é quando uma instrução BEGIN TRANSACTION é usada ou o SQL Server inicia automaticamente uma transação para você. O fim pode ser uma das quatro coisas:
- A transação é confirmada quando uma instrução COMMIT TRANSACTION é executada
- A transação é confirmada quando o SQL Server confirma automaticamente a transação no caso de uma transação de confirmação automática
- A transação termina de ser revertida depois que uma instrução ROLLBACK TRANSACTION é executada
- A transação é revertida após a ocorrência de um problema, e o SQL Server reverte automaticamente a transação
Quando uma transação é confirmada, as alterações feitas pela transação são finalizadas no banco de dados e são duráveis no log de transações do SQL Server em disco. Observe que eu disse “no log de transações”. As mudanças reais nas páginas do arquivo de dados na memória *não* são gravadas no disco quando a transação é confirmada. Eles não precisam ser duráveis nos arquivos de dados porque as alterações já são duráveis no log de transações. Eventualmente, as páginas do arquivo de dados serão gravadas no disco por uma operação de ponto de verificação.
Por outro lado, quando uma transação é revertida, as alterações de dados feitas pela transação não estão mais presentes no banco de dados. Ainda haverá algumas alterações físicas no banco de dados, pois reverter uma transação significa realizar mais alterações, mas você pode pensar em uma transação revertida como não tendo afetado os dados no banco de dados.
Pontos de verificação e operações de reversão são tópicos dignos de seus próprios posts, então vou explicá-los mais tarde na série.
Discuto esses três termos com muito mais profundidade no tutorial Introdução às transações do SQL Server no blog Sentinela.
Logging, registros de log e log de transações do SQL Server
Registrar significa simplesmente criar uma descrição durável de uma alteração em um banco de dados, quase sempre no contexto de uma transação. Quando uma alteração é feita, a alteração é descrita em um registro de log. Um registro de log geralmente contém informações suficientes para permitir que a alteração seja repetida no banco de dados ou revertida no banco de dados, se necessário.
Este registro de log estará inicialmente na memória e pode ser gravado no disco antes da confirmação da transação, mas definitivamente deve ser gravado no disco antes a transação pode terminar de confirmar, caso contrário a transação não seria durável. Uma exceção a esta regra é quando a durabilidade atrasada recurso está ativado, que Aaron Bertrand discute neste post.
Os registros de log são armazenados no log de transações (um ou mais arquivos de log em disco), que possui uma arquitetura interna um tanto complexa, e discutirei isso e muito mais sobre registros de log no próximo post da série.
Recuperação de falhas
Uma falha é quando o SQL Server é desligado inesperadamente e os vários bancos de dados alterados não podem ser desligados corretamente (certificando-se de que todas as páginas do arquivo de dados alterados sejam gravadas no disco e o banco de dados esteja marcado como desligado corretamente).
Quando o SQL Server é inicializado, ele verifica todos os bancos de dados para ver se algum não foi marcado como desligado corretamente. Se encontrar um, esse banco de dados deve passar pela recuperação de falhas. Isso garante o seguinte:
- Para qualquer transação que foi confirmada antes da falha, certifique-se de que todas as alterações na transação sejam refletidas no banco de dados (ou seja, repita a transação)
- Para qualquer transação que não foi confirmada antes da falha, certifique-se de que nenhuma das alterações na transação seja refletida no banco de dados (ou seja, reverta a transação)
Em outras palavras, a recuperação de falhas torna um banco de dados transacionalmente consistente a partir do momento em que ocorreu o acidente. A recuperação de falhas é usada:
- Quando o SQL Server é iniciado e encontra um banco de dados que precisa ser recuperado
- Durante um failover para uma cópia secundária de um banco de dados
- No final de uma sequência de restauração envolvendo backups (veja aqui)
A recuperação de falhas é um processo complexo e requer mais alguns posts na série antes que eu possa explicá-lo em profundidade.
Por que o registro é necessário?
O motivo mais básico para o registro em log é permitir que o banco de dados SQL Server torne as transações duráveis, para que possam ser recuperadas durante a recuperação de falhas ou revertidas, se necessário, durante as operações normais do banco de dados. Se não houvesse log, um banco de dados seria transacionalmente inconsistente e possivelmente estruturalmente corrompido após uma falha.
Sem log, porém, uma série de outros recursos no SQL Server não seria possível, incluindo:
- Backups de dados que podem ser recuperados de forma consistente
- Backups de log de transações do SQL Server que podem ser usados durante uma operação de restauração e para implementar o envio de log
- Replicação, que depende da capacidade de coletar transações do log de transações
- Change Data Capture, que usa o Log Reader Agent de replicação transacional para coletar as alterações do log de transações
- Espelhamento de banco de dados e grupos de disponibilidade, que dependem do envio de registros de log para cópias secundárias do banco de dados para reprodução
O SQL Server (e todos os servidores de banco de dados semelhantes) usa o que é chamado de registro de gravação antecipada . Isso significa que as descrições das alterações devem ser gravadas no disco antes das próprias alterações para garantir a capacidade de recuperar adequadamente um banco de dados. Se uma alteração fosse gravada em um arquivo de dados antes dos registros de log que a descrevem e o SQL Server travasse, não haveria como saber o que reverter e o banco de dados seria inconsistente. Essa ordenação é invariável, independentemente do nível de isolamento, tipo de transação ou se o recurso de durabilidade atrasada é usado. Registre primeiro os registros, depois as páginas de dados.
Apenas a ponta do iceberg
Como você pode ver neste post introdutório, uma grande quantidade vai para o log de transações e o log em um banco de dados SQL Server, e tudo o que fiz até agora foi definir alguma terminologia de alto nível e explicar por que o log é necessário. Espero que você se junte a mim enquanto eu me expando e me aprofundo à medida que a série avança!
