Backups com RMAN

Para a grande maioria das organizações, os dados possuem um valor inestimável. Nessa era da informação, perdas de dados podem causar grandes prejuízos e, no pior cenário, podem até levar ao encerramento de atividades de uma empresa. Mesmo quando nossos procedimentos nos permitem recuperar os dados em caso de falhas, geralmente isso demanda algum tempo de indisponibilidade, que também pode gerar prejuízos ao negócio.

Embora os sistemas gerenciadores de bancos de dados, como o Oracle, estejam bem consolidados e robustos, nunca estaremos livres de falhas. Podem ocorrer erros humanos, falhas nos equipamentos de hardware, danos à integridade física de equipamentos (um incêndio, por exemplo), entre muitas outras possibilidades.

Pelas razões expostas, na administração de banco de dados, uma das maiores responsabilidades do DBA é manter um plano de backup e disponibilidade apropriados à necessidade da empresa. Isso demanda um entendimento do negócio, dos riscos existentes e de como eles podem ser gerenciados. Desse modo, um sistema crítico normalmente demanda backups frequentes, com manutenção de mídias de backup em locais seguros e com múltiplas cópias. Esses ambientes críticos também costumam demandar soluções de alta disponibilidade e de recuperação de desastres, como o Oracle Data Guard, que permite ter uma cópia idêntica do ambiente de produção (conhecida como banco de dados Standby) em outra máquina para que essa cópia seja usada se o primeiro banco de dados (banco primário) falhar ou estiver inacessível por algum motivo qualquer. Uma das vantagens de se ter um ambiente com Data Guard é que você pode fazer backup do banco de dados Standby (usando o recurso conhecido como Active Data Guard, que exige licenciamento à parte), não onerando desse modo o banco primário.

Sistemas ou ambientes menos críticos, tais como ambientes de desenvolvimento e homologação, permitem políticas de backups menos exigentes e que muitas vezes possibilitam algum tempo de indisponibilidade. O equilíbrio correto na definição da política de backups é importante, pois políticas mais robustas demandam maiores esforços de gerenciamento, mais controle e acabam sendo bem mais caras de se implementar e de se manter.

Na grande maioria dos ambientes, a política de backup, uma vez definida, é implementada para ocorrer em janelas específicas nos horários programados. Em ambientes com diversos servidores e bancos de dados, construir e manter as rotinas de backup costuma ser algo trabalhoso. Imagine, por exemplo, um ambiente com 100 bancos de dados em 10 servidores diferentes. Entrar em cada um deles diariamente para verificar o status dos backups pode ser uma tarefa árdua e que normalmente o DBA não terá tempo para fazer. Nesse caso, as rotinas de manutenção também podem ser muito trabalhosas. Imagine se você tiver 100 scripts de backup, um para cada banco, e tiver que mudar, por exemplo, o caminho de destino dos backups. Alterar um por um não será uma tarefa rápida e nem tão pouco produtiva.

Por isso, em primeiro lugar, é muito importante criar uma forma de centralizar as rotinas de backup de modo que a manutenção e monitoração possam ser realizadas com maior facilidade e agilidade. Existem algumas maneiras de se construir rotinas centralizadas, mas devemos sempre estar atentos a um princípio: a simplicidade. Na área de TI, é muito comum termos soluções com maior complexidade do que é de fato necessário. Embora muitas vezes essas soluções até utilizem recursos interessantes, devemos nos atentar ao fato de que, quanto mais complexa é uma solução, mais difícil é a sua manutenção. Isso aumenta riscos, custos e pode reduzir agilidade. Por isso, ser capaz de administrar os backups de uma forma simples e centralizada são fatores importantes para ganhar tempo, facilitar a manutenção e minimizar riscos. Para apoiar a construção e gestão de rotinas de backup centralizadas, existem ferramentas disponíveis no mercado, tais como Oracle Secure Backup, Data Protector, Tivoli Storage Manager etc. Infelizmente, nem sempre temos as licenças disponíveis para uso delas, ou as temos apenas para alguns ambientes. Felizmente, somente com os recursos fornecidos pelo Oracle é possível montar uma rotina de backups centralizada, simples e eficiente. Para gerenciar os backups, a Oracle possui sua própria ferramenta, chamada Recovery Manager (mais conhecida como RMAN). Já para tratar a questão de agendamento das rotinas de backup necessárias, podemos contar com o Oracle Scheduler, uma ferramenta completa para execução de jobs.

Neste artigo, iremos apresentar uma proposta com estrutura simples e centralizada para controlar procedimentos típicos de backup, utilizando apenas recursos disponíveis no Oracle e no sistema operacional. Primeiramente, apresentaremos uma introdução de cada um dos recursos utilizados: RMAN, Oracle Scheduler e Oracle Wallet, para depois apresentarmos a estrutura proposta.

Podemos utilizar ferramentas externas ou mesmo procedimentos de cópia de arquivos para fazer backups de bancos de dados Oracle. São os chamados backups não gerenciados. Embora possíveis, a maneira mais eficiente de se fazer backups no Oracle, é utilizando o RMAN, que é uma ferramenta do amplamente utilizada para executar atividades de backup e recuperação de bancos de dados, provendo flexibilidade na configuração e execução da política de backups, bem como recursos indispensáveis no processo de recuperação em caso de falhas. O RMAN utiliza processos chamados channels (canais) para realizar suas operações. Os channels são processos de servidor, como qualquer outro, mas destinados exclusivamente para fazer a cópia de arquivos.

Quando utilizamos o RMAN, é importante observarmos alguns conceitos e terminologias. Dois deles, que às vezes causam confusão, são os conceitos de backup total ou parcial, e backup completo ou incremental:

• Backup total ou parcial (whole or parcial): refere-se ao que servirá de entrada para o backup, ou seja, podemos fazer o backup de todo o banco de dados, ou podemos fazer o backup de partes dele (no caso do Oracle, de tablespaces ou datafiles específicos);
• Backup completo ou incremental (full or incremental): refere-se aos arquivos de saída do backup. No backup completo temos todo o conteúdo presente nos arquivos de saída (exceto blocos vazios ou não utilizados se usamos Backup Set). Já no caso de backup incremental, temos apenas os blocos alterados desde o último backup realizado.

Outro conceito importante são os tipos de backup do RMAN, que podem ser:

• Image Copy: é uma cópia exata do banco de dados, portanto, os arquivos de entrada são copiados byte a byte para os arquivos de saída;
• Backup Set: é uma estrutura lógica de dados que pode juntar vários arquivos de entrada em um só arquivo de saída, e que exclui os blocos vazios ou ...
  Quer ler esse conteúdo completo? Tenha acesso completo