Oracle 11g Data Guard原理研究--推荐
内容导读
互联网集市收集整理的这篇技术教程文章主要介绍了Oracle 11g Data Guard原理研究--推荐，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含10747字，纯文字阅读大概需要16分钟。
内容图文
网络上和官方文档配置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 举报，一经查实，本站将立刻删除。
内容手机端
扫描二维码推送至手机访问。