一个Data Guard 配置由一个生产库和一个或者多个standby数据库组成，在Data Guard配置中，主库和备库都既可以是rac环境，也可以是单机环境。

这篇文章主要介绍dataguard的一些基本知识

dataguard的分类、dataguard的服务类型、dataguard的保护模式

1.Dataguard中的备库分为物理备库和逻辑备库及快照备库

备库是主库的一致性拷贝，使用一个主库的备份可以创建多到30个备库，将其加入到dataguard环境中，创建成功后，dataguard通过自动应用从主库传送到备库的redo数据维护每个备库。

1.1物理备库(Physical standby database)

物理备库提供物理上和主数据库相同的拷贝，磁盘数据库结构和主库是相同的，物理备库是块到块的拷贝，一个物理备库通过应用从主库收到的redo数据保持和主库的同步，称为日志应用(redo apply),11g的dataguard在应用日志的时候是可以打开的，10g是不允许的。11g的这种特性称为active data guard。

1.2逻辑备库 (Logical standby database)

逻辑备库包含和主库相同的逻辑信息，物理结构和数据结构可以是不同的，逻辑备库把从主库收到的redo转换为sql语句，然后在备库上执行sql语句，称为sql应用(sql apply)。逻辑备库除了能应用于灾难恢复，还允许用户查询逻辑备库和通过逻辑备库生成报表，用于其他目的，使用逻辑备库能升级database软件，在无停机的情况下打补丁等操作。

1.3快照备库 (Snapshot Standby Database)

快照备库是11g中出现的，类似物理备库和逻辑备库一样，快照备库从主库接收redo数据，和物理或逻辑备库不同的是，快照备库只接收而不应用接收到的redo数据。直至快照备库转换为物理备库，之后先扔掉任何对快照备库的更新，然后应用接收到的redo数据。快照数据库最好用在要求临时的，可更新的物理备库快照场景。

典型的data guard配置如图所示，来自oracle concept

2. dataguard的服务类型 (Data GuardServices)

日志传输服务(Redo Transport Services)

日志应用服务(Apply Services)

角色转换     (Role Transitions)

2.1日志传送服务管理从生产库传送redo数据到一个或多个归档目录。日志传输服务完成以下工作：

2.1.1在配置中从主库传输redo数据到备库

2.1.2在网络失败后，管理备库缺失的archivelog，自动解决缺失

2.1.3自动扫描在备库中错误的或损坏的redo，自动从主库或其他备库重新获得并替换损坏的archive log。

log_archive_dest_n初始化参数用来确定本地的redo和远程归档redo的位置。log_archive_dest_n中详细参数解析

2.2日志应用服务在备库中应用redo数据，维护和备库主库之间的同步，redo数据默认从归档redo日志中应用，若启用了实时应用，则直接从standby redo日志中应用；对于非实时应用redo，当主库日志发生切换时，备库才会应用从主库传输来的redo日志。默认情况下，对于非实时应用，应用服务会等待备库redo日志被归档才会应用归档redo日志，实时应用允许应用服务应用当前正在填充的备库redo日志中的redo数据。

日志应用工作方式：redo apply和sql apply

物理备库和逻辑备库主要的区别就是日志应用的工作方式不同，物理备库使用redo apply，逻辑备库使用sql apply，类似MySQL 的主从的方式。

Redo apply在物理备库上使用常规的数据库恢复技术，也就是介质恢复，来应用redo中的数据。如图所示：

Sql apply在逻辑备库上使用这种方式，首先将接收到的redo数据转换为sql语句，然后在逻辑备库中执行生成的sql语句，之后在备库中应用。使用的是logminer技术。如图

日志应用服务配置

standby redolog

实时应用要求standby数据库必须有standby redo日志，lgwr同步和异步传输模式要求传输目的地配置standby redo日志，standby redo日志用于存储从一个主库接收到的redo日志，standby redo日志在结构上和联机redo日志是相同的，也使用创建和管理联机redo日志相同的sql来创建和管理standbyredo日志。

Standby数据库使用RFS前台进程接收传送过来的redo日志，将其写到当前的standby redo日志组，当源数据库发生了日志切换，传入的redo将写到下一个standby redo日志组中，之前的standby 日志通过ARCn前台进程被归档。在源数据库，进程顺序地填充和归档redo日志组，这种方式呗镜像到每个redo传输目的地，在standby数据库以相同的顺序填充和归档standby redo日志组。

每个standby redo日志的大小必须至少和redo源数据库的redo日志组中最大的redo日志一样大，推荐传输目的地的standby redo日志和源主库的redo日志中的所有日志相同大。

