DBCC SHRINKDATABASE (Transact-SQL)

Aplica-se a:SQL ServerBanco de Dados SQL do AzureInstância Gerenciada de SQL do AzureAzure Synapse AnalyticsBanco de Dados SQL no Microsoft Fabric

Reduz o tamanho dos arquivos de dados e de log do banco de dados especificado.

Não considere as operações de redução de tamanho como uma operação de manutenção regular. Os arquivos de dados e de log que crescem devido a operações comerciais regulares e recorrentes não exigem operações de redução.

Convenções de sintaxe de Transact-SQL

Sintaxe

Sintaxe para SQL Server:

DBCC SHRINKDATABASE
( database_name | database_id | 0
     [ , target_percent ]
     [ , { NOTRUNCATE | TRUNCATEONLY } ]
)
[ WITH
    {
         [ WAIT_AT_LOW_PRIORITY
            [ (
                  <wait_at_low_priority_option_list>
             ) ]
         ]
         [ , NO_INFOMSGS ]
    }
]

<wait_at_low_priority_option_list> ::=
    <wait_at_low_priority_option>
    | <wait_at_low_priority_option_list>
      , <wait_at_low_priority_option>

<wait_at_low_priority_option> ::=
  ABORT_AFTER_WAIT = { SELF | BLOCKERS }

Sintaxe para Azure Synapse Analytics:

DBCC SHRINKDATABASE
( database_name
     [ , target_percent ]
)
[ WITH NO_INFOMSGS ]

Argumentos

{ database_name | database_id | 0 }

O nome ou ID do banco de dados deve diminuir. Um valor 0 especifica o banco de dados atual.

target_percent

A porcentagem de espaço livre para deixar no arquivo do banco de dados após a conclusão da operação de encolhimento (shrink operation).

Se você especificar target_percent com TRUNCATEONLY, a operação de encolhimento pode não liberar espaço livre no final do arquivo.

NÃO RUNCATE

Move as páginas atribuídas do final do arquivo para páginas não atribuídas no início do arquivo. Essa ação compacta os dados dentro do arquivo. target_percent é opcional. O Azure Synapse Analytics não dá suporte a essa opção.

O espaço livre no final do arquivo não é retornado ao sistema operacional, e o tamanho físico do arquivo não é alterado. Devido a isso, o banco de dados não parecerá reduzido quando você especificar NOTRUNCATE.

NOTRUNCATE Aplica-se apenas a arquivos de dados. NOTRUNCATE não afeta o arquivo de log.

APENAS TRUNCADO

Libera todo o espaço livre no final do arquivo para o sistema operacional. Não move todas as páginas dentro do arquivo. O arquivo de dados é reduzido somente para a última extensão atribuída. O Azure Synapse Analytics não dá suporte a essa opção.

Se você especificar target_percent com TRUNCATEONLY, a operação de encolhimento pode não liberar espaço livre no final do arquivo.

COM NO_INFOMSGS

Suprime todas as mensagens informativas com níveis de severidade de 0 a 10.

WAIT_AT_LOW_PRIORITY com operações de redução

Aplica-se a: SQL Server 2022 (16.x) e versões posteriores, Banco de Dados SQL do Azure, Instância Gerenciada de SQL do Azure, banco de dados SQL no Microsoft Fabric

A função de espera em baixa prioridade reduz a contenção de bloqueio durante a operação de encolhimento. Para obter mais informações, confira Noções básicas sobre problemas de simultaneidade com DBCC SHRINKDATABASE.

Esse recurso é semelhante a WAIT_AT_LOW_PRIORITY com operações de índice online, mas com algumas diferenças.

• Você não pode especificar ABORT_AFTER_WAIT a opção NONE.
• Você não pode configurar essa MAX_DURATION opção. O tempo limite de baixa prioridade para travar uma operação de redução é sempre de um minuto.

WAIT_AT_LOW_PRIORITY

Quando um comando de redução é executado no WAIT_AT_LOW_PRIORITY modo, consultas que exigem bloqueios de estabilidade de esquema (Sch-S) nas páginas do Mapa de Alocação de Índice (IAM) não são bloqueadas pela operação de encolhimento. No entanto, a operação de redução pode ser bloqueada por um Sch-S bloqueio em uma página IAM. O Shrink continua a ser executado apenas quando consegue obter um bloqueio de modificação de esquema (Sch-M) em uma página IAM que exige.

Se uma operação de redução no WAIT_AT_LOW_PRIORITY modo não conseguir obter esse bloqueio devido a uma consulta de longa duração que contém um Sch-S bloqueio, a operação de redução do prazo com o erro 49516, por exemplo: Msg 49516, Level 16, State 1, Line 134 Shrink timeout waiting to acquire schema modify lock in WLP mode to process IAM pageID 1:2865 on database ID 5.

{ ABORT_AFTER_WAIT = [ SELF | BLOQUEADORES ] }

• SELF

  SELF é a opção padrão. Saia da operação de redução do banco de dados atualmente em execução sem tomar nenhuma ação adicional.

• BLOCKERS

  Encerre todas as transações de usuário que bloqueiam a operação de redução de arquivo para que a operação possa continuar. A BLOCKERS opção exige que o login tenha a ALTER ANY CONNECTION permissão de ou.KILL DATABASE CONNECTION

Conjunto de resultados

A tabela a seguir descreve as colunas do conjunto de resultados.

Comentários

Para reduzir todos os arquivos de log e dados de um banco de dados específico, execute o comando DBCC SHRINKDATABASE. Para reduzir um arquivo de dados ou de log de cada vez para um banco de dados específico, execute o comando DBCC SHRINKFILE.

Para exibir a quantidade atual de espaço livre (não alocado) no banco de dados, execute sp_spaceused.

Operações DBCC SHRINKDATABASE podem ser interrompidas a qualquer momento do processo, e todo o trabalho concluído é preservado.

O banco de dados não pode ser menor que o tamanho mínimo configurado do banco de dados. Você especifica o tamanho mínimo quando o banco de dados é originalmente criado. Ou então, o tamanho mínimo pode ser o último tamanho explicitamente definido por meio de uma operação de alteração de tamanho do arquivo. Operações como DBCC SHRINKFILE ou ALTER DATABASE são exemplos de operações de alteração de tamanho de arquivo.

Considere que um banco de dados foi criado originalmente com o tamanho de 10 MB. Em seguida, ele atinge 100 MB. O tamanho mínimo ao qual o banco de dados pode ser reduzido é 10 MB, mesmo se todos os dados no banco de dados são excluídos.

Você pode especificar a NOTRUNCATE opção ou a TRUNCATEONLY opção quando executar DBCC SHRINKDATABASE. Se você não especificar nenhuma das opções, o resultado é o mesmo que se você executasse uma DBCC SHRINKDATABASE operação com NOTRUNCATE seguida de uma DBCC SHRINKDATABASE operação com TRUNCATEONLY.

O banco de dados reduzido não precisa estar no modo do usuário único. Outros usuários podem trabalhar no banco de dados quando ele é reduzido, incluindo bancos de dados do sistema.

Não é possível reduzir um banco de dados enquanto ele estiver sendo armazenado em backup. Da mesma forma, não é possível fazer backup de um banco de dados enquanto houver uma operação de redução em processamento.

Nos pools SQL do Azure Synapse, evite executar um comando shrink porque é uma operação que exige muita I/O e pode tirar seu pool SQL dedicado (antigo SQL DW) offline. Esse comando também afeta o custo dos snapshots do seu data warehouse.

Problemas conhecidos

Aplica-se a: SQL Server, Banco de Dados SQL do Azure, Instância Gerenciada de SQL do Azure, Azure Synapse Analytics pool dedicado SQL

• No SQL Server 2022 (16.x) e versões anteriores, as páginas usadas pelos tipos de coluna LOB (varbinary(max), varchar(max) e nvarchar(max)) em segmentos comprimidos de coluna store não podem ser movidas por DBCC SHRINKDATABASE e DBCC SHRINKFILE. Para obter mais informações, confira Atualizações nos índices de armazenamento em colunas.

Como DBCC SHRINKDATABASE funciona

DBCC SHRINKDATABASE reduz os arquivos de dados individualmente, mas faz isso como se todos eles existissem em uma série de logs contíguos. Os arquivos são sempre reduzidos do final.

Suponha que você tenha dois arquivos de log e um arquivo de dados em um banco de dados chamado mydb. Os arquivos de dados e de log têm 10 MB cada e o arquivo de dados contém 6 MB de dados. Para cada arquivo, o Mecanismo de Banco de Dados calcula um tamanho de destino. Esse valor é o tamanho alvo do arquivo após encolher. Quando você especifica DBCC SHRINKDATABASE com target_percent, o Mecanismo de Banco de Dados calcula o tamanho alvo como a target_percent quantidade de espaço livre no arquivo após encolher.

Por exemplo, se você especificar um target_percent igual a 25 para a redução de mydb, o Mecanismo de Banco de Dados calculará o tamanho de destino para o arquivo de dados como 8 MB (6 MB de dados mais 2 MB de espaço livre). Portanto, o Mecanismo de Banco de Dados moverá todos os dados dos últimos 2 MB do arquivo de dados para qualquer espaço livre nos primeiros 8 MB do arquivo de dados e, em seguida, reduzirá o arquivo.

