24x7 vs Janela Noturna

A manutenção de bancos de dados 24 horas por dia, 7 dias por semana é um tópico bastante amplo com muitas opções a serem consideradas. Este tópico amplo tem muitos itens a serem considerados, mas podemos tentar tocar na base de alguns dos pontos altos.

O que você primeiro deseja identificar é que, embora muitas operações sejam 24 horas por dia, 7 dias por semana, geralmente há momentos de baixa atividade. Você pode aproveitar esses tempos para executar sua manutenção para reduzir a interferência que terá no banco de dados. A segunda é que você precisará reservar algum tempo para interrupções completas (para itens como service packs ou migrações de banco de dados), portanto, precisará negociar janelas de manutenção completas com seu gerenciamento. Para itens específicos, você precisará considerar e planejar cada um deles, bem como aproveitar suas ferramentas adequadamente. A parte importante é que você deve PLANEJAR cada um deles, todos os exemplos que forneço são muito "suas milhas podem variar".

backups

Normalmente, os backups não têm grande impacto nas cargas de trabalho, mas devem ser considerados, pois podem consumir muita E/S. Você deve agendá-los adequadamente e monitorar o tempo que leva para concluí-los. O maior obstáculo aqui é que em uma operação 24 horas por dia, 7 dias por semana, você provavelmente não conseguirá realizar backups noturnos completos todas as noites da semana. Você deve planejar quando pode fazer fulls, quando está fazendo diferenciais e períodos de retenção para ambos em combinação com seus backups de log.

Por exemplo, executo backups completos de todos os meus bancos de dados no domingo à noite (menor atividade), diferenciais em todas as outras noites (segunda a sábado). Eu mantenho as últimas duas semanas de fulls e diffs no disco, logs dos últimos dois dias. Isso me dá flexibilidade suficiente para recuperação, mas talvez seja necessário recuperar backups da fita, se necessário.

Manutenção de índices/estatísticas

Este é o tipo mais comum de manutenção ativa com a qual você terá que lidar. Você não pode evitá-lo, mas pode mitigar o impacto. A regra inicial é que você só deve fazer manutenção em objetos que precisam dela. As diretrizes gerais são apenas reconstruir índices com mais de 30% de fragmentação e mais de 1.000 páginas . Se você tiver estatísticas de atualização automática , isso cuidará da maior parte da manutenção de suas estatísticas, mas um trabalho noturno para manter as coisas sincronizadas não é uma má ideia.

Se você tiver o Enterprise Edition, também terá acesso a algumas outras opções para gerenciar a manutenção. O principal é o Online Index Rebuilds , que permitirá que você reconstrua índices enquanto eles ainda estão em uso (essencialmente, ele cria o índice lado a lado e depois o troca). Você também pode aproveitar o particionamento para tabelas "grandes" para reduzir o tempo de reconstrução necessário.

Sua melhor aposta para esse tipo de manutenção, se você não tiver scripts personalizados que lidem com essas práticas recomendadas, é usar os scripts de manutenção de Ola Hallengren . Eles são bastante fáceis de instalar e configurar e possuem muitas dessas diretrizes incorporadas.

Verificações de consistência DBCC

Dependendo de sua carga de trabalho geral, você pode achar que as verificações DBCC são muito prejudiciais para sua operação. Há duas maneiras comuns de minimizar o impacto do DBCC em seus bancos de dados:

• PHYSICAL_ONLY- Executar esta opção verificará seus bancos de dados em um nível de página física e evitará a verificação completa mais invasiva. Isso cobrirá a identificação dos tipos mais prováveis ​​de corrupção.
• Verificando uma cópia restaurada - Se você tiver espaço, poderá restaurar o banco de dados em outra instância e executar uma verificação DBCC na cópia restaurada. Isso contará a mesma história sobre seu banco de dados ativo, mas obviamente você não interferirá na atividade. Algumas outras alternativas aqui estão executando o DBCC em uma cópia enviada de log ou em um banco de dados espelhado.

Esta postagem no blog fornece mais detalhes sobre suas opções.

Trabalhos em lote/ETL

Isso realmente se resume a como você projeta seus processos. Seu ETL sempre pode interferir nas tabelas OLTP ao vivo (assim como qualquer outro aplicativo), portanto, algumas chaves devem ser lembradas:

• Programe esse trabalho em torno de sua outra manutenção e em períodos de baixa atividade.
• Dimensione corretamente o trabalho para que seja agrupado para desempenho e para que o lote não seja tão grande que bloqueie sua mesa por horas. Exemplos das extremidades do espectro: Row-by-agonizing-row (RBAR) versus exclusão de um único milhão de linhas.
• Use tabelas de estágio e processamento de dados off-line quando apropriado. Só toque no material ao vivo quando for absolutamente necessário.

Conclusão

Novamente, há muito terreno a cobrir aqui. Este não é um guia abrangente, mas uma visão geral de alto nível de algumas abordagens. Eu nem discuti as opções de alta disponibilidade (como Grupos de Disponibilidade e Clustering de Failover). Você precisará revisar cada item e elaborar um plano de como lidar com isso. De muitas maneiras, você também precisará iterar e refinar seu trabalho à medida que avança.

Recursos adicionais:

Práticas recomendadas de manutenção do SQL Skills VLDB