对于standby 数据库的每个redo线程，standby redo日志至少比在redo源主库的redo日志多一个redo日志组，在源主库，查询v$log视图确定源主库redo日志组的个数，对于rac，查询v$thread视图确定源主库redo的线程数，对每个线程使用的standby redo日志进行配置。

操作过程：

selectgroup#,bytes from v$Log ;主库

selectgroup#,bytes from v$standby_log ;备库

Oracle推荐在dataguard中的主数据库也创建standby redo日志，这样当switchover到备库角色也可以立即实现实时接收redo数据

alterdatabase add standby logfile创建或添加standby redo日志，如果standby redo日志租不活动或者redo传输用于解决缺失，那么standby数据库接收到的redo数据被直接写到一个归档redo日志。

实时应用redo 数据

若启用实时应用特性，应用服务能在不等待当前standby redo数据被归档的情况下，应用接收到的redo数据，这样使得switchover和failover的速度更快，因为standby redo日志中的数据在failover或者switchover开始的时候已经被应用到standby 数据库，减少了切换需要花费的时间。

物理备库开启实时引用

alterdatabase recover managed standby database using curren logfile dixconnect fromsession ;

逻辑备库开启实时引用

alterdatabase start logical standby apply immediate ;

启用实时应用要求备库配置由standby redo日志，并且开启了归档

注:对于日志传输，可以将其划分为实时传输(同步、异步)和切换时传输(默认传输方式)，实时传输与实时应用之间没有关系，实时传输只是和dataguard保护模式有关。

延迟应用redo

在一定程度上保护应用程序对主库的破坏及减少误操作对standby数据库的影响。当设置delay间隔之后，不能延迟传输redo数据到standby数据库，只是会延迟应用redo日志，从standby目的地完成归档开始计算延迟时间。延迟结束之后开始应用归档日志。

指定延迟时间：

在主库和备库通过指定log_archive_dest_n初始化参数delay=设置延迟时间，默认情况是没有延迟时间的，若指定了delay参数但是没有指定值，默认是30分钟。

取消指定时间

物理备库

alterdatabase recover managed standby database nodelay ;

逻辑备库

alterdatabase start logical standby apply nodelay;

执行以上的命令，在时间间隔到之前应用服务立即开始应用归档redo日志文件到备库。

2.3使用switch over或failover操作改变数据库角色，将备库转换成主库或将主库转换为备库。

Switchover是主库个一个备库的转换，可以确保没有数据丢失，是在有计划的典型操作。在switchover期间，主库角色转变为备库，备库转换为主库，在主库inactive时，failover可以将备库转换为主库角色，failover可能会导致数据丢失，failover只有在主数据库启动失败的情况下才使用。

3.dataguard的保护模式

Oracle提供三种保护模式满足不同级别的系统。最大保护、最大性能、最高可用。三种保护模式都要求使用特定的redo传送选项发送redo数据到至少一个备库

3.1最大保护

如果主库失败，最大保护模式可以确保没有数据丢失，事务在完成提交之前，事务恢复需要的redo数据必须写到主库的联机redo日志和至少一个同步的备库的standby redo log，若主库不能写redo数据到至少一个备库，为了确保数据不会丢失，主库会被关闭，正是应了最大保护模式这句话。

使用最大保护模式必须符合的条件：

a.主库在log_archive_dest_n的参数设置中必须使用到lgwr sync affirm属性来归档到备库

b.备库必须配置standby redo log

c.至少有一个备库是可用的

采用最大保护模式的主库，不能使用shutdown immediate对唯一的standby数据库执行关闭操作。因为会导致主库关闭

3.2最大性能

是默认的保护模式，提供在不影响主库性能的情况下的最高级别的数据库保护模式，主库的用户事务一旦被写入本地联机redo中，就被允许提交，不需要立刻写到至少一个备库中，主库只要使用arch 或lgwr async属性对远程的备库进行归档即可，redo数据也写到一个或多个备库，但是对于事务提交是异步完成的，因此通过延迟写redo数据到备库不会影响主库的性能，这种保护模式提供您比最高可用模式较少的保护，但是能最低程度的影响主库的性能

3.3最高可用

采用个最大保护模式同样的方式，确保redo日志被完全写入本地数据库和至少一个备库的standby redo log中，才会给用于返回提交完成的信息，若因为某些原因导致备库不可用，主库不能讲redo写入到备库的standby redo 中，此时主库并不会关闭，主库将暂时将保护模式降为最大性能模式，并且继续进行工作，一旦备库恢复正常，主库的缺失消除方案会启动，归档redo日志的缺失部分会被填满，当主库下一个日志打开的时候，主库中的保护模式又会上升为最高可用。采用最高可用必须满足的条件：

a.主库在log_archive_dest_n初始化参数中需要使用lgwr sync affirm属性归档到备库

b.备库必须配置standby redo log

c.至少有一个备库处于可用状态