Backup & Recovery Parte 1 - Configurando o Banco Recuperação

De todas as tarefas que um DBA precisa fazer, o Recover é a principal delas, ao contrario que muita gente pensa ser o Backup. O Backup nada mais do que uma tarefa para se chegar no Recover. Quando um banco de dados falhar, o DBA estará sob enorme pressão para recuperá-lo o mais rapidamente possível, contudo nenhuma DBA sofrerá pressão para fazer Backup. É fundamental estar preparado, não será nada bom ficar procurando as soluções nos manuais antes de tomar as medidas adequadas. Devido a isso a formula é estudar, conhecer o banco de dados e depois: Praticar, praticar e praticar.

Esta série de artigos visa mostrar o processo de Backup e Recover usando o RMAN em backups incrementais. O ambiente mostrado é em Windows com Oracle 10g, mas totalmente adaptável para Linux, com backup’s baseados em discos (levando em consideração do preço dos discos e a capacidade de armazenamento, atende muito bem a muitas empresas), nesta primeira parte será mostrado conceitos básicos e a configuração para preparar o banco para recuperação.

Antes de mostrar como faz backup no Oracle, será apresentado uma compreensão de como funciona o Oracle, e isto é muito importante, pois no momento em que precisar fazer o Recover e as coisas não irem bem, ter o conhecimento de como funciona o mecanismo Oracle irá ajudar e muito neste processo.

SGBD Oracle

O Oracle é composto basicamente por duas partes:

      ·         Instância Oracle
      ·         Banco de Dados Oracle

Instância Oracle

A instância é a estrutura de memória e os processos Oracle que se encontram na memória principal, obviamente uma instância existe quando a maquina está ligada, pois os dados da memória principal são voláteis.

A instância é composta por duas áreas de memória o SGA e o PGA, sendo que o 1º é uma área de memória publica e é dividida em varias outras pequenas áreas como cache de consulta ou estrutura de tabela e pacote para otimização dos processos Oracle, enquanto a segunda é uma área privada onde guarda os valores de variáveis e processos de cada sessão.

Banco de Dados

O Oracle database é composto por três tipos de arquivos que encontra-se no sistema operacional

*ControlFile

*DataFile

*LogRedo

Para saber a localização destes arquivos, basta executarem algumas consultas no dicionário de dados do Oracle.

ControlFile: O ControlFile é um arquivo pequeno, mas muito importante, pois nele contem todas as informações necessária para montar uma instancia Oracle, ou seja nele contem a informação como nome do Banco de dados, os arquivos do banco de dados e qual o valor atual do SCN, além disse as informações do backup estarão nele, e caso este arquivo corrompa é necessário restaurar o banco de dados inteiro, por isso é crucial temos backup dele.

DataFile : O DataFile é onde são armazenados as informações do banco de dados. Tanto os dados dos usuários como os dados interno do Oracle - dicionário de dados - são armazenados nestes arquivos.

RedoLog : Log de redo é um conjunto de arquivos que guardas as últimas operações de um banco de dados Oracle, no mínimo é preciso ter 2 arquivos desse, e as operações ocorrem de modo síncrono, ou seja guarda as informações no 1º arquivo depois no 2º, quando termina o Oracle sobrescreve o 1º arquivo. Quando ocorre algum uma falha, para recuperar a consistência do banco de dados ele usa o Log de Redo. Porém se por algum motivo for preciso restaurar um o algum arquivo ou o mesmo o banco de dados inteiro, será preciso usar os logRedo e/ou os Log que foram sobre-escrito, mas guardo em algum local no disco, o chamado archive, que será explicado mais para frente.

Operação na Database

Toda operação que ocorre no banco de dados, a operação é registrada a nível de instância em uma área da memória chamada Redo Log Buffer e de tempo em tempo o conteúdo deste Buffer é aplicado no arquivo ativo do Redo log. Também quando ocorre um commit o Oracle obrigatoriamente aplica o que está no Buffer no RedoLog.

Isso significa que o Oracle não grava de imediato nos DataFiles as operações do banco. Outro processo que é responsável de transferir o conteúdo do RedoLog para o DataFile. O algoritmo de gravação do Buffer paraRedoLog é extremamente rápido, ao passo que do RedoLog para DataFile é "preguiçoso". Nunca os dados que estão gravados no RedoLog são sobre-escrito antes de serem replicados para os DataFiles e opcionalmente (obrigatoriamente em produção) para algum local no disco - o chamado archive.

