對使用dblink的10046事件跟蹤
如果網路頻寬不夠大的情況下,使用dblink導資料就會非常的慢,我們使用10046事件來跟蹤一下兩邊資料庫的等待事件,來推測下dblink慢的原因.
在源短執行建表語句
create table xx_test as (select * from yy_test@to_remote_db);
遠端表yy_test@to_remote_db的大小約為9G,上面的語句執行一段時間後將它中止,我們來看看兩邊的trace檔案.
源端的trace資料:
call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 0 0.00 0.00 0 0 0 0
Execute 0 0.00 0.00 0 0 0 0
Fetch 2 0.54 40.44 1512 1498 0 52708
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 2 0.54 40.44 1512 1498 0 52708
Misses in library cache during parse: 0
Parsing user id: 71
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net more data to client 4787 3.54 63.86
db file scattered read 19 0.07 0.86
SQL*Net message from client 2 0.02 0.03
SQL*Net message to client 3 0.00 0.00
SQL*Net break/reset to client 1 0.00 0.00
目標端的trace資料:
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net more data from dblink 12633 1.52 177.21
log buffer space 37 0.10 0.73
SQL*Net message to dblink 6 0.00 0.00
SQL*Net message from dblink 6 0.00 0.02
SQL*Net break/reset to dblink 3 1.11 1.11
SQL*Net break/reset to client 1 0.00 0.00
SQL*Net message to client 1 0.00 0.00
OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 179 0.01 0.02 0 0 45 0
Execute 245 0.16 0.16 0 452 120 112
Fetch 3179 0.07 0.10 20 6393 0 3335
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 3603 0.24 0.29 20 6845 165 3447
Misses in library cache during parse: 14
Misses in library cache during execute: 14
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
db file sequential read 20 0.01 0.07
log buffer space 1 0.00 0.00
我們看到,大部分的等待事件都是SQL*NET的等待,這說明SQL執行的時間大部分都消耗在了網路上,而不是在資料庫上.
而我們觀察原始的trace檔案,可以看到源端回間歇性的出現"db file scattered read"的等待;目標端則間歇性的出現"log buffer space"等待事件.說明dblink在取資料都是一部
分一部分的取然後插入.
我們對比exp的10046事件資訊:
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 48107 0.00 0.02
SQL*Net more data to client 48089 0.00 10.41
SQL*Net message from client 48107 3.64 27.49
direct path read 23695 0.19 3.02
db file sequential read 2 0.00 0.00
SQL*Net break/reset to client 1 0.00 0.00
好像exp的方式,相對來說,空閒等待相對比較少一些.
[@more@]來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/23850820/viewspace-1042008/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 使用10046事件 +10704事件對索引線上重建的跟蹤事件索引
- 使用oracle的10046事件跟蹤SQL語句Oracle事件SQL
- 10046事件跟蹤會話sql事件會話SQL
- 使用10046事件跟蹤分析執行計劃事件
- Oracle 10046跟蹤的使用Oracle
- ORACLE 10046 設定跟蹤事件後無跟蹤檔案Oracle事件
- 啟用跟蹤事件10046---06事件
- 跟蹤SQL - SQL Trace 及 10046 事件SQL事件
- 使用10046跟蹤sql語句SQL
- 【最佳化】10046事件之生成跟蹤檔案事件
- SQL效能的度量 - 利用10046事件擴充套件SQL跟蹤SQL事件套件
- 10046 跟蹤其他會話會話
- 使用10046跟蹤Oracle前映象資料讀Oracle
- oracle sql跟蹤 event 10046 - 轉OracleSQL
- 透過ORADEBUG運用10046事件跟蹤SQL語句事件SQL
- 使用10046 event trace跟蹤全表掃描操作
- [zt] oracle跟蹤檔案與跟蹤事件Oracle事件
- oracle跟蹤檔案與跟蹤事件(zt)Oracle事件
- oracle跟蹤檔案和跟蹤事件(zt)Oracle事件
- 跟蹤查詢DBLink遠端表是否使用到索引索引
- 【TRACE】Oracle跟蹤事件Oracle事件
- Oracle 跟蹤事件【轉】Oracle事件
- 使用dbms_system來對其他會話進行10046事件12級別的跟蹤看不到等待統計資訊會話事件
- 10046 跟蹤的trace檔案相關解釋
- Oracle跟蹤事件 -- set eventsOracle事件
- (zt) 開啟事件跟蹤事件
- Oracle 跟蹤事件 set eventOracle事件
- Oracle跟蹤事件和dumpOracle事件
- oracle跟蹤事件(轉載)Oracle事件
- oracle跟蹤事件(dump)總結Oracle事件
- [zt]Oracle跟蹤事件 - set eventsOracle事件
- Oracle跟蹤事件:set events 整理Oracle事件
- HP下對程式的跟蹤
- 跟蹤資料庫的命令:event 10046等的設定(ZT)資料庫
- 使用10203事件來跟蹤oracle塊清除事件Oracle
- oracle跟蹤常用內部事件號Oracle事件
- sql_trace 和 events 跟蹤事件SQL事件
- 設定跟蹤事件不起作用。事件