Chinaunix首页 | 论坛 | 博客
  • 博客访问: 91741315
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类: Oracle

2008-04-01 16:44:31

来源:赛迪网    作者:39630

阅读本文前,您必须在数据文件或者表空间丢失之前已经进行了镜像COPY备份,如果您目前符合当前的条件,那么本文可以作为您的恢复参考:

1.首先,我们需要查看备份的情况。

RMAN> list copy ;    


List of Datafile Copies
Key     File S Completion Time Ckp SCN    Ckp Time        Name
------- ---- - --------------- ---------- --------------- ----
13  1    A 28-MAR-05       10557893   28-MAR-05  /data5/flash_recovery_area/EYGLE/datafile
/o1_mf_system_14h9tbms_.dbf
16  2    A 28-MAR-05       10557921   28-MAR-05  /data5/flash_recovery_area/EYGLE/datafile
/o1_mf_undotbs1_14h9wfq7_.dbf
17  3    A 28-MAR-05       10557950   28-MAR-05  /data5/flash_recovery_area/EYGLE/datafile
/o1_mf_sysaux_14h9wxfn_.dbf
19  4    A 28-MAR-05       10557960   28-MAR-05  /data5/flash_recovery_area/EYGLE/datafile
/o1_mf_users_14h9xjx2_.dbf
14  5    A 28-MAR-05       10557903   28-MAR-05  /data5/flash_recovery_area/EYGLE/datafile
/o1_mf_eygle_14h9v4bd_.dbf
15  6    A 28-MAR-05       10557910   28-MAR-05  /data5/flash_recovery_area/EYGLE/datafile
/o1_mf_test_14h9vn0z_.dbf
20  7    A 28-MAR-05       10557967   28-MAR-05  /data5/flash_recovery_area/EYGLE/datafile
/o1_mf_itpub_14h9y0pg_.dbf
22  8    A 28-MAR-05       4544220    13-JUN-04  /data5/flash_recovery_area/EYGLE/datafile
/o1_mf_trans_14h9ymw3_.dbf
12  9    A 28-MAR-05       10557876   28-MAR-05  /data5/flash_recovery_area/EYGLE/datafile
/o1_mf_bigtbs_14h9rwv9_.dbf
21  10   A 28-MAR-05       10557974   28-MAR-05  /data5/flash_recovery_area/EYGLE/datafile
/o1_mf_dfmbrc_14h9yjfg_.dbf
18  11   A 28-MAR-05       10557957   28-MAR-05  /data5/flash_recovery_area/EYGLE/datafile
/o1_mf_t2k_14h9xf4y_.dbf

List of Archived Log Copies
Key     Thrd Seq     S Low Time  Name
------- ---- ------- - --------- ----
229     1    1753    A 28-MAR-05 /data5/flash_recovery_area
/EYGLE/archivelog/2005_03_28/o1_mf_1_1753_14hcp43x_.arc

RMAN>

2.下一步,恢复相关的文件

注释:您可以通过SETNAME指定恢复文件到不同的位置.

$ rman target /

Recovery Manager: Release 10.1.0.2.0 - 64bit Production

Copyright (c) 1995, 2004, Oracle.  All rights reserved.

connected to target database (not started)

RMAN> startup mount;

Oracle instance started
database mounted

Total System Global Area     314572800 bytes

Fixed Size                     1301704 bytes
Variable Size                261890872 bytes
Database Buffers              50331648 bytes
Redo Buffers                   1048576 bytes

RMAN> run {
2> SET NEWNAME FOR DATAFILE 8 TO 
'/opt/oracle/oradata/eygle/trans01.dbf';
3> RESTORE DATAFILE 8;
4> SWITCH DATAFILE ALL;
5> RECOVER DATAFILE 8;
}6> 

executing command: SET NEWNAME
using target database controlfile instead of recovery catalog

Starting restore at 28-MAR-05
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=160 devtype=DISK

