É seguro ter o encolhimento automático do SQL Server ativado?

Há muitas opções do SQL Server que podem ser ativadas para bancos de dados, e uma das mais incompreendidas é a redução automática. É seguro? Se não, por que não?

(Originalmente fiz uma pergunta regular, mas depois descobri o método correto - obrigado BrentO)

Não nunca.

Eu já me deparei com isso várias vezes agora no ServerFault e quero alcançar um público amplo e agradável com alguns bons conselhos. Se as pessoas desaprovam essa maneira de fazer as coisas, votem negativamente e eu removerei isso com prazer.

A redução automática é uma configuração muito comum do banco de dados a ser ativada. Parece uma boa idéia - remova o espaço extra do banco de dados. Existem muitos 'DBAs involuntários' por aí (pense em TFS, SharePoint, BizTalk ou apenas o SQL Server antigo comum) que podem não saber que a redução automática é positivamente ruim.

Na Microsoft, eu era o proprietário do SQL Server Storage Engine e tentei remover o recurso de redução automática, mas ele tinha que ficar para compatibilidade com versões anteriores.

Por que o encolhimento automático é tão ruim?

É provável que o banco de dados cresça novamente, então por que reduzi-lo?

1. Shrink-grow-shrink-grow causa fragmentação no nível do sistema de arquivos e consome muitos recursos.
2. Você não pode controlar quando ele entra em ação (mesmo que seja normal)
3. Ele usa muitos recursos. Mover páginas pelo banco de dados requer CPU, muita IO e gera muito log de transações.
4. Aqui está o verdadeiro kicker: o encolhimento do arquivo de dados (automático ou não) causa fragmentação maciça de índice, o que leva a um desempenho ruim.

Eu fiz um post de blog há um tempo atrás, que tem um exemplo de script SQL que mostra os problemas que ele causa e explica com mais detalhes. Consulte Encolhimento automático - DESLIGUE! (sem publicidade ou lixo eletrônico no meu blog). Não confunda isso com a redução do arquivo de log, que é útil e necessário ocasionalmente.

Então, faça um favor a si mesmo - procure nas configurações do banco de dados e desative a redução automática. Você também não deve ter encolhimento em seus planos de manutenção, exatamente pelo mesmo motivo. Espalhe a notícia para seus colegas.

Editar: devo acrescentar isso, lembrado pela segunda resposta - há um equívoco comum de que interromper uma operação de redução pode causar corrupção. Não, não vai. Eu costumava possuir o código de redução no SQL Server - ele reverte a mudança de página atual que está fazendo se for interrompida.

Espero que isto ajude!

É claro que Paulo está certo.

Veja todos os bancos de dados e suas configurações de autoshrink. Se você tiver muitos bancos de dados, um deles entrará furtivamente.

sp_msforeachdb  @command1 = 'Select ''[?]'',DATABASEPROPERTYEX(''?'',''IsAutoShrink'')'

Isso está no dmv em algum lugar .... eu me pergunto.

Não é "inseguro" - não danifica nada.

Mas isso não é recomendado para ambientes de produção em que o banco de dados pode decidir sair e iniciar um exercício de reorganização caro pouco antes de uma pilha de solicitações chegar, fazendo com que essas solicitações demorem mais para serem atendidas. É muito melhor usar o agendamento de operações de redução, juntamente com outras operações de manutenção, como backups (na verdade, após os backups - serão mais do log de transações dessa maneira). Ou simplesmente não encolhe, a menos que haja um problema de crescimento - você sempre pode configurar um monitor para saber quando o espaço alocado não utilizado cresce além de uma determinada proporção ou tamanho fixo.

IIRC, a opção está desativada por padrão para todos os bancos de dados em todas as edições do MSSQL, exceto o Express.

Há um documento técnico disponível no TechNet que explica a manutenção do SQL em mais detalhes.

http://technet.microsoft.com/en-us/library/cc262731.aspx

Eu já vi um servidor SQL com o Autogrow e o Autoshrink ativados. Esse servidor (relativamente poderoso) era terrivelmente lento, porque tudo o que fazia o dia inteiro era diminuir e aumentar os arquivos do banco de dados. O autoshrink pode ser útil, mas recomendo duas coisas:

1. Desative o Autoshrink por padrão.
2. Documente as configurações do servidor para saber onde o Crescimento Automático e o Autoshrink estão ativados e onde não estão.

A única vez que fui forçado a reduzir um banco de dados foi atualizar uma cópia em um servidor de teste com menos espaço em disco (insuficiente para armazenar o banco de dados de produção).

Os arquivos do banco de dados de produção tinham um espaço livre generoso; infelizmente, você precisa restaurar um banco de dados com os mesmos tamanhos de arquivo dos quais você fez backup. Portanto, não tivemos escolha a não ser diminuir a produção antes de fazer o backup. (A redução levou séculos, muitos recursos foram consumidos e o crescimento subsequente do log de transações foi problemático.)

Confira também este vídeo tutorial ....

Assista a Paul Randal demonstrar como o encolhimento e o encolhimento automático podem causar sérios problemas de fragmentação ao seu banco de dados http://wtv.watchtechvideos.com/topic194.html