网络上和官方文档配置Data Guard 的步骤已经非常成熟,个人觉得应该逐渐深入,去理解其原理,挖掘其精髓,这篇文章是个人学习总结
网络上和官方文档配置Data Guard 的步骤已经非常成熟,个人觉得应该逐渐深入,去理解其原理,挖掘其精髓
这篇文章是个人学习总结的笔记,如果写的有错的地方,还望大家留言指正
下图为一个ADG的模型,那么这篇文章就来研究图中的箭头的原理,也就是日志是如何发送的
图中,主库在运行时会不断产生redo log,这些日志会通过网络传送到备库,这个传送动作,可以由ARCH完成,也可以由LGWR完成,选用哪种进程,对数据库的可用性和DG的保护能力有着很大的区别。
1.使用ARCH进程传送日志
主库不断的产生redo log,这些日志被LGWR写进联机日志,当一组联机日志被写满,会发生日志切换,并且ARCH会将其归档,本地归档是LOG_ARCHIVE_DEST_1='LOCATION=/...'这种参数定义,ARCH进程还会通过网络把归档日志传送给备库的一个叫做RFS的进程,备库接受日志并写入到归档日志,然后备库的MRP进程(redo apply)或者LSP进程(SQL apply)在备库上应用这些日志,于是数据就同步了。
使用ARCH传递的问题也是很明显的,只有日志切换作为前提,才能传送日志,如果主库异常停机,联机日志丢失,导致无法归档,那么丢失数据是在所难免!
在默认情况下,主库就是用ARCH进程传送日志,不需要特别的设置。
2.使用LGWR进程传送日志
LGWR又分为SYNC(同步)和ASYNC(异步)两种方式
2.1LGWR进程的SYNC方式
主库产生redo log要同时写入到日志文件和网络,即LGWR把日志写到本地联机日志文件的同时,还发送给本地的LNSN进程(Network Server Process),然后LNSN进程把日志内容通过网络发送到备库。
LGWR必须等待写入本地联机日志和LNSN进程传送成功,主库的事物才能提交,,这就是实时同步的原理。
备库的RFS进程把接收到的日志立刻写入standby redo log中,所以在备库上看,最后一个日志总是IN-MEMORY,这也是我当初疑惑的一个问题,现在终于清晰!
备库的恢复方式可以是实时恢复,也可以是完成对standby redo log的归档后恢复。
另外NET_TIMEOUT参数单位为秒,作用是该段时间网络无响应,LGWR会抛出错误
LOG_ARCHIVE_DEST_2=‘SERVICE=ST LGWR SYNC NET_TIMEOUT=30'
2.2使用LGWR进程的ASYNC方式
使用LGWR SYNC方式也有弱点,如果在发送给standby db过程中出错,LGWR会报错,主库事物无法完成,
主库LGWR过分依赖网络状态,如果网络不能保证365天高速无悬念和不会被挖掘机挖断光纤,或者对数据同步不苛刻,也可以采用LGWR ASYNC方式。
主库产生redo log之后,LGWR-->LNSN,但是LGWR只需要成功写入日志文件,事物即可允许提交,不必等待LNSN进程传送成功。
主库联机日志写满后,归档,也会触发备库的standby redo log归档,然后触发MRP活LSP进程恢复归档。
即备库的恢复方式,只能是完成对standby redo log的归档后恢复。
由于LSWR不会等待LNSN,所以无需配置NET_TIMEOUT参数。
--------------------------------------分割线 --------------------------------------
Oracle Data Guard 重要配置参数
基于同一主机配置 Oracle 11g Data Guard
探索Oracle之11g DataGuard
Oracle Data Guard (RAC+DG) 归档删除策略及脚本
Oracle Data Guard 的角色转换
Oracle Data Guard的日志FAL gap问题
Oracle 11g Data Guard Error 16143 Heartbeat failed to connect to standby 处理方法
--------------------------------------分割线 --------------------------------------
更多详情见请继续阅读下一页的精彩内容: