DBCC SHRINKDATABASE (Transact-SQL)
Reduz o tamanho dos arquivos de dados e de log do banco de dados especificado.
.gif "Ícone de vínculo de tópico")
Sintaxe
DBCC SHRINKDATABASE
( database_name | database_id | 0
[ , target_percent ]
[ , { NOTRUNCATE | TRUNCATEONLY } ]
)
[ WITH NO_INFOMSGS ]
Argumentos
database_name | database_id | 0
É o nome ou a ID do banco de dados a ser reduzido. Se 0 for especificado, será usado o banco de dados atual.target_percent
É a porcentagem de espaço livre que você se deseja deixar no arquivo de banco de dados após a redução do banco de dados.NOTRUNCATE
Compacta os dados dos arquivos de dados, movendo as páginas alocadas do final de um arquivo para as páginas alocadas à frente do arquivo. target_percent é opcional.O espaço livre final do arquivo não é devolvido ao sistema operacional e o tamanho físico do arquivo não é modificado. Portanto, quando NOTRUNCATE é especificado, o banco de dados parece não ter sido reduzido.
NOTRUNCATE só é aplicável a arquivos de dados. Os arquivos de log não são afetados.
TRUNCATEONLY
Libera todo o espaço livre no final do arquivo para o sistema operacional, mas não executa nenhuma movimentação de página dentro do arquivo. O arquivo de dados só é reduzido até a última extensão alocada. target_percent será ignorado se especificado com TRUNCATEONLY.TRUNCATEONLY só é aplicável a arquivos de dados. Os arquivos de log não são afetados.
WITH NO_INFOMSGS
Suprime todas as mensagens informativas com níveis de severidade de 0 a 10.
Conjuntos de resultados
A tabela a seguir descreve as colunas do conjunto de resultados.
Nome da coluna |
Descrição |
|---|---|
DbId |
Número de identificação de 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. Corresponde ao tamanho mínimo ou tamanho de criação inicial de um arquivo. |
UsedPages |
Número de páginas de 8 KB usado atualmente pelo arquivo. |
EstimatedPages |
Número de páginas de 8 KB a que o Mecanismo de Banco de Dados calcula que o arquivo poderia ser encolhido. |
.gif "Observação") Observação |
|---|
O Mecanismo de Banco de Dados não exibe linhas para esses arquivos não reduzidos. |
Comentários
Para reduzir todos os arquivos de dados e de log de um banco de dados específico, execute o comando DBCC SHRINKDATABASE. Para reduzir um arquivo de dados ou de log por vez de um banco de dados específico, execute o comando DBCC SHRINKFILE.
Para visualizar 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, sendo preservado todo o trabalho concluído.
O banco de dados não pode se tornar menor que o tamanho mínimo do banco de dados. O tamanho mínimo é aquele especificado durante a criação inicial do banco de dados ou o último tamanho explicitamente definido por meio de uma operação de alteração de tamanho de arquivo, como DBCC SHIRNKFILE ou ALTER DATABASE. Por exemplo, se um banco de dados foi criado originalmente com um tamanho de 10 MB e atingir 100 MB, a redução máxima desse banco de dados será para 10 MB, mesmo se todos os dados do banco de dados forem excluídos.
Executar DBCC SHRINKDATABASE sem especificar a opção NOTRUNCATE ou a opção TRUNCATEONLY equivale a executar uma operação DBCC SHRINKDATABASE com NOTRUNCATE seguida de uma operação DBCC SHRINKDATABASE com TRUNCATEONLY.
O banco de dados que é reduzido não tem que estar em modo do usuário único; outros usuários podem trabalhar nele durante sua redução. Isto inclui os bancos de dados do sistema.
Não é possível reduzir um banco de dados enquanto um backup estiver sendo feito. Da mesma forma, não é possível fazer backup de um banco de dados enquanto houver uma operação de redução em processamento.
Como DBCC SHRINKDATABASE funciona
O DBCC SHRINKDATABASE reduz arquivos de dados individualmente, porém reduz arquivos de log como se todos esses arquivos existissem em uma série de logs contíguos. Os arquivos são sempre reduzidos do final.
Suponha um banco de dados denominado mydb, com um arquivo de dados e dois arquivos de log. Os arquivos de dados e de log tem 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 designado. Trata-se do tamanho a que se pretende chegar após a redução do arquivo. Quando DBCC SHRINKDATABASE é especificado com target_percent, o Mecanismo de Banco de Dados calcula o tamanho designado como a target_percent de espaço livre no arquivo após a redução. Por exemplo, se você especificar um target_percent de 25 para a redução do mydb, o Mecanismo de Banco de Dados calculará o tamanho designado 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.
Suponha que o arquivo de dados do mydb contenha 7 MB de dados. Especificar uma target_percent de 30 permitirá que ele seja reduzido pela porcentagem de 30% de espaço livre. Contudo, especificar uma target_percent de 40 não reduzirá ainda mais o arquivo de dados, pois o Mecanismo de Banco de Dados não irá reduzir um arquivo até um tamanho menor do que o espaço atualmente ocupado pelos dados. Você também pode pensar neste assunto outro modo: um arquivo de dados com 40 por cento de espaço livre desejado + 70 por cento de espaço cheio de dados (7 MB de 10 MB) dá mais que 100 por cento. Como a porcentagem livre que se deseja somada à porcentagem atual ocupada pelo arquivo de dados ultrapassa 100 por cento (em 10 por cento), qualquer valor de target_size superior a 30 não irá reduzir o arquivo de dados.
Para arquivos de log, o Mecanismo de Banco de Dados usa target_percent para calcular o tamanho designado para o log inteiro; sendo assim, target_percent será a quantidade de espaço livre 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 seu tamanho designado. Se nenhuma parte do log lógico residir nos logs virtuais além do tamanho designado do arquivo de log, o arquivo será truncado com êxito e DBCC SHRINKDATABASE terminará sem nenhuma mensagem. No entanto, se parte do log lógico residente nos logs virtuais for maior que o tamanho designado, o Mecanismo de Banco de Dados liberará o espaço disponível possível e emitirá uma mensagem informativa. A mensagem descreverá que ações são necessárias para mover o log lógico dos logs virtuais ao término do arquivo. Depois que as ações forem executadas, DBCC SHRINKDATABASE poderá ser usado para liberar o espaço restante. Para obter mais informações, consulte Reduzindo o log de transações.
Como um arquivo de log poderá ser reduzido somente a um limite de arquivo de log virtual, talvez não seja possível reduzir um arquivo de log para um tamanho menor que o tamanho de um arquivo de log virtual, mesmo que o arquivo não esteja sendo usado. O tamanho do arquivo de log virtual é definido dinamicamente pelo Mecanismo de Banco de Dados quando os arquivos de log são criados ou estendidos. Para obter mais informações sobre arquivos de log virtuais, consulte Arquitetura física de log de transações.
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 muito espaço não utilizado, como operações que truncam ou excluem uma tabela.
A maioria dos bancos de dados exige algum espaço livre disponível para operações comuns rotineiras. Se você reduzir um banco de dados repetidamente e perceber que ele aumentou novamente, isso indica que o espaço reduzido é necessário para as operações rotineiras. Nesse caso, reduzir repetidamente um banco de dados é uma operação inútil.
Uma operação de redução não preserva o estado de fragmentação de índices do banco de dados e, geralmente, aumenta o nível de fragmentação. Essa é outra razão para não reduzir o banco de dados repetidamente.
A menos que você tenha um requisito específico, não defina a opção de banco de dados AUTO_SHRINK como ON.
Solucionando problemas
É possível que operações de redução sejam bloqueadas por uma transação que está sendo executada em um nível de isolamento de controle de versão de fila. Por exemplo, se uma grande operação de exclusão estiver sendo executada em um nível de isolamento de controle de versão de linha quando uma operação DBCC SHRINK DATABASE for executada, a operação de redução aguardará a operação de exclusão ser concluída antes de reduzir os arquivos. Quando isso acontece, as operações DBCC SHRINKFILE e DBCC SHRINKDATABASE emitem uma mensagem informativa (5202 para SHRINKDATABASE e 5203 para SHRINKFILE) para o 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.
Significa que a operação de redução foi bloqueada por transações de instantâneo que têm carimbos de data/hora anteriores a 109, que é a última transação concluída pela operação de redução. Também indica que as colunas transaction_sequence_num ou first_snapshot_sequence_num na exibição de gerenciamento dinâmico sys.dm_tran_active_snapshot_database_transactions (Transact-SQL) contém um valor de 15. Se as colunas transaction_sequence_num ou first_snapshot_sequence_num da exibição contiverem um número menor que o da última transação concluída por uma operação de redução (109), a operação de redução aguardará a finalização dessas transações.
Para solucionar o problema, você pode executar uma destas tarefas:
Encerrar transação que está bloqueando a operação de redução.
Encerrar a operação de redução. Todo 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.
Para obter mais informações sobre o log de erros do SQL Server, consulte Exibindo o log de erros do SQL Server.
Permissões
Requer associação à função de servidor fixa sysadmin ou à função de banco de dados fixa db_owner.
Exemplos
A. Reduzindo um banco de dados e especificando uma porcentagem de espaço livre
O exemplo a seguir diminui 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. Truncando um banco de dados
O exemplo a seguir reduz os arquivos de dados no banco de dados de exemplo AdventureWorks até a última extensão alocada.
DBCC SHRINKDATABASE (AdventureWorks, TRUNCATEONLY);
Consulte também