Plano de Manutenção do Sql Server - Práticas recomendadas em tarefas e agendamento

Tenho a tarefa de elaborar um plano de manutenção para nossos bancos de dados do Sql Server 2005. Sei que para backups, quero fazer um backup completo diário do banco de dados e backups de log transacional a cada 15 minutos. Meu problema consiste em descobrir quais outras tarefas eu quero executar e com que frequência devo executá-las.

Até agora, tenho isso em mente. Corrija-me se houver alguma falha no meu pensamento ou uma maneira melhor de fazer isso.

1. Backup - Todas as tabelas, backup completo (diariamente)
2. Backup - Tabelas Selecionadas, Backup Completo (a cada hora)
3. Backup - Logs de transação (a cada 15 minutos)
4. Verificar a integridade do banco de dados (diariamente)
5. Reorganizar o índice (diariamente)
6. Atualizar estatísticas (diariamente)
7. Encolher banco de dados (semanalmente)
8. Recriar índice (semanalmente)
9. Limpeza de manutenção (diária)

Lembrei-me de ter lido há algum tempo (quando montei um plano semelhante em outro trabalho) que algumas dessas tarefas não precisam ser executadas diariamente ou não devem ser executadas diariamente. Quanto a quais, isso me escapa. Eu poderia usar um pouco de orientação para criar um plano de manutenção melhor que reduza a perda de dados em um desastre, mas não taxe o sistema durante a execução nos horários de pico (e também aumente o desempenho).

Josh,

Essa é uma tarefa muito comum para todos os DBAs e a resposta correta NÃO é a mesma para todos e para cada servidor. Como muitas outras coisas, isso depende do que você precisa.

Definitivamente, você não deseja executar o "Shrink Database", como já sugerido. Seu mal desempenho e a referência abaixo mostrará o porquê. Isso causa fragmentação do disco e do índice e isso pode levar a problemas de desempenho. É melhor pré-alocar um tamanho grande para os arquivos de dados e log, para que o crescimento automático NÃO comece.

Eu não entendi o seu # 2. tabelas selecionadas backup completo. Você pode elaborar mais sobre isso?

Chegando ao Index, reorganize, atualize as estatísticas e reconstrua o índice, você precisará ter cuidado com o modo de fazer isso, caso contrário, você acabará usando mais recursos e também problemas de desempenho.

Quando você reconstrói índices, as estatísticas dos índices são atualizadas com o fullscan, mas se você atualizar as estatísticas depois disso, elas serão atualizadas novamente com uma amostra padrão (que depende de vários fatores, geralmente 5% da tabela quando o tamanho da tabela> 8 MB), o que pode levar a problemas de desempenho. Dependendo da edição que você possui, você poderá fazer recriações de índice online. A maneira correta de executar essa atividade é verificar a quantidade de fragmentação e, dependendo disso, a reconstrução do índice ou a reorganização do índice + as estatísticas de atualização. Além disso, convém identificar quais tabelas precisam atualizar as estatísticas com mais frequência e tentar atualizá-las com mais frequência.

Os planos de manutenção estão OK, mas é difícil tirar o máximo proveito deles fazendo essas personalizações, a menos que você possa fazer login no SSIS e ajustar os MPs. é por isso que prefiro NÃO usá-los e usar os scripts gratuitos de Ola Hallengren que são mais robustos que os MP. Além disso, eu recomendaria acompanhar o artigo referenciado por Paul Randal sobre este tópico.

Ref: http://technet.microsoft.com/en-us/magazine/2008.08.database.aspx

Esta NÃO é uma resposta abrangente para sua pergunta, mas um bom ponto de partida. HTH e deixe-nos saber se você tiver quaisquer perguntas / comentários adicionais.

Vou compartilhar minha experiência, mesmo se você já aceitou uma resposta. Talvez seja útil :-).

1. Backup diário completo (diário) - ótimo, mas não se esqueça de verificar se há espaço e remover arquivos antigos depois de um tempo predefinido.
2. Fazer backup de tabelas selecionadas (a cada hora) - não entendo por que você precisaria disso, é melhor optar por backups diferenciais. Como você faz backup apenas de determinadas tabelas: SSIS, scripts, bcp? Em relação aos backups diferenciais, não agende com muita frequência, pois você roubará a função de backups de log.
3. Backups de log de transações (a cada 15 minutos) - ótimo, você tem certeza de que precisa para todos os bancos de dados? Todos os bancos de dados usam o modelo de recuperação completa ou não?
4. Verifique a integridade do banco de dados - sim, mas você precisa ter certeza de que não mata seu ambiente. As instruções de verificação do DBCC são bastante egoístas nos recursos e examinam os dbs completos; portanto, precisam ser agendadas fora do horário de expediente.
5. Reorganize o índice (diariamente) - não force, faça-o apenas se necessário. Verifique os DMVs do índice em relação à fragmentação e reorganize apenas com base nas necessidades. Eu moveria todas as operações de índice e estatísticas em uma única tarefa semanal.
6. Atualizar estatísticas (diariamente) - Veja minha resposta a uma pergunta anterior. Em vez de apenas forçar a atualização de todas as estatísticas, todos os dias, é melhor verificar quando as estatísticas foram atualizadas por último e apenas em alguns casos atualizá-las.
7. Encolher banco de dados (semanalmente) - Oh, não. Por favor, leia o artigo de Paul Randal sobre a redução de arquivos.
8. Índice de reconstrução (semanalmente) - consulte 5.

