Backup e Recovery de Control Files no Oracle

04 out

Backup e Recovery de Control Files no Oracle

Design sem nome (2)

Backup e Recovery de Control Files no Oracle

 

Aprenda como realizar recovery de control files nesse Laboratório.

 

Neste laboratório vamos trabalhar com dois cenários, aprendendo a como restaurar os arquivos de configuração (Recovery de Control Files) do banco de dados Oracle.

 

  • Cenário 1: Perda de todos os control files, recuperação a partir do autobackup
  • Cenário 2: Perda de todos os control files, recuperação sem backup usando SNAPSHOT CONTROLFILE

O que é um Control File? Um Control File é um pequeno arquivo binário que faz parte de um banco de dados. Ele é usado para acompanhar o status e a estrutura física do banco de dados, sendo atualizado constantemente pelo Oracle durante sua utilização, ficando disponível para escrita apenas quando o banco de dados está aberto, ou seja, OPEN. Caso o arquivo de controle não esteja acessível por alguma razão, o banco de dados não irá funcionar corretamente, podendo trazer problemas ao iniciar a instância.

 

Pré-requisitos para o Lab:

Possuir um servidor Linux com banco de dados Oracle 11g ou 12c. Copiar o script crashmanager.sh para o diretório /home/oracle com as permissões:

 

[sql]
# chmod 775 /home/oracle/crashmanager.sh
# chown oracle:oinstall /home/oracle/crashmanager.sh
[/sql]

 

Definições importantes:

 

Estrutura física

 

Arquivos e outras estruturas que compõem o banco de dados Oracle e protegem de possíveis falhas.

 

Datafiles e Data Blocks

 

Um banco de dados consiste em uma ou mais unidades lógicas chamadas tablespaces. Cada tablespace consiste em um ou mais arquivos de dados chamados datafiles.

 

O banco de dados gerencia o espaço armazenamento nos datafiles em unidades denominadas data blocks. Os data blocks são as menores unidades de armazenamento que o banco de dados pode usar ou alocar. As cópias dos datafiles são uma parte crítica de qualquer backup.

 

Redo Logs

 

Redo logs registra todas as alterações feitas nos datafiles. Cada vez que os dados são alterados no banco de dados, essa alteração é gravada primeiro no registro de redo log online, antes de ser aplicada nos datafiles.

 

Se um backup de um datafile em algum ponto do tempo e um conjunto completo de redo logs a partir de ponto para frente estiverem disponíveis, o banco de dados pode reaplicar as alterações registradas nos redo logs, para reconstruir o conteúdo do datafile em qualquer ponto entre o último backup e o final do último registro do redo log. No entanto isto só é possível se o banco estiver com o modo de archive log habilitado.

 

Sem archive redo logs, suas opções de backup e recuperação são severamente limitadas.

 

Control Files

 

 O arquivo de controle contém o registro das estruturas físicas do banco de dados e seu status. Vários tipos de informações armazenadas no arquivo de controle estão relacionados ao backup e recuperação:

 

  • Informações do banco de dados (resetlogs scn e time stamp)
  • Registros do tablespace e datafile (filenames, datafile checkpoints, read/write status, offline ranges)
  • Informações sobre redo (current online redo log)
  • Registros de log (log sequence numbers, intervalo SCN em cada log)
  • Um registro dos backups anteriores do RMAN
  • Informações sobre blocos corrompidos de datafile

 

Undo Segments

 

 Em geral, quando os dados em um datafile são atualizados, antes as imagens desses dados são escritas no undo segments. Se uma transação for revertida (rolled back), essas informações da undo podem ser usadas para restaurar o conteúdo do arquivo de datafile original.

 

No contexto da recuperação, as informações da undo são usadas para desfazer os efeitos das transações não confirmadas, uma vez que todas as alterações do arquivo de dados dos registros de redo foram aplicadas aos arquivos de datafiles.

 

Você não deve se preocupar com undo segments ou gerenciá-los diretamente como parte do seu backup ou processo de recuperação.

 

Cenário 1: Perda de todos os control files, recuperação a partir do autobackup

 

[sql]

$ rman target /
RMAN> show all;
RMAN> configure controlfile autobackup on; // Sem que for executado algum backup
RMAN> report schema;
RMAN> backup datafile 6; // Use o datafile users
RMAN> quit;

$ sh /home/oracle/crashmanager.sh // Executar crashmanager e selecionar a opção 2.

[/sql]

 

Deixar alert log aberto em um terminal

[sql]

$ tail - f $ORACLE_BASE/diag/rdbms/wint/WINT/trace/alert_WINT.log
$ sqlplus / as sysdba

SQL> select count(*) from all_users; // Executar operação normal
SQL> shutdown abort;
SQL> quit;

$ rman target /

RMAN> startup nomount;
RMAN> restore controfile from autobackup;
RMAN> alter database mount;
RMAN> alter database open; // Controlfile está desatualizado, é necessário atualizar com recover database
RMAN> recover database;
RMAN> alter database open; // Ocorre um erro, será necessário criar uma nova encarnação do banco
RMAN> list incarnation; // Verificando encarnação
RMAN> alter database open resetlogs;
RMAN> list incarnation; // Verificando a nova encarnação
RMAN> backup database; // É recomendado fazer um backup completo
RMAN> quit

[/sql]

 

Cenário 2: Perda de todos os control files, recuperação sem backup usando SNAPSHOT CONTROLFILE

 

[sql]

$ rman target /

RMAN> show all; // Snapshot é realizado sempre que é iniciado o backup
RMAN> list backup of controlfile
RMAN> quit;

$ rm -rf /u01/app/oracle/fast_recovery_area/autobackup
$ sh /home/oracle/crashmanager.sh // Executar crashmanager e selecionar a opção 2.

[/sql]

 

Deixar alert log aberto em um terminal

 

[sql]

$ tail - f $ORACLE_BASE/diag/rdbms/wint/WINT/trace/alert_WINT.log
$ sqlplus / as sysdba

SQL> select count(*) from all_users; // Executar operação normal
SQL> shutdown abort;
SQL> quit;

$ cd $ORACLE_HOME/dbs
$ ls -l // Encontre o arquivo snapcf_WINT.f

// Podemos verificar os diretórios dos control files abrindo o arquivo spfileWINT.ora

$ strings spfileWINT.ora
$ cp snapcf_WINT.f  /u01/oradata/WINT/controle/control01.ctl
$ cp snapcf_WINT.f /u01/oradata/WINT/espelhocontrole/control02.ctl

$ rman target /

RMAN> startup mount;
RMAN> recover database;
RMAN> alter database open resetlogs; // Será necessário criar uma nova encarnação do banco
RMAN> list incarnation; // Verificando a nova encarnação
RMAN> backup database; // É recomendado fazer um backup completo
RMAN> quit;

[/sql]

 

 

Referências Bibliográficas:

http://docs.oracle.com/cd/B19306_01/backup.102/b14192/intro002.htm

https://docs.oracle.com/cd/B19306_01/backup.102/b14192/recov004.htm

https://sourceforge.net/projects/crashmanager/files/crashmanager/

https://www.youtube.com/watch?v=seRGtJ5nka8&t

https://www.youtube.com/watch?v=kPmGIFpXARM