Dataguard 在 多实例间同步带传动设计实例

来源：蜘蛛抓取(WebSpider) 时间：2018-06-22 15:40 标签： lstm时间序列预测实例
查看: 3584|回复: 7
如何提升Active Dataguard 与主库的同步速度
认证徽章论坛徽章:71
Oracle 11.2.0.2.0 ,&&2 Nodes RAC ,&&Active Dataguard&&.
刚接手一个任务&&， 虽然是做过的 active data guard ,&&但是业务量非常大，&&主库和备库之间还是存在数据同步时间差,& &
这个主库备库已经实施完成 ，&&具体的一些参数还需要下周才能有权限登入查看 ,& & 先在这里问问，&&11g&&Active Dataguard
同步方面延迟改善有哪些方向(或参数)& &？
论坛徽章:112
(1)主、备对等不？
(2)距离多远？网络环境如何？
(3)保护模式是？
(4)目前延迟多久？
(5)期望的延迟是？
(6)有没有初步分析是网络问题还是备端apply导致？
招聘 : 论坛徽章:2
先找出以前延迟的原因，并做了充足测试之后，再调整
认证徽章论坛徽章:295
先看看你是什么保护模式
认证徽章论坛徽章:71
Toms_zhang 发表于
(1)主、备对等不？
(2)距离多远？网络环境如何？
(3)保护模式是？
(1)主、备对等不？
主库是11.2.0.2 Cluster, 备库为单机，不设置自动切换 (对等的定义是 ？)
(2)距离多远？网络环境如何？
在不同building间的机房，光纤连接，网络环境OK .
(3)保护模式是？
保护模式为最大可用性
(4)目前延迟多久？
高峰延迟200秒
(5)期望的延迟是？
期望延迟在10秒以内(不能影响系统性能过大)&&
(6)有没有初步分析是网络问题还是备端apply导致？
基本可以确定是apply速度慢
论坛徽章:1
APPLY速度慢，会不会是备库的磁盘IO性能不行？刚检查了我们的备库参数，没啥特别的啊。
论坛徽章:92
Use larger SDU and SEND_BUF_SIZE/RECV_BUF_SIZE;
Try compress for LGWR if you've licence
log_archive_dest_2 = 'service=&(DESCRIPTION=(SDU=32767)(SEND_BUF_SIZE=1048576)(RECV_BUF_SIZE=1048576)(ADDRESS=(PROTOCOL=TCP)(HOST=XXXXXXXXXXXXXX)(PORT=XXXX))(CONNECT_DATA=(SID=XXXX)))& reopen=5 lgwr async'
on standby listener.ora:
LISTENER_XXXXXXX_STBY=& && && &
(ADDRESS_LIST=& && && && && &&&
&&(ADDRESS =& && && && && && && &
& & (PROTOCOL = TCP)& && && && && &
& & (HOST = XXXXXXXXXXXX)&&
& & (PORT = XXXXXXXx)& && && && && && && && && &&&
& & (SEND_BUF_SIZE=1048576)& && &&&
& & (RECV_BUF_SIZE=1048576)& && &&&
&&)& && && && && && && && && && &
)& && && && && && && && && && &
SID_LIST_LISTENER_XXXXX_STBY =& &
(SID_LIST =& && && && && && &&&
&&(SID_DESC =& && && && && && &&&
& & (SDU=32767)& && && && && && &&&
& & (SID_NAME = XXXXXXXXXX)& && && && && &
& & (ORACLE_HOME = XXXXXXXXXXXXXXXXXXXXXXX)
论坛徽章:46
主、备库的存储的性能怎样？
磁盘个数、RAID级别？
itpub.net All Right Reserved. 北京盛拓优讯信息技术有限公司版权所有　　　　
　北京市公安局海淀分局网监中心备案编号：10　广播电视节目制作经营许可证：编号（京）字第1149号linux11g，dataguard的备库，已经有一个与主库同步的实例orcl1，可以在备库上安装第二个实例吗？
[问题点数：100分，结帖人csdnhadoop]
本版专家分：28
结帖率 86.67%
CSDN今日推荐
本版专家分：58958
2016年8月优秀大版主2015年7月优秀大版主2015年8月优秀大版主2015年9月优秀小版主2015年9月优秀大版主2015年5月优秀小版主2015年2月论坛优秀版主2014年11月论坛优秀版主
2016年1月 Oracle大版内专家分月排行榜第一2015年6月 Oracle大版内专家分月排行榜第一2015年4月 Oracle大版内专家分月排行榜第一2015年3月 Oracle大版内专家分月排行榜第一2015年2月 Oracle大版内专家分月排行榜第一2014年6月 Oracle大版内专家分月排行榜第一2009年11月 Oracle大版内专家分月排行榜第一2009年10月 Oracle大版内专家分月排行榜第一
2015年9月 Oracle大版内专家分月排行榜第二2015年7月 Oracle大版内专家分月排行榜第二2015年1月 Oracle大版内专家分月排行榜第二2014年12月 Oracle大版内专家分月排行榜第二2014年11月 Oracle大版内专家分月排行榜第二2014年8月 Oracle大版内专家分月排行榜第二2014年7月 Oracle大版内专家分月排行榜第二2014年5月 Oracle大版内专家分月排行榜第二2010年1月 Oracle大版内专家分月排行榜第二2009年9月 Oracle大版内专家分月排行榜第二
2015年12月 Oracle大版内专家分月排行榜第三2014年10月 Oracle大版内专家分月排行榜第三2014年9月 Oracle大版内专家分月排行榜第三2010年5月 Oracle大版内专家分月排行榜第三2009年12月 Oracle大版内专家分月排行榜第三2009年8月 Oracle大版内专家分月排行榜第三
本版专家分：28
结帖率 86.67%
本版专家分：58958
2016年8月优秀大版主2015年7月优秀大版主2015年8月优秀大版主2015年9月优秀小版主2015年9月优秀大版主2015年5月优秀小版主2015年2月论坛优秀版主2014年11月论坛优秀版主
2016年1月 Oracle大版内专家分月排行榜第一2015年6月 Oracle大版内专家分月排行榜第一2015年4月 Oracle大版内专家分月排行榜第一2015年3月 Oracle大版内专家分月排行榜第一2015年2月 Oracle大版内专家分月排行榜第一2014年6月 Oracle大版内专家分月排行榜第一2009年11月 Oracle大版内专家分月排行榜第一2009年10月 Oracle大版内专家分月排行榜第一
2015年9月 Oracle大版内专家分月排行榜第二2015年7月 Oracle大版内专家分月排行榜第二2015年1月 Oracle大版内专家分月排行榜第二2014年12月 Oracle大版内专家分月排行榜第二2014年11月 Oracle大版内专家分月排行榜第二2014年8月 Oracle大版内专家分月排行榜第二2014年7月 Oracle大版内专家分月排行榜第二2014年5月 Oracle大版内专家分月排行榜第二2010年1月 Oracle大版内专家分月排行榜第二2009年9月 Oracle大版内专家分月排行榜第二
2015年12月 Oracle大版内专家分月排行榜第三2014年10月 Oracle大版内专家分月排行榜第三2014年9月 Oracle大版内专家分月排行榜第三2010年5月 Oracle大版内专家分月排行榜第三2009年12月 Oracle大版内专家分月排行榜第三2009年8月 Oracle大版内专家分月排行榜第三
本版专家分：28
结帖率 86.67%
本版专家分：28
结帖率 86.67%
本版专家分：58958
2016年8月优秀大版主2015年7月优秀大版主2015年8月优秀大版主2015年9月优秀小版主2015年9月优秀大版主2015年5月优秀小版主2015年2月论坛优秀版主2014年11月论坛优秀版主
2016年1月 Oracle大版内专家分月排行榜第一2015年6月 Oracle大版内专家分月排行榜第一2015年4月 Oracle大版内专家分月排行榜第一2015年3月 Oracle大版内专家分月排行榜第一2015年2月 Oracle大版内专家分月排行榜第一2014年6月 Oracle大版内专家分月排行榜第一2009年11月 Oracle大版内专家分月排行榜第一2009年10月 Oracle大版内专家分月排行榜第一
2015年9月 Oracle大版内专家分月排行榜第二2015年7月 Oracle大版内专家分月排行榜第二2015年1月 Oracle大版内专家分月排行榜第二2014年12月 Oracle大版内专家分月排行榜第二2014年11月 Oracle大版内专家分月排行榜第二2014年8月 Oracle大版内专家分月排行榜第二2014年7月 Oracle大版内专家分月排行榜第二2014年5月 Oracle大版内专家分月排行榜第二2010年1月 Oracle大版内专家分月排行榜第二2009年9月 Oracle大版内专家分月排行榜第二
2015年12月 Oracle大版内专家分月排行榜第三2014年10月 Oracle大版内专家分月排行榜第三2014年9月 Oracle大版内专家分月排行榜第三2010年5月 Oracle大版内专家分月排行榜第三2009年12月 Oracle大版内专家分月排行榜第三2009年8月 Oracle大版内专家分月排行榜第三
本版专家分：28
结帖率 86.67%
本版专家分：50
本版专家分：19422
2017年2月 Oracle大版内专家分月排行榜第二2003年10月 PowerBuilder大版内专家分月排行榜第二
2017年6月 Oracle大版内专家分月排行榜第三2017年3月 Oracle大版内专家分月排行榜第三2006年12月 Oracle大版内专家分月排行榜第三
本版专家分：28
结帖率 86.67%
本版专家分：19422
2017年2月 Oracle大版内专家分月排行榜第二2003年10月 PowerBuilder大版内专家分月排行榜第二
2017年6月 Oracle大版内专家分月排行榜第三2017年3月 Oracle大版内专家分月排行榜第三2006年12月 Oracle大版内专家分月排行榜第三
本版专家分：216
匿名用户不能发表回复！|
CSDN今日推荐11gR2 dataguard 备库文件损坏处理一例 - 为程序员服务
11gR2 dataguard 备库文件损坏处理一例
本站文章除注明转载外，均为本站原创： 转载自
本文链接地址:
某客户的一套11gR2 dataguard环境出现异常，检查发现是备库出现文件损坏，且无法正常情况，已经超过1个多月没同步了。 我们先来看下备库的日志：
.......省略部分内容
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], [], [], [], [], [], [], [], [], []
ORA-10567: Redo is inconsistent with data block (file# 3, block# 6118, file offset is
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], [], [], [], [], [], [], [], [], []
ORA-10567: Redo is inconsistent with data block (file# 3, block# 3740, file offset is
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 28
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], [], [], [], [], [], [], [], [], []
ORA-10567: Redo is inconsistent with data block (file# 16, block# 1016759, file offset is
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_2.trc
Tue May 27 19:30:06 2014
Dumping diagnostic data in directory=[cdmp_06], 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], [], [], [], [], [], [], [], [], []
ORA-10567: Redo is inconsistent with data block (file# 16, block# 1016759, file offset is
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], [], [], [], [], [], [], [], [], []
ORA-10567: Redo is inconsistent with data block (file# 16, block# 1016759, file offset is
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_2.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 12
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检查你会发现是这么一种情况：
[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) , 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: 0x (file 2, block 121298)
Fractured block found during dbv:
Data in bad block:
type: 6 format: 2 rdba: 0x
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
Total Pages Processed (Data) : 77609
Total Pages Failing
(Data) : 0
Total Pages Processed (Index): 66328
Total Pages Failing
(Index): 0
Total Pages Processed (Lob)
Total Pages Failing
Total Pages Processed (Other): 108285
Total Pages Processed (Seg)
Total Pages Failing
Total Pages Empty
Total Pages Marked Corrupt
Total Pages Influx
Total Pages Encrypted
Highest block SCN
[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) , 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
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)
Total Pages Failing
Total Pages Empty
Total Pages Marked Corrupt
Total Pages Influx
Total Pages Encrypted
Highest block SCN
我这里检查了2个报错的文件，发现sysaux的文件有一个坏块，然而另外一个数据dbv检查并没有提示坏块，但是为什么会报错呢？
这里的错误基本上都是类似ORA-10567: Redo is inconsistent with data block 的问题，这可能不是block本身的问题，可能是
日志写的内容和块的内容不一致了。
开始我看只有3个文件有报错，那我就想，能否直接从主库scp 这3个文件到备库，然后直接recover就行了呗？ 大概是这样一个操作：
alter database dat
mv xxxx.dbf
xxxx.dbf.bak
/xxx/xxxx/xxxx.dbf
oracle@x.x.x.x:/xxx/xxx/xxx.dbf
alter databa
alter database recover managed standby database dis
这种操作本身没有问题，然而有问题的是，这3个文件处理了之后，恢复发行又报错其他的数据文件了，我檫。
整个数据库一共2.2TB，80个30g的文件。 我不可能给他全库scp过去。
那么怎么弄呢 ？
其实很简单，我很早之前也讲过利用rman增量的方式来恢复dataguard环境中缺少日志导致gap的情况。 我们也可以使用类似
这个方法来做，下面是我的基本操作：
—定位备库同步的scn
SQL& col FIRST_CHANGE# for 9999999
SQL& col next_change# for 9999
SEQUENCE# APPLIED
FIRST_CHANGE#
NEXT_CHANGE#
---------- --------- -------------------- -----------------
。。。。。省略部分内容
—主库进行增量备份（基于scn）
rman target / && OEF
allocate channel d1
allocate channel d2
allocate channel d3
allocate channel d4
backup as compressed backupset incremental from SCN 27 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;
—-将主库的备份文件scp到备库，并注册到catalog
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_sp9btk8_1_1.bak
File Name: /oraclenew/datadir3/temp/db_incr_CRJNEW_kp9botr_1_1.bak
File Name: /oraclenew/datadir3/temp/db_incr_CRJNEW_op9brdj_1_1.bak
File Name: /oraclenew/datadir3/temp/db_incr_CRJNEW_mp9bqlg_1_1.bak
File Name: /oraclenew/datadir3/temp/db_incr_CRJNEW_up9butr_1_1.bak
File Name: /oraclenew/datadir3/temp/db_incr_CRJNEW_p9c01g_1_1.bak
File Name: /oraclenew/datadir3/temp/db_incr_CRJNEW_p9c37k_1_1.bak
File Name: /oraclenew/datadir3/temp/db_incr_CRJNEW_lp9bqhs_1_1.bak
File Name: /oraclenew/datadir3/temp/db_incr_CRJNEW_gp9bmtn_1_1.bak
File Name: /oraclenew/datadir3/temp/db_incr_CRJNEW_jp9boid_1_1.bak
File Name: /oraclenew/datadir3/temp/db_incr_CRJNEW_ip9bmtn_1_1.bak
File Name: /oraclenew/datadir3/temp/db_incr_CRJNEW_tp9bul8_1_1.bak
File Name: /oraclenew/datadir3/temp/db_incr_CRJNEW_pp9bsg4_1_1.bak
File Name: /oraclenew/datadir3/temp/db_incr_CRJNEW_rp9btan_1_1.bak
File Name: /oraclenew/datadir3/temp/db_incr_CRJNEW_qp9bsul_1_1.bak
File Name: /oraclenew/datadir3/temp/db_incr_CRJNEW_np9br09_1_1.bak
File Name: /oraclenew/datadir3/temp/db_incr_CRJNEW_fp9bmtn_1_1.bak
File Name: /oraclenew/datadir3/temp/db_incr_CRJNEW_vp9bvp7_1_1.bak
File Name: /oraclenew/datadir3/temp/db_incr_CRJNEW_hp9bmtn_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_sp9btk8_1_1.bak
File Name: /oraclenew/datadir3/temp/db_incr_CRJNEW_kp9botr_1_1.bak
File Name: /oraclenew/datadir3/temp/db_incr_CRJNEW_op9brdj_1_1.bak
File Name: /oraclenew/datadir3/temp/db_incr_CRJNEW_mp9bqlg_1_1.bak
File Name: /oraclenew/datadir3/temp/db_incr_CRJNEW_up9butr_1_1.bak
File Name: /oraclenew/datadir3/temp/db_incr_CRJNEW_p9c01g_1_1.bak
File Name: /oraclenew/datadir3/temp/db_incr_CRJNEW_p9c37k_1_1.bak
File Name: /oraclenew/datadir3/temp/db_incr_CRJNEW_lp9bqhs_1_1.bak
File Name: /oraclenew/datadir3/temp/db_incr_CRJNEW_gp9bmtn_1_1.bak
File Name: /oraclenew/datadir3/temp/db_incr_CRJNEW_jp9boid_1_1.bak
File Name: /oraclenew/datadir3/temp/db_incr_CRJNEW_ip9bmtn_1_1.bak
File Name: /oraclenew/datadir3/temp/db_incr_CRJNEW_tp9bul8_1_1.bak
File Name: /oraclenew/datadir3/temp/db_incr_CRJNEW_pp9bsg4_1_1.bak
File Name: /oraclenew/datadir3/temp/db_incr_CRJNEW_rp9btan_1_1.bak
File Name: /oraclenew/datadir3/temp/db_incr_CRJNEW_qp9bsul_1_1.bak
File Name: /oraclenew/datadir3/temp/db_incr_CRJNEW_np9br09_1_1.bak
File Name: /oraclenew/datadir3/temp/db_incr_CRJNEW_fp9bmtn_1_1.bak
File Name: /oraclenew/datadir3/temp/db_incr_CRJNEW_vp9bvp7_1_1.bak
File Name: /oraclenew/datadir3/temp/db_incr_CRJNEW_hp9bmtn_1_1.bak
—进行recover备库
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_op9brdj_1_1.bak
channel ORA_DISK_1: piece handle=/oraclenew/datadir3/temp/db_incr_CRJNEW_op9brdj_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_pp9bsg4_1_1.bak
channel ORA_DISK_1: piece handle=/oraclenew/datadir3/temp/db_incr_CRJNEW_pp9bsg4_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_up9butr_1_1.bak
......部分内容
hannel ORA_DISK_1: reading from backup piece /oraclenew/datadir3/temp/db_incr_CRJNEW_hp9bmtn_1_1.bak
channel ORA_DISK_1: piece handle=/oraclenew/datadir3/temp/db_incr_CRJNEW_hp9bmtn_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_qp9bsul_1_1.bak
channel ORA_DISK_1: piece handle=/oraclenew/datadir3/temp/db_incr_CRJNEW_qp9bsul_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，你会发现类似这样的信息：
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//o1_mf_1_4go_.arc
Completed: alter database recover managed standby database disconnect from session
Media Recovery Log /u01/app/oracle/fast_recovery_area/CRJNEW/archivelog//o1_mf_1_s4v_.arc
Media Recovery Log /u01/app/oracle/fast_recovery_area/CRJNEW/archivelog//o1_mf_1_zkm_.arc
Media Recovery Log /u01/app/oracle/fast_recovery_area/CRJNEW/archivelog//o1_mf_1_4yk_.arc
Media Recovery Log /u01/app/oracle/fast_recovery_area/CRJNEW/archivelog//o1_mf_1_6bo_.arc
Wed May 28 14:30:34 2014
Media Recovery Log /u01/app/oracle/fast_recovery_area/CRJNEW/archivelog//o1_mf_1_fv0_.arc
Media Recovery Log /u01/app/oracle/fast_recovery_area/CRJNEW/archivelog//o1_mf_1_g10_.arc
Media Recovery Log /u01/app/oracle/fast_recovery_area/CRJNEW/archivelog//o1_mf_1_mnqhc_.arc
Media Recovery Log /u01/app/oracle/fast_recovery_area/CRJNEW/archivelog//o1_mf_1_6209_9obb1c7s_.arc
你会发现Oracle仍然会去检查，并跳过这部分差了1个多月的归档，这个过程很快的，不到10分钟完成了。
当然，这个case就算over了。
备注：oracle 11gR2（准确的说是11.2.0.2）开始，active dataguard引入了Automatic Block Repair 机制。然后该机制
需要满足的一定的条件，如下是官方文档的说明：
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模式。
Related posts:
本站文章除注明转载外，均为本站原创： 转载自love wife & love life —Roger 的Oracle技术博客 本文链接地址: 11gR2 dataguard 备库文件损坏处理一例 某客户的一套11gR2 dataguard环境出现异常，检查发现是备库出现文件损坏，且无法正常情况，已经超过1个多月没同步了。 我们先来看下备库的日志： .......省略部分内容 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], [], [], [], [], [], [], [], [], [] ORA-10567: [...]
生活其实很简单！
原文地址：, 感谢原作者分享。
您可能感兴趣的代码

我要回帖

更多关于 lstm时间序列预测实例 的文章

 

随机推荐