[SQLServer] Shrink do arquivo de LOG em alta disponibilidade AlwaysOn – AG

Fala pessoal, quanto tempo… Estamos de volta a todo vapor.

Decidi começar a postar uma nova série de “dicas rápidas”. A ideia é mostrar dicas que ajudam bastante no nosso dia a dia de DBA.

Atenção: Para essa dica, é necessário que você entenda os pré-requisitos básicos do AlwaysOn availability group (AG).

Cenário

1. Disco de Log sem espaço.
2. Arquivo de log muito grande e crescendo sem parar.

Em determinadas situações, necessitamos realizar um shrink de algum arquivo de log que está crescendo sem parar. Esse crescimento pode ser por inúmeros fatores como por exemplo:  Queries construídas de formas erradas, falta de uma rotina de backup de logs, etc. O fato é que as vezes, o recurso de disco já está limitado e o arquivo de log (.ldf) continua crescendo sem parar.

Para quem não sabe o que é um shrink, leia este artigo como apoio:

• https://www.sqlshack.com/sql-server-transaction-log-backup-truncate-and-shrink-operations/
• https://www.brunodba.com/2020/08/13/shrink-databases/

Obviamente que o correto é identificar a causa raiz e corrigir, lógico. Entretanto, em alguns cenários não temos mais tempo de fazer a análise porque o recurso de disco já está no limite, ou seja, estourando. Logo, precisamos tomar uma decisão rápida para que os serviços não parem.

Quando estamos nesse cenário, a primeira opção que vem de cara é realizar o shrink do arquivo de log.

Contudo, shrink para o arquivo de log dentro do AlwaysON AG, é um pouco chato de fazer por causa da arquitetura.

O AlwaysOn AG foi arquitetado para atender demandas extremamente críticas, com isso entende-se que  o ativo tem aplicações bastante sólidas, rotinas implementadas, etc. Na teoria, o availability group não foi planejado para eventuais shrinks. Entretanto, não é bem o que acontece na maioria das vezes.

No laboratório a seguir, vamos simular esse cenário.

Laboratório

No laboratório, vamos simular que um arquivo de Log está muito grande, consumindo muito disco, e precisamos realizar um shrink na alta disponibilidade.

Vamos aos passos:

A) Colocar o Recovery Model da base de dados que deseja fazer o shrink em “simple“.

Mudando Recovery Model para simple

B) O problema é que ao tentar colocar em simple, recebemos o seguinte erro dentro do AlwaysOn(AG)

C) Neste ponto, entramos justamente no cenário mencionado. O fato é que precisamos tirar a base da alta disponibilidade para realizar o shrink do arquivo de log.  Quando tiramos a base de dados da alta disponibilidade para fazer o shrink, significa que após o procedimento vamos ter que adicionar novamente na alta disponibilidade e isso dá um trabalho grande.

D) Pensando nesse cenário pensei em um Script que pudesse economizar meu tempo e esforço para esse tipo de situação.

E) Dica rápida: Rode o comando abaixo, trocando apenas o nome do banco de dados.

use [namedatabase] -- select database
BACKUP LOG [namedatabase] to disk = 'NUL:' with NO_CHECKSUM, CONTINUE_AFTER_ERROR 
declare @fileId as int = (select file_id from sys.database_files where type_desc = 'LOG') 
DBCC SHRINKFILE (@fileId, EMPTYFILE) -- action of shrink..

Prontinho, Shrink realizado em alta disponibilidade sem a necessidade de alterar o Recovery Model do banco de dados ou sincronizar tudo novamente.

Me siga para mais dicas rápidas!

Comente em caso de dúvidas.