Oracle RMAN 学习：恢复

6 rman恢复

Rman中的恢复对应restore，recover

Restore，数据修复，利用备份集的数据文件来替换已损坏的数据文件或将其恢复到另外一个位置，在进行修复时会根据恢复目录（控制文件）中获取备份信息，并从中选择最合适的进行修复

Recover，数据恢复，指应用所有的重做日志，将恢复到崩溃前的状态，或者应用备份redo，将其修复到指定的时间点

6.1 Rman基础

Rman恢复可以分成3部分

1 将db置于正确的状态，mount，open，一般在整库恢复的话需要在mount状态操作，表空间或数据文件也可以在open状态恢复

2 执行完全恢复或不完全恢复，完全恢复就是利用所有db生成的重做日志，不完全恢复就是利用部分redo

3 打开db，如果执行的是不完全恢复，则需要open resetlogs

1 rman 如何选择备份集

首先如果没有指定until，则从最近的备份集中，指定了until，则从满足until的开始

2 rman恢复的自动化

3增量恢复和利用重做日志

了解与恢复相关的信息

1 理解报警日志文件

select * from v$parameter where name like 'background_dump_dest';

background_dump_dest 2 /u01/app/oracle/admin/grs/bdump /u01/app/oracle/admin/grs/bdump

[root@localhost oracle_rman]# cd /u01/app/oracle/admin/grs/bdump

[root@localhost bdump]# ll

total 1660

-rw-r----- 1 oracle oinstall 66476 Nov 11 20:00 alert_grs.log

报警日志文件一般记载了数据库的启动/关闭信息，归档信息，备份信息，恢复信息，常见错误信息，部分数据库修改记录等。一般令名规则为<SID>Alrt.log 或Alrt<SID>.log，

12c

/u02/app/oracle/diag/rdbms/hongquan1/hongquan1/trace

2 后台进程跟踪文件

后台进程跟踪文件的路径与报警日志文件的路径一致，在某些情况下，你可以通过后台

跟踪文件的信息了解更多的需要恢复的信息。如在数据库需要恢复的时候，报警日志文件中

常有这样的语句：

[root@localhost bdump]# more grs_dbw0_23409.trc

/u01/app/oracle/admin/grs/bdump/grs_dbw0_23409.trc

Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production

With the Partitioning, OLAP and Data Mining options

ORACLE_HOME = /u01/app/oracle/product/10.2.0/db_1

System name: Linux

Node name: localhost.localdomain

Release: 2.6.18-8.el5

Version: #1 SMP Fri Jan 26 14:15:21 EST 2007

Machine: i686

Instance name: grs

Redo thread mounted by this instance: 1

Oracle process number: 5

Unix process pid: 23409, image: oracle@localhost.localdomain (DBW0)

*** SERVICE NAME:() 2014-11-11 17:28:35.686

*** SESSION ID:(167.1) 2014-11-11 17:28:35.686

ORA-01157: cannot identify/lock data file 7 - see DBWR trace file

ORA-01110: data file 7: '/u01/app/oracle/grs/rman_test.dbf'

ORA-27037: unable to obtain file status

Linux Error: 2: No such file or directory

Additional information: 3

*** 2014-11-11 17:30:17.312

ORA-01157: cannot identify/lock data file 7 - see DBWR trace file

ORA-01110: data file 7: '/u01/app/oracle/grs/rman_test.dbf'

ORA-27037: unable to obtain file status

Linux Error: 2: No such file or directory

Additional information: 3

3 V$recover_file与v$recovery_log

这是两个动态性能视图，可以在 mount下查看，通过这两个视图，你可以了解详细的

需要恢复的数据文件与需要使用到的归档日志

6.1 rman恢复的基础操作

Rman实现数据恢复包含2个步骤：数据修复restore，数据恢复recover（这一步不是必须的）

Rman提供了多种不同级别的恢复方式，能用rman备份的就能够被恢复

6.1.1 对db进行完全介质恢复

如果db只剩下controlfile跟spfile，其他数据文件都丢失，但是之前有过全备份（所有归档文件和重做日志文件都在）

1 rman>startup mount

2 rman>restore database

Rman>recover database delete archivelogs skip tablespace temp;

Recover: delete archivelogs表示rman完成恢复后自动删除恢复过程中它产生的归档日志文件，

skip tablespace temp 跳过指定的表空间，

maxsize n：用来指定在恢复过程中，自动产生的归档文件的最大可占用空间，超过及删除，循环利用

3 rman>alter database open;

上述在归档模式下进行，在非归档模式下，在执行restore之前，首先需要恢复之前备份的控制文件，并且在执行了restore和recover命令后，必须以open resetlogs方式打开数据库

6.1.2 恢复表空间和数据文件

执行表空间跟数据文件恢复时，数据库可以是mount状态，也可以是open状态，

1 恢复表空间，被恢复的表空间必须出现offline状态（open时），

Rman>sql ‘alter tablespace yyhhqq offile immediate’;

Rman>restore tablespace yyhhqq;

Rman>recover tablespace yyhhqq;

Rman>sql ‘alter tablespace yyhhqq online’;

2 恢复数据文件

恢复之前，需要将datafile置于offline

Rman>sql ‘alter database datafile 6 offline’;

Rman>restore datafile 6;

Rman>recover datafile 6;

Rman>sql ‘alter database datafile 6 onlie’;

数据文件会恢复到默认的位置，如果由于磁盘损坏导致数据文件无法访问，则在恢复数据文件时需要指定新的路径

Run{

Set newname for datafile 6 to ‘F:oracleproduct10.2.0oradataorcl’;

Restore datafile 6;

Switch datafile6;

Recover datafile 6;}

6.1.3 恢复归档文件

恢复归档序号为10-20之间的归档文件

Rman>restore archivelog sequence between 10 and 20;

默认情况下，rman将归档文件恢复到初始化参数log_archive_dest_1指定的路径下，

可以指定新的路径

Run{

Set archivelog destination to ‘f:oracleackuparchive’;

Restore archivelog sequence between 10 and 20;}

这样恢复出来的归档文件将存在在f:oracleackuparchive路径下

6.1.4 恢复控制文件跟spfile文件

1恢复控制文件

A 自动从备份中恢复，没有控制文件，db只能启动到nomount状态，在启动数据库之前，必须设置dbid，

在rman备份中都有dbid

也可以从v$database中获取

CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/u01/app/rman_oracle/rman_CONTROL_%F';

包含dbid

Piece Name: /u01/app/rman_oracle/rman_CONTROL_c-1404914474-20150422-00

select dbid from v$database—dbid

rman>set dbid=1343277122;

rman>start nomount;

