Sql Server - Práticas recomendadas para o crescimento de arquivos de banco de dados

Eu tenho monitorado o crescimento de arquivos por meio do coletor de dados no sql server 2008 r2 por duas semanas. O banco de dados cresce constantemente em torno de 35 (MB) / dia. O banco de dados ainda não atingiu o tamanho inicial de 2 GB.

O crescimento automático dos arquivos de banco de dados está definido como 5 MB e eu gostaria de tentar uma abordagem diferente, por isso estou procurando sugestões e / ou comentários.

Há uma tarefa de ajuste que é executada todas as semanas no domingo à noite às 01:30. A tarefa irá:

• Verificar integridade do banco de dados
• Reduzir o arquivo de log - (isso é bom porque o modo de log é simples)
• Encolher banco de dados
• Reorganizar o índice
• Índice de reconstrução
• Atualizar estatísticas
• Limpar histórico

Gostaria de adicionar mais duas etapas ao plano de ajuste semanal:

1. Aumente o arquivo do banco de dados em 500 MB se o espaço usado atingir um determinado limite ou tamanho total.
2. Aumente o arquivo de log em 250 MB (após a redução) se o espaço usado atingir um determinado limite do tamanho total.

Ao colocar a carga de crescimento em horas off-line, espero obter desempenho reduzindo o número de eventos de crescimento automático durante cargas pesadas.

Tenho duas perguntas relacionadas aos arquivos de crescimento automático.

• O melhor local para colocar as etapas de crescimento do arquivo seria antes ou depois das etapas atuais?
• Se eu usar o ALTER DATABASE|MODIFY FILEpara aumentar o arquivo, como posso determinar se SpaceUsedInFile >= (TotalFileSpace-@AllowanceThreshold)?

Você deve ter como objetivo crescer automaticamente o mínimo possível. Sete vezes por dia é torturante, mesmo com a inicialização instantânea de arquivos.

Não faça um banco de dados de redução. Sempre. Arquivo de encolhimento, talvez, mas somente após um evento extraordinário. Encolher apenas para crescer novamente é um exercício de futilidade e deve ser chamado de auto-fragmento.

Se o modelo de recuperação for simples, não há como você precisar aumentar seu arquivo de log em 250 GB. O espaço usado no arquivo se limpará automaticamente com o tempo, a menos que você tenha iniciado uma transação há um mês e não tenha nenhuma intenção de confirmá-la ou revertê-la.

Então, meu conselho seria:

Aumente automaticamente o arquivo de dados manualmente durante um período silencioso para um tamanho que acomodará vários meses de crescimento. Por que você está salvando isso enquanto isso?

Defina o incremento de crescimento automático para o arquivo de dados como algo relativamente pequeno (para que ele não interrompa os usuários quando isso acontecer) e alerta sobre esse evento (você pode capturá-lo no rastreamento padrão, por exemplo, ou por meio de extensão eventos). Isso pode lhe dizer que você está atingindo o ponto alto estimado e que é hora de crescer manualmente novamente. Nesse ponto, você desejará manter este manual caso queira adicionar um novo arquivo / grupo de arquivos em uma unidade diferente para acomodar o espaço, pois, eventualmente, você preencherá a unidade atual.

Aumente automaticamente o arquivo de log para, digamos, o dobro do maior já registrado. Não deve crescer automaticamente, a menos que haja alguma transação anormal sustentando as coisas. Você deve monitorar esse evento também, para que você saiba sobre eles.

O crescimento automático é algo que você deve tentar evitar, se possível. O problema é que você não tem controle sobre quando o crescimento pode ocorrer e seu sistema pode sofrer um sério golpe enquanto isso ocorre.

Defina o tamanho do arquivo como algo sensato por um mês ou mais e monitore sua taxa de crescimento a partir daí, calcule quanto espaço você estima para X por um período de tempo e defina seu tamanho para isso + uma margem de erro.

Eu configurei um trabalho de monitoramento simples que me alertará quando o tamanho do arquivo atingir um máximo predefinido antes do crescimento automático. Você poderia usar algo como isto:

SELECT instance_name,
       [Data File(s) Size (KB)],
       [LOG File(s) Size (KB)],
       [Log File(s) Used Size (KB)],
       [Percent Log Used]
       into ##Logsize
FROM
(
   SELECT *
   FROM sys.dm_os_performance_counters
   WHERE counter_name IN
   (
       'Data File(s) Size (KB)',
       'Log File(s) Size (KB)',
       'Log File(s) Used Size (KB)',
       'Percent Log Used'
   )
     AND instance_name = 'database your interested in' 
) AS Src
PIVOT
(
   MAX(cntr_value)
   FOR counter_name IN
   (
       [Data File(s) Size (KB)],
       [LOG File(s) Size (KB)],
       [Log File(s) Used Size (KB)],
       [Percent Log Used]
   )
) AS pvt 
go
declare @logsize int
Select @logsize = [Percent Log Used] from ##Logsize

If @logsize > the maximum percent you want the log to fill too i.e 90
    BEGIN
        --Do your thing here
    END

Drop table ##Logsize

Obviamente, isso poderia ser agendado como um trabalho.