Posso alterar um banco de dados SQL ao vivo do Autogrow com segurança?

Question

Eu tenho um banco de dados ao vivo do SQL 2005, e estou na posição muito infeliz de ser o DBA involuntário.

O banco de dados tem um arquivo MDF de 1,4 GB e um LDF com 2,2 GB. O crescimento automático está definido para crescimento irrestrito em 10%. Eu tenho muito espaço em disco - então pensei que seria melhor definir o tamanho inicial para ser consideravelmente maior. Está crescendo rapidamente - dobrando de tamanho nos últimos 6 meses.

Posso apenas escolher um número alto (desde que eu tenha bastante espaço), e simplesmente alterar o Tamanho Inicial (talvez para 4.000 ou algo assim) - e então configurá-lo como uma verificação semanal para ter certeza de que não estamos dentro de alguns por cento deste número?

Obrigado.

    

Answer 1

Sim. Você pode aumentar o tamanho inicial do mdf e o SQL Server aumentará o arquivo para esse tamanho. É bastante seguro fazer isso em um banco de dados ao vivo, mas escolha um momento de tranquilidade! Você deve achar que o aumento de tamanho é muito rápido. Eu apenas desenvolvi um banco de dados de teste de 128MB para 4GB e levou 2 segundos.

Um tamanho inicial de 4 GB parece razoável, dado o tamanho atual do banco de dados. Se você tiver muito espaço em disco, por que não definir o crescimento para algo alto, por exemplo, 2GB ou até 4GB? Aumentar o banco de dados em grandes incrementos reduz a fragmentação física do arquivo mdf.

Você não precisa de uma verificação semanal, pois o SQL Server continuará aumentando o arquivo. Apenas certifique-se de não ficar sem espaço em disco.

JR

PS Acabei de ver a resposta de Aaron. Eu diferir dele em que eu não tenho nenhum problema com o crescimento automático do banco de dados. No entanto, você deseja definir os parâmetros de crescimento automático para evitar muitos pequenos aumentos. 10% é o padrão, e acho que é pequeno demais para a maioria dos bancos de dados.

PPS que o tamanho do log parece um pouco grande. O banco de dados está definido como "Registro completo" e, em caso afirmativo, tem certeza de que o banco de dados está sendo submetido a backup? Se o tamanho do arquivo de log ficar fora de controle, você poderá usar o "dbcc shrinkfile" para reduzi-lo. Veja os livros online para mais detalhes.

    

Answer 2

Quão oportuno - eu acabei de escrever uma postagem no blog sobre exatamente este assunto ontem - confira em Importância do gerenciamento de tamanho de arquivo de dados . Resumo:

• dimensione os arquivos de dados inicialmente para contabilizar o tamanho atual e, pelo menos, um ano de crescimento, se possível
• ative a inicialização instantânea do arquivo, se puder (observe: isso afeta apenas os arquivos de dados, os arquivos de log sempre precisam ser zerados)
• SEMPRE tem o crescimento automático ativado - eu discordo totalmente e sem reservas com qualquer um que diga o contrário. Ele deve estar sempre ligado para emergências quando o monitoramento falhar (a menos que o bug do SCOM esteja impedindo que você o tenha - veja o artigo para explicação)
• defina o crescimento automático para um tamanho adequado e fixo
• Não confie no crescimento automático. Monitore o uso de arquivos e cresça manualmente. Monitor para auto-crescimento acontecendo em emergências
• nunca, nunca encolha, se você puder evitá-lo. Meu blog tem um script que mostra o porquê.
• seu arquivo de log parece muito grande. Check-out esta outra postagem no blog Importância do gerenciamento adequado do tamanho do log de transações para algumas dicas e sugestões.

Espero que isso ajude!

    

Answer 3

aSkywalker, use The Force ou, alternativamente, dê uma olhada no artigo de Paul Randal para 'DBAs involuntários' aqui:

link