Introdução ao RMAN – Conceitos de backup e recover

Introdução ao RMAN – Conceitos de backup e recover

Pessoal, olá!

Vamos então começar a nossa sessão de RMAN com uma rápida introdução aos conceitos de backup e recover.

Irei, no começo de cada artigo, citar todas as fontes que utilizei para estudo\criação dos mesmos, fiquem a vontade para consultar os materiais.

Lembrando que estou, assim como muitos que provavelmente irão ler este artigo, começando com RMAN, logo, minhas dúvidas poderão ser suas dúvidas ou vice-versa e prometo que irei tentar responder quaisquer questões que sejam deixadas nos comentários.

Queria dedicar este parágrafo com um agradecimento especial ao Rodrigo Almeida, que além de ler o artigo ainda me deu uns toques super úteis e bacanas para corrigir\complementar, coisa de gente que sabe!

Vamos ao que interessa!

Parte 1 – Conceitos.

O que é um backup?

Um backup é uma cópia de arquivos\dados que existe para garantir a restauração dos mesmos em caso de falha.

Uma falha pode ser desde uma corrupção de arquivos, falha de hardware, sinistros (incêndio, tsunamis) até erro de usuário (drops acidentais, exclusão de arquivos, má aplicação de atualizações).

Quais são os tipos de backup?

Falando agora diretamente de Oracle nós temos dois tipos de backups:

• Backups Lógicos: Que contêm dados e\ou definições de objetos. Um exemplo comum de backup lógico é o famoso export\import através do datapump pois ele gera nada mais do que um arquivo binário com as definições de estrutura, índices, grants, dados (e o que mais você quiser) para importação.

• Backups Físicos: Que contém os arquivos físicos do banco de dados como datafiles, archive logs ou controlfiles.

Podem ser feitos pelo banco (RMAN ou manualmente com o BEGIN\END BACKUP) ou diretamente pelo usuário administrador via servidor.

Backups Consistentes e inconsistentes

Dentro dos backups físicos ainda temos dois subtipos que também são muito importantes.

• Backups Consistentes (também conhecidos como cold backup):  Feitos com a base “desligada” ou em modo mount.

Consiste basicamente em fazer um backup sem que a base esteja com transações ativas, garantindo assim que todas as transações previamente realizadas estejam consistentes.

A característica deste tipo de backup é que há a garantia de que todos os SCNs estão idênticos, ou seja, todas as alterações que estavam no redo log e no buffer estão gravadas nos datafiles.

• Backups Inconsistentes (também conhecidos como hot backup): Feitos com a base aberta e gerando transações.

Como o banco está sendo constantemente utilizado antes, durante e depois do backup os SCNs geralmente nunca batem (daí o nome inconsistente), o que faz o sistema depender dos archived logs para posterior recuperação.

Conforme podemos analisar das afirmações é certo que backups inconsistentes necessitam que a base esteja em modo ARCHIVELOG.

Ainda temos outros tipos de backup que serão abordados durante os próximos capítulos.

O que é uma recuperação?

Uma recuperação é o processo de reconstruir\restaurar arquivos ou dados que tenham sofrido algumas das catástrofes citadas no parágrafo de backup (sim, os usuários também entram em “catástrofes” =D).

Geralmente envolvem duas fases:

• Restaurar o arquivo físico, que nada mais é do que pegar o arquivo do backup e deixar o mesmo disponível para a database (conhecida como Fase de Restore).
• Recuperar os dados aplicando os on-line\archived redo a fim de trazer a base ao ponto mais atual antes de falha (conhecida como Fase de Recover).

No Oracle existem três tipos básicos de recuperação:

• Instance recovery:

Realizado pelo próprio banco após uma queda anormal ou um shutdown abort, é feito com o objetivo de garantir a integridade dos dados, aplica no banco o que está em redo (commitados) e da rollback no que estiver em undo (não commitados).

Neste processo não há intervenção do usuário.

• Media recover:

É a recuperação de algum arquivo que está danificado (devido a uma falha de disco por exemplo).

Temos como casos de media recovery as recuperações de SPfiles, datafiles ou controlfiles.

Neste processo há intervenção do usuário pois o sistema precisa receber as informações de o que restaurar e onde estão os dados de backup.

Uma vez recuperado o arquivo o sistema irá analisar se há a necessidade de Recovery, se houver o mesmo irá realizar este passo sem intervenção (A menos que você especifique que queira interferir como com o comando “RECOVER DATABASE UNTIL CANCEL”).

Lembrando apenas que essa ação não é realizada pelo RMAN. Pois o RMAN não faz recuperação UNTIL CANCEL, somente LOG SEQUENCE, TIME ou SCN, as quais serão abordadas em capítulos posteriores.

