Blog Flávio Soares
Oracle, Database, Data Guard, RAC, Performance, Exadata, ASM, Goldengate, Troubleshooting
June 20, 2012
Há uma maneira correta de montar a NFS em dispositivos NAS para os arquivos de dados Oracle? A resposta é Sim! E existem muitos NFS por aí montados para ambientes Oracle de maneira errada, não de acordo com as exigências da Oracle.
De acordo com o Oracle, as opções necessárias para montar uma NFS para um datafile são as seguintes:
rw,bg,hard,rsize=32768,wsize=32768,vers=3,nointr,timeo=600,tcp,actimeo=0*
Isso também se faz necessários para NFS onde backups RMAN são executados, evitando assim o erro:
ORA-19504: failed to create file "/backup/DBTST_2_5_U9idjai.bkp" ORA-27054: NFS file system where the file is created or resides is not mounted with correct options
February 23, 2012
Oracle sempre surpreendendo, dessa vez com um restore em RMAN. Essa eu peguei sexta-feira passada em um cliente o ambiente era um Oracle 10g 64b em um Red Hat Linux 5.
O erro ocorria assim: Sempre quando tentava realizar um restore da base a seguinte mensagem era mostrada pelo RMAN.
RMAN-06026: some targets not found - aborting restore RMAN-06023: no backup or copy of datafile 4 found to restore RMAN-06023: no backup or copy of datafile 5 found to restore
Já pensei comigo, “poxa não tenho backups dos datafiles 4 e 5″ mais o problema estava ai, eu tinha o backup dos datafiles 4 e 5. Veja abaixo que quando peço para listar os backups do banco ele sinaliza o backup para os datafiles 4 e 5:
RMAN> list backup of database;
List of Backup Sets
===================
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ -------------------
9965 Incr 0 50.13G DISK 00:49:12 22.02.2012 14:15:11
BP Key: 8201 Status: AVAILABLE Compressed: YES Tag: FULL_DB
Piece Name: /oracle/backup/FULL_DB_1.bkp
List of Datafiles in backup set 9965
File LV Type Ckp SCN Ckp Time Name
---- -- ---- ---------- ------------------- ----
1 0 Incr 92563519151 22.02.2012 14:15:11 /oradata/system01.dbf
2 0 Incr 92563519151 22.02.2012 14:15:11 /oradata/df_tst1.dbf
3 0 Incr 92563519151 22.02.2012 14:15:11 /oradata/sysaux01.dbf
4 0 Incr 92563519151 22.02.2012 14:15:11 /oradata/datafiledb1.dbf
5 0 Incr 92563519151 22.02.2012 14:15:11 /oradata/datafiledb2.dbf
6 0 Incr 92563519151 22.02.2012 14:15:11 /oradata/users01.dbf
7 0 Incr 92563519151 17.02.2012 14:15:11 /oradata/undotbs01.dbf
Mesmo apresentando no backup que os datafiles 4 e 5 estavam presentes não adiantava, o erro RMAN-06023 aparecia:
RMAN> RESTORE DATABASE; using target database control file instead of recovery catalog allocated channel: c1 channel c1: sid=321 devtype=DISK Starting restore at 22.02.2012 15:15:21 released channel: c1 RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03002: failure of restore command at 22/02/2012 15:15:22 RMAN-06026: some targets not found - aborting restore RMAN-06023: no backup or copy of datafile 4 found to restore RMAN-06023: no backup or copy of datafile 5 found to restore
Realmente o erro era inesperado, pois eu tinha o backup:
RMAN> list backup of datafile 4;
List of Backup Sets
===================
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ -------------------
9965 Incr 0 50.13G DISK 00:49:12 22.02.2012 14:15:11
BP Key: 8201 Status: AVAILABLE Compressed: YES Tag: FULL_DB
Piece Name: /oracle/backup/FULL_DB_1.bkp
List of Datafiles in backup set 9965
File LV Type Ckp SCN Ckp Time Name
---- -- ---- ---------- ------------------- ----
4 0 Incr 92563519151 22.02.2012 14:15:11 /oradata/datafiledb1.dbf
RMAN> list backup of datafile 5;
List of Backup Sets
===================
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ -------------------
9965 Incr 0 50.13G DISK 00:49:12 22.02.2012 14:15:11
BP Key: 8201 Status: AVAILABLE Compressed: YES Tag: FULL_DB
Piece Name: /oracle/backup/FULL_DB_1.bkp
List of Datafiles in backup set 9965
File LV Type Ckp SCN Ckp Time Name
---- -- ---- ---------- ------------------- ----
5 0 Incr 92563519151 22.02.2012 14:15:11 /oradata/datafiledb2.dbf
Solução encontrada? Desabilitar a Flash Recovery Area. Isso mesmo, após desabilitar a flash recovery area o problema não aconteceu mais.
Mais porque? Bom …
Quando iniciamos um restore de uma base através de um backup de controlfile em que a flash recovery area está habilita o RMAN executa um implícito crosscheck e cataloga todos os objetos na flash recovery area. Com isso o RMAN vai catalagar QUALQUER objeto que estiver na flash recovery area e se qualquer um desses arquivos pertencer a uma encarnação diferente da ATUAL encarnação do controlfile então muda a atual encarnação para do arquivo que está sendo catalogado.
Isso de acordo com a Oracle evita ao banco de dados restaurar backups que pertencem a uma velha encarnação. Para mais detalhes veja a nota 965122.1 do suporte Oracle.
Após desabilitado a flash recovery area, meu restore funcionou perfeitamente 
October 3, 2011
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
June 3, 2011
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.
May 10, 2011
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.
May 10, 2011
Uma das formas para descobrir quanto tempo ainda falta para terminar o backup realizado com RMAN, é consultando a viewv$session_longops.
Essa view mostra as vários operações que estão executando por mais de 6 segundos no banco de dados Oracle.
Veja os passos abaixos:
Primeiro vamos relacionar o processo servidor com o channel do RMAN, através do comando SET COMMAND ID
RMAN> run {
2> allocate channel t1 type disk;
3> set command id to ‘rman’;
4> backup datafile 1;
5> release channel t1;
6> }
Agora, basta executar a query, vendo o resultado.
SYS@orcl> SELECT sid, serial#, sofar, totalwork, 2 round(sofar/totalwork*100,2) "% Complete" 3 FROM v$session_longops 4 WHERE opname LIKE 'RMAN:%' 5 AND opname NOT LIKE 'RMAN: aggregate%' 6 AND totalwork != 0; SID SERIAL# SOFAR TOTALWORK % Complete ---------- ---------- ---------- ---------- ---------- 139 17 13951 62720 22.24 SYS@orcl> / SID SERIAL# SOFAR TOTALWORK % Complete ---------- ---------- ---------- ---------- ---------- 139 17 24831 62720 39.59 SYS@orcl> / SID SERIAL# SOFAR TOTALWORK % Complete ---------- ---------- ---------- ---------- ---------- 139 17 62591 62720 99.79