rman>restore controlfile from autobackup;

--恢复到默认路径下,备份集中的控制文件会被恢复到初始化参数control_files指定的路径下

select * from v$parameter where name like'%control_files%'

F:ORACLEPRODUCT10.2.0ORADATAORCLCONTROL01.CTL, F:ORACLEPRODUCT10.2.0ORADATAORCLCONTROL02.CTL, F:ORACLEPRODUCT10.2.0ORADATAORCLCONTROL03.CTL

----指定控制文件从那个备备份集中获取

rman>restore controlfile to ‘f:oracleproductorcloradatacontrl.ctl’ from autobackup;

restore controlfile to '/u01/app/oracle/oradata/grs/control03.ctl' from '/u01/app/oracle/backup/contrul_0gp7s8et_1_1';

--将控制文件恢复到指定路径下

在nocatalog模式下修改控制文件自动备份的保存路径时，不要使用configure命令，此命令时永久改变配置，使用set命令

Rman>set controlfile autobackup format for device type disk to ‘f:mydbackup\%f’;

然后

Rman>restore controlfile from autobackup;

B 从备份集中恢复

10g开始可以直接从指定的备份片段中恢复控制文件（确保控制文件在备份集中）

Rman>set dbid=1343277122;

Rman>start nomount;

Rman>restore controlfile from ‘F:mydbackupBAK_0IOFIBDL_1_1’;

同时可以指定恢复路径，在使用备份集恢复控制文件后，必须recover database，以open resetlogs打开db

2 恢复spfile文件

Rman在备份控制文件时，会自动备份spfile文件，

数据库在运行过程中会在alter文件中留下数据库启动时的初始化参数信息，

即使运行中的db丢失了spfile，db也不会崩溃，只有在下次启动时才会起不来，

Rman>set dbid=1343277122;

Rman >start nomount;在rman中能启动到Nomount状态，sqlplus下不能

Rman>restore spfile from autobakup;

初始化参数的路径

select * from v$parameter where name like'%spfile%'

F:ORACLEPRODUCT10.2.0DB_1DATABASESPFILEORCL.ORA

如果实例正在运行，不能覆盖，可以restore spfile to ‘f:xxxx’ from autobackup 到别的路径

6.2 rman恢复操作

6.2.1 归档模式无备份，丢失数据文件的恢复

这种恢复是有条件的，在某些特定条件下，才有可能在没有备份的情况下恢复丢失的数据文件

并不是所有的数据文件丢失都能够被恢复，丢失的tmp数据文件不需要恢复，丢失或者损坏的system表空间，除非借助备份，否则无法直接恢复。

Linux下

CREATE TABLESPACE rman_test DATAFILE

'/u01/app/oracle/oradata/grs/rman_test.dbf'SIZE 10M AUTOEXTEND ON NEXT 10M MAXSIZE 20M

create table temp11(a number) TABLESPACE rman_test

insert into temp11

select rownum from dual connect by rownum<=10

查询表空间跟数据文件的对应的路径跟序列号

select ts.tablespace_name, df.file_name, df.file_id, tf.file_name

from dba_tablespaces ts, dba_data_files df, dba_temp_files tf

where ts.tablespace_name = df.tablespace_name(+)

and ts.tablespace_name = tf.tablespace_name(+)

[oracle@localhost ~]$ sqlplus /nolog

SQL*Plus: Release 10.2.0.1.0 - Production on Mon Oct 28 11:15:20 2013

SQL> conn /as sysdba

Connected.

SQL> shutdown immediate----------关闭数据库

Database closed.

Database dismounted.

ORACLE instance shut down.

[oracle@localhost grs]$ rm rman_test.dbf-----------删除测试的数据文件

--SQL> !rm /u01/app/oracle/oradata/grs/rman_test.dbf;

SQL> startup --------启动报错

ORACLE instance started.

Total System Global Area 285212672 bytes

Fixed Size 1218992 bytes

Variable Size 92276304 bytes

Database Buffers 188743680 bytes

Redo Buffers 2973696 bytes

Database mounted.

ORA-01157: cannot identify/lock data file 9 - see DBWR trace file

ORA-01110: data file 9: '/u01/app/oracle/oradata/grs/rman_test.dbf'

SQL> alter database create datafile '/u01/app/oracle/oradata/grs/rman_test.dbf'as '/u01/app/oracle/oradata/grs/rman_test.dbf';-----------手动创建数据文件

Database altered.

SQL> recover datafile 9;-----数据文件从创建时刻起，所有的重做日志都还在。

Media recovery complete.------修复丢失的数据文件

SQL> alter database open;

Database altered.

SQL> conn scott

Enter password:

Connected.

SQL> select * from temp11;

----------

10 rows selected.

2 利用rman恢复

[oracle@localhost grs]$ rm yyhhqq.dbf

[oracle@localhost grs]$ sqlplus /nolog

SQL*Plus: Release 10.2.0.1.0 - Production on Mon Nov 4 15:02:58 2013

SQL> conn /as sysdba

Connected to an idle instance.

SQL> startup

ORACLE instance started.

Total System Global Area 285212672 bytes

Fixed Size 1218992 bytes

Variable Size 109053520 bytes

Database Buffers 171966464 bytes

Redo Buffers 2973696 bytes

Database mounted.

ORA-01157: cannot identify/lock data file 6 - see DBWR trace file

ORA-01110: data file 6: '/u01/app/oracle/oradata/grs/yyhhqq.dbf'

SQL> alter database datafile 6 offline drop;

Database altered.

SQL> alter database open;

Database altered.

SQL> exit

Disconnected from Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production

With the Partitioning, OLAP and Data Mining options

[oracle@localhost grs]$ rman target/

Recovery Manager: Release 10.2.0.1.0 - Production on Mon Nov 4 15:05:26 2013

connected to target database: GRS (DBID=325518186)

RMAN> run{

allocate channel c1 type disk;

restore datafile 6;

recover datafile 6;

sql 'alter database datafile 6 online';

release channel c1;

}2> 3> 4> 5> 6> 7>

using target database control file instead of recovery catalog

sql statement: alter database datafile 6 online

released channel: c1

RMAN> exit

Recovery Manager complete.

[oracle@localhost grs]$

也可以是,恢复表空间

run{

allocate channel c1 type disk;

restore tablespace users;

recover tablespace users;

sql 'alter database datafile 6 online';

release channel c1;

}

在丢失多个数据文件时：

当启动检查数据文件丢失报错时可以查看该视图看需要恢复的数据文件有哪些

select * from v$recover_file;

FILE# ONLINE ONLINE_ ERROR CHANGE# TIME

然后可以根据来进行指定恢复或者全库恢复

