DBCC SHRINKDATABASE (Transact-SQL)

Aplica-se a:SQL ServerBanco de Dados SQL do AzureInstância Gerenciada SQL do AzureBanco de Dados SQL do Azure Synapse Analyticsno Microsoft Fabric

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

Não considere as operações de redução como uma 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.

Transact-SQL convenções de sintaxe

Sintaxe

Sintaxe do 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 do Azure Synapse Analytics:

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

Argumentos

{ database_name | database_id | 0 }

O nome ou ID da base de dados para encolher. Um valor 0 especifica a base de dados atual.

target_percent

A percentagem de espaço livre a deixar no ficheiro da base de dados após a conclusão da operação de redução.

Se especificar target_percent com TRUNCATEONLY, a operação de encolhimento pode não libertar espaço livre no final do ficheiro.

NOTRUNCATE

Move páginas atribuídas do final do arquivo para páginas não atribuídas na frente do arquivo. Esta ação compacta os dados dentro do arquivo. target_percent é opcional. O Azure Synapse Analytics não suporta esta opção.

O espaço livre no final do ficheiro não é devolvido ao sistema operativo e o tamanho físico do ficheiro não é alterado. Como tal, o banco de dados não parece encolher quando se especifica NOTRUNCATE.

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

TRUNCATEONLY

Libera todo o espaço livre no final do arquivo para o sistema operacional. Não move nenhuma página dentro do arquivo. O arquivo de dados diminui apenas até a última extensão atribuída. O Azure Synapse Analytics não suporta esta opção.

Se especificar target_percent com TRUNCATEONLY, a operação de encolhimento pode não libertar espaço livre no final do ficheiro.

SEM NO_INFOMSGS

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

WAIT_AT_LOW_PRIORITY com operações de encolhimento

Aplica-se a: SQL Server 2022 (16.x) e versões posteriores, Base de Dados SQL do Azure, Azure SQL Managed Instance, base de dados SQL no Microsoft Fabric

A funcionalidade de espera a baixa prioridade reduz a contenção de bloqueio durante a operação de encolhimento. Para obter mais informações, consulte Compreender os problemas de concorrência com o DBCC SHRINKDATABASE.

Este recurso é semelhante ao WAIT_AT_LOW_PRIORITY com operações de índice on-line, com algumas diferenças.

• Não podes especificar ABORT_AFTER_WAIT a opção NONE.
• Não podes definir essa MAX_DURATION opção. O tempo de bloqueio de baixa prioridade para uma operação de redução é sempre de um minuto.

ESPERAR_COM_BAIXA_PRIORIDADE

Quando um comando shrink é executado no WAIT_AT_LOW_PRIORITY modo, as consultas que requerem bloqueios de estabilidade de esquema (Sch-S) nas páginas do Index Allocation Map (IAM) não são bloqueadas pela operação de shrink. No entanto, a operação de redução pode ser bloqueada por um Sch-S bloqueio numa página IAM. O shrink continua a ser executado apenas quando consegue obter um bloqueio de modificação de esquema (Sch-M) numa página IAM que necessita.

Se uma operação de encolhimento em WAIT_AT_LOW_PRIORITY modo não conseguir obter este bloqueio devido a uma consulta de longa duração que contém um Sch-S bloqueio, a operação de encolhimento expira 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 = [ EU | BLOQUEADORES ] }

• SELF

  SELF é a opção padrão. Sair da operação de redução da base de dados que está a ser executada sem tomar qualquer ação adicional.

• BLOCKERS

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

Conjunto de resultados

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

Comentários

Para reduzir todos os dados e arquivos de log 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.

As operações DBCC SHRINKDATABASE podem ser interrompidas em qualquer ponto do processo, e qualquer trabalho concluído é preservado.

O banco de dados não pode ser menor do que o tamanho mínimo configurado do banco de dados. Você especifica o tamanho mínimo quando o banco de dados é originalmente criado. Ou, o tamanho mínimo pode ser o último tamanho explicitamente definido usando uma operação de alteração de tamanho de 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 é originalmente criado com um tamanho de 10 MB. Em seguida, ele cresce para 100 MB. O menor banco de dados pode ser reduzido para 10 MB, mesmo que todos os dados no banco de dados tenham sido excluídos.

