FICHEIRO DE SHRINK DBCC (Transact-SQL)

Aplica-se a:SQL ServerBase de Dados SQL do AzureAzure SQL Managed InstanceBase de dados SQL no Microsoft Fabric

Reduz os dados especificados do banco de dados atual ou o tamanho do arquivo de log. Você pode usá-lo para mover dados de um arquivo para outros arquivos no mesmo grupo de arquivos, o que esvazia o arquivo e permite sua remoção do banco de dados. Você pode reduzir um arquivo para menos do que seu tamanho na criação, redefinindo o tamanho mínimo do arquivo para o novo valor.

Use DBCC SHRINKFILE apenas quando necessário, pois o encolhimento é uma operação de longa duração e que consome muitos recursos.

Transact-SQL convenções de sintaxe

Sintaxe

DBCC SHRINKFILE
(
    { file_name | file_id }
    { [ , EMPTYFILE ]
    | [ [ , target_size ] [ , { 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 }

Argumentos

file_name

O nome lógico do ficheiro para encolher.

file_id

O número de identificação (ID) do ficheiro a diminuir. Para obter uma ID de arquivo, use a função de sistema FILE_IDEX ou consulte a exibição de catálogo sys.database_files no banco de dados atual.

target_size

Um inteiro que representa o novo tamanho de megabyte do arquivo. Se definires target_size para 0 ou não especificares, DBCC SHRINKFILE o ficheiro reduz ao seu tamanho de criação.

Você pode reduzir o tamanho padrão de um arquivo vazio usando DBCC SHRINKFILE <target_size>. Por exemplo, se você criar um arquivo de 5 MB e, em seguida, reduzir o arquivo para 3 MB enquanto o arquivo ainda estiver vazio, o tamanho padrão do arquivo será definido como 3 MB. Isso se aplica apenas a arquivos vazios que nunca contiveram dados.

Esta opção não é suportada para contêineres de grupo de arquivos FILESTREAM.

Se especificado, DBCC SHRINKFILE tenta reduzir o arquivo para target_size. As páginas usadas na área do arquivo a serem liberadas são movidas para o espaço livre nas áreas mantidas do arquivo. Por exemplo, com um arquivo de dados de 10 MB, uma operação de DBCC SHRINKFILE com um 8target_size move todas as páginas usadas nos últimos 2 MB do arquivo para quaisquer páginas não alocadas nos primeiros 8 MB. DBCC SHRINKFILE não reduz um arquivo além do tamanho de dados armazenados necessário. Por exemplo, se 7 MB de um arquivo de dados de 10 MB for usado, uma DBCC SHRINKFILE instrução com uma target_size de 6 reduz o arquivo para apenas 7 MB, não 6 MB.

Se especificar target_size com TRUNCATEONLY, DBCC SHRINKFILE pode não libertar espaço livre no final do ficheiro.

EMPTYFILE

Migra todos os dados do arquivo especificado para outros arquivos no mesmo grupo de arquivos. Em outras palavras, EMPTYFILE migra dados de um arquivo especificado para outros arquivos no mesmo grupo de arquivos. EMPTYFILE garante que nenhum novo dado seja adicionado ao arquivo, apesar de esse arquivo não ser somente leitura. Pode usar a ALTER DATABASE instrução para remover um ficheiro. Se usar a ALTER DATABASE instrução para alterar o tamanho do ficheiro, a bandeira de apenas leitura é reiniciada e os dados podem ser adicionados.

Para contêineres de grupo de arquivos FILESTREAM, você não pode usar ALTER DATABASE para remover um arquivo até que o Coletor de Lixo FILESTREAM tenha executado e excluído todos os arquivos de contêiner de grupo de arquivos desnecessários que EMPTYFILE copiou para outro contêiner. Para obter mais informações, consulte sp_filestream_force_garbage_collection. Para informações sobre a remoção de um contentor FILESTREAM, consulte a secção correspondente em ALTER DATABASE Opções de Ficheiros e Grupos de Ficheiros

EMPTYFILEnão é suportado no Base de Dados SQL do Azure, Base de Dados SQL do Azure Hyperscale ou SQL Database no Microsoft Fabric.

NOTRUNCATE

Move as páginas alocadas do final de um ficheiro de dados para páginas não alocadas no início de um ficheiro, com ou sem a especificação de target_percent. O espaço livre na extremidade do ficheiro não é devolvido ao sistema operativo e o tamanho físico do ficheiro não é alterado. Portanto, se NOTRUNCATE for especificado, o arquivo parece não diminuir.

NOTRUNCATE é aplicável apenas a ficheiros de dados. Os arquivos de log não são afetados.

Esta opção não é suportada para contêineres de grupo de arquivos FILESTREAM.

TRUNCATEONLY

Libera todo o espaço livre no final do arquivo para o sistema operacional, mas não executa nenhum movimento de página dentro do arquivo. O arquivo de dados é reduzido apenas até a última extensão alocada.

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

A TRUNCATEONLY opção não move informação no registo, mas remove ficheiros virtuais de registo (VLFs) inativos do final do ficheiro de registo. Esta opção não é suportada para contêineres de grupo de arquivos FILESTREAM.

SEM NO_INFOMSGS

Suprime todas as mensagens informativas.

WAIT_AT_LOW_PRIORITY com operações de redução

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 mais informações, consulte Compreender problemas de concorrência com DBCC SHRINKFILE.

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

• Não podes especificar a ABORT_AFTER_WAIT 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.

AGUARDAR_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 ] }

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

• SELF

  SELF é a opção padrão. Sai da operação de redução de ficheiro 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 do conjunto de resultados.

Comentários

DBCC SHRINKFILE se aplica aos arquivos do banco de dados atual. Para mais informações sobre como alterar a base de dados atual, consulte USE.

Você pode parar as operações DBCC SHRINKFILE a qualquer momento, e qualquer trabalho concluído será preservado. Se você usar o parâmetro EMPTYFILE e cancelar a operação, o arquivo não será marcado para impedir que dados adicionais sejam adicionados.

Outros usuários podem trabalhar no banco de dados durante a redução de arquivos; O banco de dados não precisa estar no modo de usuário único. Não é necessário executar a instância do SQL Server no modo de usuário único para reduzir os bancos de dados do sistema.

Problemas conhecidos

Aplica-se a: SQL Server, Base de Dados SQL do Azure, SQL database em Microsoft Fabric, Azure SQL Managed Instance, Azure Synapse Analytics pool dedicado SQL

• Nas versões do SQL Server anteriores ao SQL Server 2025 (17.x), as páginas usadas pelos tipos de colunas de objetos grandes (LOB) (varbinary(max), varchar(max) e nvarchar(max)) em segmentos comprimidos de coluna 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.

Compreender os problemas de concorrência com DBCC SHRINKFILE

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 ocupados de processamento de transações online (OLTP).

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. Isto 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.

Reduzir um arquivo de log

Para arquivos de log, o Mecanismo de Banco de Dados usa target_size para calcular o tamanho de destino do log inteiro. Portanto, target_size é o espaço livre do log após a operação de redução. O tamanho de destino de todo o log é então convertido para o tamanho de destino de cada arquivo de log. DBCC SHRINKFILE tenta reduzir cada arquivo de log físico para seu tamanho de destino imediatamente. No entanto, se parte do log lógico residir nos logs virtuais que estão 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 SHRINKFILE podem ser usadas para liberar o espaço restante.

Como um arquivo de log só pode ser reduzido para um limite de arquivo de log virtual, 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, mesmo que ele não esteja sendo usado. O Motor de Base de Dados escolhe dinamicamente o tamanho do ficheiro de log virtual quando os ficheiros de log são criados ou estendidos.

Melhores práticas

Considere as seguintes informações ao planejar reduzir um arquivo:

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

• 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. 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.

• 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

Esta seção descreve como diagnosticar e corrigir problemas que podem ocorrer ao executar o comando DBCC SHRINKFILE.

O arquivo não encolhe

Se o tamanho do ficheiro não mudar após uma operação de encolhimento sem erros, tente os seguintes passos para verificar se o ficheiro tem espaço livre suficiente:

• Execute a seguinte consulta.

  SELECT name,
         size / 128.0 - CAST (FILEPROPERTY(name, 'SpaceUsed') AS INT) / 128.0 AS AvailableSpaceInMB
  FROM sys.database_files;
  

• Se quiser reduzir o ficheiro do registo de transações, use a vista dinâmica de gestão do sys.dm_db_log_space_usage (DMV) para ver o espaço utilizado no registo de transações.

A operação de encolhimento não pode reduzir ainda mais o tamanho do ficheiro se não houver espaço livre suficiente.

Uma razão comum para um ficheiro de registo de transações não encolher é a ausência de backups regulares dos registos de transações. Para truncar o log, faça backup do log de transações e execute a operação DBCC SHRINKFILE novamente. Se não for necessária a recuperação em determinado momento, considere os modelos de recuperação (SQL Server) para evitar o crescimento de ficheiros de registo.

A operação de redução está bloqueada

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, se uma grande operação de eliminação, em execução sob um isolamento baseado em versionamento de linha, estiver em andamento quando uma operação DBCC SHRINKDATABASE for executada, a operação de redução aguardará que a eliminação seja concluída antes de continuar. Quando esse bloqueio acontece, as operações DBCC SHRINKFILE e DBCC SHRINKDATABASE imprimem uma mensagem informativa (5202 para SHRINKDATABASE e 5203 para SHRINKFILE) no log de erros do SQL Server. Esta mensagem é registada a cada cinco minutos na primeira hora e, em seguida, a cada hora. Por exemplo:

DBCC SHRINKFILE for file ID 1 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.

Esta mensagem significa que as transações instantâneos com marcas temporais anteriores a 109 (a última transação concluída pela operação de encolhimento) estão bloqueando a operação de encolhimento. Ele também indica que o transaction_sequence_num, ou first_snapshot_sequence_num colunas no modo de exibição de gerenciamento dinâmico sys.dm_tran_ative_snapshot_database_transactions contém um valor de 15. Se a coluna de exibição transaction_sequence_num ou first_snapshot_sequence_num contiver um número menor do que a última transação concluída de uma operação de redução (109), a operação de redução aguardará a conclusão dessas transações.

Para resolver o problema, siga um dos seguintes passos:

• Encerre a transação que está bloqueando a operação de redução.
• Conclua a operação de redução. Qualquer trabalho concluído será mantido se a operação de redução terminar.
• 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 arquivo de dados para um tamanho de destino especificado

O exemplo a seguir reduz o tamanho de um arquivo de dados chamado DataFile1 no banco de dados de usuário UserDB para 7 MB.

USE UserDB;
GO

DBCC SHRINKFILE (DataFile1, 7);
GO

B. Reduzir um arquivo de log para um tamanho de destino especificado

O exemplo a seguir reduz o arquivo de log no banco de dados AdventureWorks2025 para 1 MB. Para permitir que o DBCC SHRINKFILE comando reduza o ficheiro, o ficheiro é primeiro truncado definindo o modelo de recuperação da base de dados para SIMPLE.

USE AdventureWorks2025;
GO

-- Truncate the log by changing the database recovery model to SIMPLE.
ALTER DATABASE AdventureWorks2025
    SET RECOVERY SIMPLE;
GO

-- Shrink the truncated log file to 1 MB.
DBCC SHRINKFILE (AdventureWorks2025_Log, 1);
GO

-- Reset the database recovery model.
ALTER DATABASE AdventureWorks2025
    SET RECOVERY FULL;
GO

C. Truncar um ficheiro de dados

O exemplo a seguir trunca o arquivo de dados primário no banco de dados AdventureWorks2025. A visualização do catálogo sys.database_files é consultada para obter a file_id do arquivo de dados.

USE AdventureWorks2025;
GO

SELECT file_id,
       name
FROM sys.database_files;
GO

DBCC SHRINKFILE (1, TRUNCATEONLY);

D. Esvaziar um ficheiro

O exemplo a seguir demonstra o esvaziamento de um arquivo para que ele possa ser removido do banco de dados. Para as finalidades deste exemplo, um arquivo de dados é criado primeiro e contém dados.

USE AdventureWorks2025;
GO

-- Create a data file and assume it contains data.
ALTER DATABASE AdventureWorks2025
    ADD FILE (NAME = Test1data, FILENAME = 'C:\t1data.ndf', SIZE = 5 MB);
GO

-- Empty the data file.
DBCC SHRINKFILE (Test1data, EMPTYFILE);
GO

-- Remove the data file from the database.
ALTER DATABASE AdventureWorks2025
     REMOVE FILE Test1data;
GO

E. Reduzir um arquivo de banco de dados com WAIT_AT_LOW_PRIORITY

O exemplo a seguir tenta reduzir o tamanho de um arquivo de dados no banco de dados de usuário atual para 1 MB. A visualização do catálogo sys.database_files é consultada para obter a file_id do ficheiro de dados, neste exemplo, file_id 5. Se um bloqueio não puder ser obtido dentro de um minuto, a operação de encolhimento será abortada.

USE AdventureWorks2025;
GO

SELECT file_id,
       name
FROM sys.database_files;
GO

DBCC SHRINKFILE (5, 1) WITH WAIT_AT_LOW_PRIORITY (ABORT_AFTER_WAIT = SELF);

Conteúdo relacionado

• Reduzir um banco de dados
• Reduzir um ficheiro
• DBCC SHRINKDATABASE (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.database_files (Transact-SQL)
• sys.databases (Transact-SQL)
• FILE_ID (Transact-SQL)
• ALTER DATABASE (Transact-SQL)
• Gerir o espaço de ficheiros para bases de dados na Base de Dados SQL do Azure