RMAN> run{

allocate channel c1 type disk;

restore database;

recover database;

sql 'alter database open';

release channel c1;

}

说明：

1、只要有备份与归档存在，RMAN 也可以实现数据库的完全恢复（不丢失数据）。

2、同OS 备份恢复，适合于丢失大量数据文件，或包含系统数据文件在内的数据库的恢复。

3、目标数据库在mount 下进行，如果恢复成功，再打开数据库。

4、RMAN的备份与恢复命令相对比较简单并可靠，建议有条件的话，都采用 RMAN进行数

据库的备份。

6.2.2 归档模式有备份，数据文件丢失

linux下

[oracle@localhost grs]$ rman target/

Recovery Manager: Release 10.2.0.1.0 - Production on Mon Oct 28 14:12:20 2013

connected to target database: GRS (DBID=325518186)

RMAN> backup tablespace rman_test format '/u01/oracle/backup/rman_back_%U';

insert into temp11

select rownum from dual connect by rownum<=10 -------在插入数据

删除数据文件

[oracle@localhost grs]$ rm rman_test.dbf

SQL> startup-------启动时报错

ORACLE instance started.

Total System Global Area 285212672 bytes

Fixed Size 1218992 bytes

Variable Size 92276304 bytes

Database Buffers 188743680 bytes

Redo Buffers 2973696 bytes

Database mounted.

ORA-01157: cannot identify/lock data file 9 - see DBWR trace file

ORA-01110: data file 9: '/u01/app/oracle/oradata/grs/rman_test.dbf'

利用rman来恢复

connected to target database: GRS (DBID=325518186, not open)

RMAN> restore datafile 9;

Starting restore at 28-OCT-13

using target database control file instead of recovery catalog

allocated channel: ORA_DISK_1

channel ORA_DISK_1: sid=155 devtype=DISK

channel ORA_DISK_1: starting datafile backupset restore

channel ORA_DISK_1: specifying datafile(s) to restore from backup set

restoring datafile 00009 to /u01/app/oracle/oradata/grs/rman_test.dbf

channel ORA_DISK_1: reading from backup piece /u01/oracle/backup/rman_back_17onhs9k_1_1

channel ORA_DISK_1: restored backup piece 1

piece handle=/u01/oracle/backup/rman_back_17onhs9k_1_1 tag=TAG20131028T141412

channel ORA_DISK_1: restore complete, elapsed time: 00:00:01

Finished restore at 28-OCT-13

RMAN> recover datafile 9;

Starting recover at 28-OCT-13

using channel ORA_DISK_1

starting media recovery

media recovery complete, elapsed time: 00:00:02

Finished recover at 28-OCT-13

RMAN> alter database open;

database opened

6.2.3控制文件丢失的恢复

在nocatalog模式下，rman相关的备份信息也在控制文件中，如果有备份，则可以用备份恢复，如果都丢失，在dba熟悉db的情况下，可以手动建立控制文件，

本节将在归档模式下，对控制文件丢失的恢复，借助前面的备份，

在恢复控制文件之前，必须知道db的dbid

在使用备份集恢复控制文件后，必须recover database，以open resetlogs打开db

1 模拟文件丢失

由于控制文件在oracle数据库运行期间被oracle进程锁定，所以必须将db关闭

Shutdown immediate

Sql>host del ‘F:ORACLEPRODUCT10.2.0ORADATAORCLCONTROL01.CTL’;

Sql>startup nomount;

2 恢复控制文件

新开一个窗口，连接rman

Set oracle_sid=orcl

Rman target /

Rman>set dbid=xx;

Rman>show all;

Rman>restore controlfile from ‘F:mydbackupC-1343277122-20130801-01’;

---可以显示指定路径，不指定默认在control_files指定的路径下

Rman>alter database mount;

Rman>recover database;

Rman>alter database open resetlogs

Linux下

SQL> shutdown immediate

Database closed.

Database dismounted.

ORACLE instance shut down.

[oracle@localhost grs]$ mkdir control_backup

[oracle@localhost grs]$ mv control01.ctl control02.ctl control03.ctl /u01/app/oracle/oradata/grs/control_backup/

SQL> startup;

ORACLE instance started.

Total System Global Area 285212672 bytes

Fixed Size 1218992 bytes

Variable Size 75499088 bytes

Database Buffers 205520896 bytes

Redo Buffers 2973696 bytes

ORA-00205: error in identifying control file, check alert log for more info

----查看alert log文件

[oracle@localhost grs]$ tail -f -n 20 /u01/app/oracle/admin/grs/bdump/alert_grs.log

DBW0 started with pid=5, OS id=22318

LGWR started with pid=6, OS id=22320

CKPT started with pid=7, OS id=22322

SMON started with pid=8, OS id=22324

RECO started with pid=9, OS id=22326

CJQ0 started with pid=10, OS id=22328

MMON started with pid=11, OS id=22330

Thu Mar 20 15:04:02 2014

starting up 1 dispatcher(s) for network address '(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))'...

starting up 1 shared server(s) ...

MMNL started with pid=12, OS id=22332

Thu Mar 20 15:04:03 2014

ALTER DATABASE MOUNT

Thu Mar 20 15:04:03 2014

ORA-00202: control file: '/u01/app/oracle/oradata/grs/control01.ctl'

ORA-27037: unable to obtain file status

Linux Error: 2: No such file or directory

Additional information: 3

Thu Mar 20 15:04:06 2014

ORA-205 signalled during: ALTER DATABASE MOUNT...

---这个时候连接rman

[oracle@localhost grs]$ rman target /

Recovery Manager: Release 10.2.0.1.0 - Production on Thu Mar 20 15:09:01 2014

connected to target database: grs (not mounted)

RMAN> set dbid=325518186

executing command: SET DBID

RMAN> show all;

RMAN configuration parameters are:---全部是rman的默认配置，控制文件丢失

CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default

CONFIGURE BACKUP OPTIMIZATION OFF; # default

CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default

CONFIGURE CONTROLFILE AUTOBACKUP OFF; # default

CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default

CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default

CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default

CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default

CONFIGURE MAXSETSIZE TO UNLIMITED; # default

CONFIGURE ENCRYPTION FOR DATABASE OFF; # default

CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default

CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default

-----------此时要恢复控制文件，不能直接使用restore controlfile from autobackup命令，因为自动备份的设置也丢失了，并且是在nocatalog模式下，无法配置controlfile autobackup的相关属性，因此此时显式指定控制文件备份集的方式恢复控制文件

RMAN> restore controlfile from '/u01/oracle/backup/rman_backup_c-325518186-20131025-01';

