Quando Murphi ataca…

Quando o improvável acontece, ter um plano B pode ser a diferença…Bom dia, boa tarde, boa noite! Que bom que você está aqui! Não imagina como tem sido bom ver a audiência do site crescendo tanto a cada dia… Hummm… Fiquei na dúvida será que para blog é audiência? Acho que são visualizações. Bem, mas enfim, é muito bom que você esteja aqui.

Hoje vou comentar um assunto muito interessante e que por tantas vezes nos deparamos com ele em nossas vidas. Aquela situação onde algo que parecia improvável de dar errado acaba dando. Sim! A famosa Lei de Murphi. Um cara que ao contrário do que parece não era pessimista, ele era extremamente precavido e preparado para qualquer coisa que acontecesse.
Sei que no dia a dia é muito difícil de andarmos preparados para todos os embates da vida, é impossível saber tudo que poderá acontecer. Porém sempre falo que muito importante na vida e termos sempre um chamado plano B. Sim, aquele mesmo que já se tornou jargão em palestras, discussões, mas que é muito interessante. Este é o cara que vai te garantir quando um plano principal falhar.

Eu mesmo sempre costumo ter um plano B para tudo na vida, profissionalmente e pessoalmente falando.

Pensando nisso que resolvi escrever o post e a dica de hoje.
Quando falamos em banco de dados Oracle, todos sabemos da importância do arquivo chamado controlfile, não é mesmo? Então relembrando, ele é o arquivo que o banco de dados lê quando passa do estado NOMOUNT para MOUNT, ele é responsável por trazer todos os dados do banco de dados, desde nomes de arquivos até configurações.

Então, é impossível falar na perda do controlfile sem imaginar problema grave no banco de dados. É por isso que todo procedimento de backup sempre fala em cópia dele, também é por isso que multiplexamos, mantemos cópias obrigatoriamente redundantes e com isto mantemos ele 100% seguro. SERÁ????

E se por acaso ocorrer sua perda? Se a peça de backup tiver problema?

Pensando nisso vou colocar uma dica que pode ser o seu plano B para o caso de um desastre sem backup. Como todo plano B ele deve ser elaborado e preparado. Segue abaixo dica de como se preparar para a perda de um arquivo de controle (controlfile) sem backup no RMAN.

Primeiro passo é localizar os controlfiles do banco de dados

    SQL> select name from v$controlfile;

NAME
——————————————————————————–
/u01/app/oracle/oradata/orcl/control01.ctl
/u01/app/oracle/oradata/orcl/control02.ctl
/u01/app/oracle/oradata/orcl/control03.ctl

Depois precisamos verificar onde estão os datafiles por segurança

    SQL> select name from v$datafile;

NAME
——————————————————————————–
/u01/app/oracle/oradata/orcl/system01.dbf
/u01/app/oracle/oradata/orcl/undotbs01.dbf
/u01/app/oracle/oradata/orcl/sysaux01.dbf
/u01/app/oracle/oradata/orcl/users01.dbf

 

Agora os membros do redolog e seu status

SQL> col member format a50
SQL> select a.group#,a.member,b.status from v$logfile a, v$log b where a.group#=b.group#;

GROUP# MEMBER                                             STATUS
———- ————————————————– —————-
3 /u01/app/oracle/oradata/orcl/redo03.log            ACTIVE
2 /u01/app/oracle/oradata/orcl/redo02.log            CURRENT
1 /u01/app/oracle/oradata/orcl/redo01.log            ACTIVE

Agora precisamos criar um arquivo chamado de trace do controlfile. Este arquivo será utilizado para recriação do arquivo caso todos sejam perdidos.

SQL> ALTER DATABASE BACKUP CONTROLFILE TO TRACE  
    2  AS ‘/home/oracle/create_control.sql’;
Database altered.

Com o comando acima será criado no diretório /home/oracle um arquivo com o nome create_control.sql que vai conter os dados conforme veremos abaixo.