Um fato a ser percebido é que a gravação no RedoLog representa um gargalo de desempenho do Oracle, ele é um funil, nunca um commit será mais rápido do que o processo de escrita do Buffer para o RedoLog. E se necessário o banco trava até os processos responsáveis por replicar o conteúdo do RedoLog nos datafiles e arquivar o conteúdo no disco. Este é um ponto a ser avaliado em questão de performance do banco de dados Oracle.

Entendo o que é Backup Oracle

Um banco de dados pode guardar uma enorme quantidade de dados e por isso são feitos backups do banco de dados. Os backups são cópias de segurança, que deverão ser usados caso ocorra alguma falha no software ou hardware que venha a gerar inconsistência da informação.

O SGBD Oracle oferece uma variedade de procedimentos e opções de backup que ajudam a proteger um banco. Quando adequadamente implementada, essas opções permitirão que se faça a recuperação da base de dados.

O Banco de dados Oracle oferece backups lógicos, backups físicos e os backups incrementais. Estes são os tipos de backup que o Oracle faz independente da plataforma (Sistema Operacional) que estiver rodando.

Um backup lógico envolve a leitura de um conjunto de registro do banco de dados e a gravação deste em um arquivo. Este tipo de backup geralmente não é a primeira opção para a restauração de um banco de dado. Contudo é ideal quando se deseja recuperar objeto(s) especifico a nível lógico, como tabelas, views entre outros.

O backup físico envolve a cópia dos arquivos que constituem o banco de dados Oracle. Em geral é a opção mais usada, pois caso ocorra uma falha em apenas um dos arquivos de dados do banco é possível fazer uma restauração e a recuperação apenas deste arquivo, gerando assim menos tempo de indisponibilidade do SGBD. É possível fazer backup's a nível de Sistema Operacional com os comandos cp ou copy, contudo este tipo de backup só é considerado consistente com o banco desligado normalmente. Entretanto o RMAN é a ferramenta mais usada para realizar este tipo de backup, e em conjunto o modo archive é perfeitamente recuperável um banco mesmo tendo backup's inconsistente feito com o banco aberto e disponível para os usuários.

O backup incremental também é um backup físico. Consiste em fazer um backup das transações que ocorreram após o ultimo backup completo, opção disponível quando o banco esta no modo archive que os backups sendo feito pelo Rman.

Protegendo um Banco de Dados Oracle

                                                Multiplexação do ControlFile e LOG de Redo

Como um ControlFile é muito importante a primeira ação a ser feita é a Multiplexação dele. Para isso é preciso desligar o banco de dados.

Multiplexação é a processo de espelhamento, muito usado em disco, o chamado RAID, este processo é feito via hardware, mas neste caso a multiplexação é feito via o software do Oracle e é uma solução para quem não tem como adquirir espelhamento em discos com RAID.

Realize a consulta ”select name from v$controlfile” para saber a localização do ControlFile.

Depois baixe o serviço do Oracle. Logado com SYS execute - shutdown immediate depois faça a copia do arquivo ControlFile.

Feito isso, cola o arquivo em algum diretório, neste exemplo foi criado o diretório “c:\oracle\espelhoControlFile”  e incluir três copias do arquivo. É importante saber que todos os controlfiles devem ter nomes distintos e que o Oracle somente usa um dos arquivos, mas cada alteração feita no controlfile é refletida nos arquivos espelhos. O ideal é que cada copia fique em discos diferentes, mas mesmo que tenha apenas um disco na maquina é aconselhado a criação das copias do controlfile e pelo menos em diretórios diferente como neste exemplo.

É preciso informar ao Oracle a localização dos espelhos do controlFile, para isto acesse  o arquivo de texto INIT.ORA que por padrão fica localizado em “C:\oraclexe\app\oracle\product\10.2.0\server\config\scripts” e alterar o parâmetro Control_file.

Inclua a localização de todos os arquivos, sendo que o 1º e o controlfile que será usado e os demais serão espelhos.

Feito isso inicie o serviço do Oracle indicando o arquivo de parâmetro, para isso execute no SQLPLUS

Startup pfile= C:\oraclexe\app\oracle\product\10.2.0\server\config\scripts\init.ora

Depois disso realize a consulta do controlfile para ver que o banco de dados já tem ciência da copia dos controlfile. Para não precisar subir o banco pelo arquivo init.ora, recrie o SPFILE a partir do pfile.

Se preferir pode alterar o parâmetro pelo SPFILE e depois desligar o banco de dados, copiar os novos controlfile e depois iniciar o banco de dados:

alter system set control_files =
'c:\oraclexe\oradata\XE\control.dbf’,
 'c:\oracle\EspelhoControlFile\control01.ctl',
