Janela 24x7 vs Noite

Onde posso encontrar recursos sobre como mudar melhor para uma operação 24x7? Como as grandes empresas com grandes bancos de dados conseguem isso? Nossos trabalhos noturnos, como

1. limpar dados antigos
2. reindexar
3. atualizar estatísticas

tudo parece causar impacto crítico ao nosso sistema ( ou seja, feeds de dados. usuários online e em tempo real). Procurei na Amazon qualquer livro relacionado a esse assunto e até agora não encontrei nada.

Manter bancos de dados 24x7 é um tópico bastante amplo, com muitas opções a serem consideradas. Esse tópico amplo tem muitos itens a serem considerados, mas podemos tentar abordar alguns dos pontos altos.

O que você primeiro deseja identificar é que, embora muitas operações sejam 24x7, geralmente há momentos de baixa atividade. Você pode aproveitar esses tempos para executar sua manutenção, para reduzir a interferência que você terá no banco de dados. O segundo é que você precisará reservar algum tempo para interrupções completas (para itens como service packs ou migrações de banco de dados), portanto, será necessário negociar janelas de manutenção completas com seu gerenciamento. Para itens específicos, você precisará considerar e planejar cada um deles, além de alavancar suas ferramentas adequadamente. O ponto importante é que você PLANEJA cada um desses exemplos. Todos os exemplos que eu fornecer são muito "suas milhas podem variar".

Backups

Os backups geralmente não terão um grande impacto nas cargas de trabalho, mas devem ser considerados, pois podem consumir muita E / S. Você desejará agendá-las adequadamente e monitorar o tempo necessário para concluir. O maior obstáculo aqui é que, em uma operação 24x7, você provavelmente não poderá realizar backups noturnos completos todas as noites da semana. Você desejará planejar quando poderá obter os totais, os diferenciais e os períodos de retenção para ambos em combinação com os backups de log.

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

Índice / Manutenção Estatística

Esse é 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 geral é que você deve fazer manutenção apenas nos objetos que precisam. As diretrizes gerais são para reconstruir apenas índices maiores que 30% fragmentados e maiores que 1000 páginas . Se você tiver estatísticas de atualização automática , isso cuidará da maior parte de sua manutenção de estatísticas, mas um trabalho noturno para manter as coisas sincronizadas não é uma má idéia.

Se você possui o Enterprise Edition, também tem acesso a outras opções para gerenciar a manutenção. O primeiro é o Online Index Rebuilds , que permitirá que você reconstrua os índices enquanto eles ainda estiverem 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 a quantidade de tempo de reconstrução necessária.

Sua melhor aposta para esse tipo de manutenção, se você não possui scripts personalizados que lidam com essas práticas recomendadas, é usar os scripts de manutenção de Ola Hallengren . Estes são razoavelmente fáceis de instalar e configurar e têm muitas dessas diretrizes integradas.

Verificações de consistência DBCC

Dependendo da carga de trabalho geral, você pode achar que as verificações de DBCC são perturbadoras para sua operação. Existem duas maneiras comuns de minimizar o impacto no DBCC para seus bancos de dados:

• PHYSICAL_ONLY- A execução dessa opção verificará seus bancos de dados no nível da página física e evitará a verificação completa mais invasiva. Isso abrangerá 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 para 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 você obviamente não irá interferir na atividade. Algumas outras alternativas aqui estão executando o DBCC em uma cópia enviada por log ou em um banco de dados espelhado.

Esta postagem do 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 ativas (como qualquer outro aplicativo), portanto, algumas chaves devem ser lembradas:

• Programe esse trabalho para sua outra manutenção e em períodos de baixa atividade.
• Dimensione o trabalho de forma correta, para que ele seja enviado em lotes para desempenho e para que o lote não seja tão grande que bloqueie sua mesa por horas. Exemplos dos fins do espectro: RBAR (linha por agonização) versus uma exclusão de um milhão de linhas.
• Use tabelas de estágio e off-line, seu processamento de dados, quando apropriado. Toque apenas no material ao vivo quando for absolutamente necessário.

Conclusão

Novamente, há muito terreno a ser abordado aqui. Este não é um guia abrangente, mas uma visão geral de alto nível de algumas abordagens. Ainda nem discuti opções de alta disponibilidade (como Grupos de Disponibilidade e Cluster de Failover). Você precisará revisar cada item e elaborar um plano de como lidar com ele. De várias 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