今天是正式上线后，回访的同事正式上班的第一天，担心数据库压力会比较大，一早就来值守，9点钟开始，监控软件显示应用响应开始变慢，后来简直是大红大紫，经过OEM 12C观察，发现大部分等待都是gc和commit相关，AWR报告中显著的等待也都是gc和log写有关，经过分析，最终确定是DG的日志传输参数设置不当导致的，调整后相关等待显著下降，下图是调整前和调整后的对比。数据库版本11.2.0.4.0。

通过上图可以清晰的看到故障点之后，曲线有个明显的下降，之后又明显上升，最好趋于平稳，下面简单描述下以上的这几个阶段的操作。

通过监控发现，响应较慢的SQL都是INSERT操作，SELECT操作都很快，下面是我测试INSERT操作的案例，确实INSERT和COMMIT都较慢。

SQL> create table man_test as select * from ORD_ORD_INS_TO_M where 1=2;

Table created.

Elapsed: 00:00:00.31
SQL> insert into man_test values (13511039874,'','','','','','','','','','','','','');

1 row created.

Elapsed: 00:00:00.18

SQL> commit;

Commit complete.

Elapsed: 00:00:00.26

(以上经过多次测试，时间基本差不多)可见INSERT需要0.18秒提交需要0.26秒，这很不正常。通过OEM 12C监控到的等待信息和AWR报告的等待信息，基本可以判断是DG导致的这个问题，DG启用的是最大可用模式，将DG的日志传输禁止后，OEM 12C显示各种等待均明显下降，也就是上图曲线明显下降部分。

SQL> show parameter log_archive_dest_3

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
log_archive_dest_3                   string      service=ivldbst lgwr sync comp
                                                 ression=enable valid_for=(onli
                                                 ne_logfiles,primary_role) db_u
                                                 nique_name=ivldbst
SQL> alter system set log_archive_dest_state_3=RESET;

System altered.

再次测试，INSERT和COMMIT都看不到时间了，非常快，这才是正常的。

SQL> insert into man_test values (13511039874,'','','','','','','','','','','','','');

1 row created.

Elapsed: 00:00:00.00
SQL> commit;

Commit complete.

Elapsed: 00:00:00.00

(以上经过多次测试，时间基本差不多)，打开日志传输，再次测试，INSERT和COMMIT又需要将近0.2秒左右的时间，到这就可以断定就是DG的日志传输导致的问题了。

SQL> alter system set log_archive_dest_state_3=enable;

System altered.

SQL> truncate table man_test;

Table truncated.

Elapsed: 00:00:01.06
SQL> insert into man_test values (13511039874,'','','','','','','','','','','','','');

1 row created.

Elapsed: 00:00:00.19
SQL> commit;

Commit complete.

Elapsed: 00:00:00.39

(以上经过多次测试，时间基本差不多)，观察日志传输参数发现使用了压缩，带宽是足够的，取消压缩后测试，时间有所下降，但影响不大。

SQL> alter system set log_archive_dest_3='service=ivldbst lgwr sync compression=disable valid_for=(online_logfiles,primary_role) db_unique_name=ivldbst';

System altered.

SQL> insert into man_test values (13511039874,'','','','','','','','','','','','','');

1 row created.

Elapsed: 00:00:00.09
SQL> commit;

Commit complete.

Elapsed: 00:00:00.19

那么问题就出在了同步传输上了，将SYNC修改为ASYNC，问题解决。

SQL> alter system set log_archive_dest_3='service=ivldbst lgwr async compression=disable valid_for=(online_logfiles,primary_role) db_unique_name=ivldbst';

System altered.
SQL> truncate table man_test;

Table truncated.

Elapsed: 00:00:00.21

SQL> insert into man_test values (15201127340,'','','','','','','','','','','','','');

1 row created.

Elapsed: 00:00:00.00
SQL> commit;

Commit complete.

Elapsed: 00:00:00.00

在网络条件较好的情况下，异步日志传输延迟也是非常小的，对主库影响较小，是比较常见的配置。这个库是其他第三方集成公司给安装配置的，包括存储的配置，各种奇葩的问题，头疼。

可能有人看到这篇文章会说，这都是在说COMMIT等待，并没看到GC等待相关的信息呀，可现实是有关的，下图说明一切。

而且ACTIVE的SESSON也明显减少。

本文固定链接: http://www.dbdream.com.cn/2015/08/dg%e9%85%8d%e7%bd%ae%e4%b8%8d%e5%bd%93%ef%bc%8c%e5%af%bc%e8%87%b4%e4%b8%bb%e5%ba%93commit%e5%92%8cgc%e7%ad%89%e5%be%85%e8%b6%85%e9%ab%98/ | 信春哥，系统稳，闭眼上线不回滚！