9. Limpeza de manutenção (diária) - ok com isso.

10. É melhor também adicionar uma tarefa para verificar seus backups - existe uma versão do comando RESTORE (verifique somente. Se me lembro corretamente) - digamos semanalmente, embora prefira diariamente.

Você mencionou que deseja ser protegido em caso de perda de dados, portanto, seria necessário adicionar os bancos de dados do sistema neste procedimento de manutenção. E também tome cuidado para fazer backup dos arquivos em uma máquina diferente da do próprio servidor. Mantenha em algum lugar um arquivo com o que fazer, caso seja necessário reconstruir o mestre db, msdb..etc. Boa sorte com sua tarefa!

Resposta tardia, mas pode ser útil para outros leitores.

Lembre-se de que existem muitas tarefas de manutenção ou relatório, que você pode criar, que carregam riscos invisíveis associados a elas.

O que aconteceria quando uma unidade fosse preenchida durante backups diferenciais realizados diariamente? E se um trabalho de reconstrução de índice for longo demais? E se um processo de carregamento de dados causar contenção extensa de recursos, colocando as operações normais de joelhos? Todos esses são eventos planejados, mas podem causar perturbações consideráveis ​​nos mesmos processos que estamos tentando proteger.

Sempre considere como diferentes trabalhos interagem e cronometre-os para que não haja sobreposição em tarefas sensíveis ou com uso intenso de recursos.

Sugiro a leitura deste artigo primeiro: http://www.sqlshack.com/removing-the-risk-from-important-maintenance-tasks-in-sql-server/

Ele descreve como executar tarefas importantes de manutenção no SQL Server - sem riscos. Por exemplo - você pode criar verificações simples em seus trabalhos de manutenção para verificar os recursos disponíveis, bem como o que uma operação exigirá antes da execução. Isso permite garantir que seu ambiente possa lidar com o que você está prestes a fazer e abortar com um erro significativo se os recursos forem inadequados.

1. Parece bom

2. Você pode se beneficiar de fazer backups diferenciais aqui. Olhe para eles com certeza

3. Parece bom

4. Parece bom

5. Como afirmado anteriormente, os encolhimentos do banco de dados são ruins porque criam uma fragmentação física de seus dados e arquivos de log, causando mais leituras aleatórias de E / S.

5, 6 e 8: Veja a seguir.

Eles realmente andam de mãos dadas, pois os índices se baseiam em estatísticas atualizadas e a ordem dessas operações é bastante importante. O método de linha de base que eu emprego, que reconhecidamente pode não funcionar para todos, é que eu execute duas rodadas de manutenção de índice. Primeiro, faço os índices em cluster e depois os índices não clusterizados. O método empregado para ambos é o seguinte. Se um índice for grande o suficiente e fragmentado o suficiente (sys.dm_db_index_physical_stats), reconstruirei o índice (que inclui uma atualização de estatísticas com varredura completa). Se um índice for muito pequeno para uma reconstrução ou não for suficientemente fragmentado para uma reconstrução (menos de 100 páginas e entre 5% e 15% de fragmentação), primeiro executarei uma reorganização do índice. Em seguida, executarei uma atualização de estatísticas com verificação completa.

Agora, isso cobre as estatísticas do índice, mas deixa de fazer qualquer coisa para colocar as estatísticas da coluna. Semanalmente, atualizarei as estatísticas da coluna.

Espero que isso tenha ajudado de alguma forma!

Inclinei seu comentário sobre "a perda de dados pode ter implicações legais aqui".

Então, você definitivamente deseja obter uma poderosa ferramenta de terceiros (como DPM) que pode lidar com backups (e se recuperar de eventos catastróficos em um flash e com um mínimo de confusão) muito mais rápido e muito melhor do que qualquer script que você possa acessar a Internet.

Ter backups é uma coisa. Saber usá-los em uma emergência é outra.

Não se esqueça de que, se você estiver prestes a restaurar um backup após uma falha grave, provavelmente já estará sob uma carga de estresse e pressão. Você não precisa do encargo adicional de desenterrar e escrever perfeitamente a instrução RESTORE DATABASE com 12 arquivos de log de transações ... E rezar para que isso não falhe ...

No meu local de trabalho, posso recuperar / restaurar um banco de dados de 350 GB em qualquer ponto dentro de um período de 5 minutos da última semana usando o DPM. Com uma interface gráfica. Vale a pena, no meu livro.

De resto, analise definitivamente o script de índice de Ola Hallengren e ajuste os parâmetros às suas necessidades. Pessoalmente, juntei-o a uma tarefa agendada que o executa por uma hora a cada noite sem redigitalização, para que ele lide com os piores índices todas as vezes e forço uma redigitalização completa da fragmentação todos os sábados ou quando todos os índices da lista foram desfragmentados.

Por fim, adiciono minha voz ao grupo "não encolha seus arquivos automaticamente, nunca". O Encolhimento de arquivo é apenas uma ferramenta a ser usada esporadicamente quando ocorre um evento irregular que sobrecarrega seus logs ou arquivos de banco de dados (loop infinito ou algo semelhante). Não é para ser uma ferramenta de manutenção. Se você tiver pressão no espaço em disco, a redução só atrasará o inevitável.