Starting restore at 28-OCT-13

allocated channel: ORA_DISK_1

channel ORA_DISK_1: sid=159 devtype=DISK

channel ORA_DISK_1: restoring control file

channel ORA_DISK_1: restore complete, elapsed time: 00:00:02

output filename=/u01/app/oracle/oradata/grs/control01.ctl

output filename=/u01/app/oracle/oradata/grs/control02.ctl

output filename=/u01/app/oracle/oradata/grs/control03.ctl

Finished restore at 28-OCT-13

RMAN> alter database mount;

database mounted

released channel: ORA_DISK_1

RMAN> recover database;

Starting recover at 28-OCT-13

Starting implicit crosscheck backup at 28-OCT-13

allocated channel: ORA_DISK_1

channel ORA_DISK_1: sid=159 devtype=DISK

Crosschecked 19 objects

Finished implicit crosscheck backup at 28-OCT-13

RMAN-00571: =================================================

RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS

RMAN-00571: ========================================================

RMAN-03002: failure of recover command at 10/28/2013 15:00:40

ORA-01119: error in creating database file '/u01/app/oracle/oradata/grs/rman_test.dbf'

ORA-27038: created file already exists

Additional information: 1

SQL> select status from v$instance;

STATUS

------------------------

MOUNTED

SQL> alter database create datafile '/u01/app/oracle/oradata/grs/rman_test.dbf'as '/u01/app/oracle/oradata/grs/rman_test.dbf';

Database altered.

RMAN> recover database;

Starting recover at 28-OCT-13

using channel ORA_DISK_1

starting media recovery

archive log thread 1 sequence 29 is already on disk as file /u01/app/oracle/oradata/grs/redo01.log

archive log filename=/u01/app/oracle/oradata/grs/redo01.log thread=1 sequence=29

media recovery complete, elapsed time: 00:00:02

Finished recover at 28-OCT-13

RMAN> alter database open resetlogs;

database opened

[oracle@localhost grs]$ rman target /

Recovery Manager: Release 10.2.0.1.0 - Production on Mon Oct 28 15:25:40 2013

connected to target database: GRS (DBID=325518186)

RMAN> show all;

using target database control file instead of recovery catalog

RMAN configuration parameters are:

CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;

CONFIGURE BACKUP OPTIMIZATION ON;

CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default

CONFIGURE CONTROLFILE AUTOBACKUP ON;

CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/u01/oracle/backup/rman_backup_%F';

CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default

CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default

CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default

CONFIGURE MAXSETSIZE TO UNLIMITED; # default

CONFIGURE ENCRYPTION FOR DATABASE OFF; # default

CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default

CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default

CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/u01/app/oracle/product/10.2.0/db_1/dbs/snapcf_grs.f'; # default

select * from v$log

1 1 1 52428800 1 NO CURRENT 1072869 2013-10-28 15:18:09

2 1 0 52428800 1 YES UNUSED 0

3 1 0 52428800 1 YES UNUSED 0

-------------------2 备份信息不正确

RMAN> recover database;

Starting recover at 20-MAR-14

Starting implicit crosscheck backup at 20-MAR-14

allocated channel: ORA_DISK_1

channel ORA_DISK_1: sid=155 devtype=DISK

Crosschecked 2 objects

Finished implicit crosscheck backup at 20-MAR-14

Starting implicit crosscheck copy at 20-MAR-14

using channel ORA_DISK_1

Finished implicit crosscheck copy at 20-MAR-14

searching for all files in the recovery area

cataloging files...

no files cataloged

using channel ORA_DISK_1

starting media recovery

archive log thread 1 sequence 1 is already on disk as file /u01/app/oracle/oradata/grs/redo02.log

archive log thread 1 sequence 2 is already on disk as file /u01/app/oracle/oradata/grs/redo01.log

archive log filename=/u01/app/oracle/oradata/grs/redo02.log thread=1 sequence=1

creating datafile fno=2 name=/u01/app/oracle/oradata/grs/undotbs01.dbf

RMAN-00571: ===========================================================

RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============

RMAN-00571: ===========================================================

RMAN-03002: failure of recover command at 03/20/2014 15:15:11

ORA-01119: error in creating database file '/u01/app/oracle/oradata/grs/undotbs01.dbf'

ORA-27038: created file already exists

Additional information: 1

SQL> col error format a15

SQL> select * from v$recover_file;

FILE# ONLINE ONLINE_STATUS ERROR CHANGE# TIME

---------- --------------------- --------------------- --------------- ---------- ------------------

2 ONLINE ONLINE FILE MISSING 0

SQL> alter database datafile 2 offline drop;

Database altered.

SQL> alter database open resetlogs;

alter database open resetlogs

ERROR at line 1:

ORA-01153: an incompatible media recovery is active

SQL> alter database create datafile '/u01/app/oracle/oradata/grs/undotbs01.dbf' as '/u01/app/oracle/oradata/grs/undotbs01.dbf';

alter database create datafile '/u01/app/oracle/oradata/grs/undotbs01.dbf' as '/u01/app/oracle/oradata/grs/undotbs01.dbf'

ERROR at line 1:

ORA-01516: nonexistent log file, datafile, or tempfile "/u01/app/oracle/oradata/grs/undotbs01.dbf"

SQL> create undo tablespace UNDOTBS1 datafile '/u01/app/oracle/oradata/grs/undotbs01.dbf' size 100m;

create undo tablespace UNDOTBS1 datafile '/u01/app/oracle/oradata/grs/undotbs01.dbf' size 100m

ERROR at line 1:

ORA-01109: database not open

[oracle@localhost control_backup]$ mv control02.ctl control03.ctl /u01/app/oracle/oradata/grs/

SQL> startup;

ORACLE instance started.

Total System Global Area 285212672 bytes

Fixed Size 1218992 bytes

Variable Size 75499088 bytes

Database Buffers 205520896 bytes

Redo Buffers 2973696 bytes

Database mounted.

Database opened.

6.2.4 丢失联机重做日志文件的恢复

Oracle的联机重做日志保存的是重做信息，是循环记录oracle的操作，几乎时刻都在写，

Oracle对于联机重做日志文件，oracle通过文件冗余的机制来确保联机日志的安全，即每组联机重做日志文件创建多个文件（至少2个），每个文件的路径都可以单独的放在独立的disk，

Oracle运行时会自动对redo进行锁定，

日志文件状态：

unused：表示从未使用过，一般完成open resetlogs打开db后，或者alter database clear logfile会变成unused状态（需要以resetlogs打开数据的情况：不完全恢复，控制文件恢复

active

current：当前使用

inactive：日志已经被归档或顺利写入数据文件，该组可以继续使用

