Acontece que estamos usando o SQL Server 2012 Standard Edition. Também uso os scripts de Ola Hallengren para fornecer uma estrutura fácil e mais flexível para fazer backups e manutenção.
Esta pergunta não é tanto sobre os scripts de Ola, mas sim sobre uma prática recomendada. Sei que a resposta final é "depende dos requisitos da sua empresa". Mas estou tentando buscar o conselho da comunidade sobre a melhor forma de cumprir o que entendo dos requisitos de nossa empresa.
Desejo configurar backups de log de transações a cada 15 minutos. Dessa forma, esperamos não perder mais de 15 minutos de dados. Devo configurar um trabalho que usa ALL_DATABASES? ou é melhor configurar um trabalho para cada banco de dados e iniciá-los todos em paralelo? Pergunto, porque tenho a sensação, com base em como vejo o script de Ola funcionando, de que os backups são iniciados em série. A desvantagem do serial seria que cada backup sucessivo espera até que o outro seja concluído. Isso pode aumentar potencialmente a quantidade de tempo entre os backups (ou seja, mais de 15 minutos). Além disso, minha preocupação seria que uma falha em um backup impedisse que os outros acontecessem, e eu não gostaria que fosse esse o caso. Eu gostaria que os outros continuassem recuando.
Então é verdade que os scripts do Ola são executados em série e também uma falha interrompe os backups sucessivos?
E é melhor ter um trabalho para cada banco de dados? ou um único trabalho que faz tudo? Minha inclinação é para trabalhos separados, mas desejo entender o que os DBAs do SQL Server em geral tendem a fazer.
Sugiro configurar um trabalho que faça backup dos logs de transação (em série). Isso também garantiria que o backup não utilizasse pesadamente a E/S porque você está executando o backup para o banco de dados um de cada vez.
Quais poderiam ser as possíveis desvantagens da execução em paralelo
Suponha que você tenha 50 bancos de dados e agende o backup do log de transações de todos os bancos de dados e todos eles comecem a ser executados em paralelo, isso definitivamente utilizará muita E/S. E se o disco no qual está fazendo backup dos arquivos tiver outros arquivos de dados, você verá lentidão. Já vi o backup ficar lento quando uma consulta ruim solicitando muita E/S é executada junto com a tarefa de backup.
Novamente, suponha que você tenha 50 bancos de dados, não seria difícil gerenciar 50 trabalhos no agente do SQL Server e qual seria a condição se você tivesse 100-200 bancos de dados? apenas mantenha-o simples. Tenho certeza que o mesmo caso seria com você.
Os backups de log de transações são geralmente pequenos e, se você tiver um banco de dados ocupado produzindo muitos registros de log, talvez seja necessário alterar a frequência de backup. Na maioria das vezes, vi o backup do log de transações sendo concluído corretamente quando a frequência é de 15 minutos. Eu não acho que deveria ser motivo de preocupação para você.
Eu diria apenas não se preocupe com isso. Os backups de log de transações simplesmente não podem falhar, a menos que você cometa algum erro. Os erros podem ser
O proprietário que executa o trabalho é removido do AD
Alguém mudou o modelo de recuperação do banco de dados.
Espaço em disco insuficiente
Além do exposto acima, não vi nenhum motivo para a falha do backup do log de transações. É muito robusto, você pode confiar nele.
Em geral, sempre execute seus backups T-log em série; muitas das minhas instâncias têm algumas dezenas de bancos de dados e vários que são muito ativos, e os backups do log de transações levam apenas alguns segundos no total; até meio minuto ou mais quando está particularmente ocupado.
A execução de backups em paralelo só seria realmente benéfica se todas as seguintes condições fossem verdadeiras:
Seus bancos de dados e arquivos de log estão todos em eixos independentes exclusivos (ou estão em discos de estado sólido em qualquer combinação)
Seus destinos de backup para cada banco de dados estão em eixos separados.
Você não está usando SAN HBA ou iSCSI compartilhado ou outra largura de banda entre a instância do SQL Server e a mídia.
ou seja, o IOPS da leitura do banco de dados A e gravação do backup A NÃO use os mesmos discos para leitura do banco de dados B e gravação do backup B.
Se tudo isso for verdade, é possível que algum grau de paralelismo diminua a quantidade de tempo total do calendário. Se tudo isso não for verdade, muito provavelmente você fará com que um ou mais conjuntos de discos travem, e seus backups paralelos levarão mais tempo do que seriais, mas também podem causar fragmentação do sistema de arquivos ou do nível de armazenamento, porque você está escrevendo Backup A e Backup B ao mesmo tempo!
Não se preocupe com a falha de um backup e o sucesso do restante - se algum falhar, você precisa verificar tudo de qualquer maneira, e as únicas vezes que vi backups falharem são devido a:
Falha de disco
Falha de software de compactação Hyperbac/Litespeed/de terceiros (se você tiver software entre o SQL e o disco que falha)
Falha do produto de criptografia (se você tiver software entre o SQL e o disco que falha)
Falha na rede (se os arquivos do banco de dados ou, mais provavelmente, os arquivos de backup estiverem na rede)
Permissões
mais comum com novas instalações
ou novos locais de backup
alterando o usuário do SQL Server Service (que é o que precisa das permissões para backups normais)
bloqueando o usuário do serviço SQL Server porque ele é usado por mais de uma instância do SQL Server
Erros de configuração
Falha de energia
travamento do sistema operacional
A maioria dos quais não afetará um e não os outros, a menos que as condições acima também sejam atendidas.
Só para acrescentar, Ola projeta seus scripts onde, se um backup de banco de dados falhar por qualquer motivo, o(s) próximo(s) é(são) tentado(s). Como afirmado anteriormente, você poderia ter um alerta configurado para informá-lo sobre a falha do trabalho, pois o trabalho de backup ainda falharia, mesmo se apenas um backup de banco de dados falhasse de todos os bancos de dados do usuário - assumindo que você está fazendo backup de todos os bancos de dados (um trabalho para todos).