• Recover Completo\Incompleto e Point-in-Time:

Recover completo é o processo de trazer a base de dados para o momento mais atual após a falha, sem nenhuma perda dos dados commitados.

Por exemplo, você teve um problema às 10 da manhã, mas possui os backups certinhos e os archives até antes da falha, então, você irá restaurar os arquivos com problema e o sistema aplicará se necessário os archives para trazer todos os dados dos arquivos até 9:59, praticamente Zero de perda.

Porém nem sempre isto será possível, por exemplo, se você precisa voltar um DROP TABLE incorreto de um usuário que foi feito as 9:00 e agora já são 10:00 é impossível utilizar uma recuperação completa pois a mesma irá manter as informações do último horário.

Nestas situações é realizada uma operação de recover incompleto (também conhecida como Point-in-Time) que é voltar à base a um SCN que não seja último para consertar um erro de usuário ou na falta de um archive (O que pelo amor de seus empregos não recomendo que aconteça).

Temos como uma opção ao Point-in-Time recovery (como no exemplo do DROP TABLE ou de um UPDATE INCORRETO) a funcionalidade de Flashback, porém não iremos abordar a mesma nestes artigos.

E pra completar a parte de hoje, o que diabos é um SCN?

SCN (System Change Number) é um número em formato atômico mantido pelo Oracle para registrar quais alterações foram feitas no seu banco de dados.

Toda vez que um commit é aplicado um novo SCN é gerado marcando os arquivos para que o Oracle saiba onde e quanto de recuperação deverá ser aplicado em caso de falha, lembrando que o CONTROL FILE é o coração deste processo pois ele é o responsável por dizer ao Oracle quais os SCNs corretos.

O primeiro SCN é gravado já logo após o commit, quando o LGWr grava os dados do log buffer para o redo ele leva também um SCN identificando que aquela transação foi realizada com sucesso.

Os outros SCN são gravados a cada checkpoint no banco de dados, como sabemos o checkpoint grava as informações contidas nos blocos de memória (Database Buffer) para os arquivos em disco (datafiles) e ao fazer atualiza o controlfile e os datafiles envolvidos no processo com o respectivo SCN.

Quando o processo termina o Oracle entende que todos os datafiles envolvidos foram gravados com sucesso e que, em caso de falha, só o que ocorrer depois deste checkpoint deverá ser recuperado.

No banco de dados, para garantir os dados e a integridade da base, temos então os seguintes SCNs

• SCN dos datafiles: A cada checkpoint completo o Oracle marca o datafile com o SCN mais recente.

sys@ORCL> select name,checkpoint_change# from v$datafile;

NAME                                       CHECKPOINT_CHANGE#
--------------------------------------     ------------------
/u01/oracle/oradata/ORCL/system01.dbf      6124985
/u01/oracle/oradata/ORCL/undotbs01.dbf     6124985
/u01/oracle/oradata/ORCL/sysaux01.dbf      6124985
/u01/oracle/oradata/ORCL/users01.dbf       6124985
/u02/oracle/oradata/ORCL/DADOS.dbf         6124985

• SCN do controlfile: A cada checkpoint completo o Oracle marca o controlfile com o SCN mais recente.

sys@ORCL> select checkpoint_change# from v$database;

CHECKPOINT_CHANGE#
------------------
6124985

• SCN inicial: Dentro do cabeçalho do Datafile temos o SCN inicial que nada mais é do que um valor gravado para identificar se este arquivo irá necessitar de recuperação durante a próxima inicialização da instância.

sys@ORCL> select name,checkpoint_change# from v$datafile_header;

NAME                                       CHECKPOINT_CHANGE#
--------------------------------------     ------------------
/u01/oracle/oradata/ORCL/system01.dbf      6124985
/u01/oracle/oradata/ORCL/undotbs01.dbf     6124985
/u01/oracle/oradata/ORCL/sysaux01.dbf      6124985
/u01/oracle/oradata/ORCL/users01.dbf       6124985
/u02/oracle/oradata/ORCL/DADOS.dbf         6124985

• SCN final: Durante o processo de uso normal da base, todos os SCN de controlfiles, o SCN dos datafiles e o SCN inicial do cabeçalho estão idênticos e o SCN final está marcado como NULL.

sys@ORCL> select name,last_change# from v$datafile;

NAME                                       LAST_CHANGE#
--------------------------------------     ------------------
/u01/oracle/oradata/ORCL/system01.dbf
/u01/oracle/oradata/ORCL/undotbs01.dbf
/u01/oracle/oradata/ORCL/sysaux01.dbf
/u01/oracle/oradata/ORCL/users01.dbf
/u02/oracle/oradata/ORCL/DADOS.dbf

