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