Recuperação de banco de dados acelerada no SQL Server 2019

Uma visão geral da recuperação tradicional

Assim como em todos os sistemas de banco de dados relacionais, o SQL Server garante a durabilidade dos dados ao implementar a recuperação de falhas. Durabilidade na sigla ACID que se refere às características das transações em bancos de dados relacionais significa que podemos ter certeza de que se o banco de dados falhar repentinamente, nossos dados estão seguros.

O SQL Server implementa esse recurso usando o log de transações. As alterações feitas por todas as operações de manipulação de dados no SQL Server são capturadas no log de transações antes de serem aplicadas aos arquivos de dados (por meio do processo de ponto de verificação) caso seja necessário reverter ou avançar.

O processo de recuperação de falhas em três fases no SQL Server é o seguinte:

• Análise – SQL Server lê o log de transações do ponto de verificação mais recente até o final do log de transações
  

• Refazer – O SQL Server reproduz o log da transação não confirmada mais antiga até o final do log
  

• Desfazer – O SQL Server lê o log do final do log até a transação não confirmada mais antiga e reverte todas as transações que estavam ativas durante a falha
  

DBAs experientes teriam, em algum momento ou outro de suas carreiras, a experiência desanimadora de esperar impotente pela conclusão da recuperação de falhas em um banco de dados muito grande. A transação ROLLBACK usa um mecanismo semelhante ao processo de recuperação de falhas. A Microsoft aprimorou significativamente o processo de recuperação no SQL Server 2019.

Recuperação de banco de dados acelerada

A Recuperação Acelerada de Banco de Dados é um novo recurso baseado em controle de versão que aumenta significativamente a taxa de recuperação no caso de um ROLLBACK ou recuperação de uma falha.

No SQL Server 2019, três novos mecanismos dentro do mecanismo do SQL Server modificam a maneira como a recuperação é tratada e reduzem efetivamente o tempo necessário para executar um rollback/rollforward.

• Armazenamento de versões persistentes (PVS) – Captura versões de linha dentro do banco de dados em questão. O Armazenamento de Versão Persistente pode ser definido em um grupo de arquivos separado por motivos de desempenho ou tamanho
  

• Reversão lógica – Usa as versões de linha armazenadas no PVS para executar a reversão quando uma reversão é chamada para uma transação específica ou quando a fase de desfazer da recuperação de falha é chamada.
  

• sLog – Isso possivelmente significa secundário registrar . É um fluxo de log na memória usado para capturar operações que não podem ser versionadas. Quando o ADR está habilitado no banco de dados, o sLog é sempre reconstruído durante a fase de análise de recuperação de falhas. Durante o refazer Nesta fase, o sLog é usado em vez do log de transações real, tornando o processo mais rápido, pois fica na memória e contém menos transações. O processo de recuperação tradicional lida com transações do último ponto de verificação. O sLog também é usado durante o desfazer fase.
  

• Limpador – Remove versões de linha desnecessárias do PVS. A Microsoft também fornece um procedimento armazenado para forçar manualmente uma limpeza de versões de linha desnecessárias.
  

-- LISTING 1: INVOKE THE BACKGROUND CLEANER

USE TSQLV4_ADR
GO
EXECUTE sys.sp_persistent_version_cleanup;

USE master
GO
EXECUTE master.sys.sp_persistent_version_cleanup 'TSQLV4_ADR';

A Recuperação Acelerada do Banco de Dados está DESATIVADA por padrão

O fato de o ADR estar desativado no SQL Server 2019 por padrão pode parecer surpreendente para alguns DBAs, já que parece ser um ótimo recurso. O ADR usa o controle de versão no banco de dados do usuário no qual está habilitado. Isso pode afetar significativamente o tamanho do banco de dados. Além disso, pode ser necessário planejar o crescimento do banco de dados, bem como a possível localização do PVS, para garantir um bom desempenho se o ADR estiver ativado. Portanto, faz sentido habilitar deliberadamente essa funcionalidade.

O experimento:fase preparatória

Montamos um experimento para explorar o novo recurso e ver o impacto do ADR no tamanho do log de transações, bem como na velocidade do ROLLBACK. Em nosso experimento, criamos dois bancos de dados idênticos usando um único conjunto de backup e, em seguida, habilitamos o ADR apenas em um desses bancos de dados. A Listagem 2 mostra as etapas preparatórias para a tarefa.

[expandir título =”Código”]

-- LISTING 2: PREPARE THE DATABASES AND CONFIGURE ADR

