使用RMAN的备份及恢复一例-丢失所有控制文件

1.数据库基本信息
[oracle@standby oracle]$ sqlplus "/ as sysdba"

SQL*Plus: Release 9.2.0.4.0 - Production on Wed Mar 9 09:55:14 2005

Connected to:
Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production
With the Partitioning option
JServer Release 9.2.0.4.0 - Production

SQL> select name from v$datafile;

NAME
--------------------------------------------------------------------------------
/opt/oracle/oradata/primary/system01.dbf
/opt/oracle/oradata/primary/undotbs01.dbf
/opt/oracle/oradata/primary/users01.dbf

SQL> archive log list;
Database log mode              Archive Mode
Automatic archival             Enabled
Archive destination            /opt/oracle/oradata/primary/archive
Oldest online log sequence     122
Next log sequence to archive   124
Current log sequence           124
SQL> select name from v$archived_log;

NAME
--------------------------------------------------------------------------------
/opt/oracle/oradata/primary/archive/1_109.dbf
/opt/oracle/oradata/primary/archive/1_110.dbf
/opt/oracle/oradata/primary/archive/1_111.dbf
/opt/oracle/oradata/primary/archive/1_112.dbf
/opt/oracle/oradata/primary/archive/1_113.dbf
/opt/oracle/oradata/primary/archive/1_114.dbf
/opt/oracle/oradata/primary/archive/1_115.dbf
/opt/oracle/oradata/primary/archive/1_116.dbf
/opt/oracle/oradata/primary/archive/1_117.dbf
/opt/oracle/oradata/primary/archive/1_118.dbf
/opt/oracle/oradata/primary/archive/1_119.dbf

NAME
--------------------------------------------------------------------------------
/opt/oracle/oradata/primary/archive/1_120.dbf
/opt/oracle/oradata/primary/archive/1_121.dbf
/opt/oracle/oradata/primary/archive/1_122.dbf
/opt/oracle/oradata/primary/archive/1_123.dbf

15 rows selected.

SQL> select name from v$controlfile;

NAME
--------------------------------------------------------------------------------
/opt/oracle/oradata/primary/control01.ctl
/opt/oracle/oradata/primary/control02.ctl
/opt/oracle/oradata/primary/control03.ctl

SQL> exit
Disconnected from Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production
With the Partitioning option
JServer Release 9.2.0.4.0 - Production

2.启用控制文件的自动备份
[oracle@standby oracle]$ rman target /

Recovery Manager: Release 9.2.0.4.0 - Production

connected to target database: PRIMARY (DBID=1367687269)

RMAN> configure controlfile autobackup on;

using target database controlfile instead of recovery catalog
new RMAN configuration parameters:
CONFIGURE CONTROLFILE AUTOBACKUP ON;
new RMAN configuration parameters are successfully stored

RMAN> exit

Recovery Manager complete.

3.执行RMAN全备份

[oracle@standby oracle]$ ls
10g admin dictionary.ora initprimary.ora jre oradata oraInventory oui
[oracle@standby oracle]$ mkdir orabak
[oracle@standby oracle]$ rman target /

Recovery Manager: Release 9.2.0.4.0 - Production

connected to target database: PRIMARY (DBID=1367687269)

RMAN> run {
2> backup database
3> format '/opt/oracle/orabak/full_%d_%T_%s'
4> plus archivelog
5> format '/opt/oracle/orabak/arch_%d_%T_%s'
6> delete all input; }