Pode especificar a NOTRUNCATE opção ou a TRUNCATEONLY opção quando executa DBCC SHRINKDATABASE. Se não especificares nenhuma das opções, o resultado é o mesmo que se executares 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 de usuário único. Outros usuários podem estar trabalhando no banco de dados quando ele é reduzido, incluindo bancos de dados do sistema.

Não é possível reduzir um banco de dados enquanto o backup do banco de dados está sendo feito. Por outro lado, não é possível fazer backup de um banco de dados enquanto uma operação de redução no banco de dados está em processo.

Nos pools SQL do Azure Synapse, evite executar um comando shrink porque é uma operação intensiva em I/O que pode desligar o seu pool SQL dedicado (anteriormente SQL DW). Este comando também afeta o custo dos snapshots do seu data warehouse.

Problemas conhecidos

Aplica-se a: SQL Server, Base de Dados SQL do Azure, Azure SQL Managed Instance, 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 columnstore não podem ser movidas por DBCC SHRINKDATABASE e DBCC SHRINKFILE. Para mais informações, consulte O que há de novo nos índices de columnstore.

Como funciona o DBCC SHRINKDATABASE

DBCC SHRINKDATABASE reduz os arquivos de dados por arquivo, mas reduz os arquivos de log como se todos os arquivos de log existissem em um pool de logs contíguo. Os ficheiros são sempre encolhidos a partir do fim.

Assuma que tem dois ficheiros de registo e um ficheiro de dados numa base de dados chamada mydb. Os dados e arquivos de log são 10 MB cada e o arquivo de dados contém 6 MB de dados. O Mecanismo de Banco de Dados calcula um tamanho de destino para cada arquivo. Este valor é o tamanho alvo do ficheiro após encolher. Quando especificas DBCC SHRINKDATABASE com target_percent, o Database Engine calcula o tamanho alvo como a target_percent quantidade de espaço livre no ficheiro após encolher.

Por exemplo, se você especificar uma target_percent de 25 para reduzir mydb, o Mecanismo de Banco de Dados calculará o tamanho de destino do arquivo de dados como 8 MB (6 MB de dados mais 2 MB de espaço livre). Como tal, o Mecanismo de Banco de Dados move 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, reduz o arquivo.

Suponha que o arquivo de dados do mydb contém 7 MB de dados. Especificar uma target_percent de 30 permite que esse arquivo de dados seja reduzido para a porcentagem livre de 30. No entanto, especificar uma target_percent de 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ê pode pensar nessa questão de outra maneira: 40% queriam espaço livre + 70% de arquivo de dados completo (7 MB de 10 MB) é mais de 100%. Qualquer target_percent maior que 30 não reduzirá o arquivo de dados. Ele não diminuirá porque a porcentagem livre que você deseja mais a porcentagem atual que o arquivo de dados ocupa é superior a 100%.

Para arquivos de log, o Mecanismo de Banco de Dados usa target_percent para calcular o tamanho alvo para o log inteiro. É por isso que target_percent representa a quantidade de espaço livre no log após a operação de redução. O tamanho alvo para todo o log é então ajustado para um tamanho alvo para cada ficheiro de log.

DBCC SHRINKDATABASE tenta reduzir cada arquivo de log físico para seu tamanho de destino imediatamente. Se nenhuma parte do registo lógico permanecer nos registos virtuais para além do tamanho alvo do ficheiro de registo, DBCC SHRINKDATABASE o ficheiro trunca com sucesso e termina sem quaisquer mensagens. No entanto, se parte do log lógico permanecer nos logs virtuais além do tamanho de destino, o Mecanismo de Banco de Dados liberará o máximo de espaço possível e, em seguida, emitirá uma mensagem informativa. A mensagem descreve as ações para mover o log lógico para fora dos registos virtuais no final do ficheiro. Depois de executadas as ações, use DBCC SHRINKDATABASE para libertar o espaço restante.

Só podes reduzir um ficheiro de registo para um limite virtual de ficheiro de registo. É por isso que não é possível reduzir um ficheiro de registo para um tamanho menor do que o tamanho de um ficheiro de registo virtual. O Database Engine escolhe dinamicamente o tamanho do ficheiro de registo virtual ao criar ou estender ficheiros de registo.

