DG概念与机制

数据卫士—DG

数据卫士—DG
1. 相关概念
1.1 什么是DG
1.2 DG的原理架构
1.3 DG相关服务
1.3.1 日志发送
1.3.1.1 日志发送—使用ARCH进程
1.3.1.2 日志发送—使用LGWR进程
1.3.2 日志接收
1.3.3 日志应用
1.4 DG保护模式

toc

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;

来自为知笔记(Wiz)