Considere que o arquivo de dados de mydb contém 7 MB de dados. Especificar um target_percent igual a 30 permite que esse arquivo de dados seja reduzido para um percentual livre igual a 30. No entanto, especificar um target_percent igual a 40 não reduz o arquivo de dados porque não é possível criar espaço livre suficiente no tamanho total atual do arquivo de dados.

Você também pode pensar nessa questão de outra forma: um arquivo de dados com 40 por cento de espaço livre desejado + 70 por cento de espaço de dados completo (7 MB de 10 MB) é igual a mais de 100 por cento. Qualquer target_percentage maior que 30 não reduzirá o arquivo de dados. Ele não será reduzido porque o percentual de espaço que você deseja mais o percentual atual ocupado pelo arquivo de dados soma mais de 100%.

Para arquivos de log, o Mecanismo de Banco de Dados usa target_percent para calcular o tamanho de destino do log inteiro. É por isso que target_percent é a quantidade de espaço livre no log após a operação de redução. O tamanho designado do log inteiro é convertido no tamanho designado de cada arquivo de log.

DBCC SHRINKDATABASE tenta reduzir cada arquivo de log físico imediatamente para o tamanho de destino. Se nenhuma parte do log lógico permanecer nos logs virtuais além do tamanho alvo do arquivo log, DBCC SHRINKDATABASE o arquivo é truncado com sucesso e termina sem nenhuma mensagem. No entanto, se parte do log lógico ficar nos logs virtuais além do tamanho designado, o Mecanismo de Banco de Dados liberará o espaço disponível possível e emitirá uma mensagem informativa. A mensagem descreve as ações para mover o log lógico para fora dos logs virtuais no final do arquivo. Após as ações serem executadas, use DBCC SHRINKDATABASE para liberar o espaço restante.

Você só pode reduzir um arquivo de log para um limite virtual de arquivo de log. Por isso, reduzir um arquivo de log para um tamanho menor que o tamanho de um arquivo de log virtual. O Mecanismo de Banco de Dados escolhe dinamicamente o tamanho do arquivo de log virtual ao criar ou estender arquivos de log.

Noções básicas sobre problemas de simultaneidade com DBCC SHRINKDATABASE

Os comandos de redução de banco de dados e redução de arquivos podem causar problemas de concorrência, especialmente em manutenções ativas, como reconstrução de índices, ou em ambientes OLTP movimentados.

Por exemplo, uma consulta de usuário pode adquirir um bloqueio de estabilidade de esquema (Sch-S) em uma página de Mapa de Alocação de Índice (IAM) e mantê-lo até a conclusão. Ao tentar recuperar espaço durante o uso regular, operações de redução de banco de dados e redução de arquivos exigem um bloqueio de modificação de esquema (Sch-M) ao mover ou excluir páginas IAM, bloqueando os Sch-S bloqueios necessários pelas consultas do usuário. Como resultado, consultas de longa duração podem bloquear uma operação de encolhimento. Esse comportamento também significa que qualquer nova consulta que exija um Sch-S bloqueio em uma página IAM pode ficar em fila atrás da operação de encolhimento, agravando ainda mais esse problema de concorrência.

Introduzido no SQL Server 2022 (16.x), o recurso de espera em baixa prioridade para operações de redução resolve esse problema ao usar o bloqueio de modificação de esquema nas páginas IAM nesse WAIT_AT_LOW_PRIORITY modo. Para obter mais informações, confira WAIT_AT_LOW_PRIORITY com operações de redução.

Para mais informações sobre Sch-S bloqueios, Sch-M veja o guia de bloqueio de transações e versionamento de linhas.

Práticas recomendadas

Considere as seguintes informações ao planejar reduzir um banco de dados:

• Uma operação de redução é mais eficiente depois de uma operação que cria espaço não utilizado, como operações truncate table ou drop table.

• A maioria dos bancos de dados requer algum espaço livre para operações regulares do dia a dia. Se você reduzir repetidamente um arquivo de banco de dados e perceber que o tamanho do banco de dados cresce novamente, esse crescimento indica que as operações regulares exigem espaço livre. Nesses casos, reduzir repetidamente o arquivo do banco de dados é contraproducente. O crescimento do arquivo necessário para alocar novo espaço após a redução pode prejudicar o desempenho.

