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

44

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?

Paul Randal
fonte

Respostas:

70

(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!

Paul Randal
fonte
Existe uma maneira de você voltar a indexar logo após um psiquiatra?
Lance Roberts
4
Não reindexar, porque isso aumentará o arquivo novamente (cria novo índice antes de abandonar o antigo), mas a reorganização (através do meu antigo DBCC INDEXDEFRAG ou do novo ALTER INDEX ... REORGANIZE) resolverá a fragmentação, às custas de mais IO, cpu, registro ...
Paul Randal
Notei que depois de remover o autoshrink, o uso de memória do srrver é maior.
User193655
4

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

Sam
fonte
2
sys.databases tem uma is_auto_shrink campo (e is_auto de perto, is_auto_update_stats, etc)
Paul Randal
im maravilhoso pesquisando: como é que eu tenho um relatório nos ajudar a saber qual DBS configurado como autoshrink e seu código de boa execução e gerar um bom relatório de todo db para nós
sabre tabatabaee Yazdi
2

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.

David Spillett
fonte
2
Os psiquiatras não devem ser agendados - devem ser operações realmente raras devido aos problemas que causam. Não entendo o seu comentário sobre a redução após o backup - os registros de log gerados pela operação de redução serão selecionados pelo próximo backup do log de transações, independentemente de quando você faz ou de outros backups. Obrigado
Paul Randal
1

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

Jeremy Thake
fonte
Infelizmente, esse documento técnico é destinado apenas às instalações do SharePoint e, na verdade, possui alguns erros. Passei um tempo ensinando a classe atual do MCM do SharePoint com o autor do documento, Bill Baer.
Paul Randal
3
Uma boa introdução geral à manutenção de banco de dados está no meu artigo da TechNet Magazine sobre o assunto Manutenção Efetiva de Banco de Dados - technet.microsoft.com/en-us/magazine/cc671165.aspx .
Paul Randal
1

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.
Carl C
fonte
1

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

SuperCoolMoss
fonte
1

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

Sakthivel Chidambaram
fonte