Dando um “vi” (comando do Linux para editar) no arquivo poderemos ver o seguinte conteúdo:

   u01/app/oracle/admin/orcl/udump/orcl_ora_10939.trc  
    Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 – Production  
    With the Partitioning and OLAP options  
    ORACLE_HOME = /u01/app/oracle/product/10.2.0/db_1  
    System name: Linux  
    Node name: rac1.localdomain  
    Release: 2.6.9-42.0.0.0.1.ELhugemem  
    Version: #1 SMP Sun Oct 15 14:06:18 PDT 2006  
    Machine: i686  
    Instance name: orcl  
    Redo thread mounted by this instance: 1  
    Oracle process number: 23  
    Unix process pid: 10939, image: oracle@rac1.localdomain (TNS V1-V3)  
      
    *** SERVICE NAME:(SYS$USERS) 2010-09-21 16:52:23.473  
    *** SESSION ID:(142.32) 2010-09-21 16:52:23.473  
    *** 2010-09-21 16:52:23.472  
    — The following are current System-scope REDO Log Archival related  
    — parameters and can be included in the database initialization file.  
    —  
    — LOG_ARCHIVE_DEST=”  
    — LOG_ARCHIVE_DUPLEX_DEST=”  
    —  
    — LOG_ARCHIVE_FORMAT=%t_%s_%r.dbf  
    —  
    — DB_UNIQUE_NAME=”orcl”  
    —  
    — LOG_ARCHIVE_CONFIG=’SEND, RECEIVE, NODG_CONFIG’  
    — LOG_ARCHIVE_MAX_PROCESSES=2  
    — STANDBY_FILE_MANAGEMENT=MANUAL  
    — STANDBY_ARCHIVE_DEST=?/dbs/arch  
    — FAL_CLIENT=”  
    — FAL_SERVER=”  
    —  
    — LOG_ARCHIVE_DEST_10=’LOCATION=USE_DB_RECOVERY_FILE_DEST’  
    — LOG_ARCHIVE_DEST_10=’OPTIONAL REOPEN=300 NODELAY’  
    — LOG_ARCHIVE_DEST_10=’ARCH NOAFFIRM NOEXPEDITE NOVERIFY SYNC’  
    — LOG_ARCHIVE_DEST_10=’REGISTER NOALTERNATE NODEPENDENCY’  
    — LOG_ARCHIVE_DEST_10=’NOMAX_FAILURE NOQUOTA_SIZE NOQUOTA_USED NODB_UNIQUE_NAME’  
    — LOG_ARCHIVE_DEST_10=’VALID_FOR=(PRIMARY_ROLE,ONLINE_LOGFILES)’  
    — LOG_ARCHIVE_DEST_STATE_10=ENABLE  
    —  
    — Below are two sets of SQL statements, each of which creates a new  
    — control file and uses it to open the database. The first set opens  
    — the database with the NORESETLOGS option and should be used only if  
    — the current versions of all online logs are available. The second  
    — set opens the database with the RESETLOGS option and should be used  
    — if online logs are unavailable.  
    — The appropriate set of statements can be copied from the trace into  
    — a script file, edited as necessary, and executed when there is a  
    — need to re-create the control file.  
    —  
    —     Set #1. NORESETLOGS case  
    —  
    — The following commands will create a new control file and use it  
    — to open the database.  
    — Data used by Recovery Manager will be lost.  
    — Additional logs may be required for media recovery of offline  
    — Use this only if the current versions of all online logs are  
    — available.  
    — After mounting the created controlfile, the following SQL  
    — statement will place the database in the appropriate  
    — protection mode:  
    —  ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PERFORMANCE  
    STARTUP NOMOUNT  
    CREATE CONTROLFILE REUSE DATABASE “orcl” NORESETLOGS FORCE LOGGING ARCHIVELOG  
      MAXLOGFILES 16  
      MAXLOGMEMBERS 3  
      MAXDATAFILES 100  
      MAXINSTANCES 8  
      MAXLOGHISTORY 292  
    LOGFILE  
    GROUP 1 ‘/u01/app/oracle/oradata/orcl/redo01.log’  SIZE 5M,  
    GROUP 2 ‘/u01/app/oracle/oradata/orcl/redo02.log’  SIZE 5M,  
    GROUP 3 ‘/u01/app/oracle/oradata/orcl/redo03.log’  SIZE 5M  
    — STANDBY LOGFILE  
    DATAFILE  
    ‘/u01/app/oracle/oradata/orcl/system01.dbf’,  
    ‘/u01/app/oracle/oradata/orcl/undotbs01.dbf’,  
    ‘/u01/app/oracle/oradata/orcl/sysaux01.dbf’,  
    ‘/u01/app/oracle/oradata/orcl/users01.dbf’  
    CHARACTER SET WE8ISO8859P1  
    ;  
    — Configure RMAN configuration record 1  
    VARIABLE RECNO NUMBER;  
    EXECUTE :RECNO := SYS.DBMS_BACKUP_RESTORE.SETCONFIG(‘CONTROLFILE AUTOBACKUP’,’ON’);  
    — Commands to re-create incarnation table  
    — Below log names MUST be changed to existing filenames on  
    — disk. Any one log file from each branch can be used to  
    — re-create incarnation records.  
    — ALTER DATABASE REGISTER LOGFILE ‘/u01/app/oracle/flash_recovery_area/orcl/archivelog/2010_09_21/o1_mf_1_1_%u_.arc’;  
    — ALTER DATABASE REGISTER LOGFILE ‘/u01/app/oracle/flash_recovery_area/orcl/archivelog/2010_09_21/o1_mf_1_1_%u_.arc’;  
    — ALTER DATABASE REGISTER LOGFILE ‘/u01/app/oracle/flash_recovery_area/orcl/archivelog/2010_09_21/o1_mf_1_1_%u_.arc’;  
    — ALTER DATABASE REGISTER LOGFILE ‘/u01/app/oracle/flash_recovery_area/orcl/archivelog/2010_09_21/o1_mf_1_1_%u_.arc’;  
    — Recovery is required if any of the datafiles are restored backups,  
    — or if the last shutdown was not normal or immediate.  
    RECOVER DATABASE  
    — All logs need archiving and a log switch is needed.  
    ALTER SYSTEM ARCHIVE LOG ALL;  
    — Database can now be opened normally.  