-- 2a. Backup a sample database and restore as two identical databases

BACKUP DATABASE TSQLV4 TO DISK='TSQLV4.BAK' WITH COMPRESSION;

-- Restore Database TSQLV4_NOADR (ADR will not be enabled)
RESTORE DATABASE TSQLV4_NOADR FROM DISK='TSQLV4.BAK' WITH 
MOVE 'TSQLV4' TO 'C:\MSSQL\DATA\TSQLV4_NOADR.MDF',
MOVE 'TSQLV4_log' TO 'E:\MSSQL\LOG\TSQLV4_NOADR_LOG.LDF';

-- Restore Database TSQLV4_ADR (ADR will be enabled)
RESTORE DATABASE TSQLV4_ADR FROM DISK='TSQLV4.BAK' WITH 
MOVE 'TSQLV4' TO 'C:\MSSQL\DATA\TSQLV4_ADR.MDF',
MOVE 'TSQLV4_log' TO 'E:\MSSQL\LOG\TSQLV4_ADR_LOG.LDF';

-- 2b. Enable ADR in TSQLV4_ADR
USE [master]
GO

-- First create a separate filegroup and add a file to the filegroup
ALTER DATABASE [TSQLV4_ADR] ADD FILEGROUP [ADR_FG];
ALTER DATABASE [TSQLV4_ADR] ADD FILE ( NAME = N'TSQLV4_ADR01', FILENAME = N'C:\MSSQL\Data\TSQLV4_ADR01.ndf' , 
SIZE = 8192KB , FILEGROWTH = 65536KB ) TO FILEGROUP [ADR_FG]
GO

-- Enable ADR
ALTER DATABASE TSQLV4_ADR SET ACCELERATED_DATABASE_RECOVERY = ON (PERSISTENT_VERSION_STORE_FILEGROUP = ADR_FG);
GO

-- 2c. Check if all ADR is enabled as planned
SELECT name
, compatibility_level
, snapshot_isolation_state_desc
, recovery_model_desc
, target_recovery_time_in_seconds
, is_accelerated_database_recovery_on FROM SYS.DATABASES
WHERE name LIKE 'TSQLV4_%';


-- 2d. Check sizes of all files in the databases
SELECT DB_NAME(database_id) AS database_name
, name AS file_name
, physical_name
, (size * 8)/1024 AS [size (MB)]
, type_desc
FROM SYS.master_files
WHERE DB_NAME(database_id) LIKE 'TSQLV4_%';


-- 2e. Check size of log used

CREATE TABLE ##LogSpaceUsage (database_name VARCHAR(50)
, database_id INT, total_log_size_in_bytes BIGINT
, used_log_space_in_bytes BIGINT
, used_log_space_in_percent BIGINT
, log_space_in_bytes_since_last_backup BIGINT)

INSERT INTO ##LogSpaceUsage
EXEC sp_MSforeachdb @command1='
IF ''?'' LIKE ("TSQLV4_%")
SELECT DB_NAME(database_id), * FROM ?.SYS.dm_db_log_space_usage;'

SELECT * FROM ##LogSpaceUsage;

DROP TABLE ##LogSpaceUsage;

O experimento:fase de execução

Depois de capturarmos os detalhes necessários para prosseguir, executamos o código SQL das Listagens 3 e 4 em etapas. As duas listagens são equivalentes, mas estamos executando-as em dois bancos de dados idênticos separadamente. Primeiro, fazemos um INSERT (Listagem 3, 3a), depois executamos um DELETE (Listagem 3, 3b) que posteriormente reverteremos. Observe que tanto no INSERT quanto no DELETE, encapsulamos as operações em transações. Além disso, observe que o INSERT é executado 50 vezes. Em cada estágio de execução, ou seja, entre 3a, 3b e 3c, capturamos o uso do log de transações com a ajuda do código da Listagem 2.2e. Isso é o mesmo para as seções 4a, 4b e 4c.

-- LISTING 3: EXECUTE DML IN TSQLV4_NOADR DATABASE

-- 3a. Execute INSERT Statement in TSQLV4_NOADR Database

USE TSQLV4_NOADR
GO

BEGIN TRAN
SET STATISTICS IO ON;
SET STATISTICS TIME ON;
SELECT * INTO [Sales].[OrderDetails_noadr] FROM [Sales].[OrderDetails];
GO
INSERT INTO [Sales].[OrderDetails_noadr] 
SELECT * FROM [Sales].[OrderDetails];
GO 50

