Um backup Image copy é mais rápido para o restore e para o DBA tempo é tudo.
Quando um datafile é restaurado de um image copy a estrutura do datafile já existe, é o famoso backup/restore bit-a-bit. O Oracle tem o dever de pegar o bit do backup e colocar no disco, diferente de um backupset que ele tem que montar a estrutura física no disco.
Aqui eu mostro o processo na prática de um backup e restore, de um datafile. Não preciso nem dizer para não realizar esse teste em um ambiente de produção né
Prmeiro vamos ao backup do datafile example01.dbf
$ rman target / Recovery Manager: Release 11.2.0.2.0 - Production on Mon Oct 3 20:43:20 2011 Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved. connected to target database: DBTST (DBID=2973952248) RMAN> report schema; using target database control file instead of recovery catalog Report of database schema for database with db_unique_name DBTST List of Permanent Datafiles =========================== File Size(MB) Tablespace RB segs Datafile Name ---- -------- -------------------- ------- ------------------------ 1 700 SYSTEM *** /u01/app/oracle/oradata/dbtst/system01.dbf 2 600 SYSAUX *** /u01/app/oracle/oradata/dbtst/sysaux01.dbf 3 200 UNDOTBS1 *** /u01/app/oracle/oradata/dbtst/undotbs01.dbf 4 2203 USERS *** /u01/app/oracle/oradata/dbtst/users01.dbf 5 1024 EXAMPLE *** /u01/app/oracle/oradata/dbtst/example01.dbf List of Temporary Files ======================= File Size(MB) Tablespace Maxsize(MB) Tempfile Name ---- -------- -------------------- ----------- -------------------- 1 34 TEMP 32767 /u01/app/oracle/oradata/dbtst/temp01.dbf RMAN> backup as copy datafile 5 format '/u01/app/oracle/backup/dbtst/example01.bkp'; Starting backup at 03-OCT-11 allocated channel: ORA_DISK_1 channel ORA_DISK_1: SID=32 device type=DISK channel ORA_DISK_1: starting datafile copy input datafile file number=00005 name=/u01/app/oracle/oradata/dbtst/example01.dbf output file name=/u01/app/oracle/backup/dbtst/example01.bkp tag=TAG20111003T204407 RECID=1 STAMP=763591516 channel ORA_DISK_1: datafile copy complete, elapsed time: 00:01:15 Finished backup at 03-OCT-11
Vamos agora remover o datafile example01.dbf do disco:
$ rm /u01/app/oracle/oradata/dbtst/example01.dbf
Novamente ao RMAN, vamos aproveitar o image copy e realizar o switch para ele:
RMAN> list copy of datafile 5;
using target database control file instead of recovery catalog
List of Datafile Copies
=======================
Key File S Completion Time Ckp SCN Ckp Time
------- ---- - --------------- ---------- ---------------
1 5 A 03-OCT-11 348805 03-OCT-11
Name: /u01/app/oracle/backup/dbtst/example01.bkp
Tag: TAG20111003T204407
RMAN> sql 'alter database datafile 5 offline';
sql statement: alter database datafile 5 offline
RMAN> switch datafile 5 to copy;
datafile 5 switched to datafile copy "/u01/app/oracle/backup/dbtst/example01.bkp"
RMAN> recover datafile 5;
Starting recover at 03-OCT-11
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=33 device type=DISK
starting media recovery
media recovery complete, elapsed time: 00:00:01
Finished recover at 03-OCT-11
RMAN> sql 'alter database datafile 5 online';
sql statement: alter database datafile 5 online
$ sqlplus / as sysdba
SQL*Plus: Release 11.2.0.2.0 Production on Mon Oct 3 20:52:48 2011
Copyright (c) 1982, 2010, Oracle. All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SQL> select name from v$dbfile;
NAME
--------------------------------------------------------------------------------
/u01/app/oracle/oradata/dbtst/system01.dbf
/u01/app/oracle/oradata/dbtst/sysaux01.dbf
/u01/app/oracle/oradata/dbtst/undotbs01.dbf
/u01/app/oracle/oradata/dbtst/users01.dbf
/u01/app/oracle/backup/dbtst/example01.bkp
Cuidem de sua infra estrutura e de seus backups ou você pode ficar sem banco de dados !
ORA-00600: internal error code, arguments: [kccpb_sanity_check_2], [2101], [2100], [0x0], [], [], [], []
Início da história … a noite anterior o erro, houve um corte de energia sem motivo aparente e os no-breaks pra variar não aguentaram, decorrer da história já deu até para imaginar … Banco danificado!
Já no outro dia verificando como estava a saúde do ambiente depois do impacto, aparentemente tudo normal. Sistema Operacional Linux Red Hat Enterprise 5 trabalhando, nenhum erro nos logs apesar da queda
Hora de checar o banco, bem nele, que as coisas começam a piorar …
Ao executar um simples startup do banco, para desespero de todos, um ORA-600 é disparado na tela. O interessante que o erro não sinalizava nada no meta link pela versão de banco 10.2.0.3.
Verificando o alert log do banco foi fácil perceber que o problema estava sendo disparado bem na hora de ler os controlfiles. Pensei, que algum controlfile devia estar corrompido. Teria sido muito mais fácil se os controlfiles estivessem multiplexados … tirava o ruim, copiava um novo de um bom e pronto, é … teria sido rápido … mais eles não estavam multiplexado. Tudo estava um um group ASM chamado DATA de um único disco.
Como havia backup horas antes do problema e tudo o archive necessário até aquele momento, a operação de recuperação do banco foi tranquila apesar do susto e nem muito demorada apesar do tamanho do banco. Foi simplesmente restaurado o controlfile de um backup controlfile, feito o recover do banco e aplicado os archives até o momento da queda. Nenhum dado perdido, nenhuma informação deixada para atrás … assim é o Oracle : )
RMAN> restore controlfile from '/backup/bkp_controlfile.ctl'; RMAN> recover database;
Apesar de todo o susto, no final foi deu tudo certo para esse ambiente, mais nem sempre é assim. Já vi empresas perderem muito dinheiro por não terem cuidado simples, como validação de backup e manutenção em seus equipamentos (no-breaks, gerados, etc …). Ter uma infra estrutura e uma equipe técnica preparada e pronto para atender, faz muita diferença na hora resolver problemas e catástrofes como essas.
Em algumas situações, há a necessidade de guardar determinado backup além da retenção definida pelo RMAN.
Hoje em dia, existem leis que exigem que determinado backup seja armazenado por um tempo definido. É nesse momento que a desconsiderar a retenção do RMAN faz toda diferença.
No exemplo abaixo, estou demonstrado que o backup do dataflie 4 será armazenado em minha retenção do RMAN como 30 dias ignorando minha retenção padrão, o backup do datafile 4 só será considerada obsolete depois de 30 dias.
RMAN> backup datafile 4 keep until time "sysdate+30"; Starting backup at 07-APR-11 current log archived using target database control file instead of recovery catalog allocated channel: ORA_DISK_1 channel ORA_DISK_1: SID=55 device type=DISK backup will be obsolete on date 07-MAY-11 archived logs required to recover from this backup will be backed up channel ORA_DISK_1: starting full datafile backup set channel ORA_DISK_1: specifying datafile(s) in backup set input datafile file number=00004 name=/oracle/oradata/orcl/users01.dbf channel ORA_DISK_1: starting piece 1 at 07-APR-11 channel ORA_DISK_1: finished piece 1 at 07-APR-11 piece handle=/oracle/backup/ORCL_1_4.bkp tag=TAG20110407T222922 comment=NONE channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01 using channel ORA_DISK_1 backup will be obsolete on date 07-MAY-11 archived logs required to recover from this backup will be backed up channel ORA_DISK_1: starting full datafile backup set channel ORA_DISK_1: specifying datafile(s) in backup set including current SPFILE in backup set channel ORA_DISK_1: starting piece 1 at 07-APR-11 channel ORA_DISK_1: finished piece 1 at 07-APR-11 piece handle=/oracle/backup/ORCL_1_5.bkp tag=TAG20110407T222922 comment=NONE channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01 current log archived using channel ORA_DISK_1 backup will be obsolete on date 07-MAY-11 archived logs required to recover from this backup will be backed up channel ORA_DISK_1: starting archived log backup set channel ORA_DISK_1: specifying archived log(s) in backup set input archived log thread=1 sequence=7 RECID=5 STAMP=747872969 channel ORA_DISK_1: starting piece 1 at 07-APR-11 channel ORA_DISK_1: finished piece 1 at 07-APR-11 piece handle=/oracle/backup/ORCL_1_6.bkp tag=TAG20110407T222922 comment=NONE channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01 using channel ORA_DISK_1 backup will be obsolete on date 07-MAY-11 archived logs required to recover from this backup will be backed up channel ORA_DISK_1: starting full datafile backup set channel ORA_DISK_1: specifying datafile(s) in backup set including current control file in backup set channel ORA_DISK_1: starting piece 1 at 07-APR-11 channel ORA_DISK_1: finished piece 1 at 07-APR-11 piece handle=/oracle/backup/ORCL_1_7.bkp tag=TAG20110407T222922 comment=NONE channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01 Finished backup at 07-APR-11
Veja que até os archives são guardados na retenção e também não são removidos caso seja requisitado a execução os archives obsoletos.
Agora, se você deseja deixar guardado somente o BACKUP ignorando os archives basta executar usar a palavra chave nologs, ou seja ele permite no entando, que o RMAN remova os archives logs que seriam necessário para recuperar o backup.
