Noções básicas do log de transações do SQL Server

O que é um registro de transações?

Existe um requisito em sistemas de banco de dados relacionais de que as transações devem ser duráveis. Este é “D” nas propriedades ACID das transações. O sistema deve garantir que, se ocorrer uma falha repentina, a transação possa ser repetida. O SQL Server atende a esse requisito capturando todas as transações em um arquivo físico chamado arquivo de log de transações .

Em essência, sempre que uma transação é confirmada, o SQL Server registra as alterações produzidas por essa transação em um log de transações. Mesmo que a transação não tenha persistido no arquivo de dados, ela está disponível no log de transações e pode ser repetida no caso de uma falha repentina.

Modelos de recuperação e registros de transações

O SQL Server opera em três modelos de recuperação – Full, Bulk Logged e Simple.

No modo de recuperação completa, TODAS as transações são registradas. Assim, o banco de dados pode ser totalmente recuperado se ocorrer uma falha. Isso também significa que o backup do banco de dados pode ser restaurado para um momento específico se a transação ou o backup relacionado estiver disponível. Nos modos Full e Bulk-Logged Recovery, os logs de transações são truncados sempre que um backup de log é executado.

No modo Simple Recovery, TODAS as transações ainda são registradas. No entanto, a operação do log de transações é truncada sempre que o banco de dados executa o ponto de verificação.

Um ponto de verificação acontece quando o SQL Server grava buffers sujos no arquivo de dados. Buffers sujos são páginas essenciais armazenadas na memória que foram alteradas por transações, como quando o estado na memória não corresponde ao estado no disco. No entanto, não vamos discutir isso aqui. No modo de Recuperação Simples, o SQL Server captura todas essas alterações no log de transações para mantê-las até que sejam persistidas.

A estrutura do log de transações

O log de transações é um arquivo físico visível na camada do SO do servidor onde o banco de dados do SQL Server está hospedado. Cada banco de dados possui um log de transações, mas é possível configurar mais. O problema é que ter vários logs SQL de transação não traz nenhuma vantagem de desempenho. O SQL Server grava no log de transações sequencialmente – um arquivo deve estar cheio antes que o próximo arquivo seja usado. No entanto, vários arquivos em discos separados podem salvar o dia se o primeiro arquivo ficar cheio.

Internamente, o arquivo de log de transações é uma série de arquivos de log virtuais. O tamanho e o número desses arquivos afetam o tempo necessário para fazer backup do banco de dados ou colocá-lo online. É sempre uma boa ideia dimensionar o log de transações corretamente e garantir que as configurações de crescimento automático se ajustem ao nível de atividade esperado. Então os crescimentos de arquivos não acontecerão com muita frequência.

O que faz o registro crescer?

Vamos começar criando um pequeno banco de dados usando o código da Listagem 1. O arquivo de dados tem 4 MB de tamanho, o arquivo de log tem 2 MB para começar. Seus bancos de dados de produção nunca seriam desse tamanho, especialmente com a prática popular de pré-alocação . Escolhemos esses tamanhos apenas para fins de demonstração.

-- Listing 1: Create a Small Database

create database tranlogexperiment
on primary 
( name = N'tranlogexperiment', filename = N'C:\MSSQL\Data\tranlogexperiment.mdf', size = 4MB , FILEGROWTH = 1024KB )
log on
( name = N'Test1_log', filename = N'E:\MSSQL\Log\Test1_log.ldf' , size = 2MB , FILEGROWTH = 1024KB );
go

Nesse banco de dados, criamos uma única tabela para as instruções adicionais da linguagem de manipulação de dados (DML) (Listagem 2).

-- Listing 2: Create a Table

use tranlogexperiment
go
create table txn_log (
ID int
, FName varchar(50)
, LName varchar(50)
, CountryCode char (2)
)

Ao executar o código na Listagem 3, verificamos e verificamos o que fizemos.

-- Listing 3: Check Recovery Model and File Sizes
select name, recovery_model_desc, log_reuse_wait_desc from sys.databases where name='tranlogexperiment';

select DB_NAME(database_id) [Database Name]
, type_desc [Database Name]
, name [Logical file Name]
, physical_name [Physical file Name]
, size*8/1024 [File Size (MB)]
, growth*8/1024 [File Growth (MB)]
from sys.master_files where database_id=DB_ID('tranlogexperiment');

Preste atenção ao Tamanho do arquivo coluna. Continuamos a invocar o crescimento do log de transações executando INSERTs e DELETEs 100.000 vezes (Listagem 4).

-- Listing 4: Create a Small Table
use tranlogexperiment
go
insert into txn_log values (1, 'Kenneth','Igiri', 'NG');
delete from txn_log where ID=1;
go 100000

A Listagem 4 insere uma única linha no txn_log table e exclui a mesma linha, repetindo essa ação 100.000 vezes.

No geral, a tabela não cresce devido a essa atividade, mas o log de transações cresce significativamente. Quando repetimos a consulta na Listagem 3 depois de executar a instrução DML da Listagem 4, vemos o quanto o log de transações cresceu:

O log de transações cresceu de 4 MB para 40 MB devido a essa atividade, embora o tamanho do arquivo de dados não tenha sido alterado. Isso nos mostra claramente que o tamanho do log de transações tem pouco a ver com o tamanho dos dados. O impacto no tamanho é da atividade (DML) que ocorre no banco de dados.

Como gerenciamos os registros de transações?

Os administradores de banco de dados que gerenciam instâncias locais do SQL Server de instalações IaaS devem fazer backup dos logs de transação regularmente. É útil ter as configurações de recuperação de desastres, como Log Shipping ou AlwaysOn AG . Tais configurações fazem os backups automaticamente.

No modo de recuperação completa, um backup de log do SQL Server truncará as partes do log de transações que não são mais necessárias para recuperação. O truncamento de log exclui arquivos de log virtuais inativos. Dessa forma, ele libera espaço nos logs de transações para reutilização.

O código na Listagem 6 mostra o tamanho do log de transações e quanto espaço livre temos nele.

-- Listing 6: Change Recovery Model
USE [tranlogexperiment]
GO
SELECT DB_NAME() AS [Database Name], 
    name AS [Logical File Name], 
    type_desc,
    size/128.0 AS [Current Size (MB)],  
    size/128.0 - CAST(FILEPROPERTY(name, 'SpaceUsed') AS INT)/128.0 AS [Free Space (MB)]
FROM sys.database_files
WHERE type IN (0,1);

Também podemos reduzir o log de transações físico usando o código da Listagem 7. Antes de reduzir, certifique-se de ter um backup do log de transações. Na produção, é melhor agendar os backups de log para evitar o crescimento descontrolado do arquivo de log físico e garantir que os dados sejam preservados. Com a opção de recuperação de desastres como Log Shipping ou AlwaysOn AG configurado, isso já é concedido.

Podemos consultar o log_reuse_wait_desc coluna em sys.databases exibição de catálogo para determinar quaisquer condições que impeçam que o log de transações seja reduzido. Observe que consultamos essa coluna na Listagem 3.

Essas condições podem ser um ponto de verificação pendente, um backup de log pendente, um backup ou restauração em andamento, uma transação ativa de longa duração e atividades semelhantes no banco de dados.

-- Listing 7: Change Recovery Model
USE [tranlogexperiment]
GO
DBCC SHRINKFILE (N'Test1_log' , 0, TRUNCATEONLY)
GO

Usamos o código na Listagem 8 para fazer backup do banco de dados. Em nosso caso específico, primeiro devemos fazer um backup completo porque os backups de log sempre fazem referência a um backup completo. O “último” backup completo inicia a cadeia ao lidar com a recuperação pontual.

-- Listing 8: Backup Transaction Log
backup database tranlogexperiment to disk='tranlogexperiment.bkp';
backup log tranlogexperiment to disk='tranlogexperiment_log.trn';

Ao executar um banco de dados no modo Simple Recovery, o log de transações é truncado em cada checkpoint . Nesse modo, os backups de log não são possíveis.

A localização do arquivo de log de transações deve ser dimensionada adequadamente para acomodar as transações de longa duração que ocorrem ocasionalmente. Caso contrário, o log de transações ainda poderá preencher o espaço em disco. A Figura 4 mostra o que acontece com o log internamente quando um backup é feito. Observe que o arquivo físico ainda tem 40 MB, mas agora temos cerca de 37 MB de espaço livre.

O que acontece no modo de recuperação simples?

Agora, vamos definir o translogexperiment banco de dados para o modo de recuperação simples.

-- Listing 9: Change Recovery Model
use master
go
alter database tranlogexperiment set recovery simple;

Quando executarmos o código apresentado anteriormente na Listagem 4, teremos um comportamento ligeiramente diferente.

A Figura 6 mostra o crescimento do log de transações no modo Simple Recovery quando executamos o código da Listagem 4. O tamanho do arquivo de log físico é de apenas 15 MB. É metade menos do que era no modelo de recuperação total anterior. Além disso, observe o espaço livre de 11,5 MB.

Isso significa que houve menos crescimento de log?

Não. A Figura 7 mostra que enquanto a sessão estava em execução, nosso SQL Server também executou vários pontos de verificação. Isso truncou o log e deu espaço para as transações retomarem o crescimento do log em intervalos.

Conclusão

O log de transações é um componente extremamente importante de um banco de dados SQL Server. Ele afeta tudo o que requer ou depende de recuperação – backups, restaurações, recuperação de desastres e assim por diante. Você também pode registrar a atividade do banco de dados.

Neste artigo, discutimos a natureza do log de transações, aspectos de como gerenciá-lo corretamente e demonstramos o comportamento do DML em bancos de dados com modos de recuperação completa ou simples em vigor. No entanto, há muito mais para aprender sobre o log de transações. As entradas nas referências seriam um bom ponto de partida para você.

Referência s

Registro de transações
Bancos de dados e armazenamento do SQL Server