Backups de log de transações seriais ou paralelos?

Por acaso, estamos usando o SQL Server 2012 Standard Edition. Também utilizo 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 sobre as melhores práticas. Sei que a resposta final é "depende dos requisitos da sua empresa". Mas estou tentando procurar 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 que não percam mais de 15 minutos de dados. Devo configurar um trabalho que use ALL_DATABASES? ou é melhor configurar um trabalho para cada banco de dados e iniciá-los todos em paralelo? Eu pergunto, porque tenho a sensação de que, como vejo o script de Ola funcionando, os backups são iniciados em série. A desvantagem do serial seria que cada backup sucessivo espere até que o outro seja concluído. Isso pode aumentar potencialmente a quantidade de tempo entre os backups (ou seja, maior que 15 minutos). Além disso, minha preocupação é que uma falha em um backup impeça que os outros aconteçam, e eu não gostaria que fosse esse o caso. Eu gostaria que os outros continuassem fazendo backup.

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 emprego 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.

Devo configurar um trabalho que use ALL_DATABASES? ou é melhor configurar um trabalho para cada banco de dados e iniciá-los todos em paralelo?

Sugiro que você configure um trabalho que faça backup dos logs de transações (serialmente). Isso também garantiria que o backup não faça uso intenso da E / S, porque você está executando o backup do banco de dados, um de cada vez.

O que poderia ser possível desvantagens com a execução em paralelo

1. Suponha que você tenha 50 bancos de dados e programe o backup do log de transações de todos os bancos de dados e todos eles comecem a ser executados em paralelo. E se o disco no qual está fazendo o backup dos arquivos tiver outros arquivos de dados, você verá lentidão. Vi o backup ficar lento quando uma consulta ruim solicitando muita E / S é executada juntamente com a tarefa de backup.

2. Mais uma vez, 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? Eu simplesmente não gostaria quando você abre o agente do SQL Server e vê muitos trabalhos, apenas mantenha-o simples. Estou certo de que o mesmo caso estaria com você.

A desvantagem do serial seria que cada backup sucessivo espere até que o outro seja concluído. Isso pode aumentar potencialmente a quantidade de tempo entre os backups (ou seja, maior que 15 minutos).

Os backups do log de transações são geralmente pequenos e, se você tiver um banco de dados ocupado produzindo muitos registros, poderá precisar alterar a frequência do backup. Na maioria das vezes, eu 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ê.

Além disso, minha preocupação seria que uma falha em um backup impeça que os outros aconteçam, e eu não gostaria que esse fosse o caso

Eu diria que não se preocupe. Os backups do log de transações não podem falhar, a menos que você cometa algum erro. Os erros podem ser

1. O proprietário que está executando o trabalho é removido do AD

2. Alguém mudou o modelo de recuperação do banco de dados.

3. Espaço em disco insuficiente

Além do acima, não vi nenhum motivo para falha no backup do log de transações. É muito robusto, você pode confiar nele.

Em geral, sempre execute seus backups do T-log em série; muitas das minhas instâncias têm algumas dúzias de bancos de dados e vários muito ativos, e os backups do log de transações levam apenas alguns segundos no total; até meio minuto, quando estiver particularmente ocupado.

A execução de backups em paralelo apenas seria realmente benéfica se todas as seguintes condições forem verdadeiras:

• Seus bancos de dados e arquivos de log estão todos em eixos independentes exclusivos (ou em discos de estado sólido em qualquer combinação)

  • Para backups apenas de log-T, apenas os arquivos de log precisariam atender a esse requisito.

• 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 da gravação do backup A NÃO use os mesmos discos que da leitura do banco de dados B e da gravação do backup B.

Se tudo isso for verdade, é possível que algum grau de paralelismo diminua a quantidade total de tempo do calendário. Se tudo isso não for verdade, é mais provável que você faça com que um ou mais conjuntos de discos sejam debulhados, e seus backups paralelos levarão mais tempo do que serial, mas também podem causar fragmentação do sistema de arquivos ou nível de armazenamento, porque você está escrevendo o Backup A e o Backup B ao mesmo tempo!

Não se preocupe com a falha de um backup e o restante com êxito - se houver algum, você precisará verificar tudo de qualquer maneira, e as únicas vezes em que vi os backups falharem devem-se a:

• Falha no disco

• Hyperbac / Litespeed / falha no software de compactação de terceiros (se você tiver um software entre o SQL e o disco que falhar)

  • Como aviso, a falha pode assumir a forma de uma tarefa de backup que nunca termina, portanto, é importante verificar se há "tarefas que executam mais que o esperado" que envia alertas.

• Falha no produto de criptografia (se você tiver um software entre o SQL e o disco que falhar)

• Falha na rede (se os arquivos do banco de dados, ou mais provavelmente os arquivos de backup, estiverem na rede)

• Permissões

  • mais comum em instalações novas

  • 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

• Falha no sistema operacional

A maioria dos quais não afetará um e nem os outros, a menos que as condições acima também sejam atendidas.

Apenas para adicionar, Ola cria seus scripts nos quais, se um backup do banco de dados falhar, por qualquer motivo, os próximos são tentados. Como declarado anteriormente, você pode ter um alerta configurado para informá-lo sobre a falha da tarefa, pois a tarefa de backup ainda falharia, mesmo que apenas um backup do banco de dados falhe em todos os bancos de dados do usuário - supondo que você esteja fazendo backup de todos os bancos de dados (um trabalho para todos).