Partilhar via

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.

Observação

As operações de encolhimento não devem ser consideradas 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.

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_namedatabase_id | 0

O nome ou ID do banco de dados a ser reduzido. 0 especifica que o banco de dados atual é usado.

target_percent

A porcentagem de espaço livre que você deseja deixar no arquivo de banco de dados após a conclusão da operação de redução.

Se target_percent for especificado com TRUNCATEONLY, o espaço livre no final do arquivo pode não ser liberado.

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 é aplicável 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 target_percent for especificado com TRUNCATEONLY, o espaço livre no final do arquivo pode não ser liberado.

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, Banco de Dados SQL do Azure, Instância Gerenciada do SQL do Azure

O recurso de espera em baixa prioridade reduz a contenção de bloqueio. 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 é possível especificar a opção ABORT_AFTER_WAITNONE.

ESPERAR_COM_BAIXA_PRIORIDADE

Quando um comando de encolhimento é executado no modo WAIT_AT_LOW_PRIORITY, novas consultas que exigem bloqueios de estabilidade de esquema (Sch-S) não são bloqueadas pela operação de encolhimento em espera até que a operação de encolhimento pare de esperar e comece a ser executada. A operação shrink é executada quando é capaz de obter um bloqueio de modificação de esquema (Sch-M). Se uma nova operação de redução no modo WAIT_AT_LOW_PRIORITY não puder obter um bloqueio devido a uma consulta de longa execução, a operação de redução acabará por atingir o tempo limite após 1 minuto por padrão e sairá sem erro.

Se uma nova operação de redução no modo WAIT_AT_LOW_PRIORITY não puder obter um bloqueio devido a uma consulta de longa duração, a operação de redução acabará por expirar após 1 minuto, por padrão, e sairá sem erro. Isso ocorre se a operação de redução não puder obter o bloqueio Sch-M devido a consulta ou consultas simultâneas que mantêm bloqueios Sch-S. Quando ocorre um tempo limite, o erro 49516 é enviado para o log de erros do SQL Server, 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. Repita a operação de redução no modo WAIT_AT_LOW_PRIORITY.

ABORT_AFTER_WAIT = [ EU | BLOQUEADORES ]

  • EU MESMO

    SELF é a opção padrão. Saia da operação de redução de banco de dados que está sendo executada no momento sem executar nenhuma ação.

  • BLOQUEADORES

    Mate todas as transações de usuário que bloqueiam a operação de redução de banco de dados para que a operação possa continuar. A opção BLOCKERS requer que o login tenha permissão ALTER ANY CONNECTION.

Conjunto de resultados

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

Nome da coluna Descrição
DbId Número de identificação do banco de dados do arquivo que o Mecanismo de Banco de Dados tentou reduzir.
FileId Número de identificação do arquivo que o Mecanismo de Banco de Dados tentou reduzir.
CurrentSize Número de páginas de 8 KB que o arquivo ocupa atualmente.
MinimumSize Número de páginas de 8 KB que o arquivo poderia ocupar, no mínimo. Esse valor corresponde ao tamanho mínimo ou ao tamanho originalmente criado de um arquivo.
UsedPages Número de páginas de 8 KB atualmente usadas pelo arquivo.
EstimatedPages Número de páginas de 8 KB para as quais o Mecanismo de Banco de Dados estima que o arquivo pode ser reduzido.

Observação

O Motor de Base de Dados não exibe linhas para os arquivos que não foram compactados.

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.

Especifique a opção NOTRUNCATE ou a opção TRUNCATEONLY quando executar DBCC SHRINKDATABASE. Se não o fizer, o resultado será o mesmo que se executar uma operação DBCC SHRINKDATABASE com NOTRUNCATE seguida de uma operação DBCC SHRINKDATABASE 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.

Quando especificado com WAIT_AT_LOW_PRIORITY, a solicitação de bloqueio de Sch-M da operação de redução aguarda com baixa prioridade durante a execução do comando por um minuto. Se a operação for bloqueada durante esse período, a ação ABORT_AFTER_WAIT especificada será executada.

Nos pools SQL do Azure Synapse, a execução de um comando shrink não é recomendada, pois essa é uma operação intensiva de E/S e pode colocar seu pool SQL dedicado (anteriormente SQL DW) offline. Além disso, poderão haver implicações de custo para os seus instantâneos do armazém de dados depois de executar este comando.

Problemas conhecidos

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

  • Atualmente, as colunas que usam tipos de dados LOB (varbinary(max), varchar(max) e nvarchar(max)) em segmentos columnstore compactados não são afetadas por DBCC SHRINKDATABASE e DBCC SHRINKFILE.

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.

