生產環境sqlldr載入效能問題及分析之一

jeanron100發表於2014-06-28
原文網址 : http://blog.itpub.net/23718752/viewspace-1198054/
SQL

在測試環境中進行了多輪測試，使用sqlldr批量載入資料，csv檔案大概有120G左右，在一致的資料量的情況下，測試環境都在一個小時左右，但是在生產環境中竟然跑了將近2個小時，效能差了一倍。而且生產環境的伺服器配置還要好一些。對於這個奇怪的問題，儘管說資料第一輪資料遷移已經完成了，對於之後的資料遷移還是很好的參考和經驗借鑑。

今天對生產環境和測試環境中的資訊進行了比對。先拿到對應的awr報告。
測試環境的資料庫情況如下。

Host Name Platform CPUs Cores Sockets Memory (GB)
test_db Linux x86 64-bit 40 20 2 354.11

Snap Id Snap Time Sessions Cursors/Session
Begin Snap: 1996 23-Jun-14 23:30:34 264 2.3
End Snap: 1998 24-Jun-14 00:30:18 105 3.0
Elapsed:   59.74 (mins)    
DB Time:   5,864.54 (mins)    


生產環境的資料庫情況如下：

Host Name Platform CPUs Cores Sockets Memory (GB)
prod_db Linux x86 64-bit 40 20 2 180.89

Snap Id Snap Time Sessions Cursors/Session
Begin Snap: 12852 27-Jun-14 03:00:55 760 2.5
End Snap: 12853 27-Jun-14 04:00:22 780 2.5
Elapsed:   59.45 (mins)    
DB Time:   8,861.63 (mins)    
通過上面的資訊可以得到，
1.在生產庫的負載將近是測試庫的兩倍，資料載入速度卻是測試庫的50%,從這個角度來看，也確實是合理的。
2.對於session的情況，測試庫和生產庫有著明顯的差別，測試庫中的session在105-264左右，但是在生產庫中卻有760-780左右，我之前建議在生產資料遷移的時候把listener的埠改了，這樣，開發測試部分的人就連不到庫了，能從一定程度上減少額外的干擾，但是限於時間緊迫，需要考慮的因素比較多，客戶不太願意這麼做。
3.基於第二點，有人在資料遷移的過程中訪問資料庫，進行了一些查詢，從某種程度上降低了資料庫的響應速度。但是活躍的session有那麼多嘛，因為在測試和生產中，並行的插入執行緒都基本控制在150個左右。怎麼有這麼大的差別啊。如果想得到一些更為有效的資訊，可以通過ash，下面就是通過ash得到的資料。
測試環境：

CPUs SGA Size Buffer Cache Shared Pool ASH Buffer Size
40 11,198M (100%) 6,144M (54.9%) 783M (7.0%) 80.0M (0.7%)


Sample Time Data Source
Analysis Begin Time: 23-Jun-14 23:30:00 DBA_HIST_ACTIVE_SESS_HISTORY
in AWR snapshot 1996
Analysis End Time: 24-Jun-14 00:30:00 DBA_HIST_ACTIVE_SESS_HISTORY
in AWR snapshot 1998
Elapsed Time: 60.0 (mins)  
Sample Count: 37,692  
Average Active Sessions: 104.70  
Avg. Active Session per CPU: 2.62  
Report Target: None specified  


生產環境


CPUs SGA Size Buffer Cache Shared Pool ASH Buffer Size
40 12,233M (100%) 6,144M (50.2%) 1,891M (15.5%) 80.0M (0.7%)


Sample Time Data Source
Analysis Begin Time: 27-Jun-14 03:00:00 DBA_HIST_ACTIVE_SESS_HISTORY
in AWR snapshot 12852
Analysis End Time: 27-Jun-14 04:00:00 DBA_HIST_ACTIVE_SESS_HISTORY
in AWR snapshot 12853
Elapsed Time: 60.0 (mins)  
Sample Count: 55,608  
Average Active Sessions: 154.47  
Avg. Active Session per CPU: 3.86  
Report Target: None specified  
可以看到活躍的session數確實比測試庫多了不少。這個可以稍後做確認。

還有一個是歸檔的問題
下面是檢視資料庫歸檔的情況，可以看到生產庫歸檔在119次左右，而測試庫在130次左右，日誌切換的次數多，說明在那個時間段內處理了更多的資料操作。

最後，比較top event的情況作為一個引子，明天來詳細的闡述這些等待事件後面的一些問題。
測試庫的情況

Top User Events

Event Event Class % Event Avg Active Sessions
log buffer space Configuration 46.82 49.03
db file sequential read User I/O 14.00 14.66
log file sync Commit 7.07 7.40
CPU + Wait for CPU CPU 5.98 6.26
buffer busy waits Concurrency 5.64 5.90

Back to Top Events 
Back to Top

Top Background Events

Event Event Class % Activity Avg Active Sessions
db file parallel write System I/O 2.48 2.60



生產庫的情況

Top User Events

Event Event Class % Event Avg Active Sessions
free buffer waits Configuration 22.29 34.43
buffer busy waits Concurrency 15.20 23.48
log buffer space Configuration 13.97 21.58
enq: TX - index contention Concurrency 10.16 15.70
log file switch (checkpoint incomplete) Configuration 9.94 15.35

Back to Top Events 
Back to Top

Top Background Events

Event Event Class % Activity Avg Active Sessions
db file async I/O submit System I/O 2.56 3.96


來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/23718752/viewspace-1198054/，如需轉載，請註明出處，否則將追究法律責任。

相關文章