1模拟丢失非当前的redo

Shutdown immediate

Host del F:MYDBYHQ_REDO04.LOG—redo 5 有多个文件成员

Startup

5 INVALID ONLINE F:MYDBYHQ_REDO04.LOG NO

查看db的日志组状态

select * from v$log

1 1 72 52428800 1 YES INACTIVE 2354655 2013-8-1 16:02:27

2 1 74 52428800 1 NO CURRENT 2396759 2013-8-5 13:49:38

3 1 70 52428800 1 YES INACTIVE 2305833 2013-7-30 17:00:59

4 1 73 52428800 2 YES INACTIVE 2354737 2013-8-1 16:04:06

5 1 71 52428800 3 YES INACTIVE 2335159 2013-8-1 10:00:29

查看日志组对应的文件

select * from v$logfile

3 ONLINE F:ORACLEPRODUCT10.2.0ORADATAORCLREDO03.LOG NO

2 ONLINE F:ORACLEPRODUCT10.2.0ORADATAORCLREDO02.LOG NO

1 ONLINE F:ORACLEPRODUCT10.2.0ORADATAORCLREDO01.LOG NO

4 ONLINE F:ORACLEPRODUCT10.2.0ORADATAORCLREDO04.LOG NO

4 ONLINE F:ORACLEPRODUCT10.2.0ORADATAORCLREDO05.LOG NO

5 ONLINE F:MYDBYHQ_REDO04.LOG NO

5 ONLINE F:MYDBYHQ_REDO05.LOG NO

5 ONLINE F:MYDBYHQ_REDO06.LOG NO

2 修复丢失的redo

Sql>alter database clear logfile group 5;

-- 5 1 0 52428800 3 YES UNUSED 2335159 2013-8-1 10:00:29

Sql>alter database open;

3 模拟丢失当前所用的redo（CURRENT）

Sql>host del ‘F:ORACLEPRODUCT10.2.0ORADATAORCLREDO02.LOG’;

Sql>alter database open;--失败

Sql>alter database clear logfile group 2;--失败

4执行不完全恢复

Sql>alter system set “_ALLOW_RESETLOGS_CORRUPTION”= TRUE SCOPE=SPFILE;

--修改一个隐含参数

Sql>shutdown immediate;

Sql>startup mount;

Sql>recover database until cancel;

Sql>alter database open resetlogs;

Note:对应redo的保护方式就是冗余。

Linux下

1 非当前redo文件的丢失--------不一定会丢失数据

select * from v$log

select * from v$logfile----查看redo文件

3 ONLINE /u01/app/oracle/oradata/grs/redo03.log NO

2 ONLINE /u01/app/oracle/oradata/grs/redo02.log NO

1 ONLINE /u01/app/oracle/oradata/grs/redo01.log NO

[oracle@localhost grs]$ rm redo03.log

[oracle@localhost grs]$ sqlplus /nolog

SQL*Plus: Release 10.2.0.1.0 - Production on Mon Oct 28 15:52:11 2013

SQL> conn /as sysdba

Connected to an idle instance.

SQL> startup

ORACLE instance started.

Total System Global Area 285212672 bytes

Fixed Size 1218992 bytes

Variable Size 96470608 bytes

Database Buffers 184549376 bytes

Redo Buffers 2973696 bytes

Database mounted.

ORA-00313: open failed for members of log group 3 of thread 1

ORA-00312: online log 3 thread 1: '/u01/app/oracle/oradata/grs/redo03.log'

SQL> alter database clear logfile group 3;--重建该组重做日志文件

Database altered.

SQL> alter database open;

Database altered.

SQL> select * from v$log;

RMAN> alter database mount;

database mounted

released channel: ORA_DISK_1

released channel: ORA_DISK_2

RMAN> sql'alter database clear logfile group 3';

sql statement: alter database clear logfile group 3

说明：

1、如果损坏的是非当前的联机日志文件，一般只需要 clear 就可以重建该日志文件，但是如果该数据库处于归档状态但该日志还没有归档，就需要强行 clear。

2、建议clear，特别是强行 clear后作一次数据库的全备份。

3、此方法适用于归档与非归档数据库。

2 丢失当前的redo-------即使有备份，也会丢失数据

归档模式下当前日志的损坏有两种情况：

一、是数据库是正常关闭，日志文件中没有未解决的事务需要实例恢复，当前日志组的损坏就可以直接用alter database clear unarchived logfile group n 来重建。

二、是日志组中有活动的事务，数据库需要媒体恢复，日志组需要用来同步，有两种补救办

法：

A.最好的办法就是通过不完全恢复，可以保证数据库的一致性，但是这种办法要求在归档方式下，并且有可用的备份。

B.通过强制性恢复，但是可能导致数据库不一致。

下面分别用来说明这两种恢复方法

a.) 通过备份来恢复

1、打开数据库，会遇到一个类似的错误

ORCL> startup

ORACLE instance started

Database mounted.

ORA-03113: 通信通道的文件结尾

进程 ID: 19294

会话 ID: 1 序列号: 5

Alert日志报错

2、查看 V$log，发现是当前日志

ORCL> select group#,sequence#,archived,status from v$log;

3、发现 clear不成功

ORCL> alter database clear unarchived logfile group 1;

4、拷贝有效的数据库的全备份，并不完全恢复数据库

可以采用获取最近的SCN 的办法用until scn恢复或用 until cnacel恢复

RMAN> recover database until cancel

先选择 auto，尽量恢复可以利用的归档日志，然后重新。

RMAN> recover database until cancel

这次输入 cancel，完成不完全恢复，也就是说恢复两次。如：

RMAN> recover database until cancel;

Auto

……

RMAN> recover database until cancel;

Cancel;

5、利用 alter database open resetlogs 打开数据库

说明：

1、这种办法恢复的数据库是一致的不完全恢复，会丢失当前联机日志中的事务数据。

2、这种方法适合于归档数据库并且有可用的数据库全备份。

3、恢复成功之后，记得再做一次数据库的全备份。

4、建议联机日志文件一定要实现镜相在不同的磁盘上，避免这种情况的发生，因为任何数据

的丢失对于生产来说都是不容许的。

b.) 如果没有备份，进行强制性恢复

1、打开数据库，会遇到一个类似的错误

2、查看 V$log，发现是当前日志

TEST@ORCL> select group#,sequence#,archived,status from v$log;

3、发现 clear不成功

TEST@ORCL> alter database clear unarchived logfile group 2;

alter database clear unarchived logfile group 2

4、把数据库 down 掉

TEST@ORCL> shutdown immediate

5、在 init<sid>.ora中加入如下参数

