Standby Redo Logs的前世此生与最佳实践

编辑手记：使用过Data Guard的人应该对于Standby Redo Logs都不陌生，在配置了 Standby Redo Logs的standby中，可以进行日志的实时应用，同时Standby Redo Logs可以给主库传输过来的日志增长一层安全保护。然而在不少的生产环境中，你们都不多使用Standby Redo Logs。本文将会深刻剖析Standby Redo Logs的前世此生，工做机制以及一些最佳实践。

本文翻译自BPeaslandDBA的博客。

原文连接：https://community.oracle.com/docs/DOC-1007036

 

Introduction

在生产环境中，我发现大部分的Data Guard的standby上没有配置Standby Redo Logs，这让我感到很惊讶。我认为配置Standby Redo Logs是很是必要的，在个人环境中，我历来都会配置Standby Redo Logs。 固然配置Standby Redo Logs的确对于DBA来讲，是增长了一项须要维护的内容，但这是彻底值得的，而且Standby Redo Logs在配置并投入使用以后，后期基本上不须要花太多心思惟护的。

我想大部分人不使用SRLs的缘由是，他们不理解SRLs可以带来的好处，本文将会详解SRLs的优点，其建立维护方式及最佳实践。

为何使用SRLs?

若是standby配置的是最大保护模式，那么必须配置Standby Redo Logs。

经过SRLs对几乎实时传输过来的日志进行存储并及时应用。固然，若是是最大性能模式，配置SRLs也一样会有不少好处，为了让读者更好地理解这一点，

首先咱们来看一下在没有SRLs的状况下，日志的传输是怎么进行的。

在上图中，staandby中没有配置SRLs,所以Redo传输和应用的过程以下：

一、事务将日志条目写入SGA中的Redo Log buffer。

二、LGWR进程将Redo 条目从Redo Log buffer写入到online Redo logs.

三、当online Redo logs发生切换（通常是因为当前日志写满了），ARC0进程会将online Redo logs中的内容写入到Archived Redo log.

四、在standby数据库存在的状况下，归档进程会多启用一条子进程ARC1，读取archived Redo log的内容，并传输到对端的RS进程（remote file server）。

五、RFS将主库接受过来的日志发送给standby库的ARCn进程。

六、standby的ARCn进程将日志写入到standby的archived redo log。

七、当日志成功发送到archived redo log以后，MRP0进程在备库进行日志应用。

以上过程虽然看着复杂，但逻辑是比较简单和清晰的。

那么若是在配置了SRLs的环境中，日志的传输过程又是怎么样的呢？

在配置了SRLs的状况下，日志的传输中不只增长了新的元素，还增长了许多新的选择。

一、跟没有配置SRLs的时候同样，第一步仍然是事务产生的Redo条目写入。

二、LGWR进程将Redo写入到online Redo log。

三、明确是最大保护模式仍是最大性能模式

　　　　 a、在最大保护模式下，进行的是同步的日志传输（SYNC），网络服务器同步进程（NSSn）是LGWR的slave进程。它的做用是将Redo传输给standby的RFS进程。

 　　　　b、在最大性能模式下，进行的是Redo的异步传输（ASYNS），网络服务器异步传输进程（NSAn）从主库的online Redo log中读取数据，并传输给standby库的RFS进程。

四、standby服务器上的RFS进程将Redo流 直接写入到SRLs。

五、日志的应用方式取决于系统是否配置了实时应用。

a、若是配置了实时应用，MRP0进程将直接将SRLs的日志读取并应用到standby数据库。

b、若是没有配置实时的日志应用的话，MRP0进程将等待SRLs中的日志完成归档以后，再将归档后的日志应用到standby数据库。

在上述的步骤中，步骤三基本上解释了咱们为何要使用SRLs,在DG的最大保护模式下，也就是日志的同步传输模式下，必需要配置SRLs，不然同步的机制就不能生效。

在最大性能模式下，配置SRLs仍然是有必要的，由于SRLs可以将数据的丢失从小时下降到秒级别。在最大性能模式下配置SRLs可以实现几乎零数据丢失的数据传输。

使用SRLs的另一个比较重要的缘由是当配置了实时的日志应用，可以带来很大的好处。只要将Redo传输到了SRLs里面，就可以当即应用到standby数据库当中，不须要等待日志切换。只有配置了SRLs,才能保证在实时应用日志的时候，failover的切换和恢复时间降到最低。

