data guard 配置详解

data guard 架构
1，日志发送
2，日志接收
3，日志应用


日志发送 （redo send）
两种方式
1，ARCH 进程 是ARC0在完成本地归档触发时ARC1会将日志通过net发送到远程的RFS进程，standby 


database 端的RFS进程把接收到的日志写入归档日志，然后standbydatabase 端的MRP或者lsp 进程会


应用这些日志。缺点是若果primary database 异常宕机 联机日志中的redo就会丢失
2，LGWR （sync 同步 async 异步）
sync通过LNSn进程将本地日志发送到远程目的地 sync是只有在远程发送成功后primary上的事务才会


提交，然后standby database的RFS进程会把接收到的日志谢日到standby database上的日志切换，即


standby datavase 对standby redo log的归档然后触发MRP 或 LSP 进程恢复归档日志。
async方式 sync问题在于 如果日志发送给standby database失败，lgwr集成就会出错也就是说 


primary database 的LGWR进程依赖于网络状况这时会用到async方式，这个方式的好处在于不用等待


lnsn进程网络传送成功与否。
指定方式在 log_archive_dest_2=


日志接收 （redo receive）


standby database 的RFS进程接收到日志之后，就会写入standby redo log 或者archive log
如果放在standby rebo log中 字primary database 发生日志切换时会触发 远程也进行日志切换，但


两种方式的目的都是将日志写到archive log中。


日志应用 （redo apply）


根据在远程日志的重演方式不同可分为物理standby（physical standby）和 逻辑standby （logical 


standby）两种类型。
物理standby使用的是 media recovery技术，在数据块级别进行恢复。这种方式没有数据类型限制，


可以保证两个数据库的完全一致。但这种方式只能在数据库处于mount状态下进行恢复，也可以打开，


单只能以只读模式打开，而且打开是不能执行恢复。
逻辑standby使用的是logminer技术，通过日志还原出sql语句，然后执行这些sql，但这种方式不支持


所有的数据类型，可以在视图（dba_logstdby_unsupported)中查看不支持的数据类型,如果使用了这


种高数据类型则不能保证数据库完全一致。而且在恢复的同时也可进行读写操作。






data guard环境中的重要进程


在primary database上
1，LGWR 该进程是复杂吧redo buffer中的内容写入联机日志文件中。
2，LNS（logwrite network service):该进程读取日志，并通过网络送给standby database，这个进


程的目的为了减轻LGWR的负担，LGWR进程不用再参与到网络日志的传递中了。
3，ARCH（归档进程）在primary database中可以有30个归档进程，其中有一个专门负责本地归档的，


而其他的arch进程都可以想standby database传送日志。
在standby 一端
1,RFS (remote file server) :这个进程负责接收网络上传送过来的redo日志，并把这些日志写到


standby redo log（SRL）文件中。
2，ARCH 进程：同样是归档进程，只是在standby上，需要归档的是SRL日志文件。
3，MRP （managed RECOVERY process) 进程：这个负责协调截止恢复管理工作，整个物理standby就


是建立在截止恢复技术上的。
4，PROx（parallel recover process）：这是进行具体恢复工作的进程，如果是real-time apply模


式下，这些进程会从standby redo log（SRL）文件中读取日志，而在其他模式下，是从归档日志中读


取日志然后再进行日志应用工作。
5，LSP（logical standby process）：这个进程在logical standby中才有，功能和物理standby中的


MRP进程类似，负责协调sql apply过程。


standby log file（SRL)


在data gaurd环境中 通常建议配置一种额外的日志文件standby redo log 和原有的online redo log


相比，SRL有特殊的要求和作用。两者的关系可以进行几点比较。
1，两中文件内容完全相同，单两者发挥的作用和场景不同。
2，SRL只在standby database上起作用。虽然 primary database 上也可以配置SRL，但是当数据库处


于primary role的时候是不活动的，只有经过了角色转换，SRL才会变成活动的。
3，对于standby database来说 ORL不是必须的也不会起作用。




用户常用的几个视图
v$archive_dest_stastus:在standby database上可以在这个视图中查看接收日志编号、恢复的日志编


号，从而可以了解standby database比primary database的之后程度。如果之后太多应该考虑增加恢


复进程。这个视图中的recovery_mode列也显示了是否使用了实时恢复（Real-time apply）
v$archive_dest：这个视图中的error列可以用于辅助挣断。
v$managed_standby:这个视图可以确认standby RAC中的那些实例是recover的实例。