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

Os dados armazenados nos bancos de dados da empresa são o seu maior patrimônio. Transformar estes dados em informações úteis para o negócio da empresa é o grande desafio da TI – Tecnologia da Informação. É a já velha e conhecida, porém sempre atual máxima: “A informação certa, para a pessoa certa e no tempo certo”.

Uma vez que estes dados são de vital importância, obviamente que devemos possuir mecanismos de proteção para os dados, a fim de evitar perdas (garantindo a disponibilidade), adulteração e acesso indevido aos dados (garantindo a integridade e autenticidade dos dados). Evitar adulteração e acesso indevido aos dados faz parte da segurança de acesso aos dados, quer da segurança lógica quanto da segurança física – do acesso a sala dos servidores. Porém segurança é assunto para o Capítulo 6.

Neste capítulo vamos tratar das estratégias e mecanismos de implementação de rotinas de Backup dos dados (cópias de segurança dos dados). O Backup é certamente uma das técnicas mais antigas e mais eficientes para se proteger contra a perda de dados (infelizmente, por incrível que possa parecer, as atividades de backup/restore, os planos de contingência e de recuperação a desastres, continuam não tendo a devida atenção, cuidado e planejamento necessários).

Iniciaremos o capítulo falando sobre transações e o Log de Transações (Transaction Log) em Bancos de Dados do SQL Server 2005. Precisamos entender o conceito de Log de Transações, para que possamos estudar as diversas estratégias de Backup e identificar qual a estratégia mais adequada para cada situação.

Entendido o conceito de Log de Transações, podemos partir para o estudo das estratégias de Backup/Restore. A operação de Restore é a utilização de uma cópia de Backup para “Restaurar” os dados de volta para o Banco de Dados, em caso de perda dos originais. Por isso, não existe sentido falar somente em Backup. Quando fazemos uma Cópia de segurança do Banco de Dados para outro dispositivo, normalmente uma fita magnética ou uma pasta no HD, estamos fazendo um Backup (Cópia de segurança). Se acontecer algum problema com os dados, precisamos “Restaurar” (Restore) os dados a partir do Backup, de volta para o Banco de Dados. Existe até uma brincadeira bastante conhecida entre os DBAs: “O Backup sempre funciona, o problema é o Restore”. Nesta situação, o DBA (Database Administrator) está querendo dizer que a operação de Backup, normalmente, não apresenta problemas. As maiores complicações acontecem na hora de restaurar os dados. Embora seja uma “brincadeira”, esta afirmativa representa uma realidade, muitas vezes bastante cruel. Se não formos cuidadosos e planejarmos com precisão o nosso sistema de Backup/Restore, poderemos ter problemas bastante desagradáveis. Já pensou a reação do chefe quando você informa que não poderá restaurar os dados com as operações financeiras da última semana porque na hora de fazer o Backup foi tudo bem; porém na hora de restaurar os dados, nada funcionou?

Uma vez entendidas as diversas estratégias de Backup/Restore, iremos para a implementação prática das rotinas de Backup/Restore. Em um exercício prático, faremos o backup de um Banco de Dados, depois iremos “corromper” os dados e aí teremos que restaurar os dados a partir do backup feito inicialmente. Seguindo o padrão dos demais capítulos, aprenderemos a fazer Backup/Restore utilizando o SQL Server Management Studio e também comandos T-SQL, usando a janela de execuão de comandos do SQL Server Management Studio, a qual você já aprendeu a utilizar nos capítulos 3 e 4.

À medida que o banco de dados vai crescendo, pode tornar-se praticamente impossível fazer o backup manualmente. E se o backup tiver que ser feito às 5h da manhã? Ou se tiver que iniciar as 2:00 hs da manhã, para que possa ser concluído antes das 8:00 hs, que é quando inicia o expediente. Iremos contratar um DBA especialmente para esta tarefa? Conforme veremos, é possível “Agendar Tarefas” no SQL Server 2005. E um ótimo exemplo de tarefa que se presta a ser agendada é a execução de Rotinas de Backup, fora do horário de expediente. Aprenderemos a agendar tarefas e fazer com que após a execução da tarefa uma determinada mensagem seja enviada para o DBA. Também veremos quais outros tipos de tarefas que podem ser agendadas e os demais recursos para agendamento de tarefas.

Know-how em: Conceito de Log de Transações no SQL Server 2005

Pré-Requisitos:

• Fundamentos apresentados na Parte I.

Metodologia:

• Apresentação teórica sobre o log de transações.

No Capítulo 2, em uma breve introdução a respeito de transações, defini uma transação da seguinte maneira:

“Uma transação, de uma maneira bastante simples, é um conjunto de operações sobre os dados, que deve acontecer com um todo, ou seja, todas as operações contidas na transação devem ser finalizadas com sucesso, ou nenhuma delas deve ser realizada. Caso uma das operações, contidas na transação, venha a falhar, as operações ainda pendentes devem ser canceladas; e as operações já realizadas devem ser revertidas. Com isso garantimos que a transação acontece como um todo, ou que nenhuma de suas operações seja realizada.”

No Capítulo 3, onde aprendemos a criar Bancos de Dados no SQL Server 2005, nós vimos que todo Banco de Dados deve ter, no mínimo, um arquivo de log, o qual também é chamado de Transaction Log do Banco de Dados. Em resumo, todo Banco de Dados do SQL Server 2005 deve possuir pelo menos um arquivo de log, sendo que não é possível desativar o mecanismo de log no SQL Server 2005. De agora em diante iremos utilizar o termo: o Log de Transações do Banco de Dados.

No Capítulo 3 escrevi o seguinte parágrafo:

“Os arquivos de log armazenam o chamado Log de transações. O Log de transações é um registro das operações que são efetuadas nos dados do Banco de Dados. Veremos mais detalhes sobre o log mais adiante.”

No Log de Transações do Banco de Dados são registradas as seguintes operações efetuadas sobre os dados:

• INSERT
• UPDATE
• DELETE

No Log de Transações fica o registro da transação, caso esta tenha sido executada com sucesso, ou o registro da reversão (Roll Back) da transação, caso uma ou mais das operações que compõem a transação, venha a falhar. Este mecanismo é fundamental para garantir a integridade dos dados, garantindo que estes estejam em um estado sempre consistente.