数据卫士—DG

1. 相关概念

1.1 什么是DG

??DG全称Data Guard，官方给出的定义是“Oracle Data Guard ensures high availability, data protection, and disaster recovery for enterprise data.”DG保证了数据库的高可用，数据保护以及灾备。DG通过冗余数据来提供数据保护，通过日志同步机制保证冗余数据和主数据之前的同步，这种同步可以是实时，延时，同步，异步多种形式。DG常用于异地容灾和小企业高可用方案。DG中可以在Standby database上执行只读查询，从而分散Primary database的性能压力，但是这并不是用来解决性能问题的方案。

1.2 DG的原理架构

??在DG环境中，至少有两个数据库，一个处于开启状态面向应用提供服务称之为Primary Database。 第二个处于恢复状态，叫作Standby Database。 运行时primary Database 对外提供服务，用户在Primary Database 上进行操作，操作被记录在联机日志和归档日志中，这些日志通过网络传递给Standby Database。 这个日志会在Standby Database 上重演，从而实现Primary Database 和Standby Database 的数据同步。生产环境中往往一个主库多个备库。

备库的类型：

• physical standby database：物理备库，完全复制主库提供了一个物理上相同的(完全相同)主数据库的副本,与相同的磁盘数据库结构。主数据库基于block-for-block(基础)。
• Logical standby database：逻辑备库，包含与生产数据库相同的逻辑信息，但是数据的物理组织和结构可能不同。使用SQL Apply进行数据同步。逻辑备库是在物理备库的层次上升级而来。但是稳定性很差。
• Snapshot Standby Database：快照备库。

1.3 DG相关服务

相关服务按功能区分：

• 日志发送 （redo send）：
  Primary Database 运行过程中，会源源不断地产生Redo 日志，这些日志需要发送到Standy Database。 这个发送动作可以由Primary Database 的LGWR 或者ARCH进程完成， 不同的归档目的地可以使用不同的方法，但是对于一个目的地，只能选用一种方法。 选择哪个进程对数据保护能力和系统可用性有很大区别。
• 日志接收 （redo recieve）：
  Standby Database 的RFS（Remote File Server）进程接收到日志后，就把日志写到Standby Redo Log或者Archived Log文件中，具体写入哪个文件，取决于Primary 的日志传送方式和Standby database的位置。如果写到Standby Redo Log文件中，则当Primary Database发生日志切换时，也会触发Standby Database上的Standby Redo Log 的日志切换，并把这个Standby Redo Log 归档。 如果是写到Archived Log，那么这个动作本身也可以看作是个归档操作。
• 日志应用 （redo apply）：
  日志应用服务，就是在Standby Database上重演Primary Database日志，从而实现两个数据库的数据同步。 根据Standby Database重演日志方式的不同，可分为物理Standby（Physical Standby） 和 逻辑Standby（Logical Standby）。

1.3.1 日志发送

1.3.1.1 日志发送—使用ARCH进程

这是默认Primary database的发送日志的方式。
1）Primary database被应用使用时会不断产生redo log，这些日志由LGWR进程写入到联机日志。
2）日志被写满后，发生日志切换从而触发检查点开始日志本地归档。
3）日志归档完成后，联机日志就可以被覆盖重用。
4）这个时候ARCH进程会把归档日志通过Net发送给standby database的RFS（Remote File Server）进程。
5）standby database端的RFS进程把接收的归档日志写入本地。
6）standby database端的MRP（Managed Recovery Process）进程（执行redo apply）或者LSP进程（执行sql apply）在standby database应用这些日志，进而实现数据的同步。
关于这两种应用日志的区别：
物理Standby接收完Primary数据库生成的REDO数据后，以介质恢复的方式实现同步，这种方式也叫Redo Apply。
逻辑Standby接收后将其转换成SQL语句，在Standby数据库上执行SQL语句实现同步，这种方式叫SQL Apply。
使用ARCH进程的缺点：
Primary Database 只有在发生归档时才会发送日志到Standby Database。 如果Primary Database 异常宕机，联机日志中的Redo 内容就会丢失，因此使用ARCH 进程无法避免数据丢失的问题，要想避免数据丢失，就必须使用LGWR。

1.3.1.2 日志发送—使用LGWR进程

为了避免数据丢失，使用LGWR进程，LGWR进程又分为了SYNC（同步）和ASYNC（异步）两种方式。

• 使用LGWR的SYNC方式：
  1）Primary Database 产生的Redo 日志要同时写道日志文件和网络。也就是说LGWR进程把日志写到本地日志文件的同时还要发送给本地的LNSn进程（Network Server Process），再由LNSn（LGWR Network Server process）进程把日志通过网络发送给远程的目的地，每个远程目的地对应一个LNS进程，多个LNS进程能够并行工作。
  2）LGWR 必须等待写入本地日志文件操作和通过LNSn进程的网络传送都成功，Primary Database 上的事务才能提交，这也是SYNC的含义所在。
  3）Standby Database的RFS进程把接收到的日志写入到Standby Redo Log日志中。
  4）Primary Database的日志切换也会触发Standby Database 上的日志切换，即Standby Database 对Standby Redo Log的归档，然后触发Standby Database 的MRP或者LSP 进程恢复归档日志。
  因为Primary Database 的Redo 是实时传递的，于是Standby Database 端可以使用两种恢复方法：
  实时恢复（Real-Time Apply）： 只要RFS把日志写入Standby Redo Log 就会立即进行恢复；
  归档恢复： 在完成对Standby Redo Log 归档才触发恢复。
  primary database 默认使用ARCH进程，如果需要使用LGWR需要指定同时如果是sync方式可以额外使用参数NET_TIMEOUT（秒）来设置若干秒内网络发送没有响应报错。示例如下：