_allow_resetlogs_corruption=TRUE

SQL> alter system set "_allow_resetlogs_corruption"=true scope=spfile;

6、重新启动数据库,利用until cancel 恢复

TEST@ORCL> recover database until cancel;

Cancel

如果出错，不再理会，发出

TEST@ORCL> alter database open resetlogs;

7、数据库被打开后，马上执行一个 full export

8、shutdown数据库,去掉_all_resetlogs_corrupt 参数

再SQL> alter system set "_allow_resetlogs_corruption"=false scope=spfile;

9、重建库

10、import并完成恢复

11、建议执行一下ANALYZE TABLE ...VALIDATE STRUCTURE CASCADE;

说明：

1、该恢复方法是没有办法之后的恢复方法，一般情况下建议不要采用，因为该方法可能导致

数据库的不一致。

2、该方法也丢失数据，但是丢失的数据没有上一种方法的数据多，主要是未写入数据文件的

已提交或未提交数据。

3、建议成功后严格执行以上的 7 到11 步，完成数据库的检查与分析

4、全部完成后做一次数据库的全备份

5、建议联机日志文件一定要实现镜相在不同的磁盘上，避免这种情况的发生，因为任何数据

的丢失对于生产来说都是不容许的。

6.2.5不同故障下的恢复总结

各种故障背景下的恢复方法
丢失或损坏的文件	归档模式		数据库状态	恢复方法
一个或多个数据文件	不归档模式		关闭状态	利用一致的完全数据库备份修复整个数据库，自从备份之后发生的所有修改都将丢失；修复数据库后不需要进行恢复，利用RESETLOGS选项直接打开数据库；注意：在这种情况下进行恢复时，惟一一种可以不利用RESETLOGS选项打开数据库的情况就是在执行最近一次备份之后，联机重做日志中的内容没有被覆盖掉。
一个或多个数据文件，以及联机重做日志文件	不归档模式		关闭状态	利用一致的完全数据库备份修复整个数据库，自从备份之后发生的所有修改都将丢失；修复数据库后不需要进行恢复，利用RESETLOGS选项直接打开数据库。
一个或多个数据文件以及所有的控制文件	不归档模式		关闭状态	利用一致的完全数据库备份修复整个数据库，自从备份之后发生的所有修改都将丢失；修复数据库后不需要进行恢复，利用RESETLOGS选项直接打开数据库。
注：以上三种不归档模式下的数据库恢复都需要在数据库关闭状态下进行，并且需要拥有正确的控制文件备份。
一个或多个数据文件	归档模式	加载状态		在数据库打开状态下执行表空间或数据文件恢复操作，首先将表空间或数据文件置为脱机状态，然后利用备份修复它们，对它们进行恢复，最后再将它们重新置为联机状态；任何数据修改都不会丢失，并且在恢复过程中数据库的其他部分仍然是可以访问的。
全部的数据文件	归档模式	关闭状态		利用备份修复数据文件，然后使用控制文件加载数据库，并且执行完全恢复；如果所有的联机重做日志文件都没有丢失或损害，最后可以用正常方式打开数据库（不需要使用RESETLOGS选项）
一个或多个数据文件以及恢复所需的归档重做日志文件。	归档模式	加载状态		对包含丢失的数据文件的表空间进行基于时间的表空间恢复，将这个表空间恢复到最近的可用归档重做日志所对应的时刻下的状态。
所有的控制文件，还可能包括一个或多个数据文件	归档模式	未加载状态		利用备份修复丢失的控制文件与数据文件，然后对数据文件进行恢复；任何数据修改都不会丢失，但是在恢复过程中数据库将处于不可用状态。
所有的控制文件，还可能包含一个或多个数据文件，以及恢复所需的归档惩一儆百日志文件与联机重做日志文件	归档模式	未加载状态		利用备份修复丢失的控制文件与数据文件，然后进行不完全恢复，将数据库恢复到最近的可用归档重做日志所对应的时刻下的状态；包含在丢失的日志文件中以及它随后的其它日志文件中的数据修改都将会丢失；最后需要使用RESETLOGS选项来打开数据库。
注：归档模式下的数据库恢复并不一定要求关闭数据库，其中某些情况要求在加载模式下进行恢复，并且也需要拥有正确的控制文件备份。

不同备份恢复方式的特点
RMAN方式	自定义方式
在对联机数据文件进行备份时，RMAN将对当前处于不一致状态的数据块进行反复读取，直到读取到一个一致状态的数据块为止；你不将包含数据文件的表空间设置为进入备份模式	必须将包含要进行备份的数据文件的表空间设置为进入备份状态，然后在备份完成后再将表空间设置为退出备份模式；在表空间处于备份模式期间，数据库的性能将会由于频繁的I/O操作而受到严重影响(oracle会将用户修改的数据块先写入联机重做日志文件中)
可以进行增量备份，即仅对那些上一次自动备份以来发生变化的数据块进行备份；可以使用增量备份对数据库进行恢复，这就意味着你可以对运行在不归档模式下的数据库进行恢复；不过当数据库运行在不归档模式时，所做的增量备份也必须是一致的（即完全关闭状态下建立的备份）	在备份时只能对所有的数据块进行备份（复制文件），而不能仅对变化的数据块进行备份；如果数据库运行在不归档模式下，就只能进行数据库修复而不能进行任何恢复操作。
在备份过程中会对复制的每一个数据块进行校验，在利用备份进行修复时也会对数据库的正确性进行检查	在备份和修复过程中都不会对数据块进行任何校验与检查；如果修复所使用的备份中包含损坏的数据块，那么恢复后的数据库中将包含错误的数据
在备份过程中仅会复制那些包含数据的数据块，而并不会复制那些完全空白的数据块，这样得到的备份文件的大小就会大大缩小。	在备份过程中只能完全复制数据文件，无论数据文件中包含了多少实际数据，备份的大小与数据库的大小是相同的。
利用恢复目录来存放与备份和恢复相关的重要信息，包括： l 数据库中包含的模式 l 哪些文件需要进行备份 l 哪些文件在经过了指定的天数后还没有进行新的备份 l 哪些文件由于已经有了更新的备份或者已经无法用户恢复过程而需要删除 l 当前RMAN的参数配置等	不会对用户的备份与恢复操作进行任何记录，除非你自己以手工方式进行记录
可以将一系统相关的RMAN命令作为脚本保存在档案库中，在需要时招行这些脚本就可以完成特定的备份或恢复操作	只能将备份或恢复命令保存成操作系统批处理文件，维护起来比较困难。
可以利用RMAN备份轻松地复制出一个与当前数据库一模一样的数据库，你可以利用复制出来的数据库作为测试用数据库或者备用数据库使用	如果要建立测试用数据库或备份数据库，必须按照创建普通数据库的过程来进行复杂的操作。
在进行备份或修复操作时可以自动进行并行操作	必须根据要进行备份或恢复的文件以手工方式并行招行操作系统命令
提供归档日志自动容错功能：如果RMAN发现某个备份中丢失了或损坏一个归档重做日志文件，它会自动利用其它备份中的相同的归档重做文件来进行替换	无法自动提供归档日志的容错替换功能
通过使用介质管理API，RMAN可以与其它第三方的介质管理软件紧密地结合在一起进行工作。	无法与任何第三方介质管理软件直接结合在一起进行工作。