Starting backup at 09-MAR-05
current log archived
using target database controlfile instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=14 devtype=DISK
channel ORA_DISK_1: starting archive log backupset
channel ORA_DISK_1: specifying archive log(s) in backup set
input archive log thread=1 sequence=109 recid=1 stamp=539688042
input archive log thread=1 sequence=110 recid=2 stamp=539688042
input archive log thread=1 sequence=111 recid=3 stamp=539688043
input archive log thread=1 sequence=112 recid=4 stamp=539735252
input archive log thread=1 sequence=113 recid=5 stamp=539789259
input archive log thread=1 sequence=114 recid=6 stamp=539844028
input archive log thread=1 sequence=115 recid=7 stamp=539899304
input archive log thread=1 sequence=116 recid=8 stamp=539954539
input archive log thread=1 sequence=117 recid=9 stamp=539972835
input archive log thread=1 sequence=118 recid=10 stamp=541574463
input archive log thread=1 sequence=119 recid=11 stamp=543757271
input archive log thread=1 sequence=120 recid=12 stamp=545854003
input archive log thread=1 sequence=121 recid=13 stamp=547951007
input archive log thread=1 sequence=122 recid=14 stamp=550047742
input archive log thread=1 sequence=123 recid=15 stamp=552403943
input archive log thread=1 sequence=124 recid=16 stamp=552478112
channel ORA_DISK_1: starting piece 1 at 09-MAR-05
channel ORA_DISK_1: finished piece 1 at 09-MAR-05
piece handle=/opt/oracle/orabak/arch_PRIMARY_20050309_1 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:08
channel ORA_DISK_1: deleting archive log(s)
archive log filename=/opt/oracle/oradata/primary/archive/1_109.dbf recid=1 stamp=539688042
archive log filename=/opt/oracle/oradata/primary/archive/1_110.dbf recid=2 stamp=539688042
archive log filename=/opt/oracle/oradata/primary/archive/1_111.dbf recid=3 stamp=539688043
archive log filename=/opt/oracle/oradata/primary/archive/1_112.dbf recid=4 stamp=539735252
archive log filename=/opt/oracle/oradata/primary/archive/1_113.dbf recid=5 stamp=539789259
archive log filename=/opt/oracle/oradata/primary/archive/1_114.dbf recid=6 stamp=539844028
archive log filename=/opt/oracle/oradata/primary/archive/1_115.dbf recid=7 stamp=539899304
archive log filename=/opt/oracle/oradata/primary/archive/1_116.dbf recid=8 stamp=539954539
archive log filename=/opt/oracle/oradata/primary/archive/1_117.dbf recid=9 stamp=539972835
archive log filename=/opt/oracle/oradata/primary/archive/1_118.dbf recid=10 stamp=541574463
archive log filename=/opt/oracle/oradata/primary/archive/1_119.dbf recid=11 stamp=543757271
archive log filename=/opt/oracle/oradata/primary/archive/1_120.dbf recid=12 stamp=545854003
archive log filename=/opt/oracle/oradata/primary/archive/1_121.dbf recid=13 stamp=547951007
archive log filename=/opt/oracle/oradata/primary/archive/1_122.dbf recid=14 stamp=550047742
archive log filename=/opt/oracle/oradata/primary/archive/1_123.dbf recid=15 stamp=552403943
archive log filename=/opt/oracle/oradata/primary/archive/1_124.dbf recid=16 stamp=552478112
Finished backup at 09-MAR-05

Starting backup at 09-MAR-05
using channel ORA_DISK_1
channel ORA_DISK_1: starting full datafile backupset
channel ORA_DISK_1: specifying datafile(s) in backupset
input datafile fno=00001 name=/opt/oracle/oradata/primary/system01.dbf
input datafile fno=00002 name=/opt/oracle/oradata/primary/undotbs01.dbf
input datafile fno=00003 name=/opt/oracle/oradata/primary/users01.dbf
channel ORA_DISK_1: starting piece 1 at 09-MAR-05
channel ORA_DISK_1: finished piece 1 at 09-MAR-05
piece handle=/opt/oracle/orabak/full_PRIMARY_20050309_2 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:25
Finished backup at 09-MAR-05

Starting backup at 09-MAR-05
current log archived
using channel ORA_DISK_1
channel ORA_DISK_1: starting archive log backupset
channel ORA_DISK_1: specifying archive log(s) in backup set
input archive log thread=1 sequence=125 recid=17 stamp=552478150
channel ORA_DISK_1: starting piece 1 at 09-MAR-05
channel ORA_DISK_1: finished piece 1 at 09-MAR-05
piece handle=/opt/oracle/orabak/arch_PRIMARY_20050309_3 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:02
channel ORA_DISK_1: deleting archive log(s)
archive log filename=/opt/oracle/oradata/primary/archive/1_125.dbf recid=17 stamp=552478150
Finished backup at 09-MAR-05

Starting Control File and SPFILE Autobackup at 09-MAR-05
piece handle=/opt/oracle/product/9.2.0/dbs/c-1367687269-20050309-00 comment=NONE
Finished Control File and SPFILE Autobackup at 09-MAR-05

RMAN> exit

Recovery Manager complete.

4.移除所有控制文件及数据文件

[oracle@standby oracle]$ sqlplus "/ as sysdba"