channel ORA_DISK_1: restoring datafile 00008
input datafilecopy recid=25 stamp=554139614 
filename=/data5/flash_recovery_area/EYGLE
/datafile/o1_mf_trans_14h9ymw3_.dbf
destination for restore of datafile 00008: 
/opt/oracle/oradata/eygle/trans01.dbf
channel ORA_DISK_1: copied 
datafilecopy of datafile 00008
output filename=/opt/oracle/oradata
/eygle/trans01.dbf recid=26 stamp=554142136
Finished restore at 28-MAR-05

datafile 8 switched to datafile copy
input datafilecopy recid=27 stamp=554142139 filename=/opt/oracle/oradata/eygle/trans01.dbf

Starting recover at 28-MAR-05
using channel ORA_DISK_1

starting media recovery
media recovery complete

Finished recover at 28-MAR-05

RMAN> alter database open;

database opened

RMAN>

3.最后,查看一下alert文件的记录

在这里大家可以留意一下恢复过程中alert文件中记录的详细信息:

Mon Mar 28 16:21:09 2005
Database mounted in Exclusive Mode.
Completed: alter database mount
Mon Mar 28 16:22:16 2005
Copy of datafile copy /data5/flash_recovery_area/EYGLE
/datafile/o1_mf_trans_14h9ymw3_.dbf complete 
to datafile copy /opt/oracle/oradata/eygle/test01.dbf
  checkpoint is 4544220
Mon Mar 28 16:22:20 2005
Switch of datafile 8 complete to datafile copy 
  checkpoint is 4544220
Mon Mar 28 16:22:22 2005
alter database recover datafile list clear
Completed: alter database recover datafile list clear
Mon Mar 28 16:22:22 2005
alter database recover if needed
 datafile 8
Media Recovery Datafile: 8
Media Recovery Start
ORA-264 signalled during: 
alter database recover if needed
 datafile 8
...
Mon Mar 28 16:22:35 2005
alter database open
Mon Mar 28 16:22:35 2005
Block change tracking file is current.
Mon Mar 28 16:22:35 2005
LGWR: STARTING ARCH PROCESSES
ARC0 started with pid=15, OS id=29888
ARC0: Archival started
Mon Mar 28 16:22:35 2005
LGWR: STARTING ARCH PROCESSES COMPLETE
ARC1 started with pid=16, OS id=29890
ARC1: Archival started
ARC1: Becoming the 'no FAL' ARCH
ARC1: Becoming the 'no SRL' ARCH
Mon Mar 28 16:22:35 2005
ARC0: Becoming the heartbeat ARCH
Mon Mar 28 16:22:35 2005
LGWR: Primary database is in CLUSTER CONSISTENT mode
Maximum redo generation record size = 132096 bytes
Maximum redo generation change vector size = 116476 bytes
Private_strands 3 at log switch
Thread 1 opened at log sequence 1755
Current log# 3 seq# 1755 mem# 0: 
/opt/oracle/oradata/eygle/redo03.log
Successful open of redo thread 1
Mon Mar 28 16:22:36 2005
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
Mon Mar 28 16:22:37 2005
Starting background process CTWR
CTWR started with pid=17, OS id=29892
Block change tracking service is active.
Mon Mar 28 16:22:37 2005
SMON: enabling cache recovery
Mon Mar 28 16:22:39 2005
Successfully onlined Undo Tablespace 1.
Mon Mar 28 16:22:39 2005
SMON: enabling tx recovery
Mon Mar 28 16:22:39 2005
Database Characterset is ZHS16GBK
Mon Mar 28 16:22:39 2005
Published database character set on system events channel
Mon Mar 28 16:22:42 2005
Starting background process QMNC
QMNC started with pid=18, OS id=29896
Mon Mar 28 16:22:44 2005
replication_dependency_tracking turned off 
(no async multimaster replication found)
Mon Mar 28 16:22:45 2005
Starting background process MMON
Starting background process MMNL
MMON started with pid=19, OS id=29911
MMNL started with pid=20, OS id=29913
Mon Mar 28 16:22:46 2005
Completed: alter database open
Mon Mar 28 16:22:49 2005
db_recovery_file_dest_size of 10240 MB is 25.07% used. This is a
user-specified limit on the amount of space that will be used by this
database for recovery-related files, and does not reflect the amount of
space available in the underlying filesystem or ASM diskgroup.
阅读(256) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~