Coloquei acima o conteúdo completo para que se familiarize com ele, porém iremos precisar apenas do trecho abaixo que deverá ser salvo em um arquivo com um nome. Eu usarei como exemplo create_control.sql

CREATE CONTROLFILE REUSE DATABASE “orcl” RESETLOGS FORCE LOGGING ARCHIVELOG
MAXLOGFILES 16
MAXLOGMEMBERS 3
MAXDATAFILES 100
MAXINSTANCES 8
MAXLOGHISTORY 292
LOGFILE
GROUP 1 ‘/u01/app/oracle/oradata/orcl/redo01.log’  SIZE 5M,
GROUP 2 ‘/u01/app/oracle/oradata/orcl/redo02.log’  SIZE 5M,
GROUP 3 ‘/u01/app/oracle/oradata/orcl/redo03.log’  SIZE 5M
— STANDBY LOGFILE
DATAFILE
‘/u01/app/oracle/oradata/orcl/system01.dbf’,
‘/u01/app/oracle/oradata/orcl/undotbs01.dbf’,
‘/u01/app/oracle/oradata/orcl/sysaux01.dbf’,
‘/u01/app/oracle/oradata/orcl/users01.dbf’
CHARACTER SET WE8ISO8859P1;

A partir de agora para demostração irei utilizar uma base de teste, onde irei apagar manualmente os controlfiles existentes para simular a situação. É claro que isso só deve ser feito em bases teste. Hummmm será que eu precisava ter falado isso?? Bem, aprendi que é melhor pecar pelo excesso.

Removendo os controlfiles manualmente para teste.

SQL> host rm -rf /u01/app/oracle/oradata/orcl/control01.ctl
SQL> ! rm -rf /u01/app/oracle/oradata/orcl/control02.ctl
SQL> ! rm -rf /u01/app/oracle/oradata/orcl/control03.ctl

Feito isso basta baixar o banco e tentar subir ele novamente.
SQL> shutdown immediate

Tentando subir
SQL> startup
ORACLE instance started.

Total System Global Area  444596224 bytes
Fixed Size                  1219904 bytes
Variable Size             167772864 bytes
Database Buffers          272629760 bytes
Redo Buffers                2973696 bytes
ORA-00205: error in identifying control file, check alert log for more info

Situação do banco de dados:
Foram perdidos todos os controlfiles, logo o banco não poderá subir. Para resolver este problema precisa ser rodado o script de criação deles.