alter system set log_archive_dest_2 = ‘SERVICE=ST  LGWR  SYNC  NET_TIMEOUT=30‘ scope=both;

• 使用LGWR的ASYNC方式：
  SYNC的方式可能会由于网络情况导致报错，对网络质量要求较高，所以ASYNC就是为了应对这种情况产生。
  1） Primary Database 一段产生Redo 日志后，LGWR 把日志同时提交给日志文件和本地LNS 进程，但是LGWR进程只需成功写入日志文件就可以，不必等待LNSn进程的网络传送成功。
  2） LNSn进程异步地把日志内容发送到Standby Database。多个LNSn进程可以并发发送。
  3） Primary Database的Online Redo Log 写满后发生Log Switch，触发归档操作，也触发Standby Database对Standby Database对Standby Redo Log 的归档；然后触发MRP或者LSP 进程恢复归档日志。
  设置示例如下：

alter system set log_archive_dest_2 = ‘SERVICE=ST  LGWR  ASYNC ‘ scope=both;

1.3.2 日志接收

在日志接收中，需要注意的是归档日志会被放在什么位置：
1） 如果配置了STANDBY_ARCHIVE_DEST 参数，则使用该参数指定的目录。
2） 如果某个LOG_ARCHIVE_DEST_n 参数明确定义了VALID_FOR=(STANDBY_LOGFILE,*)选项，则使用这个参数指定的目录。
3） 如果数据库的COMPATIBLE参数大于等于10.0，则选取任意一个LOG_ARCHIVE_DEST_n的值。
4） 如果STANDBY_ARCHIVE_DEST 和 LOG_ARCHIVE_DEST_n 参数都没有配置，使用缺省的STANDBY_ARCHIVE_DEST参数值，这个缺省值是$ORACLE_HOME/dbs/arc.

1.3.3 日志应用

Physical Standby 使用的是Media Recovery 技术，在数据块级别进行恢复，这种方式没有数据类型的限制，可以保证两个数据库完全一致。 Physical Standby数据库只能在Mount 状态下进行恢复，也可以是打开，但只能已只读方式打开，并且打开时不能执行恢复操作。
Logical Standby 使用的是Logminer 技术，通过把日志内容还原成SQL 语句，然后SQL引擎执行这些语句，Logminer Standby不支持所有数据类型，可以在视图DBA_LOGSTDBY_UNSUPPORTED 中查看不支持的数据类型，如果使用了这种数据类型，则不能保证数据库完全一致。 Logical Standby数据库可以在恢复的同时进行读写操作。
Standby数据库的相关进程读取接收到的REDO数据（可能来自于Standby端的归档文件，也可能来自于Standby Redologs），再将其写入Standby数据库。保存之后数据又是怎么生成的呢？两种方式：物理Standby通过REDO应用，逻辑Standby通过SQL应用。

根据Redo Apply发生的时间可以分成两种：
一种是实时应用（Real-Time Apply）， 这种方式必须Standby Redo Log，每当日志被写入Standby Redo Log时，就会触发恢复，使用这种方式的好处在与可以减少数据库切换（Switchover 或者Failover）的时间，因为切换时间主要用在剩余日志的恢复上。
另一种是归档时应用，这种方式在Primary Database发生日志切换，触发Standby Database 归档操作，归档完成后触发恢复。 这也是默认的恢复方式。
如果是Physical Standby，可以使用下面命令启用Real-Time：
Alter database recover managed standby database using current logfile;
如果是Logical Standby，可以使用下面命令启用Real-Time：
Alter database start logical standby apply immediate;
查看是否使用Real-Time apply：
Select recovery_mode from v$archive_dest_status;
具体请参考：
http://blog.csdn.net/tianlesoftware/article/details/5514082

1.4 DG保护模式

• Maximum Performance：最大性能模式，默认的保护模式。完全不影响主库的保护模式。
• Maximum Protection：最大保护模式，这个模式对主库的影响最大，可能会导致主库的崩溃。需要保证备库和主库完全一致，不能有任何差别。保证了在主库宕机时备库数据和主库完全一致。为了达到这种保护级别，redo data必须同时写入主库的online redo log和备库的standby redo log。如果备库的日志没有写入成功，那么主库会夯住，超过某个时间主库崩溃。
• Maximum availablility：最大可用模式，介于以上两种模式之间，要求所有事务必须在提交前将redo数据在至少一个standby database可用，区别在于如果未能实现这个要求主库不会崩溃，而是转换为最大性能模式。等到standby database恢复后会自动转换为最大可用模式。

修改保护模式的方法：
1）关闭数据库，重启到Mount 状态，如果是RAC，需要关闭所有实例，然后只启动一个实例到mount状态。
2）修改模式：
语法：ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE {PROTECTION | AVAILABILITY | PERFORMANCE};
如：SQL>ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PROTECTION;
3）打开数据库： alter database open;
4）确认修改数据保护模式：
SQL>select protection_mode,protection_level from v$database;

DG概念与机制

原文：https://www.cnblogs.com/plutozzl/p/13356565.html