11gR2 dataguard 备库文件损坏处理一例
本站文章除注明转载外，均为本站原创： 转载自love wife love life —Roger的Oracle/MySQL/PostgreSQL数据恢复博客
本文链接地址: 11gR2 dataguard 备库文件损坏处理一例
某客户的一套11gR2 dataguard环境出现异常，检查发现是备库出现文件损坏，且无法正常情况，已经超过1个多月没同步了。 我们先来看下备库的日志：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 |
.......省略部分内容 See Note 411.1 at My Oracle Support for error and packaging details. Slave exiting with ORA-600 exception Errors in file /u01/app/oracle/diag/rdbms/crjnew/crjnew/trace/crjnew_pr0p_9892.trc: ORA-00600: internal error code, arguments: [3020], [3], [6118], [12589030], [], [], [], [], [], [], [], [] ORA-10567: Redo is inconsistent with data block (file# 3, block# 6118, file offset is 50118656 bytes) ORA-10564: tablespace UNDOTBS1 ORA-01110: data file 3: '/u01/app/oracle/oradata/CRJNEW/datafile/o1_mf_undotbs1_859l2yrm_.dbf' ORA-10560: block type 'KTU UNDO BLOCK' Use ADRCI or Support Workbench to package the incident. See Note 411.1 at My Oracle Support for error and packaging details. Slave exiting with ORA-600 exception Errors in file /u01/app/oracle/diag/rdbms/crjnew/crjnew/trace/crjnew_pr1p_9964.trc: ORA-00600: internal error code, arguments: [3020], [3], [3740], [12586652], [], [], [], [], [], [], [], [] ORA-10567: Redo is inconsistent with data block (file# 3, block# 3740, file offset is 30638080 bytes) ORA-10564: tablespace UNDOTBS1 ORA-01110: data file 3: '/u01/app/oracle/oradata/CRJNEW/datafile/o1_mf_undotbs1_859l2yrm_.dbf' ORA-10560: block type 'KTU UNDO BLOCK' Recovery interrupted! Recovered data files to a consistent state at change 12331596958128 MRP0: Background Media Recovery process shutdown (crjnew) .....省略部分内容 Tue May 27 19:30:03 2014 Errors in file /u01/app/oracle/diag/rdbms/crjnew/crjnew/trace/crjnew_pr1e_21956.trc (incident=444672): ORA-00600: internal error code, arguments: [3020], [16], [1016759], [68125623], [], [], [], [], [], [], [], [] ORA-10567: Redo is inconsistent with data block (file# 16, block# 1016759, file offset is 4034322432 bytes) ORA-10564: tablespace CRJ ORA-01110: data file 16: '/u01/app/oracle/oradata/CRJNEW/datafile/crj_data09.dbf' ORA-10561: block type 'TRANSACTION MANAGED INDEX BLOCK', data object# 77037 Incident details in: /u01/app/oracle/diag/rdbms/crjnew/crjnew/incident/incdir_444672/crjnew_pr1e_21956_i444672.trc Tue May 27 19:30:06 2014 Dumping diagnostic data in directory=[cdmp_20140527193006], requested by (instance=1, osid=21956 (PR1E)), summary=[incident=444672]. Use ADRCI or Support Workbench to package the incident. See Note 411.1 at My Oracle Support for error and packaging details. Slave exiting with ORA-600 exception Errors in file /u01/app/oracle/diag/rdbms/crjnew/crjnew/trace/crjnew_pr1e_21956.trc: ORA-00600: internal error code, arguments: [3020], [16], [1016759], [68125623], [], [], [], [], [], [], [], [] ORA-10567: Redo is inconsistent with data block (file# 16, block# 1016759, file offset is 4034322432 bytes) ORA-10564: tablespace CRJ ORA-01110: data file 16: '/u01/app/oracle/oradata/CRJNEW/datafile/crj_data09.dbf' ORA-10561: block type 'TRANSACTION MANAGED INDEX BLOCK', data object# 77037 Tue May 27 19:30:06 2014 Errors in file /u01/app/oracle/diag/rdbms/crjnew/crjnew/trace/crjnew_mrp0_21854.trc (incident=444262): ORA-00600: internal error code, arguments: [3020], [16], [1016759], [68125623], [], [], [], [], [], [], [], [] ORA-10567: Redo is inconsistent with data block (file# 16, block# 1016759, file offset is 4034322432 bytes) ORA-10564: tablespace CRJ ORA-01110: data file 16: '/u01/app/oracle/oradata/CRJNEW/datafile/crj_data09.dbf' ORA-10561: block type 'TRANSACTION MANAGED INDEX BLOCK', data object# 77037 Incident details in: /u01/app/oracle/diag/rdbms/crjnew/crjnew/incident/incdir_444262/crjnew_mrp0_21854_i444262.trc Use ADRCI or Support Workbench to package the incident. See Note 411.1 at My Oracle Support for error and packaging details. Recovery Slave PR1E previously exited with exception 600 Tue May 27 19:30:07 2014 MRP0: Background Media Recovery terminated with error 448 Errors in file /u01/app/oracle/diag/rdbms/crjnew/crjnew/trace/crjnew_pr00_21856.trc: ORA-00448: normal completion of background process Recovery interrupted! Recovered data files to a consistent state at change 12331596967112 MRP0: Background Media Recovery process shutdown (crjnew) Tue May 27 19:30:11 2014 Sweep [inc][444672]: completed Sweep [inc][444262]: completed Sweep [inc2][444672]: completed Sweep [inc2][444262]: completed Tue May 27 19:32:08 2014 Primary database is in MAXIMUM PERFORMANCE mode |
你会看到，当你手工发起recover managed standby database disconnect from session后，会出现上述的错误。我们也可以清楚
的看到，之所以MRP经常无法正常启动，是因为有文件存在坏块。对于数据文件坏块，通过dbv检查你会发现是这么一种情况：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 |
[oracle@gscrj01 ~]$ dbv file=/u01/app/oracle/oradata/CRJNEW/datafile/o1_mf_sysaux_859l29lq_.dbf blocksize=8192 DBVERIFY: Release 11.2.0.3.0 - Production on Tue May 27 18:02:42 2014 Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved. DBVERIFY - Verification starting : FILE = /u01/app/oracle/oradata/CRJNEW/datafile/o1_mf_sysaux_859l29lq_.dbf Page 121298 is influx - most likely media corrupt Corrupt block relative dba: 0x0081d9d2 (file 2, block 121298) Fractured block found during dbv: Data in bad block: type: 6 format: 2 rdba: 0x0081d9d2 last change scn: 0x0b37.2c742a38 seq: 0x3 flg: 0x04 spare1: 0x0 spare2: 0x0 spare3: 0x0 consistency value in tail: 0x441f0601 check value in block header: 0xf89f computed block checksum: 0x2281 DBVERIFY - Verification complete Total Pages Examined : 655360 Total Pages Processed (Data) : 77609 Total Pages Failing (Data) : 0 Total Pages Processed (Index): 66328 Total Pages Failing (Index): 0 Total Pages Processed (Lob) : 9344 Total Pages Failing (Lob) : 0 Total Pages Processed (Other): 108285 Total Pages Processed (Seg) : 0 Total Pages Failing (Seg) : 0 Total Pages Empty : 393793 Total Pages Marked Corrupt : 1 Total Pages Influx : 1 Total Pages Encrypted : 0 Highest block SCN : 745850569 (2871.745850569) [oracle@gscrj01 ~]$ dbv file=/u01/app/oracle/oradata/CRJNEW/datafile/crj_data07.dbf blocksize=8192 DBVERIFY: Release 11.2.0.3.0 - Production on Tue May 27 18:12:41 2014 Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved. DBVERIFY - Verification starting : FILE = /u01/app/oracle/oradata/CRJNEW/datafile/crj_data07.dbf DBVERIFY - Verification complete Total Pages Examined : 3932160 Total Pages Processed (Data) : 47043 Total Pages Failing (Data) : 0 Total Pages Processed (Index): 22456 Total Pages Failing (Index): 0 Total Pages Processed (Other): 3862660 Total Pages Processed (Seg) : 0 Total Pages Failing (Seg) : 0 Total Pages Empty : 1 Total Pages Marked Corrupt : 0 Total Pages Influx : 0 Total Pages Encrypted : 0 Highest block SCN : 745794635 (2871.745794635) |
我这里检查了2个报错的文件，发现sysaux的文件有一个坏块，然而另外一个数据dbv检查并没有提示坏块，但是为什么会报错呢？
这里的错误基本上都是类似ORA-10567: Redo is inconsistent with data block 的问题，这可能不是block本身的问题，可能是
日志写的内容和块的内容不一致了。
开始我看只有3个文件有报错，那我就想，能否直接从主库scp 这3个文件到备库，然后直接recover就行了呗？ 大概是这样一个操作：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
--备库 alter database datafile n offline drop; mv xxxx.dbf xxxx.dbf.bak --主库 scp /xxx/xxxx/xxxx.dbf oracle@x.x.x.x:/xxx/xxx/xxx.dbf --备库 alter database datafile n online; alter database recover managed standby database disconnect from session; |
这种操作本身没有问题，然而有问题的是，这3个文件处理了之后，恢复发行又报错其他的数据文件了，我檫。
整个数据库一共2.2TB，80个30g的文件。 我不可能给他全库scp过去。
那么怎么弄呢 ？
其实很简单，我很早之前也讲过利用rman增量的方式来恢复dataguard环境中缺少日志导致gap的情况。 我们也可以使用类似
这个方法来做，下面是我的基本操作：
—定位备库同步的scn
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
SQL> col FIRST_CHANGE# for 9999999999999999999 SQL> col next_change# for 9999999999999999 SQL> / SEQUENCE# APPLIED FIRST_CHANGE# NEXT_CHANGE# ---------- --------- -------------------- ----------------- 6141 YES 12331596661580 12331596717210 6142 YES 12331596717210 12331596758421 6143 YES 12331596758421 12331596805008 6144 YES 12331596805008 12331596838849 6145 YES 12331596838849 12331596901470 6146 YES 12331596901470 12331596958127 6147 NO 12331596958127 12331597090365 6148 NO 12331597090365 12331597133130 6149 NO 12331597133130 12331597176234 6150 NO 12331597176234 12331597220783 6151 NO 12331597220783 12331597276144 。。。。。省略部分内容 |
—主库进行增量备份（基于scn）
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
rman target / << OEF run { allocate channel d1 type disk; allocate channel d2 type disk; allocate channel d3 type disk; allocate channel d4 type disk; backup as compressed backupset incremental from SCN 12331596958127 database format '/oraclenew/datadir3/rmanback双击查看原图_incr_%d_%T_%U.bak' include current controlfile for standby filesperset=5 tag 'forstandby0527'; release channel d1; release channel d2; release channel d3; release channel d4; } exit EOF |
—-将主库的备份文件scp到备库，并注册到catalog
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 |
RMAN> catalog start with '/oraclenew/datadir3/temp/'; using target database control file instead of recovery catalog searching for all files that match the pattern /oraclenew/datadir3/temp/ List of Files Unknown to the Database ===================================== File Name: /oraclenew/datadir3/temp/db_incr_CRJNEW_20140527_0sp9btk8_1_1.bak File Name: /oraclenew/datadir3/temp/db_incr_CRJNEW_20140527_0kp9botr_1_1.bak File Name: /oraclenew/datadir3/temp/db_incr_CRJNEW_20140527_0op9brdj_1_1.bak File Name: /oraclenew/datadir3/temp/db_incr_CRJNEW_20140527_0mp9bqlg_1_1.bak File Name: /oraclenew/datadir3/temp/db_incr_CRJNEW_20140527_0up9butr_1_1.bak File Name: /oraclenew/datadir3/temp/db_incr_CRJNEW_20140527_10p9c01g_1_1.bak File Name: /oraclenew/datadir3/temp/db_incr_CRJNEW_20140527_11p9c37k_1_1.bak File Name: /oraclenew/datadir3/temp/db_incr_CRJNEW_20140527_0lp9bqhs_1_1.bak File Name: /oraclenew/datadir3/temp/db_incr_CRJNEW_20140527_0gp9bmtn_1_1.bak File Name: /oraclenew/datadir3/temp/db_incr_CRJNEW_20140527_0jp9boid_1_1.bak File Name: /oraclenew/datadir3/temp/db_incr_CRJNEW_20140527_0ip9bmtn_1_1.bak File Name: /oraclenew/datadir3/temp/db_incr_CRJNEW_20140527_0tp9bul8_1_1.bak File Name: /oraclenew/datadir3/temp/db_incr_CRJNEW_20140527_0pp9bsg4_1_1.bak File Name: /oraclenew/datadir3/temp/db_incr_CRJNEW_20140527_0rp9btan_1_1.bak File Name: /oraclenew/datadir3/temp/db_incr_CRJNEW_20140527_0qp9bsul_1_1.bak File Name: /oraclenew/datadir3/temp/db_incr_CRJNEW_20140527_0np9br09_1_1.bak File Name: /oraclenew/datadir3/temp/db_incr_CRJNEW_20140527_0fp9bmtn_1_1.bak File Name: /oraclenew/datadir3/temp/db_incr_CRJNEW_20140527_0vp9bvp7_1_1.bak File Name: /oraclenew/datadir3/temp/db_incr_CRJNEW_20140527_0hp9bmtn_1_1.bak Do you really want to catalog the above files (enter YES or NO)? yes cataloging files... cataloging done List of Cataloged Files ======================= File Name: /oraclenew/datadir3/temp/db_incr_CRJNEW_20140527_0sp9btk8_1_1.bak File Name: /oraclenew/datadir3/temp/db_incr_CRJNEW_20140527_0kp9botr_1_1.bak File Name: /oraclenew/datadir3/temp/db_incr_CRJNEW_20140527_0op9brdj_1_1.bak File Name: /oraclenew/datadir3/temp/db_incr_CRJNEW_20140527_0mp9bqlg_1_1.bak File Name: /oraclenew/datadir3/temp/db_incr_CRJNEW_20140527_0up9butr_1_1.bak File Name: /oraclenew/datadir3/temp/db_incr_CRJNEW_20140527_10p9c01g_1_1.bak File Name: /oraclenew/datadir3/temp/db_incr_CRJNEW_20140527_11p9c37k_1_1.bak File Name: /oraclenew/datadir3/temp/db_incr_CRJNEW_20140527_0lp9bqhs_1_1.bak File Name: /oraclenew/datadir3/temp/db_incr_CRJNEW_20140527_0gp9bmtn_1_1.bak File Name: /oraclenew/datadir3/temp/db_incr_CRJNEW_20140527_0jp9boid_1_1.bak File Name: /oraclenew/datadir3/temp/db_incr_CRJNEW_20140527_0ip9bmtn_1_1.bak File Name: /oraclenew/datadir3/temp/db_incr_CRJNEW_20140527_0tp9bul8_1_1.bak File Name: /oraclenew/datadir3/temp/db_incr_CRJNEW_20140527_0pp9bsg4_1_1.bak File Name: /oraclenew/datadir3/temp/db_incr_CRJNEW_20140527_0rp9btan_1_1.bak File Name: /oraclenew/datadir3/temp/db_incr_CRJNEW_20140527_0qp9bsul_1_1.bak File Name: /oraclenew/datadir3/temp/db_incr_CRJNEW_20140527_0np9br09_1_1.bak File Name: /oraclenew/datadir3/temp/db_incr_CRJNEW_20140527_0fp9bmtn_1_1.bak File Name: /oraclenew/datadir3/temp/db_incr_CRJNEW_20140527_0vp9bvp7_1_1.bak File Name: /oraclenew/datadir3/temp/db_incr_CRJNEW_20140527_0hp9bmtn_1_1.bak |
—进行recover备库
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 |
RMAN> recover database noredo; Starting recover at 28-MAY-14 allocated channel: ORA_DISK_1 channel ORA_DISK_1: SID=1261 device type=DISK channel ORA_DISK_1: starting incremental datafile backup set restore channel ORA_DISK_1: specifying datafile(s) to restore from backup set destination for restore of datafile 00001: /u01/app/oracle/oradata/CRJNEW/datafile/o1_mf_system_859l1ovo_.dbf destination for restore of datafile 00015: /u01/app/oracle/oradata/CRJNEW/datafile/crj_data08.dbf destination for restore of datafile 00016: /u01/app/oracle/oradata/CRJNEW/datafile/crj_data09.dbf destination for restore of datafile 00060: /oraclenew/datadir1/crj_data50.dbf destination for restore of datafile 00062: /oraclenew/datadir1/crj_data51.dbf channel ORA_DISK_1: reading from backup piece /oraclenew/datadir3/temp/db_incr_CRJNEW_20140527_0op9brdj_1_1.bak channel ORA_DISK_1: piece handle=/oraclenew/datadir3/temp/db_incr_CRJNEW_20140527_0op9brdj_1_1.bak tag=FORSTANDBY0527 channel ORA_DISK_1: restored backup piece 1 channel ORA_DISK_1: restore complete, elapsed time: 00:00:35 channel ORA_DISK_1: starting incremental datafile backup set restore channel ORA_DISK_1: specifying datafile(s) to restore from backup set destination for restore of datafile 00002: /u01/app/oracle/oradata/CRJNEW/datafile/o1_mf_sysaux_859l29lq_.dbf destination for restore of datafile 00017: /u01/app/oracle/oradata/CRJNEW/datafile/crj_data10.dbf destination for restore of datafile 00018: /u01/app/oracle/oradata/CRJNEW/datafile/crj_data11.dbf destination for restore of datafile 00063: /oraclenew/datadir1/crj_data52.dbf destination for restore of datafile 00064: /oraclenew/datadir1/crj_data53.dbf channel ORA_DISK_1: reading from backup piece /oraclenew/datadir3/temp/db_incr_CRJNEW_20140527_0pp9bsg4_1_1.bak channel ORA_DISK_1: piece handle=/oraclenew/datadir3/temp/db_incr_CRJNEW_20140527_0pp9bsg4_1_1.bak tag=FORSTANDBY0527 channel ORA_DISK_1: restored backup piece 1 channel ORA_DISK_1: restore complete, elapsed time: 00:00:35 channel ORA_DISK_1: starting incremental datafile backup set restore channel ORA_DISK_1: specifying datafile(s) to restore from backup set destination for restore of datafile 00004: /u01/app/oracle/oradata/CRJNEW/datafile/o1_mf_users_859l57gz_.dbf destination for restore of datafile 00006: /u01/app/oracle/oradata/CRJNEW/datafile/dzzj_index01.dbf destination for restore of datafile 00008: /u01/app/oracle/oradata/CRJNEW/datafile/crj_data01.dbf destination for restore of datafile 00054: /oraclenew/datadir1/dzzj_data02.dbf destination for restore of datafile 00076: /oraclenew/datadir3/crjnew_bin01.dbf channel ORA_DISK_1: reading from backup piece /oraclenew/datadir3/temp/db_incr_CRJNEW_20140527_0up9butr_1_1.bak ......部分内容 hannel ORA_DISK_1: reading from backup piece /oraclenew/datadir3/temp/db_incr_CRJNEW_20140527_0hp9bmtn_1_1.bak channel ORA_DISK_1: piece handle=/oraclenew/datadir3/temp/db_incr_CRJNEW_20140527_0hp9bmtn_1_1.bak tag=FORSTANDBY0527 channel ORA_DISK_1: restored backup piece 1 channel ORA_DISK_1: restore complete, elapsed time: 00:00:45 channel ORA_DISK_1: starting incremental datafile backup set restore channel ORA_DISK_1: specifying datafile(s) to restore from backup set destination for restore of datafile 00034: /u01/app/oracle/oradata/CRJNEW/datafile/crj_data27.dbf destination for restore of datafile 00035: /u01/app/oracle/oradata/CRJNEW/datafile/crj_data28.dbf destination for restore of datafile 00056: /oraclenew/datadir1/dzzj_index02.dbf destination for restore of datafile 00061: /oraclenew/datadir1/zzsb_data01.dbf channel ORA_DISK_1: reading from backup piece /oraclenew/datadir3/temp/db_incr_CRJNEW_20140527_0qp9bsul_1_1.bak channel ORA_DISK_1: piece handle=/oraclenew/datadir3/temp/db_incr_CRJNEW_20140527_0qp9bsul_1_1.bak tag=FORSTANDBY0527 channel ORA_DISK_1: restored backup piece 1 channel ORA_DISK_1: restore complete, elapsed time: 00:02:25 Finished recover at 28-MAY-14 |
如果你这个时候去看alert log，你会发现类似这样的信息：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
started logmerger process Wed May 28 14:30:22 2014 Managed Standby Recovery not using Real Time Apply Parallel Media Recovery started with 64 slaves Waiting for all non-current ORLs to be archived... All non-current ORLs have been archived. Media Recovery Log /u01/app/oracle/fast_recovery_area/CRJNEW/archivelog/2014_04_15/o1_mf_1_6147_9nv894go_.arc Completed: alter database recover managed standby database disconnect from session Media Recovery Log /u01/app/oracle/fast_recovery_area/CRJNEW/archivelog/2014_04_15/o1_mf_1_6148_9nv88s4v_.arc Media Recovery Log /u01/app/oracle/fast_recovery_area/CRJNEW/archivelog/2014_04_15/o1_mf_1_6149_9nv88zkm_.arc Media Recovery Log /u01/app/oracle/fast_recovery_area/CRJNEW/archivelog/2014_04_15/o1_mf_1_6150_9nv894yk_.arc Media Recovery Log /u01/app/oracle/fast_recovery_area/CRJNEW/archivelog/2014_04_15/o1_mf_1_6151_9nv896bo_.arc Wed May 28 14:30:34 2014 Media Recovery Log /u01/app/oracle/fast_recovery_area/CRJNEW/archivelog/2014_04_15/o1_mf_1_6152_9nv89fv0_.arc Media Recovery Log /u01/app/oracle/fast_recovery_area/CRJNEW/archivelog/2014_04_15/o1_mf_1_6153_9nv89g10_.arc ...... Media Recovery Log /u01/app/oracle/fast_recovery_area/CRJNEW/archivelog/2014_04_21/o1_mf_1_6208_9o9mnqhc_.arc Media Recovery Log /u01/app/oracle/fast_recovery_area/CRJNEW/archivelog/2014_04_21/o1_mf_1_6209_9obb1c7s_.arc ...... |
你会发现Oracle仍然会去检查，并跳过这部分差了1个多月的归档，这个过程很快的，不到10分钟完成了。
当然，这个case就算over了。
备注：oracle 11gR2（准确的说是11.2.0.2）开始，active dataguard引入了Automatic Block Repair 机制。然后该机制
需要满足的一定的条件，如下是官方文档的说明：
|
1 2 3 4 5 6 7 8 9 10 |
If ... Then ... A corrupt data block is discovered on a primary database A physical standby database operating in real-time query mode can be used to repair corrupt data blocks in a primary database. If possible, any corrupt data block encountered when a primary database is accessed will be automatically replaced with an uncorrupted copy of that block from a physical standby database operating in real-time query mode. An ORA-1578 error is returned when automatic repair is not possible. A corrupt data block is discovered on a physical standby database The server attempts to automatically repair the corruption by obtaining a copy of the block from the primary database if the following database initialization parameters are configured on the standby database: ?Configure the LOG_ARCHIVE_CONFIG parameter with a DG_CONFIG list ?Configure a LOG_ARCHIVE_DEST_n parameter for the primary database |
实际上，可能还存在一些特殊的情况，当然客户这里是没有使用real-time模式。
One Response to “11gR2 dataguard 备库文件损坏处理一例”
roger 大量思路很清晰，方法较独特。
Leave a Reply
You must be logged in to post a comment.