'c:\oracle\EspelhoControlFile\control02.ctl',
'c:\oracle\EspelhoControlFile\control03.ctl',
 scope = spfile;

 Outro tipo de arquivo que suporta o recurso de multiplexação é o LOG de Redo. Como dito anteriormente o LOG de REDO grava todas as ultimas ações realizada no banco de dados e por isso é importância para recuperação de instância. No mínimo existe dois grupo de LOG de REDO com um membro.

Ao realizar o SQL “select * from v$logfile”, percebe que o Oracle XE vem de fábrica com a configuração mínima, e totalmente insegura, ou seja apenas dois grupos e um arquivo por grupo. Para multiplexar, adicionando membros aos grupos, pasta executar o comando abaixo.

 alter database add logfile member 'C:\ORACLE\ONLINELOG\MEMBRO02.log' to group 1;
 alter database add logfile member 'C:\ORACLE\ONLINELOG\MEMBRO02.log' to group 2;

As mesmas recomendações do controlfile são válidas para o LOG de REDO, se tiver mais de um disco, coloque cada membro em disco separado.

Cada membro serão identicos, assim caso no momento do recover a chance de perder dados minimiza, pois terá vários arquivos que contém as ultimas alteração de dados.

                                                         Trabalhar no Modo Archive

Archive log mode ou Modo de Registro de Arquivamento é um do recurso que cópia o conteúdo do LOG de REDO para outro destino antes deste ser sobrescrito por novas entradas de dados.  Pode-se gravar em até 10 destinos diferente, talvez seja um excesso, mas pelo menos 2 destino um local e outro remoto é primordial para recuperação do banco de dados.

Para conseguir realizar operações fora dos discos locais, é preciso mudar o serviço Oracle no Windows. Por padrão, no Windows o serviço Oracle roda com privilégios de usuário administrador da maquina local, com isso qualquer tentativa de backup e/ou Arquivamento do LOG de REDO fora da maquina local, ocasionará erro de privilégios. Logo, no serviço do Oracle e do Listener altere o Log On de Conta Local para uma conta de Rede.

Feito isso configure o Banco de Dados para modo Achive e dois destinos, um local outro remoto:

1-Conecte com SQL*Plus com usuário SYS com privilegio de SYSDBA.

SQL> connect / as sysdba

2-Sete dois diretório de destino. Note que é necessário incluir uma barra no final do nome do diretório.

           SQL> alter system set log_archive_dest_1='location=C:\bck_oracle\Archive\' scope=spfile;

           SQL> alter system set log_archive_dest_2='location=\\172.16.1.21\particularTI\Alessandro\bck_oracle\ARCH' scope=spfile;

3-Depois desligue, inicie no modo mount, coloque no modo archive e abra o banco.

SQL> shutdown immediate;

SQL> startup mount;
SQL> alter database archivelog;
SQL> alter database open;

Para confirmar que o banco esta no modo ArchiveLog execute as query abaixos:

SQL> select log_mode from v$database;
SQL> select archiver from v$instance;

 Neste momento o Oracle está instruído para nunca sobrescrever os LOG de REDO antes de enviar o conteúdo deste para os dois destinos, isso significa que se o Oracle não conseguir arquivar o LOG de REDO ele irá parar até que resolva o problema que não permite a gravação.

Dois problemas já podem ser mapeados e ajustados aqui para evitá-los. O primeiro consiste em a área de archive encontra-se cheio e o segundo que a rede (ou a maquina remota) encontra-se indisponível.

Para evitar o primeiro problema, é preciso instruir o Oracle que apague os backup’s obsoletos. Para isso logue no rman no prompet de comando:

Rman target sys nocatalog

RMAN> configure retention policy to recovery window of 7 days;

Neste caso o Oracle guardará os backup’s e os archive necessário para restaurar o banco que qualquer tempo dentro da janela de 7 dias. O que não estiver nesta situação e considerado backup obsoleto.

Para evitar o segundo problema execute no SQL PLUS:

   SQL> alter system set log_archive_min_succeed_dest=1 scope=spfile;

 Isso irá instruir o Oracle poder sobrescrever o LOG de REDO caso apenas um destino esteja gravando, neste caso o destino local.

                                                               Conciderações

Nesta primeira parte, foi mostrado para preparar o banco de dados para a recuperação, isto é muito importante, pois em alguns casos, será decisivo se o banco de dados terá ou não recuperação. Com a multiplexção de arquivos importante como o ControlFile e o LogRedo Online, e o o processo archive, que grava em discos todo o conteúdo do  LogRedo Online, antes de sobreescrever a informação, aumenta muito a garantia que não ocorrá perdas de dados.

Na próxima parte, será apresentado a realização de backup's pelo Rman e depois alguns cenários onde será feito a restauração do banco de dados.