COMMIT;

-- 3b. Execute DELETE in TSQLV4_NOADR Database

USE TSQLV4_NOADR
GO

BEGIN TRAN
SET STATISTICS IO ON;
SET STATISTICS TIME ON;
DELETE FROM [Sales].[OrderDetails_noadr]
GO

-- 3c. Perform Rollback and Capture Time
ROLLBACK;

Fig. 4 e 5 nos mostram que a operação SELECT INTO levou 6 milissegundos a mais no banco de dados TSQLV4_ADR onde habilitamos o Accelerated Database Recovery. Também vemos na Fig. 6 que temos maior uso de log de transações no banco de dados TSQLV4_ADR. Fiquei particularmente surpreso com isso, então repeti o experimento várias vezes para garantir que estava obtendo esse resultado de forma consistente.

Fig. 4 Inserir tempo de execução para TSQLV4_NOADR



Fig. 5 Inserir tempo de execução para TSQLV4_ADR



Fig. 6 Uso do log de transações após inserções

-- LISTING 4: EXECUTE DML IN TSQLV4_ADR DATABASE

-- 4a. Execute INSERT Statement in TSQLV4_ADR Database

USE TSQLV4_ADR
GO

BEGIN TRAN
SET STATISTICS IO ON;
SET STATISTICS TIME ON;
SELECT * INTO [Sales].[OrderDetails_adr] FROM [Sales].[OrderDetails];
GO
INSERT INTO [Sales].[OrderDetails_adr] 
SELECT * FROM [Sales].[OrderDetails];
GO 50

COMMIT;


-- 4b. Execute DELETE in TSQLV4_ADR Database

USE TSQLV4_ADR
GO

BEGIN TRAN
SET STATISTICS IO ON;
SET STATISTICS TIME ON;
DELETE FROM [Sales].[OrderDetails_adr]
GO

-- 4c. Perform Rollback and Capture Time
ROLLBACK;

Fig. 7 e 8 nos mostram que a operação DELETE levou muito mais tempo para ser concluída no banco de dados TSQLV4_ADR, onde havíamos ativado a Recuperação de banco de dados acelerada, embora o mesmo número de linhas tenha sido excluído em ambos os bancos de dados. Desta vez, porém, temos maior uso de log de transações no banco de dados TSQLV4_NOADR.

Fig. 7 Excluir tempo de execução para TSQLV4_NOADR



Fig. 8 Excluir tempo de execução para TSQLV4_ADR



Fig. 9 Uso do log de transações após exclusões

A essa altura, estava ficando óbvio que as operações DML demoram mais em bancos de dados com ADR ativado. Isso explica parcialmente por que o recurso está desativado em primeiro lugar. Pensando profundamente nisso, faz sentido, pois o SQL Server deve armazenar as versões de linha no PVS enquanto uma operação de inserção, atualização ou exclusão está em execução. Seja qual for a quantidade de tempo que o DML leva, descobrimos que a emissão de um ROLLBACK com o ADR ativado leva menos de 1 milissegundo (veja as Figs. 10 – 13). Em alguns casos, a reversão rápida pode compensar a sobrecarga do próprio DML, mas não em todos os casos!

Fig. 10 Tempo de execução para ROLLBACK (após DELETE) em TSQLV4_NOADR



Fig. 11 Tempo de execução para ROLLBACK (após DELETE) em TSQLV4_ADR



Fig. 12 Tempo de execução para ROLLBACK (após INSERT) em TSQLV4_NOADR



Fig. 13 Tempo de execução para ROLLBACK (após DELETE) em TSQLV4_ADR

Conclusão

A Recuperação Acelerada de Banco de Dados é um dos grandes recursos lançados no SQL Server 2019. No entanto, como em todas as coisas extremamente boas da vida, alguém precisa pagar por isso. O ADR pode ter um impacto negativo no desempenho em determinados cenários, por isso é importante avaliar seu cenário cuidadosamente antes de implementar o ADR em seu banco de dados de produção. A Microsoft recomenda especificamente a Recuperação de Banco de Dados Acelerada para bancos de dados que dão suporte a cargas de trabalho com transações de longa duração, crescimento excessivo do log de transações ou interrupções frequentes relacionadas a uma recuperação de longa duração.

Referências

1. Recuperação acelerada de banco de dados
   

2. Como funciona a recuperação acelerada de banco de dados?
   

3. Recuperação acelerada de banco de dados