|
一個Rac庫， 在從10g遷移到11g后， 開始出現(xiàn)性能問題。
表現(xiàn)為同樣的SQL，同樣的執(zhí)行計劃，可是SQL耗費時從1秒飆升到幾十秒。
做了AWR，發(fā)現(xiàn)了癥狀，整個系統(tǒng)的IO 已經(jīng)接近崩潰。
350M/s的IO, 單次IO讀的時間高達400ms。
看wait event， 百分之85的IO是由于direct path read 引起的。
direct path read是11G引入的新特性。 當(dāng)有全表掃描時，oracle會根據(jù)一定的算法進行分析，如果發(fā)現(xiàn)走direct path read更優(yōu)，就會選擇走direct path read，取代傳統(tǒng)的scattered read。
應(yīng)該說這個特性還是不錯的。
可下面就是問題了，有這么一個很簡單的SQL，訪問一個簡單的表A，由于沒有where filter，所有肯定需要走單表掃描。
這個SQL被大量執(zhí)行，同一時刻有200個session在執(zhí)行這個SQL。而oracle經(jīng)過計算，對這個SQL選擇了走direct path read。
然后悲劇來了。
direct path read不是問題。
可當(dāng)200多個session同時做direct path read，就是個問題了。 IO系統(tǒng)直接崩潰。
并且直接導(dǎo)致其它做正常的scattered read和sequental read的session，當(dāng)涉及到phsycial IO時，由于已經(jīng)不堪重負的IO系統(tǒng)的拖累，所以，響應(yīng)時間也幾十倍的上升。
找到了原因后，解決方法就簡單了，以下兩種供參考：
1. 10049
2. alter table A cache
考慮到200多個session執(zhí)行同一個SQL， alter table A cache后害怕會降低太多IO，造成library中的爭用，引入新的風(fēng)險，所以現(xiàn)在比較傾向10049 trace。
AWR截圖，供參考。
| Wait |
Event |
Wait Time |
Summary Avg Wait Time (ms) |
| I# |
Class |
Event |
Waits |
%Timeouts |
Total(s) |
Avg(ms) |
%DB time |
Avg |
Min |
Max |
Std Dev |
Cnt |
|
* |
User I/O |
direct path read |
1,373,931 |
0.00 |
481,162.28 |
350.21 |
81.58 |
350.26 |
348.14 |
353.65 |
2.97 |
3 |
|
|
Other
|
reliable message |
32,847 |
21.54 |
9,074.56 |
276.27 |
1.54 |
369.12 |
152.35 |
495.44 |
188.58 |
3 |
|
|
User I/O
|
db file sequential read |
21,558 |
0.00 |
8,367.24 |
388.13 |
1.42 |
387.98 |
379.14 |
394.27 |
7.88 |
3 |
|
|
System I/O
|
control file sequential read |
26,328 |
0.00 |
5,801.76 |
220.36 |
0.98 |
218.09 |
211.52 |
228.97 |
9.49 |
3 |
|
|
Commit
|
log file sync |
13,094 |
0.00 |
5,346.94 |
408.35 |
0.91 |
447.49 |
251.90 |
658.57 |
203.78 |
3 |
|
|
|
DB CPU |
|
|
4,250.92 |
|
0.72
|
|
|
|
|
3 |
|
|
User I/O
|
direct path write temp |
12,742 |
0.00 |
3,505.86 |
275.14 |
0.59 |
399.88 |
124.09 |
539.61 |
238.85 |
3 |
|
|
System I/O
|
log file parallel write |
13,040 |
0.00 |
2,580.21 |
197.87 |
0.44 |
209.98 |
142.42 |
304.40 |
84.26 |
3 |
|
|
System I/O
|
db file parallel write |
3,896 |
0.00 |
800.70 |
205.52 |
0.14 |
208.68 |
172.50 |
256.24 |
43.01 |
3 |
|
|
Other
|
gcs log flush sync |
70,782 |
86.16 |
691.43 |
9.77 |
0.12 |
9.81 |
9.51 |
9.99 |
0.26 |
3 |
可以考慮cache到中間件上去，11G還有 result cache
在測試過程中也發(fā)現(xiàn)這個問題,都禁用了
成熟生產(chǎn)庫，一般發(fā)現(xiàn)問題解決問題都是在現(xiàn)有框架內(nèi)，不好隨便引入新的東西
10949 還是 10049?
alter session/system set events '10949 level 1' ?
alter system set event= '10949 trace name context forever, level 1' scope=spfile;
alter system set audit_trail=none;
禁止sql tuning advisor
BEGIN
DBMS_AUTO_TASK_ADMIN.disable(
client_name => 'sql tuning advisor',
operation => NULL,
window_name => NULL);
END;
都建議禁掉
|
