這篇blog是基於處理oracle數據庫性能問題的經驗寫就,它是對常見的性能問題做的總結,它的適用範圍: 高併發高負載的系統. 需要先申明的是: 對於所有的調優的方法,都是有適用範圍的; 所以下面提到的所有的內容,請” 批判性”閱讀.
1. OS swapping/paging 引發的數據庫concurrency方面的性能問題
Oracle數據庫在工作的時候, 對於latch/mutex這樣的輕量級的”鎖”,我們期望它是可以非常快的獲取/釋放的(這些操作都是對內存的操作,而內存的操作正常時候也確實都是很快的). 但是如果OS發生了大量的swapping/paging的情況下,那麼對內存的操作會變慢,那麼latch/mutex的操作就會變慢,在併發大的情況下就會發生hung/slow的情況.
引發swapping/paging的常見情況有:
a). 內存短缺
b). 內存並不短缺; 但短時間內, 有大量的新進程分配了很多內存
c). 拷貝大文件/備份數據庫 使得操作系統的高速文件緩存突然激增
對應的調優方式:
Lock SGA, 這樣SGA(相應的latch/mutex)就會被pin在內存裏而不受swapping的影響.
如果在SGA很大的情況下,同時使用large page(hugepage)技術,減少latch/mutex獲取/釋放的時間.
2. SGA resizing引發的數據庫性能問題
在AMM/ASMM內存自動管理的機制下, shared pool和buffer cache及其它幾個component可以根據需要自動調整大小,避免ora-4031的錯誤.但是在高併發的情況下,短時間內頻繁的resize的過程會使得一些內存操作(如latch/mutex的獲取釋放)的時間變長, 有很大機率觸發各種latch/mutex爭用. 而且如果shared pool被resize時減少的太多,那麼latch/mutex的爭用也會加劇.
引發這種問題的原因:
有些是因爲bug; 但是從深層次的角度考慮,這種resize的操作不可避免的會對性能有影響,只是影響的程度不同罷了. 而且bug的fix也只是減緩這種操作的impact, 而不能完全避免這種影響.
推薦的調優方式:
1). 設置buffer cache和shared pool的值(在內存自動管理的情況下,這個值會作爲最小值)
2). 設置resize的頻率不能少於16分鐘
alter system set "_memory_broker_stat_interval"=999;
Disable AMM/ASMM也可以作爲一個方法,但是缺點是: 碰到ora-4031的機率會比自動內存管理大.
3. DDL引發的數據庫性能問題
這種情況只發生在高併發高負載的情況下.
對於一個使用頻繁的表做DDL (比如grant, 修改表定義, 收集統計信息等等),那麼用到這個表的所有的SQL語句都會被invalidate掉;如果使用這個表的SQL語句很多並且執行頻率很快,那麼在短時間內需要hard parse 的 SQL語句就會很多. 這就變成了一種 “hardparse storm”, latch/mutex的爭用就不可避免, 還有library cache lock/row cache lock也會變多; 嚴重的時候數據庫就會slow/hung.
推薦的調優方式:
不要在負載高的時間段做DDL
案例：
記得有一次一個系統遇到嚴重的內存換頁，但是物理內存還是有很大的空閒。
後面查到的原因是，未對操作系統oracle做使用內存最大的配置
即未在/etc/security/limits.conf中配置
oracle hard memlock ×××
oracle soft memlock ×××
，導致oracle用戶只能使用默認的32k內存，從而當一些job啓動，跑一些統計分析的腳本時，出現大量的內存換頁。