Guob 2014
Montando seus datafiles em NFS
junho 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
Restore com RMAN-06023
fevereiro 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 :)

Restore Datafile de um Image Copy
outubro 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
Desconsiderando a retenção do RMAN
maio 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.

Quanto tempo vai demorar o backup?
maio 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
ORA-00600 kccpb_sanity_check_2
julho 3, 2010

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.