不少用户在基于日志的异步传输的状况下的操做都有这样一个误区。

认为只有ARCn进程才能够将主库的日志传输到备库。这样的观点在早期的版本中是对的。

可是从10g，甚至是9i开始，只有在没有配置SRLs的状况下，才由ARCn进程来传输日志。若是配置了SRLs，12c以前，是由LNS进程传输，而12c之后，传输日志的任务是由NSAn进程完成的。NSAn的传输几乎实时实时的。

在没有配置SRLs的状况下，日志的传输必需要等待主库的日志的切换，若是在主库日志一个小时切换一次，那么就有可能产生一个小时的数据的损失风险，若是主库日志切换频率更低，那么面临的数据损失的几率就更高。

固然，这种状况能够经过主库的初始化参数 ARCHIVE_LAG_TARGET的设置来改善，若是DBA将该参数设置为3600秒，那么一个小时最多可能发生一第二天志切换。但即便是这样，一个小时的数据损失仍然是很大的，并且对于大部分的企业用户来讲，这种损失都是不可接受的。

为了减小等待日志切换带来的数据损失的风险，你须要作的只是配置一下SRLs,很是简单，可是却能给你的系统带来很大的性能和安全保障。

如何建立SRLs

建立SRLs的方式跟建立普通的online redo logs的方式是很相近的，在alter Database命令中多添加一个属性的设置就好，也就是增长关键字 “Standby”。

首先咱们来看当前系统中online Redo logs的大小设置。

对于上面的结果，我曾看到有人将它理解为“50MB”，而后他们就将SRLs的大小设置为50MB，这样是不精确的。

我在操做的过程当中，都是彻底按照online Redo Log的大小精确设置SRLs的大小的。还有一点是，有时候咱们看到ORL的不一样的组里面，日志的大小设置是不同的，在这种状况下，不能直接配置SRLs。

建议先将全部的online Redo Log大小是指同样，而后再配置SRLs。

接下来咱们进行SRLs的配置。

lSRLs的建立语句跟普通的online Redo logd 的建立惟一不一样的地方在于多了一个关键字 standby。 而且在我建立的时候，SRLs的大小是彻底按照ORL 的大小设置的。

因为系统当前有三组online Redo Log，在建立SRLs 的时候，若是不指定组数的话，系统默认会写成 group 4-6。那么后续若是须要增长日志组的话，就可能产生混乱。所以我从group 10开始配置SRLs.

接下来咱们经过数据字典来查看SRLs

咱们看到SRLs对应的thread# 为0，在配置SRLs的时候，尽可能避免将SRLs制定到特定的thread上，这样就可以被主库中的全部节点的ORLs使用。

接下来咱们查看全部的日志类型的组。

因为在建立的时候，group的编号是分开的。所以，这样在查询的时候，结果就能够按照日志的类型排列。

最佳实践

其实在介绍SRLs的时候，已经设计到了一些最佳实践。这部分，将会更全面地介绍SRLs的最佳实践。

1

确保全部配置的SRLs的组，其日志大小是一致的。

2

确保全部的SRLs的组中的日志跟ORL的大小一致。保证全部从主库传输过来的日志可以在SRLs中有足够的空间保存。固然，若是实在没有办法保证SRLs跟ORLs的大小一致的，能够设置SRLs的大小大于ORLs的大小。

3

在SRLs中不要配置任何thread,这样，SRLs就可以被全部的节点使用，包含在RAC中的主节点。

4

当在standby数据库上配置SRLs的时候，也须要同时在Primary数据库上配置，正常状况下，在主库上配置的SRLs是不会被使用的，但若是某一天你须要执行switchover的话，提早配置好SRLs会带来很大的便利。

5

对于Oracle RAC的主备方案来讲，最好是在standby上配置SRLs数量跟全部Primary节点上的同样多。 好比说，若是你有一个3个节点的Oracle RAC数据库，并在每个节点上配置了4组SRLs的话，那么在standby的节点上就须要配置3*4=12组的SRLs,无论你的standby上有多少个实例，standby数据库必需要保证可以可以容纳全部Primary数据库节点上的ORLs。