6.3 rman恢复到其他db

源库：192.168.1.1 sid=orcl 记录下dbid

目标库：192.168.1.179 2个db是相同的版本

创建完整备份，（控制文件，数据文件，归档文件），非归档模式也可以，保证备份的一致性即可，

下列操作在service上执行（默认）

详见pdf

6.2.6基于时间的不完全恢复案例

OS 热备份下的基于时间的恢复

不完全恢复可以分为基于时间的恢复，基于改变的恢复与基于撤消的恢复，这里已基于时间的恢复为例子来说明不完全恢复过程。

基于时间的恢复可以不完全恢复到现在时间之前的某一个时间，对于某些误操作，如删除了一个数据表，可以在备用恢复环境上恢复到表的删除时间之前，然后把该表导出到正式环境，避免一个人为的错误。

1 创建相关的测试数据

create table rman_test2 (a number);

insert into rman_test2

select rownum from dual connect by rownum<=4

select * from rman_test2

2 备份数据库（冷备份也可以）

[oracle@localhost grs]$ rman target/

Recovery Manager: Release 10.2.0.1.0 - Production on Mon Nov 4 16:22:01 2013

connected to target database: GRS (DBID=325518186)

RMAN> run {

CONFIGURE CONTROLFILE AUTOBACKUP ON;

configure backup optimization on;

Allocate channel c1 type disk;

Backup database format '/u01/oracle/backup/full_%U';

Release channel c1;

} 2> 3> 4> 5> 6> 7>

allocated channel: c1

channel c1: sid=139 devtype=DISK

Starting backup at 04-NOV-13

channel c1: starting full datafile backupset

channel c1: specifying datafile(s) in backupset

input datafile fno=00001 name=/u01/app/oracle/oradata/grs/system01.dbf

input datafile fno=00007 name=/u01/app/oracle/oradata/grs/cmask01.dbf

input datafile fno=00003 name=/u01/app/oracle/oradata/grs/sysaux01.dbf

input datafile fno=00005 name=/u01/app/oracle/oradata/grs/example01.dbf

input datafile fno=00006 name=/u01/app/oracle/oradata/grs/yyhhqq.dbf

input datafile fno=00008 name=/u01/app/oracle/oradata/grs/rman_catalog.dbf

input datafile fno=00002 name=/u01/app/oracle/oradata/grs/undotbs01.dbf

input datafile fno=00004 name=/u01/app/oracle/oradata/grs/users01.dbf

input datafile fno=00009 name=/u01/app/oracle/oradata/grs/rman_test.dbf

channel c1: starting piece 1 at 04-NOV-13

channel c1: finished piece 1 at 04-NOV-13

piece handle=/u01/oracle/backup/full_1hoo4idq_1_1 tag=TAG20131104T162218 comment=NONE

channel c1: backup set complete, elapsed time: 00:05:48

Finished backup at 04-NOV-13

Starting Control File and SPFILE Autobackup at 04-NOV-13

piece handle=/u01/oracle/backup/rman1104_backup_c-325518186-20131104-03 comment=NONE

Finished Control File and SPFILE Autobackup at 04-NOV-13

released channel: c1

3 删除测试表

假定删除前的时间为T1,在删除前，便于测试，继续插入数据并应用归档

insert into rman_test2

select rownum from dual connect by rownum<=4

SQL> alter system switch logfile;-------- 应用归档

System altered.

SQL> alter system switch logfile;

System altered.

SQL> select to_char(sysdate,'yyyy-mm-dd hh24:mi:ss') from dual; ----查看当前的时间

