接到业务部门通知，A机房（库a)到B机房（库b)之间的数据库服务器之间的网络带宽异常突增，影响公司对外业务的整体带宽。
一接到通知，作为数据库管理对所涉及的IP还是比较敏感。第一反应就是可能当时主库产生的归档特别多，把归档通过RFS进程到机房B的备库所消耗的带宽。表面上觉得很正常，这是oracle DG所需嘛！ 深入分析才找到了产生大量归档的根本原因：
  一、先统计下异常时间短内到底产生了多少归档日志：
HOUR_END_TIME        SIZE_MB 
------------------- ---------- 
2014-03-12 17:00:00     1073.14 
2014-03-12 18:00:00   21358.794 
2014-03-12 19:00:00     297.538 
2014-03-12 20:00:00     221.761 
2014-03-12 21:00:00     312.922 
2014-03-12 22:00:00     233.074 
2014-03-12 23:00:00 442.76 
2014-03-13 00:00:00     194.012 
如红色所示，17-18点之间突然产生了21GB归档。
二、通过logmnr对17-18点之间密集产生的归档进行分析，得出如下：
select table_name,count(*) from v$logmnr_contents group by table_name order by 2 desc;
TABLE_NAME                               COUNT(*)
--------------------------------               ----------
                                                         41960
table1                                             9459
table2                                             9436
table3                                             4816
table4                                              2422
table5                                             2380

涉及数据安全，业务表用table1,table2...table5等代替。由于这些业务表在其它服务器上都有等量数据更新，理所当然就排除了table1,table2....等。接下来对table_name为空，而count(*)极高的操作。分析发现有大量如下信息存在：

   SESSION#    SERIAL# USERNAME                       SESSION_INFO                       SQL_REDO       SQL_UNDO                                         
 ---------- ---------- ------------------------------ ------------------------------------------------      ----------------------------------------------------------                          ------------------------------------------------                                                                  

                                                                                                                                                          
                                                                                                                                    
        284      30932 MATCH                          login_username= ****  client_info= OS_username=LXZ      commit;
                                                                              
        284      30932 MATCH                          login_username=****  client_info= OS_username=LXZ        set transaction read write;  

获取sql_id

select sql_id from dba_hist_active_sess_history where session_id=284 and session_serial#=30932 ;

733mzzjjugasv

f63mmpsgtw1h5

获取sql_txt

select sql_txt from v$sql where sql_id in (‘     ‘,    ‘       ‘);

或

select * from WRH$_SQLTEXT where sql_id=‘733mzzjjugasv‘ ;

找出的sql语句如下：

create table t1 as select a.*, b.* from   a,   b where a.supcatid = b.buy_supcatid  <-----------------CTS

由于数据量大到7000万+，所以产生归档量特别多。

其实初始化时可以加上nologging属性

create table t1  nologging as select a.*, b.* from   a,   b where a.supcatid = b.buy_supcatid;

alter table t1 logging;

该sql在awr报告中也有体现。

一次CTS引发的网络故障