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

时间:2022-02-14 07:48:01

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

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

Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.


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

Copyright (c) 1995, 2002, Oracle Corporation.  All rights reserved.

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

Copyright (c) 1995, 2002, Oracle Corporation.  All rights reserved.

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

Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.


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

Copyright (c) 1995, 2002, Oracle Corporation.  All rights reserved.

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

Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.


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

Copyright (c) 1995, 2002, Oracle Corporation.  All rights reserved.

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的备份策略

无觅
 
By eygle on 2005-03-09 12:15 | Comments (37) | Del.icio.us | Google | Backup&Recovery | Edit |Pageviews:6588
 

 

 

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

Copyright (c) 1995, 2002, Oracle Corporation. All rights reserved.

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

Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.


 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》,有很多更新内容,你不要看这本书了。
 
--------------------------------------------------------------------------------

CopyRight © 2004~2012 eygle.com, All rights reserved.
 数据恢复·紧急救援·联系我们:手机:13911812803 邮件:eygle@eygle.com|MSN联系:eygle@hotmail.com

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