TO_CHAR(SYSDATE,'YY

-------------------

2013-11-04 16:34:59

SQL> drop table rman_test2;

Table dropped.

4. 准备恢复到时间点

时间点为 T1，找回删除的表，先关闭数据库

RMAN> shutdown immediate

using target database control file instead of recovery catalog

database closed

database dismounted

Oracle instance shut down

RMAN> exit

5. restore所有的数据文件

不完全恢复需要还原所有的数据库文件，所以还原数据库是比较快捷的做法，而且要在 mount 状态下进行。

RMAN> startup mount;

Oracle instance started

database mounted

Total System Global Area 285212672 bytes

Fixed Size 1218992 bytes

Variable Size 113247824 bytes

Database Buffers 167772160 bytes

Redo Buffers 2973696 bytes

RMAN> restore database;

如果是冷备份，则拷贝刚才备份的所有数据文件回来。

6. 开始不完全恢复

数据库恢复到 T1 时间

RMAN> run {

sql 'alter session set nls_date_format= "YYYY-MM-DD HH24:MI:SS"';

set until time '2013-11-04 16:34:59';

recover database;

};2> 3> 4> 5>

sql statement: alter session set nls_date_format= "YYYY-MM-DD HH24:MI:SS"

executing command: SET until clause

Starting recover at 04-NOV-13

using channel ORA_DISK_1

starting media recovery

media recovery complete, elapsed time: 00:00:02

Finished recover at 04-NOV-13

RMAN> alter database open resetlogs;

database opened

说明注意：

1、不完全恢复最好备份所有的数据，冷备份亦可，因为恢复过程是从备份点往后恢复的，如果因为其中一个数据文件的时间戳(SCN)大于要恢复的时间点，那么恢复都是不可能成功的。

2、不完全恢复有三种方式，过程都一样，仅仅是 recover命令有所不一样，这里用基于时间的恢复作为示例。

3、不完全恢复之后，都必须用 resetlogs的方式打开数据库，建议马上再做一次全备份，因为 resetlogs之后再用以前的备份恢复是很难了。

4、以上是在删除之前获得时间，但是实际应用中，很难知道删除之前的实际时间，但可以采用大致时间即可，或可以采用分析日志文件(logmnr)，取得精确的需要恢复的时间。

5、一般都是在测试机后备用机器上采用这种不完全恢复，恢复之后导出/导入被误删的表回生产系统。

6.2.7基于SCN的不完全恢复案例

1 同上创建测试数据

然后备份全库

RMAN> run{

allocate channel c1 type disk;

backup as compressed backupset database format '/u01/oracle/backup/full_%U' include current controlfile;

release channel c1;

}2> 3> 4> 5>

using target database control file instead of recovery catalog

allocated channel: c1

channel c1: sid=144 devtype=DISK

删除测试表

在删除之前，便于测试，继续插入数据并应用到归档，并获取删除前的 scn 号。

alter system switch logfile;

select dbms_flashback.get_system_change_number from dual;

1328686

Oracle 9i 之前用：

TEST@ORCL> select max(ktuxescnw * power(2, 32) + ktuxescnb) scn from x$ktuxe;

RMAN> startup mount

RMAN> run{

allocate channel c1 type disk;

restore database;

recover database until scn 21069993;

sql 'ALTER DATABASE OPEN RESETLOGS';

release channel c1;

}

可以看到，表依然存在。说明：

1、RMAN也可以实现不完全恢复，方法比 OS 备份恢复的方法更简单可靠

2、RMAN可以基于时间，基于改变与基于日志序列的不完全恢复，基于日志序列的恢复可

以指定恢复到哪个日志序列，如

run {

allocate channel ch1 type disk;

allocate channel ch2 type 'sbt_tape';

set until logseq 1234 thread 1;

restore controlfile to '$ORACLE_HOME/dbs/cf1.f'

replicate controlfile from '$ORACLE_HOME/dbs/cf1.f';

alter database mount;

restore database;

recover database;

sql "ALTER DATABASE OPEN RESETLOGS";

}

3与所有的不完全恢复一样，必须在mount下，restore所有备份数据文件，需要resetlogs。

4、基于改变的恢复比基于时间的恢复更可靠，但是可能也更复杂，需要知道需要恢复到哪一

个改变号(SCN)，在正常生产中，获取 SCN 的办法其实也有很多，如查询数据库字典表

(V$archived_log or v$log_history)，或分析归档与联机日志(logmnr)等。

--获取dbid

获取DBID的几种方法
在使用RMAN的时候，dbid极为重要，dbid唯一的标识了一个数据库。在12C的CDB架构
中每个pdb都有自己的pdb。可以通过以下几种方法来查询数据库的pdb

1，查询v$database中的dbid或是12C的v$containers
SQL> select dbid from v$database;
   DBID
----------
461042625

SQL> select name,dbid from v$pdbs;
NAME                               DBID
------------------------------ ----------
PDB$SEED                      4062019834
PDBNEW3                      3955412277
PDB2                         3885634569

SQL> select name,dbid from v$containers;
NAME                               DBID
------------------------------ ----------
CDB$ROOT                      461042625
PDB$SEED                      4062019834
PDBNEW3                      3955412277
PDB2                         3885634569
2,通过RMAN的输出来得到当前的dbid或nid
[oracle@o12c ~]$ $ORACLE_HOME/bin/rman target / nocatalog
Recovery Manager: Release 12.1.0.1.0 - Production on Wed Mar 12 02:16:24 2014
Copyright (c) 1982, 2013, Oracle and/or its affiliates.  All rights reserved.
connected to target database: C12 (DBID=461042625)
......................................

[oracle@o12c ~]$ nid target=c12 sys/sys
DBNEWID: Release 12.1.0.1.0 - Production on Wed Mar 12 02:27:14 2014
Copyright (c) 1982, 2013, Oracle and/or its affiliates.  All rights reserved.
Connected to database C12 (DBID=461042625)
NID-00121: Database should not be open
.........................................

3,通过controlfile autobackup生成的文件名.当rman配置成controlfile autobackup on
且没有定义FRA时，RMAN会自动备份控制文件到$ORACLE_HOME/dbs目录下，其中的文件名就包含
了dbid信息
RMAN> show controlfile autobackup;
RMAN configuration parameters for database with db_unique_name C12 are:
CONFIGURE CONTROLFILE AUTOBACKUP ON; # default
SQL> alter system set db_recovery_file_dest='';
System altered.
SQL> show parameter db_recovery_file_dest;
NAME                               TYPE       VALUE
------------------------------------ ----------- ------------------------------
db_recovery_file_dest             string
db_recovery_file_dest_size          big integer 10G

RMAN> backup tablespace users;
......................
Starting Control File and SPFILE Autobackup at 12-MAR-14
piece handle=/u01/app/oracle/product/12.1.0/db_1/dbs/c-461042625-20140312-03 comment=NONE
Finished Control File and SPFILE Autobackup at 12-MAR-14.
.........................
c-461042625-20140312-03 文件中的461042625为数据库的dbid信息.

4,前三种方法都是在正常的情况下情况得到的，对于很多时候我们可能并没有记录dbid信息,这时候
只有数据文件或是控制文件就可以了，然后通过dump文件来得到

SQL> startup nomount;
ORACLE instance started.
Total System Global Area  835104768 bytes
Fixed Size                2293880 bytes
Variable Size          322965384 bytes
Database Buffers       503316480 bytes
Redo Buffers             6529024 bytes
SQL> alter system dump datafile '/u01/app/oracle/oradata/c12/sysaux01.dbf' block 1;
System altered.
SQL>  oradebug setmypid;
Statement processed.
SQL>  oradebug tracefile_name;
/u01/app/oracle/diag/rdbms/c12/c12/trace/c12_ora_5435.trc
数据件头信息
Start dump data block from file /u01/app/oracle/oradata/c12/sysaux01.dbf minblk 1 maxblk 1
V10 STYLE FILE HEADER:
      Compatibility Vsn = 202375168=0xc100000
      Db ID=461042625=0x1b7af3c1, Db Name='C12'
      Activation ID=0=0x0
      Control Seq=34457=0x8699, File size=192000=0x2ee00
      File Number=3, Blksiz=8192, File Type=3 DATA
Dump all the blocks in range:
Db ID=461042625=0x1b7af3c1为该数据库的dbid信息

SQL> alter session set events 'immediate trace name controlf level 4';
Session altered...
....................
PLUGGABLE DATABASE RECORDS
***************************************************************************
(size = 684, compat size = 684, section max = 10, section in-use = 5,
  last-recid= 16, old-recno = 0, last-recno = 0)
(extent = 1, blkno = 550, numrecs = 10)
Pluggable DataBase record=1
  id=1
  dbid=461042625
  name=CDB$ROOT
  first datafile link=1
............................
Pluggable DataBase record=3
  id=3
  dbid=3955412277
  name=PDBNEW3
  first datafile link=40
..............................
通过dump controlfile得到的信息最为详尽,其中包括了所有的pdb的dbid信息.