DBCC SHRINKDATABASE (Transact-SQL)

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.

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.

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

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

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);