Conceitos de backup e recover em relação ao Oracle

Por Felipe Romeu Gregolewitsch
Postado en dezembro 2011

Este artigo tem o objetivo de introduzir alguns conceitos de backup e recover em relação ao Oracle, bem como explicar o papel do SCN durante as situações do cotidiano.

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.

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.

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.

- 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.

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 para completar, o é 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’

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 vamos comprovar, 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, espero ter colaborado em alguma coisa no seu dia-a-dia.
Qualquer dúvida, sugestão ou reclamação estou à disposição.





Postado por Felipe Romeu Gregolewitsch.