敬业的IT人 >> 数据库 >> Oracle >> 用镜像文件进行基于表空间/数据文件的恢复

用镜像文件进行基于表空间/数据文件的恢复

敬业的IT人 互联网 佚名 2008-1-7 16:09:24

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

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

RMAN> list copy ; List of Datafile CopiesKey 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_.dbf16 2 A 28-MAR-05 10557921 28-MAR-05 /data5/flash_recovery_area/EYGLE/datafile/o1_mf_undotbs1_14h9wfq7_.dbf17 3 A 28-MAR-05 10557950 28-MAR-05 /data5/flash_recovery_area/EYGLE/datafile/o1_mf_sysaux_14h9wxfn_.dbf19 4 A 28-MAR-05 10557960 28-MAR-05 /data5/flash_recovery_area/EYGLE/datafile/o1_mf_users_14h9xjx2_.dbf14 5 A 28-MAR-05 10557903 28-MAR-05 /data5/flash_recovery_area/EYGLE/datafile/o1_mf_eygle_14h9v4bd_.dbf15 6 A 28-MAR-05 10557910 28-MAR-05 /data5/flash_recovery_area/EYGLE/datafile/o1_mf_test_14h9vn0z_.dbf20 7 A 28-MAR-05 10557967 28-MAR-05 /data5/flash_recovery_area/EYGLE/datafile/o1_mf_itpub_14h9y0pg_.dbf22 8 A 28-MAR-05 4544220 13-JUN-04 /data5/flash_recovery_area/EYGLE/datafile/o1_mf_trans_14h9ymw3_.dbf12 9 A 28-MAR-05 10557876 28-MAR-05 /data5/flash_recovery_area/EYGLE/datafile/o1_mf_bigtbs_14h9rwv9_.dbf21 10 A 28-MAR-05 10557974 28-MAR-05 /data5/flash_recovery_area/EYGLE/datafile/o1_mf_dfmbrc_14h9yjfg_.dbf18 11 A 28-MAR-05 10557957 28-MAR-05 /data5/flash_recovery_area/EYGLE/datafile/o1_mf_t2k_14h9xf4y_.dbfList of Archived Log CopiesKey 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_.arcRMAN>

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

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

 $ rman target /Recovery Manager: Release 10.1.0.2.0 - 64bit ProductionCopyright (c) 1995, 2004, Oracle. All rights reserved.connected to target database (not started)RMAN> startup mount;Oracle instance starteddatabase mountedTotal System Global Area 314572800 bytesFixed Size 1301704 bytesVariable Size 261890872 bytesDatabase Buffers 50331648 bytesRedo Buffers 1048576 bytesRMAN> 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 NEWNAMEusing target database controlfile instead of recovery catalogStarting restore at 28-MAR-05allocated channel: ORA_DISK_1channel ORA_DISK_1: sid=160 devtype=DISKchannel ORA_DISK_1: restoring datafile 00008input datafilecopy recid=25 stamp=554139614 filename=/data5/flash_recovery_area/EYGLE/datafile/o1_mf_trans_14h9ymw3_.dbfdestination for restore of datafile 00008: /opt/oracle/oradata/eygle/trans01.dbfchannel ORA_DISK_1: copied datafilecopy of datafile 00008output filename=/opt/oracle/oradata/eygle/trans01.dbf recid=26 stamp=554142136Finished restore at 28-MAR-05datafile 8 switched to datafile copyinput datafilecopy recid=27 stamp=554142139 filename=/opt/oracle/oradata/eygle/trans01.dbfStarting recover at 28-MAR-05using channel ORA_DISK_1starting media recoverymedia recovery completeFinished recover at 28-MAR-05RMAN> alter database open;database openedRMAN>

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

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

Mon Mar 28 16:21:09 2005Database mounted in Exclusive Mode.Completed: alter database mountMon Mar 28 16:22:16 2005Copy 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 4544220Mon Mar 28 16:22:20 2005Switch of datafile 8 complete to datafile copy checkpoint is 4544220Mon Mar 28 16:22:22 2005alter database recover datafile list clearCompleted: alter database recover datafile list clearMon Mar 28 16:22:22 2005alter database recover if needed datafile 8Media Recovery Datafile: 8Media Recovery StartORA-264 signalled during: alter database recover if needed datafile 8...Mon Mar 28 16:22:35 2005alter database openMon Mar 28 16:22:35 2005Block change tracking file is current.Mon Mar 28 16:22:35 2005LGWR: STARTING ARCH PROCESSESARC0 started with pid=15, OS id=29888ARC0: Archival startedMon Mar 28 16:22:35 2005LGWR: STARTING ARCH PROCESSES COMPLETEARC1 started with pid=16, OS id=29890ARC1: Archival startedARC1: Becoming the 'no FAL' ARCHARC1: Becoming the 'no SRL' ARCHMon Mar 28 16:22:35 2005ARC0: Becoming the heartbeat ARCHMon Mar 28 16:22:35 2005LGWR: Primary database is in CLUSTER CONSISTENT modeMaximum redo generation record size = 132096 bytesMaximum redo generation change vector size = 116476 bytesPrivate_strands 3 at log switchThread 1 opened at log sequence 1755Current log# 3 seq# 1755 mem# 0: /opt/oracle/oradata/eygle/redo03.logSuccessful open of redo thread 1Mon Mar 28 16:22:36 2005MTTR advisory is disabled because FAST_START_MTTR_TARGET is not setMon Mar 28 16:22:37 2005Starting background process CTWRCTWR started with pid=17, OS id=29892Block change tracking service is active.Mon Mar 28 16:22:37 2005SMON: enabling cache recoveryMon Mar 28 16:22:39 2005Successfully onlined Undo Tablespace 1.Mon Mar 28 16:22:39 2005SMON: enabling tx recoveryMon Mar 28 16:22:39 2005Database Characterset is ZHS16GBKMon Mar 28 16:22:39 2005Published database character set on system events channelMon Mar 28 16:22:42 2005Starting background process QMNCQMNC started with pid=18, OS id=29896Mon Mar 28 16:22:44 2005replication_dependency_tracking turned off (no async multimaster replication found)Mon Mar 28 16:22:45 2005Starting background process MMONStarting background process MMNLMMON started with pid=19, OS id=29911MMNL started with pid=20, OS id=29913Mon Mar 28 16:22:46 2005Completed: alter database openMon Mar 28 16:22:49 2005db_recovery_file_dest_size of 10240 MB is 25.07% used. This is auser-specified limit on the amount of space that will be used by thisdatabase for recovery-related files, and does not reflect the amount ofspace available in the underlying filesystem or ASM diskgroup.

粤ICP备06119539号
Copyright CiscoSky.Org,Some Rights Reserved.
Email:me1228#tom.com