Compreender os problemas de concorrência com DBCC SHRINKDATABASE

Os comandos de redução da base de dados e de redução de ficheiros podem causar problemas de concorrência, especialmente com manutenção ativa, como a reconstrução de índices, ou em ambientes OLTP movimentados.

Por exemplo, uma consulta de utilizador pode adquirir um bloqueio de estabilidade de esquema (Sch-S) numa página de Mapa de Alocação de Índice (IAM) e mantê-lo até à conclusão. Ao tentar recuperar espaço durante o uso normal, as operações de redução de base de dados e redução de ficheiros requerem um bloqueio de modificação de esquema (Sch-M) ao mover ou eliminar páginas IAM, bloqueando os Sch-S bloqueios necessários para consultas dos utilizadores. Como resultado, consultas de longa duração podem bloquear uma operação de encolhimento. Este comportamento também significa que qualquer nova consulta que exija um Sch-S bloqueio numa página IAM pode entrar em fila atrás da operação de redução, agravando ainda mais este problema de concorrência.

Introduzida no SQL Server 2022 (16.x), a funcionalidade de espera a baixa prioridade para operações de redução resolve este problema ao usar o bloqueio de modificação de esquema nas páginas IAM neste WAIT_AT_LOW_PRIORITY modo. Para obter mais informações, consulte WAIT_AT_LOW_PRIORITY com operações de redução.

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

Melhores práticas

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

• Uma operação de redução é mais eficaz após uma operação que cria espaço não utilizado, como uma tabela truncada ou uma operação de tabela suspensa.

• A maioria das bases de dados requer algum espaço livre para operações diárias regulares. Se reduzir repetidamente um ficheiro de base de dados e notar que o tamanho da base de dados volta a crescer, este crescimento indica que as operações normais requerem espaço livre. Nestes casos, reduzir repetidamente o ficheiro da base de dados é contraproducente. O crescimento do ficheiro 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 na base de dados e pode aumentar a fragmentação do índice, o que pode reduzir o débito de I/O de leitura para consultas que usam varreduras grandes.

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

• Se precisar de reduzir os ficheiros de dados de uma base de dados grande, considere usar o script PowerShell ShrinkDriver . O script automatiza e simplifica o processo de shrink, transformando-o numa única operação observável e retomável. O script encolhe vários ficheiros em paralelo, tenta novamente quando interrompido e gera relatórios detalhados de estado à medida que é executado.

Solução de problemas

Uma transação executada sob um nível de isolamento baseado em controle de versão de linha pode bloquear operações de redução. Por exemplo, executa DBCC SHRINKDATABASE enquanto uma grande operação de eliminação a correr sob um nível de isolamento baseado em versões de linhas está em curso. Neste caso, a operação de encolhimento espera que a operação de eliminação seja concluída antes de encolher os ficheiros. Quando a operação de redução está em espera, as operações DBCC SHRINKFILE e DBCC SHRINKDATABASE imprimem uma mensagem de informação (5202 para SHRINKDATABASE e 5203 para SHRINKFILE). Esta mensagem é impressa no registo 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.

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

Para resolver o problema, pode fazer uma das seguintes:

• Encerre a transação que está bloqueando a operação de redução.
• Termine a operação de encolhimento. Qualquer trabalho que esteja concluído é preservado.
• Não faça nada e permita que a operação de redução aguarde até que a transação de bloqueio seja concluída.

Permissões

Requer 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 pode ser descarregado da página inicial de Exemplos e Projetos da Comunidade do Microsoft SQL Server.

Um. Reduzir um banco de dados e especificar uma porcentagem de espaço livre

O exemplo a seguir reduz o tamanho dos dados e arquivos de log no banco de dados de usuário UserDB para permitir 10% 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 dados e os arquivos 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 uma base de dados com WAIT_AT_LOW_PRIORITY

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

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

Conteúdo relacionado

• Reduzir um banco de dados
• Reduzir um ficheiro
• FICHEIRO DE SHRINK 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)
• Gerir o espaço de ficheiros para bases de dados na Base de Dados SQL do Azure