Oracle 11g Data Guard原理研究--推荐
内容导读
互联网集市收集整理的这篇技术教程文章主要介绍了Oracle 11g Data Guard原理研究--推荐,小编现在分享给大家,供广大互联网技能从业者学习和参考。文章包含10747字,纯文字阅读大概需要16分钟。
内容图文
![Oracle 11g Data Guard原理研究--推荐](/upload/InfoBanner/zyjiaocheng/878/32fe182e361a4a51aa2baeda66cdecd8.jpg)
网络上和官方文档配置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参数。
1.关于Data Guard日志接收的总结:
备库的RFS进程接收到日志后,就把日志写到standby redo log或者archived log file文件中。
而归档日志会被放在什么位置取决于standby database归档路径的选择,
如果配置了standby_archive_dest,则使用这个参数指定的目录;
如果配置了log_archive_dest_n,该参数明确定义了VALID_FOR=(STANDBY_LOGFILE,*),则使用这个参数指定的目录;
如果数据库的COMPATIBLE参数大于等于10,则选取任意一个LOG_ARCHIVE_DEST_n的值;
如果standby_archive_dest和log_archive_dest_n参数都没有配置,使用缺省的standby_archive_dest参数,这个缺省值是$Oracle_HOME/dbs/arch。
2.关于Data Guard日志应用的总结:
日志应用服务,就是在备库上重演主库的日志,从而实现两个数据库的数据同步。
根据备库重演日志的方式不同,可分为物理和逻辑两种类型。
物理使用的media recovery技术,在数据块级别进行恢复。这种方式没有数据类型的限制,可以保证两个数据库完全一致。
而逻辑使用的logminer技术,通过把日志内容还原成SQL语句,然后SQL引擎执行这些语句。
根据redo apply发生的时间可以分为2种:
一种是实时应用,这种方式必须有standby redo log,每当日志被写入standby redo log时,就会触发恢复,
使用这种方式的好处就在于可以减少数据库切换的时间,因为切换时间主要用在剩余日志的内容恢复上。
另一种是归档时应用,这种方式在主库发生日志切换之后,才触发备库的归档,归档完成后再触发恢复,这也是默认的方式。
如果是物理备库,可以使用下面命令启用real-time
alter database recover managed standby database using current logfile;
如果是逻辑备库,可以使用下面命令启用real-time
alter database start logical standby apply immediate;
查看是否使用了real-time
select recovery_mode from v$archive_dest_status;
3.关于Data Guard环境中的重要进程的总结:
主库:
LGWR:在主库上,这个进程负责吧redo buffer中的内容写入online redo log。
LNS(logwriter network service):LNS进程读取日志,并通过网络发送给备库,这个进程的目的是为了给LGWR减轻负担,LGWR进程不用再参与到网络日志的传送中。
ARCH:归档进程,在主库中可有30个归档进程,其中有一个是专门负责本地归档的,不参与Gap Resolution,
而其他的arch进程都可以进行Gap Resolution。
备库
RFS(remote file server):这个进程负责接收网络上传来的redo日志,并把这些日志写到standby redo log文件中。
ARCH:同样是归档进程,只是在备库上,需要归档的是standby redo log文件的内容。
MRP(magaged recovery process):这个进程负责协调介质恢复管理工作,整个物理备库就是建立在介质恢复技术上的。
PR0x(Parallel Recover Process):这是进行具体恢复工作的进程,如果是real-time apply模式下,这些进程会从standby redo log文件中读日志;而在其他模式下,是从归档日志中读取日志然后再进行日志应用。
LSP(logical standby process):这个进程在logical standby中才有,功能和物理备库的MRP进程类似,负责协调SQL APPLY过程。
1.关于standby redo log的理解
Data Guard在备库中,建议配置一种额外的日志文件,叫做standby redo log(SRL),和传统的online redo log(ORL)相比,SRL有着特殊的要求和作用。两者的关系可以从下面的几点来对比:
1.SRL和ORL两种文件是完全相同的,只是两者发挥的作用和场景不同。
2.SRL只在备库上起作用,(虽然主库也可以配置SRL),但是当数据库处于主库角色的时候,SRL是不活动的,只有经过了角色切换,变成了备库角色时,SRL日志才会变成活动的。
3.对于处于备库角色的数据库来说,ORL不是必须的,也不会起作用,(在很多时候,备库虽然显示有ORL,但是并没有真正的操作系统文件存在,只有当角色切换,变成主库角色时,才真正在操作系统上创建ORL文件)!
4.对于处于备库角色的数据库来说,他从主库接收到的日志可以记录在SRL文件中,也可以记录在归档日志文件中,具体写在哪个文件中取决于具体配置,但是不会写在ORL中。
5.SRL必须和ORL大小完全一致,否则SRL也不会被用到。其次,从数量上,应该按照每个实例或日志线程N+1的数量关系来配置,例如2个实例的RAC,如果每个实例3组日志,则SRL应该是(3+1)*2=8组。
是否使用SRL,关键区别在于RFS把接收到的日志,是写在归档日志里,还是写在SRL里。
使用SRL可以带来2大好处:
1.性能
如果不使用SRL,则备库的RFS会把接收到的日志记录到归档日志文件中,每当主库做日志切换时,才会触发备库对当前归档日志的归档操作,因此他必须等待备库的RFS进程创建并且初始化下一个归档日志文件,用来容纳以后传递的REDO内容。因此这个过程会影响主库日志的切换进度,当然对于异步传送来说不影响主库性能,但是仍然会导致备库日志落后的情况。
然而使用了SRL,因为SRL预先建好,因此日志切换时,无需额外的文件初始化工作,因此性能要更好一些。
2.支持Real-Time Apply(RTA)
前面介绍了实时同步,备库最后一个日志总是IN-MEMORY状态。
2.关于Data Guard保护模式的学习和总结
数据保护模式是指备库和主库之间数据同步程度。
Data Guard允许定义3种数据库保护模式,分别是最大保护、最大可用、最大性能模式。
这3种模式的区别在于,当主库发生故障时,备库的数据会和主库有多大的差距。
1.最大保护模式 Maximum Protection
顾名思义,这是最高的数据保护级别,这个模式的规则是即便牺牲主库的可用性,也要保证不出现数据丢失!
这个级别保证备库和主库的数据是完全同步的,即使主库突然夯机,在备库上也不会出现任何数据丢失。
这种方式要求备库必须配置SRL,而主库必须使用LGWR、SYNC、AFFIRM方式归档到备库,并且用命令定义为最大保护模式。
在这种模式下,主库上的每个事务的REDO日志必须在和本地和备库上都写入日志文件后才允许提交。如果不能写入到备库,
主库就会自动关闭以方式数据丢失。但也不是立刻shutdown abort,而是不再生成任何REDO,并且不断地尝试连接备库,
这个尝试大约最多会有10分钟,因为这一段时间内LGWR不再生成任何REDO,因此整个数据库表现为挂起。
在这种模式下,至少要有一个备库是正常的,主库才能正常打开,否则主库都无法打开。
如果主库是RAC环境,如果一个实例和备库之间网络发生了问题,那么在最大保护模式下,这个实例是crash,继而触发其他实例的crash recovery,
完成这个recovery之后,Data Guard会忽略这个实例,而主库其他实例也能继续处理业务,并发送日志进行同步。除非所有实例连接备库都出现了问题,
才会出现所有实例crash,最终导致整个数据库的crash。
2.最大可用模式 Maximum Availability
这是另外一种能实现零数据丢失的数据保护方案。这种模式需要至少有一个备库是通过SYNC和AFFIRM方式传送数据,并且要使用SRL文件才行。
在这种模式下,主库发送redo日志、并等待备库确认,备库收到redo日志,记录到SRL中,并返回确认给主库,这时,主库上的事务才能结束。
这是和最大保护模式一样的地方。因此,网络状态、备库的状态都会影响主库的事务性能。等待确认的时间用一个参数NET_TIMEOUT定义。
如果主库在该段时间(默认30秒)没有收到任何反馈信息,这个备库就会被标记成failed,LGWR会继续写日志,但是会忽略掉这个failed的备库。
如果在NET_TIMEOUT内收到了standby failed的消息,LGWR和LNS还会继续尝试重新连接,直到最终放弃这个备库为止。
一旦备库被认为是failed,那么主库就会强制进行一次日志切换,以明确的标识出发生failed的时间点,也就是达到零数据丢失的时间点,
而在这以后产生的redo日志就不再向备库发送了。
在这以后的时刻,Data Guard的保护模式就降到了Unprotected了,如果是一主多备环境,会有其他备库保持同步。一致到解决了日志Gap,
主库才会继续发送REDO,Data Guard才会恢复到Maximum Availability模式。
在RAC环境下,如果一个实例认为备库是failed,则自动触发的日志切换会导致所有的实例都停止发送REDO,即便其他实例能够连接到备库。
接下来,实例的ARCH进程还继续利用ping机制检测到备库的连通性,一旦恢复连接,则所有的实例会自动去解决gap,
接着所有的实例会进行日志切换,以启动LNS进程,继续发送REDO。
这种模式只是尽量避免数据丢失,也并不能保证数据完全一致。这种模式要求备库必须配置SRL,而主库必须使用LGWR、SYNC、AFFIRM方式归档。
3.最大性能模式 Maximum Performance
这个模式是默认的模式,它更加侧重对主库可用性不造成任何影响,即“在不影响主库性能的情况下,尽可能少的数据丢失。”
主库上的事务的REDO日志只要写到本地日志文件就可以提交,不必等待到备库传递完成。主库的REDO可以异步发送到备库。
备库的任何故障,以及两者之间的网络故障都不会影响主库的活动,即便网络出现问题,主库也只不过暂时停止REDO传送,
并等待ARCH进程通过PING机制发现连接恢复之后,继续重传。
这种模式可以使用LGWR ASYNC或者ARCH实现,备库也不要求使用SRL。
如果主库是RAC,并且工作在最大性能模式下,如果只是RAC的某个实例和备库的日志传递发生故障,那么也只有该实例的日志传递被中止。
而其他实例的日志传递仍然继续。发生中断的实例上的ARCH进程会不断地通过ping机制来检查连通性,一旦发现连接恢复,这个实例上的gap会自动发送给备库,
但是LGWR进程却并不会立即启动LNS进程去发送当前的redo数据,而是直到下一次日志切换时,LGWR才会启动LNS,开始传递REDO数据。
3.定义数据保护模式
保护模式是针对主库进行设置的,这个设置是告诉主库必须要遵守的规则。对备库没有作用。
数据保护模式在定义数据保护级别的同时,捎带着也同时定义了两个重要信息:
主库如何向备库传送redo;
当备库发生故障或网络出现故障,主库应该怎么做。
以下命令都是在主库下执行:
ALTER DATABASE SET STANDBY TO MAXIMIZE PERFORMANCE;
ALTER DATABASE SET STANDBY TO MAXIMIZE AVAILABILITY;
ALTER DATABASE SET STANDBY TO MAXIMIZE PROTECTION;
切换模式的过程,先尝试能够在open状态下切换,不能的话,就在mount下切换。
shutdown immeidate
startup
alter database set standby to maximize availability;
alter database open;
select protection_mode,protection_level from v$database;
内容总结
以上是互联网集市为您收集整理的Oracle 11g Data Guard原理研究--推荐全部内容,希望文章能够帮你解决Oracle 11g Data Guard原理研究--推荐所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错,欢迎将互联网集市网站推荐给程序员好友。
内容备注
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 gblab@vip.qq.com 举报,一经查实,本站将立刻删除。
内容手机端
扫描二维码推送至手机访问。