SQL*Plus: Release 9.2.0.4.0 - Production on Wed Mar 9 10:11:23 2005

Connected to:
Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production
With the Partitioning option
JServer Release 9.2.0.4.0 - Production

SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> exit
Disconnected from Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production
With the Partitioning option
JServer Release 9.2.0.4.0 - Production
[oracle@standby oracle]$ cd oradata/
[oracle@standby oradata]$ ls
primary

[oracle@standby oradata]$ mv primary/ primarybak
[oracle@standby oradata]$ mkdir primary
[oracle@standby oradata]$ ls
primary primarybak

5.从自动备份中恢复控制文件

[oracle@standby oradata]$ rman target /

Recovery Manager: Release 9.2.0.4.0 - Production

connected to target database (not started)

RMAN> startup nomount;

Oracle instance started

Total System Global Area 135337420 bytes

Fixed Size                      452044 bytes
Variable Size                109051904 bytes
Database Buffers              25165824 bytes
Redo Buffers                    667648 bytes

RMAN> restore controlfile to '/opt/oracle/oradata/control01.ctl' from autobackup;

Starting restore at 09-MAR-05

using target database controlfile instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=11 devtype=DISK
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 03/09/2005 10:15:05
RMAN-06495: must explicitly specify DBID with SET DBID command

RMAN> set DBID=1367687269

executing command: SET DBID

RMAN> restore controlfile to '/opt/oracle/oradata/control01.ctl' from autobackup;

Starting restore at 09-MAR-05

using channel ORA_DISK_1
channel ORA_DISK_1: looking for autobackup on day: 20050309
channel ORA_DISK_1: autobackup found: c-1367687269-20050309-00
channel ORA_DISK_1: controlfile restore from autobackup complete
Finished restore at 09-MAR-05

RMAN> exit

Recovery Manager complete.

6.你可能需要修改spfile文件
当然如果文件位置等信息没有变化就无需修改

[oracle@standby oradata]$ sqlplus '/ as sysdba'

SQL*Plus: Release 9.2.0.4.0 - Production on Wed Mar 9 10:19:53 2005

Connected to:
Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production
With the Partitioning option
JServer Release 9.2.0.4.0 - Production

SQL> create pfile from spfile;

File created.

SQL> !
[oracle@standby oradata]$ cd $ORACLE_HOME/dbs
[oracle@standby dbs]$ vi initprimary.ora

*.aq_tm_processes=0
*.background_dump_dest='/opt/oracle/admin/primary/bdump'
*.compatible='9.2.0.0.0'
*.control_files='/opt/oracle/oradata/control01.ctl'
*.core_dump_dest='/opt/oracle/admin/primary/cdump'
*.db_block_size=8192
*.db_cache_size=25165824
*.db_domain=''
*.db_file_multiblock_read_count=16
*.db_name='primary'
*.fast_start_mttr_target=300
*.hash_join_enabled=TRUE
*.instance_name='primary'
*.java_pool_size=0
*.job_queue_processes=0
*.large_pool_size=8388608
*.log_archive_dest_1='LOCATION=/opt/oracle/oradata/primary/archive'
*.log_archive_format='%t_%s.dbf'
*.log_archive_start=true
*.open_cursors=300
*.pga_aggregate_target=25165824
*.processes=150
*.query_rewrite_enabled='FALSE'
*.remote_login_passwordfile='EXCLUSIVE'
*.resource_manager_plan='SYSTEM_PLAN'
*.shared_pool_size=83886080
*.sort_area_size=524288
*.star_transformation_enabled='FALSE'
*.timed_statistics=TRUE
*.undo_management='AUTO'
*.undo_retention=10800
*.undo_tablespace='UNDOTBS1'
*.user_dump_dest='/opt/oracle/admin/primary/udump'
*.utl_file_dir='/opt/oracle'
~
~
~
~
~
"initprimary.ora" 34L, 1044C written
[oracle@standby dbs]$ exit
exit

SQL> shutdown immediate;
ORA-01507: database not mounted

ORACLE instance shut down.
SQL> create spfile from pfile;

File created.

SQL> startup mount;
ORACLE instance started.

Total System Global Area 135337420 bytes
Fixed Size                   452044 bytes
Variable Size             109051904 bytes
Database Buffers           25165824 bytes
Redo Buffers                 667648 bytes
Database mounted.
SQL> exit
Disconnected from Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production
With the Partitioning option
JServer Release 9.2.0.4.0 - Production

7.使用rman进行恢复

[oracle@standby oradata]$ rman target /

Recovery Manager: Release 9.2.0.4.0 - Production

connected to target database: PRIMARY (DBID=1367687269)

RMAN> restore database;

Starting restore at 09-MAR-05

using target database controlfile instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=11 devtype=DISK
channel ORA_DISK_1: starting datafile backupset restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
restoring datafile 00001 to /opt/oracle/oradata/primary/system01.dbf
restoring datafile 00002 to /opt/oracle/oradata/primary/undotbs01.dbf
restoring datafile 00003 to /opt/oracle/oradata/primary/users01.dbf
channel ORA_DISK_1: restored backup piece 1
piece handle=/opt/oracle/orabak/full_PRIMARY_20050309_2 tag=TAG20050309T100844 params=NULL
channel ORA_DISK_1: restore complete
Finished restore at 09-MAR-05

RMAN> recover database;

Starting recover at 09-MAR-05
using channel ORA_DISK_1

starting media recovery

channel ORA_DISK_1: starting archive log restore to default destination
channel ORA_DISK_1: restoring archive log
archive log thread=1 sequence=125
channel ORA_DISK_1: restored backup piece 1
piece handle=/opt/oracle/orabak/arch_PRIMARY_20050309_3 tag=TAG20050309T100910 params=NULL
channel ORA_DISK_1: restore complete
archive log filename=/opt/oracle/oradata/primary/archive1_125.dbf thread=1 sequence=125
unable to find archive log
archive log thread=1 sequence=126
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 03/09/2005 10:44:02
RMAN-06054: media recovery requesting unknown log: thread 1 scn 6691197

RMAN> alter database open resetlogs;

database opened

RMAN>

至此恢复完成。

历史上的今天...
>> 2012-03-09文章:

Reconnect device Samsung Kies (PC studio) mode

>> 2011-03-09文章:

SAP的 XI_AF_MSG 消息表优化及清理

>> 2010-03-09文章:

飞信招聘数据库开发工程师 (开发DBA)

>> 2009-03-09文章:

Quest 的 Spotlight On Unix 漂亮的展现

Eygle.Com 网站历史

>> 2008-03-09文章:

深入理解数据库创建-补遗

巴菲特的年终总结-享受快乐与健康

相关文章：
•如何简单测试Rman的备份恢复功能?
•Oracle9i新特点-从自动备份中恢复spfile和控制文件
•如何从自动备份中恢复控制文件和SPFILE文件
•使用Catalog命令注册RMAN备份集
•使用RMAN进行排除表空间备份
•使用RMAN进行基于时间点的不完全恢复
•RMAN结合Read Only、Exclude的备份策略

37 Comments

javablue | March 9, 2005 9:22 PM

set DBID=1367687269
请问如何知道dbid,设置这个dbid的依据是什么

eygle | March 9, 2005 9:25 PM

rman target /

连接时就可以看到。

[oracle@standby oradata]$ rman target /

Recovery Manager: Release 9.2.0.4.0 - Production

connected to target database: PRIMARY (DBID=1367687269)

eygle | March 9, 2005 11:39 PM

也可以从v$database中查询得到:

SQL> select dbid from v$database;

DBID
----------
3152029224

battleman | March 12, 2005 12:48 PM

想请教：为什么要alter database open resetlogs呢？
最后一步换成alter database open 可以吗？？

eygle | March 12, 2005 12:56 PM

这个案例里边，丢失了所有的在线redo log file
所以作的是一次不完全恢复。

dai_zhy | March 21, 2005 2:41 PM

请问这个DBID是哪个库的dbid？
是old数据库的id，还是正需要恢复的dbid？

eygle | March 21, 2005 3:21 PM

就是你需要恢复的数据库的DBID,每个数据库的DBID都是唯一的。

dbwyl999 | July 12, 2005 8:54 AM

如果用原来backup controlfile to trace的脚本在
nomount状态下创建一个controlfile(代替restore controlfile to '/opt/oracle/oradata/control01.ctl' from autobackup) 然后再用rman 恢复也可以吧.

eygle | July 12, 2005 10:03 AM

to dbwyl999 ；

你重建的控制文件中，不包含备份集的信息，是无法从RMAN备份集中进行恢复的。

