Infelizmente, estou assumindo, como a maioria das pessoas nessa função, que o título DBA veio por padrão e não por design.
Estou tentando gerenciar nosso farm de 5 servidores SQL Server 2016, cada um com uma espera quente para nossa recuperação de desastres.
Consultamos nossa base de usuários e chegamos à decisão de que algum centro da cidade é aceitável, desde que possamos minimizar a perda de dados. Não precisamos de recuperações pontuais, apenas para garantir que temos os dados mais atualizados possíveis com base na aceitabilidade da perda de dados dos usuários.
O que decidimos para nosso modelo é que cada banco de dados em cada uma das primárias será copiado e restaurado no modo de espera apropriado (com o banco de dados deixado no modo de espera/somente leitura) e, em seguida, um trabalho de envio de log criado para enviar o log para o servidor em espera a cada 30 segundos a 1 hora, dependendo da sensibilidade à perda de dados. Em seguida, em cada servidor stand by, uma vez a cada 15 minutos a 1 hora, uma tarefa de restauração é executada para restaurar todas as transações enviadas do primário para o banco de dados stand by. Depois que as transações foram enviadas para o modo de espera e restauradas com sucesso, não me importo mais com essas transações.
Isso funciona muito bem, pois posso consultar os bancos de dados stand by e ver os dados atualizados conforme o esperado.
Onde faltam informações é que meu log de transações está crescendo maior que meu arquivo de banco de dados no meu primário. EU ASSUMI que o envio de logs marcaria o log como backup, mas aparentemente estou errado.
Estou hesitante em criar um trabalho que faça backups completos, pois não quero interromper a cadeia de envio de logs, então aqui é onde preciso de alguns conselhos sobre como controlar meus tamanhos de log.
Eu consultei a internet para obter respostas, mas recebo tantas respostas diferentes quanto resultados, então estou voltando aqui para obter conselhos.
Obrigado desde já, Keith
Isso é um equívoco/mito. Um backup completo nunca interromperá a cadeia de backup de log. Apenas um backup ad hoc NON COPY_ONLY interromperá a cadeia de backup de log.
Na recuperação completa, apenas um backup completo truncará o log.
Verifique suas configurações de crescimento automático. Certifique-se de que não esteja definido como Percentagem de crescimento automático e que o crescimento automático de MB seja sensato.
Você pode verificar meu script para verificar .
Além disso, você deve verificar: Por que o log de transações continua crescendo ou fica sem espaço?
O envio de logs utiliza backups de log de transações no SQL Server. Um backup T-Log marcará as partes do log que contêm transações confirmadas como inativas e disponíveis para reutilização após a conclusão do backup. Se a frequência de backup for de até 1 hora, o arquivo de log de transações poderá crescer muito devido à baixa frequência de backup e aos altos volumes de transações. Cresce constantemente ou apenas em determinados momentos (fins de semana, durante a noite etc)? Independentemente da causa, aumentar a frequência dos backups provavelmente resolverá isso.
Backups completos não quebrarão sua cadeia de logs. Você ainda deve executar backups completos regulares, mesmo ao utilizar o envio de logs, a chave é evitar backups de log ad-hoc, pois eles quebrarão a cadeia de logs.
Há uma pergunta sobre SE e as respostas fornecem informações muito boas sobre cadeias de restauração no SQL Server. Faça uma leitura para entender melhor as cadeias de restauração no SQL Server.
Você também precisa considerar outros cenários em seu plano de DR além de seu servidor principal ficar offline. Não fazer backups completos significa que, se você tiver um evento de dados incorreto iniciado pelo usuário (alguém descarta uma tabela, exclui um registro etc. acidentalmente), suas opções para recuperar o estado correto dos dados serão limitadas pela retenção de seu backup completo original.
O que acontece se esse arquivo de backup completo ficar corrompido?
Você está preparado para restaurar, potencialmente, meses de arquivos de log para reinicializar o envio de logs, se necessário?
Você retém seus backups de log por tempo suficiente para reinicializar o envio de logs do backup completo original ou fará um novo Full, possivelmente durante o horário comercial, caso precise reinicializar?
Considerando que alguns de seus bancos de dados têm RPOs tão baixos (30 segundos), você considerou outra tecnologia, como Grupos de Disponibilidade , para fornecer RPO\RTO muito menor sem a sobrecarga de envio de backups de log?