Oracle_rac_11g下的DG搭建与维护
一．DG基础知识介绍 1.Data Guard结构
Data Guard是一个集合，由一个Primary数据库（生产数据库）及一个或多个Standby数据库（最多9个Standby）组成。组成Data Guard的各个Oracle数据库之间，通过Oracle的网络服务名（Net Service Name）连接，并且有可能分布于不同地域，实际上只要各库之间能够相互通信，它们的物理位置并没有什么限制，至于操作系统就更无所谓了（某些情况下），只要支持安装Oracle数据库软件就行了。
1．Primary 数据库
Primary数据库在某些资料中也被称为主数据库，相同Data Guard环境中至少要包含一个并且仅能有一个Primary数据库，实际上就是产生修改操作，并负责将这些操作传输到其他服务器的主数据库，该库既可以是单实例主数据库，也可以是RAC结构。
2．Standby 数据库
Standby数据库在某些资料中也被称为从数据库，或者备数据库。Standby数据库可以视作Primary数据库在某个时间点时的备份（事务上一致）。在同一套Data Guard配置中最多可以创建9个Standby数据库。一旦创建完成，Data Guard通过在Standby数据库端，应用Primary数据库生成的重做记录（REDO数据）的方式，自动维护每一个Standby数据库。Standby数据库同样既可以是单实例数据库，也可以是RAC结构。
Standby数据库通常分两类：逻辑Standby和物理Standby，如何区分？两类各有什么特点？如何搭建？这方面内容在后续章节会主要介绍，在这里呢三思先简单白活一下。
逻辑Standby。就像请人帮你素描画像，基本器官是都会有的，这点你放心，但是各器官位置啦，大小啦，肤色啦，就不一定跟你本人一致了。具体到数据库，就是说内容可能相同，但结构可能有差异。
物理Standby。就像拿相机拍照，你长什么样，出来的照片就是什么样，眼睛绝对在鼻子上头。或者说就像你去照镜子，里外都是你，哇哈哈。具体到数据库，就是不仅文件的物理结构相同，甚至连块在磁盘上的存储位置都是一模一样的（默认情况下）。
为什么会这样呢？这事就得从同步的机制说起了。虽然都是接收Primary数据库生成的REDO，不过逻辑Standby接收后将其转换成SQL语句，然后在Standby数据库上执行SQL语句实现同步，这种方式有一个专业名词叫SQL Apply。
物理Standby接收完Primary数据库生成的REDO数据后，以介质恢复的方式实现同步，这种方式也有一个专业名词叫Redo Apply。
提 示
不知道大家是否注意到形容词上的细节：对于相机拍照而言，有种傻瓜相机功能强大而操作简便，而对于素描，即使是最简单的画法，也需要相当多的练习才能掌握。这个细节是不是也说明逻辑Standby比物理Standby需要操作者拥有更多的操作技能呢？
2.Data Guard服务
Data Guard后台有一个非常严谨并且完善的机制，来确保Primary与Standby数据库间的数据传输、日志应用、状态检查、角色切换等，后续章节将会详细介绍，这里先简单描述一下几个大的服务，大家先有一个大致的概念即可。
1．REDO传输服务（Redo Transport Services）
Oracle通过RTS服务（即REDO传输服务）控制REDO数据，从Primary数据库发送到其他一个或多个归档目标。归档目标既可以指向本地路径，也可以指向一个远端的Service Name。最常见的启动数据库归档模式，就是设置一个本地的归档路径，而架设Standby服务器，则是设置一个或多个远端的Service Name，通过这种方式发送Primary端生成的REDO数据。
该服务属于基础服务，主要任务如下：
按照即定配置传输REDO数据到Standby数据库。 处理由于网络中断等原因导致的归档中断（Gap）。 控制数据库的保护模式。
检查Standby端丢失或无效的归档，并自动尝试从其他Primary/Standby获取。
2．Log应用服务（Log Apply Services）
LAS服务（即Log应用服务）主要用来应用REDO数据到Standby数据库，以保持Standby数据库与Primary数据库的事务一致。
REDO数据既可以从Standby数据库端的归档文件中读取，也可直接应用Standby。Redolog文件（如果实时应用打开了的话）。
前面也提到了，物理Standby和逻辑Standby在应用REDO数据时的处理方式完全不同：
对于物理Standby，Data Guard使用Redo Apply技术，即通过标准的RECOVER方式应用REDO数据。
对于逻辑Standby，Data Guard使用SQL Apply技术，即首先将接收到的REDO数据转换成SQL语句，然后执行SQL语句的方式应用REDO数据。
3．角色转换（Role Transitions）
一套DG环境中只有两种角色：Primary和Standby。所谓角色转换就是让数据库在这两个角色中切换，切换也分两种：switchover和failover。
switchover：Primary数据库和Standby数据库之间的角色切换，如将Primary数据库转换成Standby数据库，将Standby数据库转换成Primary数据库（如果有多个Standby数据库，一次只能选择其中的一个），switchover可以确保不会丢失数据。
failover：当Primary数据库出现故障并且不能被及时恢复时，就需要通过failover将DG配置的其中一个Standby数据库转换为新的Primary数据库。在最大保护模式或最高可用性模式下，failover也可以保证不会丢失数据。
3.三种保护模式
对于Data Guard而言，它提供了三种数据保护的模式。切换说数据的保护模式，可以使用以下命令：
alter database set standby database to maximize avaliability;
最大保护（Maximum Protection）。这种模式能够确保绝无数据丢失。要实现这一步当然是有代价的，它要求所有的事务在提交前其REDO不仅被写入到本地的Online Redologs，还要同时写入到Standby数据库的Standby Redologs，并确认REDO数据至少在一个Standby数据库中可用（如果有多个的话），然后才会在Primary数据库上提交。如果出现了什么故障导致Standby数据库不可用的话（比如网络中断），Primary数据库会被Shutdown。
最高性能（Maximum performance）。这种模式在不影响Primary数据库性能前提下，提供最高级别的数据保护策略。事务可以随时提交，当前Primary数据库的REDO数据至少需要写入一个Standby数据库，不过这种写入可以是不同步的。
如果网络条件理想的话，这种模式能够提供类似最高可用性的数据保护，而仅对Primary数据库的性能有轻微影响。这也是创建Standby数据库时，系统的默认保护模式。
最高可用性（Maximum availability）。这种模式在不影响Primary数据库可用前提下，提供最高级别的数据保护策略。其实现方式与最大保护模式类似，也是要求本地事务在提交前必须至少写入一台Standby数据库的Standby Redologs中，不过与最大保护模式不同的是，如果出现故障导致Standby数据库无法访问，Primary数据库并不会被Shutdown，而是自动转为最高性能模式，等Standby数据库恢复正常之后，Primary数据库又会自动转换成最高可用性模式。
最大保护及最高可用性至少需要一个Standby数据库REDO数据被同步写入。三种模式都需要指定LOG_ARCHIVE_DEST_n初始化参数。LOG_ARCHIVE_DEST_n很重要，你看着很眼熟是吧，我保证，如果你完完整整学完Data Guard，你会对它更熟。
4.三种保护模式的详细介绍及配置说明
当某次事务处理对生产数据库中的数据作出更改时，Oracle数据库将在一个联机重做日志文件中记录此次更改。在DataGuard中可以配置写日志的这个过程，除了把日志记录到本地的联机日志文件和归档日志文件中，还可以通过网络，把日志信息发送到远程的从数据库服务器上。
A. 这个备用日志文件写入过程可以是实时、同步的，以实现零数据丢失（最大保护模式）；
B. 也可以是异步的，以减少对网络带宽的压力（最大性能模式）； C. 或者是异步和同步可以自动切换的模式（最大可用模式）。
当备份数据库接收到日志信息后，Data Guard可以自动利用日志信息实现数据与主数据库的实时同步。当主数据库打开并处于活动状态时，备用数据库可以执行恢复操作，如果主数据库出现了故障，备用数据库即可以被激活并接管生产数据库的工作
4.1三种模式的配置
保护护模式 在出现灾难时数据丢失的风险 重做传输机制 是否需要standby redo log 磁盘写入
最大保护 ：零数据丢失 LGWR SYNC YES AFFIRM 最高可用性 ：零数据丢失 LGWR SYNC YES AFFIRM 最高性能： 最小数据丢失 — 通常为几秒 LGWR ASYNC 或 ARCH 可没有但推荐有 AFFIRM or NOAFFIRM
4.2保护模式的参数说明AFFIRM.SYNC.LGWR
AFFIRM（磁盘写操作）： 保证重做日志被写进物理备用数据库。默认是NOAFFIRM。 Affirm是保证日志已经写到备库地址。当使用lgwr,sync,affirm属性的时候需要直到IO全部完成事务才能提交。该参数对数据库性能是有影响的。
Noaffirm就是说LGWR的IO操作是异步的，该参数是默认值。
表示主数据库上的REDO LOG只有被写入到从数据库的standby log才算有效