Suponha que você tenha alguns arquivos de log, um arquivo de dados e um banco de dados chamado 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. Esse valor é o tamanho para o qual o arquivo deve ser reduzido. Quando DBCC SHRINKDATABASE é especificado com target_percent, o Mecanismo de Banco de Dados calcula o tamanho do destino como a target_percent quantidade de espaço livre no arquivo após a redução.

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. Digamos que nenhuma parte do log lógico permaneça nos logs virtuais além do tamanho alvo do arquivo de log. Em seguida, o arquivo é truncado com êxito e DBCC SHRINKDATABASE termina sem nenhuma mensagem. 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 quais ações são necessárias para mover o log lógico para fora dos logs virtuais no final do arquivo. Depois que as ações são executadas, DBCC SHRINKDATABASE podem ser usadas para liberar o espaço restante.

Um arquivo de log só pode ser reduzido para um limite de arquivo de log virtual. É por isso que reduzir um arquivo de log para um tamanho menor do que o tamanho de um arquivo de log virtual pode não ser possível. Pode não ser possível, mesmo que não esteja a ser utilizado. O tamanho do arquivo de log virtual é escolhido dinamicamente pelo Mecanismo de Banco de Dados quando os arquivos de log são criados ou estendidos.

Compreender os problemas de concorrência com DBCC SHRINKDATABASE

Os comandos shrink database e shrink file podem levar a problemas de simultaneidade, especialmente com manutenção ativa, como a reconstrução de índices, ou em ambientes OLTP ocupados. Quando seu aplicativo executa consultas em tabelas de banco de dados, essas consultas adquirirão e manterão um bloqueio de estabilidade de esquema (Sch-S) até que as consultas concluam suas operações. Ao tentar recuperar espaço durante o uso regular, as operações de redução de base de dados e de ficheiros precisam atualmente de um bloqueio de modificação de esquema (Sch-M) ao mover ou excluir páginas do Mapa de Alocação de Índice (IAM), bloqueando os bloqueios Sch-S necessários para consultas de utilizador. Como resultado, consultas de longa execução bloquearão uma operação de redução até que as consultas sejam concluídas. Isso significa que quaisquer novas consultas que exijam bloqueios de Sch-S também são enfileiradas atrás da operação de redução pendente e serão igualmente bloqueadas, agravando ainda mais este problema de concorrência. Isso pode afetar significativamente o desempenho da consulta do aplicativo e também causará dificuldades para concluir a manutenção necessária para reduzir os arquivos do banco de dados. Introduzido no SQL Server 2022 (16.x), o recurso de shrink wait em baixa prioridade (WLP) aborda este problema ao usar um bloqueio de modificação de esquema no modo WAIT_AT_LOW_PRIORITY. Para obter mais informações, consulte WAIT_AT_LOW_PRIORITY com operações de redução.

Para obter mais informações sobre bloqueios de Sch-S e Sch-M, consulte Guia de bloqueio de transações e controle de versão de linha.

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 dos bancos de dados requer algum espaço livre para estar disponível para operações regulares do dia-a-dia. Se você reduzir um arquivo de banco de dados repetidamente e notar que o tamanho do banco de dados cresce novamente, isso indica que o espaço livre é necessário para operações regulares. Nesses casos, reduzir repetidamente o arquivo de banco de dados é uma operação desperdiçada. Os eventos de crescimento automático necessários para aumentar o arquivo de banco de dados prejudicam o desempenho.
  • Uma operação de redução não preserva o estado de fragmentação dos índices no banco de dados e, geralmente, aumenta a fragmentação em um grau. Esse resultado é outra razão para não reduzir repetidamente o banco de dados.
  • A menos que você tenha um requisito específico, não defina a opção AUTO_SHRINK banco de dados como ON.

Solução de problemas

É possível que uma transação, em execução com um nível de isolamento baseado em versionamento de linha, bloqueie operações de redução . Por exemplo, uma grande operação de exclusão que está a decorrer com um nível de isolamento que utiliza versionamento de linhas está em progresso quando uma operação DBCC SHRINKDATABASE é executada. Quando essa situação acontece, a operação de redução aguarda a conclusão da operação de exclusão antes de reduzir os arquivos. 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). Essa mensagem é impressa no log de erros do SQL Server a cada cinco minutos na primeira hora e, em seguida, a cada próxima 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 instantâneas com carimbos de data/hora anteriores a 109 bloquearão a operação de redução. Essa é a última transação que a operação de redução completou. Ele também indica que as colunas transaction_sequence_num ou first_snapshot_sequence_num na sys.dm_tran_active_snapshot_database_transactions (Transact-SQL) vista de gestão dinâmica 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, você pode executar uma das seguintes tarefas:

  • 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

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 (AdventureWorks2022, 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 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 ([AdventureWorks2022], 20) WITH WAIT_AT_LOW_PRIORITY (ABORT_AFTER_WAIT = SELF);

Conteúdo relacionado

  • Last updated on