Shrink an ApsaraDB RDS for SQL Server transaction log - ApsaraDB RDS: Central de Documentação do Alibaba Cloud

Este tópico explica como reduzir o log de transação de uma instância do ApsaraDB RDS for SQL Server com espaço de log suficiente ou insuficiente.

Nota

Antes de executar operações de risco, como modificar uma instância ou dados, verifique se a instância tem recursos robustos de recuperação de desastres e tolerância a falhas para proteger seus dados.
Ao modificar as configurações ou os dados de uma instância, como uma instância ECS ou uma instância do ApsaraDB RDS, recomendamos criar um snapshot ou habilitar um recurso como backup de log para a instância do ApsaraDB RDS.
Caso você tenha concedido permissões ou enviado informações de segurança, como nomes de usuário e senhas, na plataforma Alibaba Cloud, recomendamos alterá-las imediatamente.

Espaço de log suficiente

Quando o espaço de log é suficiente, use o recurso Backup and shrink transaction logs disponível no console do ApsaraDB RDS. Ele executa automaticamente um backup do log e uma operação de redução, otimizando o tamanho do arquivo de log de transação.

Importante

Ao reduzir o log de transação, o sistema executa automaticamente um backup do log. Isso arquiva o log de transação, aumentando a probabilidade de uma limpeza bem-sucedida do log local.
Antes de reduzir o log de transação, verifique o status de espera de reutilização do log do banco de dados.
- Se o status for NOTHING, é possível reduzir o log. O tamanho reduzível depende do tamanho do arquivo de log virtual (VLF) reutilizável ao final do log de transação. Caso uma transação ativa impeça que o VLF ao final do log seja marcado como reutilizável, talvez seja necessário executar outro backup de log. Em seguida, aguarde a conclusão da transação ativa e verifique novamente o status de espera de reutilização até que ele seja NOTHING.
- Se o status for LOG_BACKUP, a operação de redução poderá falhar devido a uma transação ativa. Talvez seja necessário executar a operação de redução várias vezes até que ela seja concluída com êxito.
Acesse a página Database Management > View Details para visualizar o status de reutilização do arquivo de log (log_reuse_wait_desc).

Acesse a página Instances. Na barra de navegação superior, selecione a região onde a instância RDS reside. Em seguida, localize a instância RDS e clique em seu ID.
No painel de navegação à esquerda, clique em Backup and Restoration.
Clique em Backup and shrink transaction logs e, em seguida, clique em OK.
Após a conclusão da operação de redução, acesse a página Monitoring and alerts da instância para ver o uso mais recente do espaço de log.

Na aba Standard Monitoring, localize o gráfico Instance Space e verifique a métrica sqlserver.log_size para confirmar que o espaço de log foi reduzido.

Perguntas frequentes

P: O que fazer se o botão Backup and shrink transaction logs não responder?
R: Esse problema geralmente ocorre pelos seguintes motivos:
- O status de espera de reutilização do log não atende às condições de redução: Se o status de log_reuse_wait_desc do banco de dados não for NOTHING, os arquivos de log virtuais (VLFs) no arquivo de log não podem ser marcados como reutilizáveis, o que impede a operação de redução. Acesse a página Database Management > View Details para visualizar o status de reutilização do arquivo de log (log_reuse_wait_desc). Tente novamente após o status se tornar NOTHING.
- Uma transação ativa está impedindo a liberação do VLF ao final do log: Mesmo que o status de log_reuse_wait_desc seja NOTHING, a operação de redução não consegue liberar o espaço se uma transação ativa estiver usando o VLF ao final do log. Aguarde a conclusão da transação ativa, execute um backup de log novamente e clique em Backup and shrink transaction logs.

Espaço de log insuficiente

Quando o servidor de banco de dados reporta que o "log de transação está cheio", não é possível reduzir o log de transação pelo console — é necessário executar instruções SQL. A redução de um log de transação exige algum espaço de log. Com o log cheio, a única opção é quebrar a cadeia de log por meio de comandos.

Antes de começar

As operações a seguir são apenas para situações de emergência. Recomendamos primeiro expandir o espaço em disco.
Como regra geral, não recomendamos alterar o modelo de recuperação do banco de dados para SIMPLE. Essa ação quebra a cadeia de backup do ApsaraDB RDS e faz com que todas as tarefas subsequentes de restauração para um ponto no tempo falhem.
Em instâncias da edição High-availability (HA), desative o espelhamento do banco de dados antes de alterar o modelo de recuperação.

Aviso

Executar essas operações em uma emergência significa que você reconhece e aceita os riscos associados. Prossiga com cautela.

Procedimento

Basic edition instances

-- Set the database recovery model to SIMPLE to break the database log chain.
ALTER DATABASE [DatabaseName] SET RECOVERY SIMPLE;

High-availability (HA) edition instances

Para instâncias da edição High-availability (HA), o espelhamento de banco de dados está ativo, bloqueando operações ALTER DATABASE diretas. Siga as etapas abaixo:

-- Disable database mirroring first.
ALTER DATABASE [DatabaseName] SET PARTNER OFF;
GO
-- Set the database recovery model to SIMPLE to break the database log chain.
ALTER DATABASE [DatabaseName] SET RECOVERY SIMPLE;
-- Database mirroring is restored automatically. No manual setup is required.

Embora o sistema redefina imediatamente o modelo de recuperação para FULL sem alterá-lo permanentemente para SIMPLE, o comando ainda quebra a cadeia de log com êxito. O erro resultante não afeta esse resultado e pode ser ignorado.

Msg 50000, Level 16, State 1, Procedure ******, Line 46
Login User [Test11] can't change database [TestDb] recovery model.
Msg 3609, Level 16, State 2, Line 2
The transaction ended in the trigger. The batch has been aborted.

Solução de problemas

P: Após executar o comando ALTER DATABASE [TestDb] SET RECOVERY SIMPLE, uma mensagem de erro semelhante à seguinte é exibida. Como resolver?

Msg 1468, Level 16, State 2, Line 1
The operation cannot be performed on database "zhttestdb" because it is involved in a database mirroring session or an availability group. Some operations are not allowed on a database that is participating in a database mirroring session or in an availability group.
Msg 5069, Level 16, State 1, Line 1
ALTER DATABASE statement failed.

R: As instâncias da edição High-availability (HA) do ApsaraDB RDS for SQL Server utilizam espelhamento de banco de dados, que proíbe operações ALTER no modelo de recuperação. Siga o Procedimento para resolver o problema.

Referências

Para expandir o espaço de armazenamento, consulte Change Configuration.
Para gerenciar bancos de dados por meio de comandos SQL, consulte Gerenciar bancos de dados usando comandos SQL.
Para ver o uso de espaço e solucionar problemas relacionados ao espaço, consulte Solucionar problemas de espaço insuficiente no ApsaraDB RDS for SQL Server.
Para resolver problemas em que o espaço em disco do banco de dados está esgotado, consulte Resolver um problema de disco cheio no SQL Server.