标签：des io os sp 数据 on 2014 log cti
接到业务部门通知，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报告中也有体现。
标签：des io os sp 数据 on 2014 log cti
原文地址：http://www.cnblogs.com/yiyuf/p/4103946.html