• Uma operação de redução não preserva o estado de fragmentação dos índices no banco de dados e pode aumentar a fragmentação do índice, o que pode reduzir o débito de leitura de I/O para consultas que usam varreduras grandes.

• A menos que você tenha um requisito específico, não defina a opção de AUTO_SHRINK banco de dados como ON.

• Se você precisar reduzir os arquivos de dados de um banco de dados grande, considere usar o script PowerShell ShrinkDriver . O script automatiza e simplifica o processo de encolhemento, transformando-o em uma única operação observável e retomável. O script reduz múltiplos arquivos em paralelo, tenta novamente quando interrompido e gera relatórios detalhados de status enquanto roda.

Solucionar problemas

Uma transação em execução em um nível de isolamento baseado em controle de versão de linha pode bloquear as operações de redução. Por exemplo, você executa DBCC SHRINKDATABASE enquanto uma grande operação de exclusão sob um nível de isolamento baseado em versões de linha está em andamento. Nesse caso, a operação de encolhimento espera a operação de exclusão ser concluída antes de reduzir os arquivos. Quando a operação de redução aguarda e as operações DBCC SHRINKFILE e DBCC SHRINKDATABASE imprimem uma mensagem informativa (5202 para SHRINKDATABASE e 5203 para SHRINKFILE). Essa mensagem é impressa no log de erros do SQL Server a cada cinco minutos na primeira hora e depois a cada hora. Por exemplo, se o log de erros contiver a seguinte mensagem de erro:

DBCC SHRINKDATABASE for database ID 9 is waiting for the snapshot
transaction with timestamp 15 and other snapshot transactions linked to
timestamp 15 or with timestamps older than 109 to finish.

Esse erro significa que transações snapshot com carimbos de tempo anteriores a 109 bloqueiam a operação de encolhimento. Essa transação é a última transação concluída pela operação de redução. Também indica que as transaction_sequence_num colunas ou first_snapshot_sequence_num na visão dinâmica de gerenciamento sys.dm_tran_active_snapshot_database_transactions contêm um valor de 15. A coluna transaction_sequence_num ou first_snapshot_sequence_num da exibição pode conter um número menor que o da última transação concluída por uma operação de redução (109). Nesse caso, a operação de redução aguarda a conclusão dessas transações.

Para resolver o problema, você pode fazer uma das seguintes opções:

• Encerrar a transação que está bloqueando a operação de redução.
• Encerrar a operação de redução. Todo o trabalho concluído será preservado.
• Não interferir e permitir que a operação de redução aguarde até que a transação de bloqueio seja concluída.

Permissões

Exige associação à função de servidor fixa sysadmin ou à função de banco de dados fixa db_owner .

Exemplos

Os exemplos de código neste artigo usam o banco de dados de exemplo AdventureWorks2025 ou AdventureWorksDW2025, que você pode baixar na página inicial Microsoft SQL Server Samples and Community Projects.

a. Reduzir um banco de dados e especificar um percentual de espaço livre

O exemplo a seguir reduz o tamanho dos arquivos de dados e de log no banco de dados de usuário UserDB para permitir 10 por cento de espaço livre no banco de dados.

DBCC SHRINKDATABASE (UserDB, 10);
GO

B. Truncar um banco de dados

O exemplo a seguir reduz os arquivos de dados e de log no banco de dados de exemplo AdventureWorks2025 até a última extensão atribuída.

DBCC SHRINKDATABASE (AdventureWorks2025, TRUNCATEONLY);

C. Reduzir um banco de dados do Azure Synapse Analytics

DBCC SHRINKDATABASE (database_A);
DBCC SHRINKDATABASE (database_B, 10);

D. Reduzir um banco de dados com WAIT_AT_LOW_PRIORITY

O exemplo a seguir tenta reduzir o tamanho dos arquivos de dados e de log no banco de dados AdventureWorks2025 para liberar 20% de espaço livre no banco de dados. Se um bloqueio não puder ser obtido em um minuto, a operação de redução será anulada.

DBCC SHRINKDATABASE ([AdventureWorks2025], 20) WITH WAIT_AT_LOW_PRIORITY (ABORT_AFTER_WAIT = SELF);

Conteúdo relacionado

• Reduzir um banco de dados
• Reduzir um arquivo
• ARQUIVO DE REDUÇÃO DE DBCC (Transact-SQL)
• Considerações para as configurações de crescimento automático e redução automática no SQL Server
• Arquivos de banco de dados e grupos de arquivos
• sys.databases (Transact-SQL)
• sys.database_files (Transact-SQL)
• ALTER DATABASE (Transact-SQL)
• Gerenciar o espaço de arquivo para bancos de dados no Banco de Dados SQL do Azure