bulk | July 23, 2005 5:58 PM

如你上面实验的,数据库已经起不来,备份的时候又没有记下DBID,那如何知道这个DBID.

eygle | July 23, 2005 6:11 PM

to bulk:

只要数据库还可以mount，也可以从控制文件的dump中获得:

[oracle@jumper tools]$ sqlplus "/ as sysdba"

SQL*Plus: Release 9.2.0.4.0 - Production on Sat Jul 23 18:39:19 2005

Connected to:
Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production
With the Partitioning option
JServer Release 9.2.0.4.0 - Production

SQL> alter session set events 'immediate trace name CONTROLF level 10' ;

Session altered.

SQL> @gettrc

TRACE_FILE_NAME
------------------------------------------------------------------------------------------------------------------------
/opt/oracle/admin/conner/udump/conner_ora_23213.trc

SQL> !
[oracle@jumper tools]$ more /opt/oracle/admin/conner/udump/conner_ora_23213.trc
....

*** SESSION ID:(20.10) 2005-07-23 18:39:25.717
DUMP OF CONTROL FILES, Seq # 11980 = 0x2ecc
FILE HEADER:
Software vsn=153092096=0x9200000, Compatibility Vsn=134217728=0x8000000
Db ID=3152029224=0xbbe02628, Db Name='CONNER'
Activation ID=0=0x0
Control Seq=11980=0x2ecc, File size=406=0x196
File Number=0, Blksiz=8192, File Type=1 CONTROL

当然你最好不要一无所有，如果你是DBA。

当然我们还有很多方法可以获得dbid.

bulk | July 24, 2005 5:55 PM

如果数据库可以MOUNT起来,很容易可以获得DBID.实际上的确会存在你上面的实验情况,数据库无法MOUNT了,而又没有记下DBID.看来养成做LOG,保存每次操作的日志,是DBA很好的习惯.这是我从你此贴的最大体会,THKS.

eygle | July 24, 2005 8:51 PM

实际上，即使数据库无法mount，仍然是可以获得dbid的，只是记得最好不要让你的数据库处于如此境地就好。

bulk | July 24, 2005 10:25 PM

"实际上，即使数据库无法mount，仍然是可以获得dbid的，只是记得最好不要让你的数据库处于如此境地就好。"
我就是想知道这个,等待你的回复.

bulk | July 25, 2005 12:55 AM

http://www.eygle.com/ha/Use.Hot.Backup.Recover.Day.by.Day.htm

上面这个帖子为什么不能回复呢,有些疑问还想你点明.

eygle | July 25, 2005 4:31 PM

实际上每个数据文件和控制文件上都包含dbid信息，可以自己写程序从脱机文件中读取出来：

SQL> select eygle.get_dbid('/opt/oracle/oradata/conner','user02.dbf') from dual;