1- Rodando no SQLPLUS arquivo de criação dos controlfiles:

SQL> @/home/oracle/Desktop/create_control.sql
Control file created.

2- Tentando abrir o banco com resetlogs

SQL> alter database open resetlogs;
alter database open resetlogs
*
ERROR at line 1:
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: ‘/u01/app/oracle/oradata/orcl/system01.dbf’

Apresentou erro, pois o arquivo do system não está consistente e necessita de recover

3- Tentando recover com cláusula until cancel

SQL> recover database using backup controlfile until cancel;
ORA-00279: change 557988 generated at 09/21/2010 16:13:51 needed for thread 1
ORA-00289: suggestion :
/u01/app/oracle/flash_recovery_area/orcl/archivelog/2010_09_21/o1_mf_1_4_%u_.arc
ORA-00280: change 557988 for thread 1 is in sequence #4

Specify log: {=suggested | filename | AUTO | CANCEL}
auto
ORA-00308: cannot open archived log
‘/u01/app/oracle/flash_recovery_area/orcl/archivelog/2010_09_21/o1_mf_1_4_%u_.arc’
ORA-27037: unable to obtain file status
Linux Error: 2: No such file or directory
Additional information: 3

ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: ‘/u01/app/oracle/oradata/orcl/system01.dbf’

4- Ocorreu que não foi encontrado o archivelog dentro da flash_recovery_area, neste momento temos uma carta na manga, aplicar a recuperação diretamente do redolog file que está ativo. Para isso precisaremos localizar qual o que tem status “ACTIVE”.

Rode o select para localizar qual o que tem status “ACTIVE”.

SQL> col member format a50
SQL> select a.group#,a.member,b.status from v$logfile a, v$log b where a.group#=b.group#;

GROUP# MEMBER                                             STATUS
———- ————————————————– —————-
3 /u01/app/oracle/oradata/orcl/redo03.log            ACTIVE
2 /u01/app/oracle/oradata/orcl/redo02.log            CURRENT
1 /u01/app/oracle/oradata/orcl/redo01.log            ACTIVE

 

5- Feito isso tente novamente o recover database com a mesma cláusula:
USING BACKUP CONTROLFILE UNTIL CANCEL, quando ele disser que necessita de um determinado archivelog, ele vai fazer a pergunta se você deseja:
aceitar a sugestão –> suggested
filename–> Definir você o local (é este que vamos usar abaixo)
AUTO –> deixar ele definir automaticamente
CANCEL –> Cancelar.

SQL> recover database using backup controlfile until cancel;
ORA-00279: change 557988 generated at 09/21/2010 16:13:51 needed for thread 1
ORA-00289: suggestion (neste momento ele sugere, mas não vamos aceitar vamos inserir o endereço do redolog ativo) :
/u01/app/oracle/flash_recovery_area/orcl/archivelog/2010_09_21/o1_mf_1_4_%u_.arc
ORA-00280: change 557988 for thread 1 is in sequence #4
Specify log: {=suggested | filename | AUTO | CANCEL}
/u01/app/oracle/oradata/orcl/redo02.log (QUE É O CURRENT)
Log applied.
Media recovery complete.

A mensagem acima é a que precisamos/queremos ver.

6- Feito isso abre-se o banco de dados com a opção resetlogs.

SQL> alter database open resetlogs;
Database altered.

 

7- Rodamos a verificação do modo archivelog

SQL> archive log list;
Database log mode              Archive Mode
Automatic archival             Enabled
Archive destination            USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence     0
Next log sequence to archive   1
Current log sequence           1

DICA IMPORTANTE: Sempre que abrir um banco com o modo resetlogs faça o quando antes um backup full, pois cria-se neste momento uma nova incarnação para os archivelogs.

Esta era a dica de hoje. Espero que tenha curtido, que comente divulgue, compartilhe com os amigos. Assim quando mais compartilhamentos mais assuntos.

Grande abraço para todos, muito sucesso, paz e muita luz. E é claro!!! FOCO NA METAAAAA!!!!

Sobre raul andrade

DBA e Instrutor Oracle, apaixonado pela minha família e por ensinar.
Esta entrada foi publicada em DBA Oracle. Adicione o link permanente aos seus favoritos.

Deixe um comentário