Durante o desligamento da base, caso o mesmo seja feito de forma limpa (shutdown immediate ou normal) o Oracle irá definir um valor para o SCN final.

Vamos confirmar os valores, use o comando shutdown immediate seguido de um startup mount e depois digite o seguinte comando.

sys@ORCL> select name,checkpoint_change#,last_change# from v$datafile;

NAME                                       CHECKPOINT_CHANGE#  LAST_CHANGE#
--------------------------------------     ------------------  ------------
/u01/oracle/oradata/ORCL/system01.dbf      6127897             6127897
/u01/oracle/oradata/ORCL/undotbs01.dbf     6127897             6127897
/u01/oracle/oradata/ORCL/sysaux01.dbf      6127897             6127897
/u01/oracle/oradata/ORCL/users01.dbf       6127897             6127897
/u02/oracle/oradata/ORCL/DADOS.dbf         6127897             6127897

Ao iniciar novamente a base de dados caso os valores Inicial e Final não coincidam o Oracle entende que aquele datafile precisa de recuperação.

Após completar com sucesso a inicialização do banco o controlfile seta como NULL todos os SCN finais.

sys@ORCL> alter database open;

Database altered.

sys@ORCL> select name,checkpoint_change#,last_change# from v$datafile;

NAME                                             CHECKPOINT_CHANGE#  LAST_CHANGE#
--------------------------------------     ------------------                          ------------
/u01/oracle/oradata/ORCL/system01.dbf      6127898
/u01/oracle/oradata/ORCL/undotbs01.dbf     6127898
/u01/oracle/oradata/ORCL/sysaux01.dbf      6127898
/u01/oracle/oradata/ORCL/users01.dbf       6127898
/u02/oracle/oradata/ORCL/DADOS.dbf   6127898

Explicando o papel do SCN durante uma recuperação de arquivo.

No exemplo tivemos um erro no datafile 5 (Dados) e o mesmo precisou ser restaurado.

Porém ao executar o restore eu não efetuei o recovery, vejamos como fica a base ao tentar abrir

idle> startup

ORACLE instance started.

Total System Global Area  285212672 bytes

Fixed Size                  1267068 bytes

Variable Size             150997636 bytes

Database Buffers          130023424 bytes

Redo Buffers                2924544 bytes

Database mounted.

ORA-01113: file 5 needs media recovery

ORA-01110: data file 5: '/u02/oracle/oradata/ORCL/DADOS.dbf'

Opa… o sistema não conseguiu bater o valor que possuía no SCN do controlfile com o do arquivo (que por ter sido restaurado é mais antigo).

Mas como temos os céticos vamos provar, com a base em modo mount execute os seguintes comandos.

idle> select file#,change# from v$recover_file;

FILE#    CHANGE#
---------- ----------
5    5955546

A v$recovery_file faz justamente o trabalho de mostrar quais arquivos estão com os SCNs incorretos e precisam de recuperação.

Outra sugestão é verificar o conteúdo do SCN da V$datafile juntamente com o SCN do cabeçalho, abaixo, na primeira linha vemos o SCN atual do arquivo e na segunda linha o SCN que ele deveria estar.

idle> select name,checkpoint_change# from v$datafile where FILE# = 5
union
select name,checkpoint_change# from v$datafile_header where FILE# = 5;

NAME                                                           CHECKPOINT_CHANGE#
-------------------------------------                     ------------------
/u02/oracle/oradata/ORCL/DADOS.dbf        5955546
/u02/oracle/oradata/ORCL/DADOS.dbf        6153406

Não temos outra escolha, hora do recover!

Portanto se todos os archives\on-line redo estiverem disponíveis para trazer o arquivo ao SCN desejado o sistema irá prosseguir sem erro.

idle> recover database;

Media recovery complete.

Agora é só subir a base.

idle> alter database open;

Database altered.

Bom, é isso pessoal, espero ter colaborado em alguma coisa no seu dia-a-dia.

No próximo artigo continuaremos agora dando a introdução aos conceitos do RMAN.

Qualquer dúvida, sugestão ou reclamação os comentários estão à disposição.

Abraços!

Fontes

• Guia Backup and Recovery Basics – (Oracle®) – Obtido em http://www.oracle.com/pls/db102/portal.portal_db?selected=3
• Guia Backup and Recovery Advanced User’s Guide – (Oracle®) – obtido em http://www.oracle.com/pls/db102/portal.portal_db?selected=3
• OCP: Oracle 10g Administration II Study Guide – (Sybex®)
• Doug Stuns,Tim Buterbaugh,Bob Bryla
• Oracle Database 10g OCP Certification All-In-One Exam Guide – (Oracle Press®)
• Damir Bersinic, John Watson
• Blog: neeraj-dba.blogspot.com