Júlio Battisti Livros e Cursosa sua sala de aula na internet

Quanto ao conteúdo do backup, temos duas abordagens para o backup de um Banco de Dados:

• Fazer o backup somente do Banco de Dados: Com esta abordagem o backup do Banco de Dados é feito periodicamente. Caso aconteça algum problema com o Banco de Dados, as alterações que tenham sido feitas desde o último backup serão perdidas. Considere o exemplo da Figura 5.1.

Figura 5.1 Backup somente do Banco de Dados.

Fazer o backup apenas do Banco de Dados apresenta como principal vantagem a simplicidade, e como principal desvantagem a perda das alterações entre o último backup e o momento em que o problema ocorre no Banco de Dados. Com esta abordagem, a restauração também é bastante simples, conforme veremos mais adiante, na parte prática deste capítulo.

Utilizamos este tipo de abordagem para pequenos Bancos de Dados devido a sua simplicidade. Para Bancos de Dados maiores, mais complexos devemos fazer o backup também do Log de transações, conforme descrito a seguir.

• Backup do Banco de Dados e do Log de transações: Com esta abordagem fazemos o backup de todo o Banco de Dados menos freqüentemente do que no caso anterior, em contrapartida é feito o backup do Log de transações entre os backups do Banco de Dados. Poderíamos ter a seguinte estratégia de backup:

1.       Backup do Banco de Dados no domingo às 20h.

2.       Backup do Log de transações na segunda-feira às 9:00, 15:00, 18:00 e 21:00 h

3.       Backup do log de transações na terça-feira às 9h, 15h, 18h e 21h.

4.       Backup do Log de transações na quarta-feira às 9h, 15h, 18h e 21h.

5.       Backup do Log de transações na quinta-feira às 9h, 15h, 18h e 21h.

6.       Backup do Log de transações na sexta-feira às 9h, 15h, 18h e 21h.

7.       Backup do Log de transações no sábado às 9h, 15h, 18h e 21h.

8.       Backup do Banco de Dados no domingo às 2h.

Agora vamos imaginar que o Banco de Dados tenha sido corrompido na sexta-feira, às 20h. A que situação podemos restaurá-lo?

Poderemos restaurá-lo à situação do último backup do Log de transações, que no caso foi feito na sexta-feira às 18h. Na verdade, conforme veremos mais adiante, é possível, dependendo das condições, restaurar o Banco de Dados até próximo do horário em que o banco foi corrompido, digamos um minuto antes do banco ter sido corrompido. Neste caso apenas as alterações feitas por transações que ainda não tenham sido completadas (Committed Transactions) serão perdidas.

No próximo item veremos as estratégias para a restauração do Banco de Dados quando utilizamos backups do Banco de Dados e do Log de transações.

Este tipo de abordagem é mais complexa do que a anterior, sendo indicada para Bancos de Dados maiores e que não podem, em hipótese alguma, perder alterações que tenham sido feitas desde o último backup do banco de dados. A complexidade aumenta, principalmente, na hora de restaurar os dados. Utilizando o exemplo anterior, em que o banco de dados corrompeu na sexta-feira, às 20h, teríamos que restaurar o backup do Banco de Dados feito no domingo e todos os Logs de transação feitos neste intervalo. A restauração tem que ser feita em seqüência. Além disso, ao restaurarmos os Logs de transação, estes devem ser restaurados na ordem cronológica em que foram feitos. É como se estivéssemos “aplicando” novamente todas os comandos que foram executados no Banco de Dados, uma vez que o Log de transações é um registros dos comandos executados no Banco de Dados, principalmente comandos que inserem, alteram ou excluem dados.

Temas uma novidade importante do SQL Server 2005, em relação ao backup/restauração do banco de dados. Com o SQL Server 2000, o banco de dados permanece indisponível para uso, durante todo o processo de restauração, o que aumenta o tempo de indisponibildiade do banco de dados. Já o SQL Server 2005, suporta um recurso conhecido como “Partil Restore”. No SQL Server 2005, o banco de dados passa a estar disponível para uso, assim que for concluída a restauração do filegroup Primary. O filegroup Primary contém as informações da estrutura do banco de dados, sem as quais não é possível colocar um banco de dados on line. Uma vez restaurado o filegroup Primary, o banco de dados passa a estar online e disponível para o uso e o processo de restauração continua. Se um usuário tentar acessar um conjunto de dados que ainda não foi restaurado (por exemplos, dados que estão em Filegroups que ainda não foram restaurados), o usuário receberá uma mensagem de que os dados estão off-line e que ele deve tentar novamente mais tarde. Se o usuário tentar acessar dados de um filegroup que já foi restaurado, os dados serão acessados, normalmente, e o usuário nem fica sabendo que o processo de restauração dos demais filegroups ainda está em andamento (a não ser por uma queda no desempenho, queda esta que será perfeitamente normal, para o case de uma restauração de backup estar em andamento).

Outra novidade do SQL Server 2005, na área de backup/restore é conhecida como “Concurrente Database and Log Backups”, ou seja, a possibilidade de fazer o backup, ao mesmo tempo, tanto do banco de dados quando do log de transações do banco de dados. No SQL Server 2000 você primeiro tinha que aguardar o backup do banco de dados ser completado, para depois poder fazer o backup do log de transações. No SQL Server 2005 não existe mais esta limitação, sendo possível fazer o backup do banco de dados e do log de transações, simultaneamente. Pode parecer que não seja de grande importância esta nova funcionalidade, mas é. Em grandes bancos de dados, um dos principais problemas é a chamada janela de backup, ou em palavras mais simples, o tempo que o backup demora para ser completado. Com a possibilidade de fazer o backup do banco de dados e do log de transações, simultaneamente, você pode instalar duas ou mais unidades de fita e fazer o backup de ambos ao mesmo tempo, o que pode diminuir, consideravelmetne, a janela de backup. Porém ainda existe uma limitação, que é a de somente poder fazer o backup de um dos arquivos de dados de um banco de dados (arquivos .mdf ou .ndf), por vez. Quem sabe no SQL Server 2??? esta limitação seja superada.