Corretamente configurados, os planos de manutenção permitirão que o SQL mantenha o alto desempenho, mesmo durante períodos de forte utilização do produto.
Verificação de integridade (Integrity Checks)
As verificações de integridade devem ser feitas pelo menos semanalmente, antes da execução de um backup completo. Isso impedirá que os backups ocorram após alguma corrupção do banco de dados, solicitando a intervenção do DBA.
Reorganização de índices (Index Reorg)
À medida que os índices crescem, se tornam mais fragmentados. Configurar a reorganização fará com que o SQL Server desfragmente esses índices. Tal processo faz baixo uso de recursos do Windows e pode ser usado com o índice online, permitindo que SELECTs sejam executados concomitantemente ao reorg.
A reorganização do índice deve ser avaliada pelo DBA considerando o nível de fragmentação existente. Isso será ainda mais necessário se existir um número maior de alterações em dados das tabelas. Geralmente é executado semanalmente ou mensalmente.
Reconstrução de índices (Index Rebuild)
A reconstrução do índice faz com que o SQL Server descarte o índice existente, recupere os recursos alocados e, em seguida, recrie as páginas de forma contígua. Esta é uma operação mais intensiva de recursos que alcança um resultado semelhante à reorganização de índice, de forma mais rápida e segura.
A reconstrução do índice deve ser avaliada pelo DBA considerando o nível de fragmentação presente. Isso também será ainda mais necessário se você tiver um número maior de alterações em dados das tabelas. Geralmente é executado semanalmente ou mensalmente, caso haja uma janela viável de indisponibilidade para as aplicações.
Estatísticas
O otimizador do SQL Server usa estatísticas de tabelas e índices para orientar suas decisões sobre o plano de execução adequado para cada consulta. Se as estatísticas ficarem desatualizadas, índices melhores que gerariam tempos de consulta mais rápidos não poderão ser usados.
Dependendo da frequência com que seus dados são alterados, você deve reconstruir as estatísticas com seu plano de manutenção. Essa rotina deve ser diária para sistemas em que há alterações significativas no conteúdo da tabela e semanalmente se os dados forem praticamente constantes.
Redução do banco de dados (Database Shrink)
Os planos de manutenção não devem executar operações de redução de banco de dados. Encolhê-lo liberará espaço em disco e obrigará o SQL Server a aumentar os mesmos arquivos posteriormente. Com o tempo, isso resultará em fragmentação de grande escala. Quando necessário, o DBA deverá avaliar o espaço livre do banco de dados e realizar uma operação de redução manual. Após essas operações, é recomendável reconstruir seus índices e atualizar as estatísticas.
Backup do SQL Server
O SQL Server impõe algumas restrições ao tipo de backups disponíveis para você, dependendo de qual banco de dados você esteja utilizando. É uma boa prática ter planos de manutenção separados para bancos de dados do sistema e bancos de dados de aplicações. Isso permite ajustar cada plano de manutenção às necessidades específicas. Também evita que um plano de manutenção falhe para um banco de dados e não seja executado para os demais. O banco de dados master é fundamental para os procedimentos de recuperação e é recomendável que você mantenha um plano de backup separado somente para ele.
Se houver um número elevado de transações por dia, um backup diferencial pode ser recomendado, uma vez que isso pode fornecer um tempo de recuperação menor e mais rápido.
Podemos considerar também backups de log de transações mais frequentes, assim a perda de dados tenderá a ser menor em caso de falha, uma vez que existem backups mais recentes.
Nossa recomendação para as rotinas de backup estão abaixo:
| Tipo de Bancos de Dados | Backup Recomendado – Estratégia Geral |
|---|---|
| Master | Backup Full semanal, backup de log diário. |
| Model e Msdb | Backup Full semanal e backup de log diário. |
| Outros bancos de dados de suas aplicações | Backup Full diário e backup de log de hora em hora. |
