redo log大量產生的診斷處理流程,redolog產生流程
redo log大量產生的診斷處理流程
本文是原創文章,轉載請註明出處:
http://write.blog.csdn.net/postedit/41249705
1.獲得歸檔日誌暴增時段的一個歸檔日誌:可以查詢v$archived_log視圖,結合completion_time列進行定位
2.對該歸檔日誌進行轉儲dump
ALTER SYSTEM DUMP LOGFILE '/u01/oracle/V7323/dbs/arch1_76.dbf';
--請將路徑修改成當時的redo歸檔的路徑
以上命令會在user_dump_dest中產生一個trace檔案,請將該trace檔案傳到linux中(root使用者or oracle使用者均可)
3.
[root@hosta ~]# grep -A2 "^REDO RECORD" his_ora_29032886_dump_arch.trc > redo.log
4.
[root@hosta ~]# grep OBJ: redo.log |awk -F "OBJ:" '{print $2}'|awk '{print $1}'|sort -n|uniq -c |sort -n -r2038012 4294967295 <----出現了2038012次。 107 60635 60 60464 30 59848 29 62992 29 60669 9 59810 8 60706 8 59842
OBJ:4294967295,這個是undo的redo記錄,出現了2038012次,也就是說:產生redo最多的為undo操作
[root@hosta ~]# grep OBJ: redo.log |awk -F "OBJ:" '{print $2}' | more4294967295 SCN:0x0001.96090e1b SEQ: 1 OP:5.24294967295 SCN:0x0001.96090e1e SEQ: 1 OP:5.44294967295 SCN:0x0001.96090e1f SEQ: 1 OP:5.24294967295 SCN:0x0001.96090e20 SEQ: 1 OP:5.44294967295 SCN:0x0001.96090e21 SEQ: 1 OP:5.24294967295 SCN:0x0001.96090e22 SEQ: 1 OP:5.44294967295 SCN:0x0001.96090e23 SEQ: 1 OP:5.24294967295 SCN:0x0001.96090e24 SEQ: 1 OP:5.44294967295 SCN:0x0001.96090e25 SEQ: 1 OP:5.24294967295 SCN:0x0001.96090e26 SEQ: 1 OP:5.44294967295 SCN:0x0001.96090e27 SEQ: 1 OP:5.24294967295 SCN:0x0001.96090e28 SEQ: 1 OP:5.44294967295 SCN:0x0001.96090e29 SEQ: 1 OP:5.24294967295 SCN:0x0001.96090e29 SEQ: 2 OP:5.4
注意上面的最後一列:op,這是操作的標誌碼
OP:5.2 Undo HeaderOP:5.4 Commit
5.
[root@hosta ~]# grep -A2 "^CHANGE #" his_ora_29032886_dump_arch.trc > redo_c.log
6.
[root@hosta ~]# grep OBJ: redo_c.log |awk -F "OBJ:" '{print $2}'|awk '{print $1}'|sort -n|uniq -c |sort -n -r
---這是對object_id按照出現的次數進行倒序排列,舉例:
[root@hosta ~]# grep OBJ: redo_c.log |awk -F "OBJ:" '{print $2}'|awk '{print $1}'|sort -n|uniq -c |sort -n -r3057384 42949672951018128 15 279 60669 174 60635
這是說明:OBJ:4294967295 出現了3057384次;
OBJ:15 出現了1018128次。
OBJ:4294967295,這個是undo的redo記錄.
OBJ:15,可以用如下的語句查詢出來:select object_name from dba_objects where object_id='15';
以上就可以定位到是哪個object_name 導致的redo log暴增。
下面來確認一下,是何種操作導致的redo log暴增:
[root@hosta ~]# grep OBJ: redo_c.log | moreCHANGE #1 TYP:0 CLS:15 AFN:1 DBA:0x00400009 OBJ:4294967295 SCN:0x0001.96090e1b SEQ: 1 OP:5.2CHANGE #2 TYP:0 CLS:16 AFN:1 DBA:0x0040000a OBJ:4294967295 SCN:0x0001.96090e1a SEQ: 1 OP:5.1CHANGE #3 TYP:2 CLS: 1 AFN:1 DBA:0x0040006a OBJ:15 SCN:0x0001.96090e1b SEQ: 1 OP:11.5CHANGE #1 TYP:0 CLS:15 AFN:1 DBA:0x00400009 OBJ:4294967295 SCN:0x0001.96090e1e SEQ: 1 OP:5.4CHANGE #1 TYP:0 CLS:15 AFN:1 DBA:0x00400009 OBJ:4294967295 SCN:0x0001.96090e1f SEQ: 1 OP:5.2CHANGE #2 TYP:0 CLS:16 AFN:1 DBA:0x0040000a OBJ:4294967295 SCN:0x0001.96090e1e SEQ: 1 OP:5.1CHANGE #3 TYP:2 CLS: 1 AFN:1 DBA:0x0040006a OBJ:15 SCN:0x0001.96090e1f SEQ: 1 OP:11.5CHANGE #1 TYP:0 CLS:15 AFN:1 DBA:0x00400009 OBJ:4294967295 SCN:0x0001.96090e20 SEQ: 1 OP:5.4CHANGE #1 TYP:0 CLS:15 AFN:1 DBA:0x00400009 OBJ:4294967295 SCN:0x0001.96090e21 SEQ: 1 OP:5.2CHANGE #2 TYP:0 CLS:16 AFN:1 DBA:0x0040000a OBJ:4294967295 SCN:0x0001.96090e20 SEQ: 1 OP:5.1CHANGE #3 TYP:2 CLS: 1 AFN:1 DBA:0x0040006a OBJ:15 SCN:0x0001.96090e21 SEQ: 1 OP:11.5
注意上面的最後一列:op,這是操作的標誌碼
OP:5.1 Undo RecorderOP:5.2 Undo HeaderOP:5.4 CommitOP:11.5 Update Row Piece,也就是update操作,根據obj:15,就能確認是哪個對象上的update
參考文章:
http://www.traveldba.com/archives/479
http://blog.csdn.net/duanbeibei/article/details/6091507