EYGLE.GET_DBID('/OPT/ORACLE/OR
------------------------------
3152029224

SQL> select dbid from v$database;

DBID
----------
3152029224

myanly | August 3, 2005 9:44 PM

照着搞了一遍，失败

myanly | August 3, 2005 10:02 PM

eygle:

第4步已经删除了控制文件
第5步又如何找到备份集，并从中恢复控制文件？
还是我多删除了备份集！

晕啊

eygle | August 3, 2005 10:20 PM

第五步，要恢复一个控制文件出来，我启用的自动控制文件备份，这个控制文件中包含最后一次备份集信息。

如果你没有启用自动控制文件备份，你需要最后一个控制文件。

否则就需要另外的方式恢复了。

eygle | August 3, 2005 10:26 PM

如果没有控制文件，你需要参考这个:

http://www.eygle.com/archives/2005/06/oorman06026iioe.html

myanly | August 3, 2005 10:34 PM

eygle:

第4步已经删除了控制文件
第5步又如何找到备份集，并从中恢复控制文件？
还是我多删除了备份集！

晕啊

xz | October 18, 2005 2:25 PM

我按照上面一步一步做下去，有redo log，怎么最后
open 不了？
RMAN> recover database;

Starting recover at 18-OCT-05
using channel ORA_DISK_1

starting media recovery

archive log thread 1 sequence 77 is already on disk as file /oracle/OraBase9204/
oradata/DATA/U8/redo02.log
archive log thread 1 sequence 78 is already on disk as file /oracle/OraBase9204/
oradata/DATA/U8/redo03.log
archive log thread 1 sequence 79 is already on disk as file /oracle/OraBase9204/
oradata/DATA/U8/redo01.log
channel ORA_DISK_1: starting archive log restore to default destination
channel ORA_DISK_1: restoring archive log
archive log thread=1 sequence=73
channel ORA_DISK_1: restored backup piece 1
piece handle=/oracle/OraBase9204/oradata/DATA/RMAN/BACK1/arch_U8_20051018_23.bak
tag=TAG20051018T135417 params=NULL
channel ORA_DISK_1: restore complete
archive log filename=/oracle/OraBase9204/oradata/DATA/ARC/arch_73.log thread=1 s
equence=73
archive log filename=/oracle/OraBase9204/oradata/DATA/ARC/arch_74.log thread=1 s
equence=74
archive log filename=/oracle/OraBase9204/oradata/DATA/ARC/arch_75.log thread=1 s
equence=75
archive log filename=/oracle/OraBase9204/oradata/DATA/ARC/arch_76.log thread=1 s
equence=76
archive log filename=/oracle/OraBase9204/oradata/DATA/U8/redo02.log thread=1 seq
uence=77
archive log filename=/oracle/OraBase9204/oradata/DATA/U8/redo03.log thread=1 seq
uence=78
archive log filename=/oracle/OraBase9204/oradata/DATA/U8/redo01.log thread=1 seq
uence=79
media recovery complete
Finished recover at 18-OCT-05

RMAN> alter database open;

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of alter db command at 10/18/2005 14:18:45
ORA-01589: must use RESETLOGS or NORESETLOGS option for database open

eygle | October 18, 2005 2:37 PM

ORA-01589: must use RESETLOGS or NORESETLOGS option for database open

需要用resetlogs参数打开数据库

alter database open resetlogs;

xz | October 18, 2005 4:45 PM

为什么在recover时，所有redo log都应用了，还要resetlogs打开？

在你的例子中，最后你用recover database，这个rman应该会认为是完全恢复，但是缺少redo，所以完全恢复会失败，那最后alter database open resetlogs为什么还会成功？

eygle | October 18, 2005 4:53 PM

我使用的是恢复出来的控制文件，也就是备份的控制文件。
最后自然需要resetlogs打开数据库。

你如果和我的测试一样，肯定也是需要的。

如果控制文件没有丢失，作完全恢复，就不需要resestlogs打开数据库了。

xz | October 19, 2005 1:46 PM

-----------------------------------------------
想请教：为什么要alter database open resetlogs呢？
最后一步换成alter database open 可以吗？？

Posted by: battleman at March 12, 2005 12:48 PM

这个案例里边，丢失了所有的在线redo log file
所以作的是一次不完全恢复。

Posted by: eygle at March 12, 2005 12:56 PM

-------------------------------------------------
前面的这个回复，让别人觉得如果redo log存在的话，就可以
用alter database open打开

eygle | October 20, 2005 11:19 AM

那个回复重点说的是丢失日志、不完全恢复。

jjspoty | November 24, 2005 3:15 PM

小弟照着做了一遍，比较成功，还有一些疑问想请教大虾，为什么我自己提前通过cp备份控制文件，但是无法恢复？

jjspoty | November 24, 2005 3:15 PM

小弟照着做了一遍，比较成功，还有一些疑问想请教大虾，为什么我自己提前通过cp备份控制文件，但是无法恢复？

eygle | November 24, 2005 3:40 PM

什么错误?

jjspoty | December 1, 2005 1:58 PM

非常感谢eygle大虾的回复，小弟最近比较忙，所以这么晚才恢复，今天又重新把备份恢复过程作了一遍，还是遇到同样的错误，请大虾帮我看看:

首先我做了一个全备:
RMAN> startup

connected to target database (not started)
Oracle instance started
database mounted
database opened

Total System Global Area 320308312 bytes

Fixed Size 730200 bytes
Variable Size 285212672 bytes
Database Buffers 33554432 bytes
Redo Buffers 811008 bytes

RMAN> run {
2> backup database
3> format '/u02/rmanback/fullback/full_%d_%T_%s';}

Starting backup at 30-NOV-05
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=13 devtype=DISK
channel ORA_DISK_1: starting full datafile backupset
channel ORA_DISK_1: specifying datafile(s) in backupset
including current SPFILE in backupset
including current controlfile in backupset
input datafile fno=00001 name=/u01/oracle/oradata/db235/system01.dbf
input datafile fno=00002 name=/u01/oracle/oradata/db235/undotbs01.dbf
input datafile fno=00005 name=/u01/oracle/oradata/db235/example01.dbf
input datafile fno=00010 name=/u01/oracle/oradata/db235/xdb01.dbf
input datafile fno=00006 name=/u01/oracle/oradata/db235/indx01.dbf
input datafile fno=00009 name=/u01/oracle/oradata/db235/users01.dbf
input datafile fno=00003 name=/u01/oracle/oradata/db235/cwmlite01.dbf
input datafile fno=00004 name=/u01/oracle/oradata/db235/drsys01.dbf
input datafile fno=00007 name=/u01/oracle/oradata/db235/odm01.dbf
input datafile fno=00008 name=/u01/oracle/oradata/db235/tools01.dbf
channel ORA_DISK_1: starting piece 1 at 30-NOV-05
channel ORA_DISK_1: finished piece 1 at 30-NOV-05
piece handle=/u02/rmanback/fullback/full_DB235_20051130_6 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:55
Finished backup at 30-NOV-05

看样子好像备份的没有问题，然后关闭数据库移除所有数据库文件，但是保留控制文件，应该跟我提前在操作系统层备份控制文件是一样的吧?

RMAN> shutdown immediate

database closed
database dismounted
Oracle instance shut down

$ pwd
/u01/oracle/oradata/db235
$ ls
control01.ctl cwmlite01.dbf indx01.dbf redo02.log temp01.dbf users01.dbf
control02.ctl drsys01.dbf odm01.dbf redo03.log tools01.dbf xdb01.dbf
control03.ctl example01.dbf redo01.log system01.dbf undotbs01.dbf
$ cd ..
$ ls
db235
$ mv db235 db235.bk
$ ls
db235.bk
$ mkdir db235
$ cp db235.bk/*.ctl db235
$ ls db235
control01.ctl control02.ctl control03.ctl

然后启动数据库到mount状态作恢复，可是报错
RMAN> startup mount

connected to target database (not started)
Oracle instance started
database mounted

Total System Global Area 320308312 bytes

Fixed Size 730200 bytes
Variable Size 285212672 bytes
Database Buffers 33554432 bytes
Redo Buffers 811008 bytes

RMAN> restore database;

Starting restore at 30-NOV-05

allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=13 devtype=DISK
channel ORA_DISK_1: starting datafile backupset restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
restoring datafile 00001 to /u01/oracle/oradata/db235/system01.dbf
restoring datafile 00002 to /u01/oracle/oradata/db235/undotbs01.dbf
restoring datafile 00003 to /u01/oracle/oradata/db235/cwmlite01.dbf
restoring datafile 00004 to /u01/oracle/oradata/db235/drsys01.dbf
restoring datafile 00005 to /u01/oracle/oradata/db235/example01.dbf
restoring datafile 00006 to /u01/oracle/oradata/db235/indx01.dbf
restoring datafile 00007 to /u01/oracle/oradata/db235/odm01.dbf
restoring datafile 00008 to /u01/oracle/oradata/db235/tools01.dbf
restoring datafile 00009 to /u01/oracle/oradata/db235/users01.dbf
restoring datafile 00010 to /u01/oracle/oradata/db235/xdb01.dbf
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 11/30/2005 21:48:04
ORA-19501: read error on file "/u02/rmanback/fullback/2db.dmp", blockno 129 (blocksize=8192)
ORA-27063: skgfospo: number of bytes read/written is incorrect
Additional information: 483328
Additional information: 1048576
ORA-19501: read error on file "/u02/rmanback/fullback/2db.dmp", blockno 1 (blocksize=8192)
ORA-27063: skgfospo: number of bytes read/written is incorrect
Additional information: 24576
Additional information: 1048576

RMAN>

请问是为什么？小弟初学RMAN，会不会是很傻的问题，呵呵。。。

eygle | December 1, 2005 2:09 PM

你恢复怎么读取的不是:
handle=/u02/rmanback/fullback/full_DB235_20051130_6

这个文件?

jjspoty | December 1, 2005 2:45 PM

恩，小弟没仔细看，可是我再试了一次还是这样，他现在读取的文件是我上次备份的，请问如何才能让他读取我刚才备份的文件full_DB235_20051130_6，能否把上次备份的删除？多谢！

侯雪峰| December 12, 2005 3:42 PM

D:\oracle\ora92\database
执行configure controlfile autobackup on后，会在
执行完全备份后，会生成一个控制文件的备份
格式如下C-1103686183-20051206-00
C表示控制文件备份
1103686183就是数据库id 即DBID
20051206备份日期
00当天备份的序列号，从00开始 01表示第二次备份

马瑞琪 replied to comment from eygle | March 29, 2011 5:56 PM

我在看你的书《深入浅出oracle》，学着做实验， @gettrc这个是获取转储文件的位置及其姓名，小妹妹不知道哦。请问你这个文件的sql应该怎么写啊？gettrc.sql。呵呵你可以留言，或是发邮件给我。谢谢啦。

马瑞琪| March 29, 2011 5:58 PM

@gettrc在哪里可以找到？这个sql

eygle | March 29, 2011 7:41 PM

在这里：
http://www.eygle.com/archives/2007/05/script_gettrcname.html

另外，的修订版本是《深入解析Oracle》，有很多更新内容，你不要看这本书了。

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

from :http://www.eygle.com/archives/2005/03/eoarmanaeoeoaee.html

使用RMAN的备份及恢复一例-丢失所有控制文件相关推荐

ORACLE实例控制文件删除恢复,Oracle案例：损坏控制文件的恢复方法
一: 损坏单个控制文件损坏单个控制文件是比较容易恢复的,因为一般的数据库系统,控制文件都不是一个,而且所有的控制文件都互为镜相,只要拷贝一个好的控制文件替换坏的控制文件就可以了. 1.控制文件损坏, ...
oracle某个表丢失,丢失一个控制文件并恢复数据库
只丢失或损坏一个控制文件的情况下来恢复数据库,相对来说简单一点.一般来说,控制文件都需要形成一个多路径冗余策略,来提高数据库的安全性.这样的话只需将完好的控制文件复制一个副本放到丢失或者损坏了的控 ...
oracle 安全备份与rman_Oracle 11g下使用RMAN进行备份和恢复操作（一）
备注:从10g版本起,log_archive_start 参数已经废弃,不用设置了. 介绍:RMAN备份和恢复操作,要求数据库必须运行在归档模式下.本节先介绍如何开启数据库的归档模式. 第一步:查看当 ...
oracle备份的输出日志文件,oracle导出数据，备份及恢复数据，及数据库日志文件的查看...
以salary为例,在PLSQL Developer中操作 1.导出salary表的数据:将 salary 表的数据以 insert 语句的方式导出 tools-->Export Tables- ...
dataguard从库数据库丢失恢复例子(模拟所有的控制文件)
1.退出日志应用模式 [oracle@localhost ~]$ sqlplus /nolog SQL*Plus: Release 11.2.0.4.0 Production on Mon Jan 1 ...
【技术分享】Oracle控制文件的备份、恢复以及多路复用
Oracle控制文件的备份.恢复以及多路复用前言今天Frank给大家带来有关Oracle控制文件的技术分享.不积跬步无以至千里,不积小流无以成江海. ...
复用Oracle数据文件,Oracle控制文件的备份、恢复以及多路复用
前言今天给大家带来有关Oracle控制文件的技术分享.不积跬步无以至千里,不积小流无以成江海.Oracle技术博大精深,以我一个人的力量,那无异于蜉蝣于天地,沧海之一粟.在此,笔者抛砖引玉,希望读者 ...
RMAN深入解析之--控制文件
控制文件负责数据库的物理结构,控制文件控制数据库查找物理文件的位置,并控制每个文件当前包含的头信息,其内容包含数据文件信息,重做日志信息和归档日志信息:控制文件还还有与数据库关联的关键文件的每 ...
执行用户管理（不依赖于RMAN）的备份和恢复_执行用户管理的数据库闪回和恢复
本章描述在用户管理的备份和恢复策略中如何还原和恢复数据库和使用Oracle数据库的闪回特性.用户管理的备份和还原策略意味着不依赖RMAN的方法. 1．使用SQL*Plus执行闪回数据库可以在非CDB ...

使用RMAN的备份及恢复一例-丢失所有控制文件

使用RMAN的备份及恢复一例-丢失所有控制文件相关推荐

最新文章

热门文章