ORACLE DBMS_RESOURCE_MANAGER Package 使用心得

理論上DBA都知道最好把ONLINE跟OLAP作業分開,
但是現實與理想總是有落差的,工作上往往很難把這些USER拆開,
結果有時候就出現資源被OLAP吃掉,造成ONLINE作業反應速度慢,
甚至拖垮整個主機效能的情況.
很不幸的我就遇到了.(雪上加霜的是AP的SQL已經到哀莫大於心死的地步)
基本上對跑報表的人道德勸說是無用的.因為他們不會覺得自己有錯.
我曾經請他們可以sequential跑,不要一次全灑下去,
顯然效果不好,他們只想賭我不會一直都在盯session,
還是一次全下.

ORACLE提供了一個package(從哪版開始有我不確定)
DBMS_RESOURCE_MANAGER
下面是我使用的三個例子

SQL> BEGIN
2 DBMS_RESOURCE_MANAGER.SET_INITIAL_CONSUMER_GROUP('SQL_GY','LOW_GROUP');
3 END;
4 /
PL/SQL procedure successfully completed.

第一個例子,把這個報表USER的INITIAL_CONSUMER_GROUP設到LOW_GROUP,
第二天早上我的CPU idle值果然上升了,
且我也不需要去道德勸說,你要一次灑好幾支一起跑,那你就跑吧.

SQL> BEGIN
2 DBMS_RESOURCE_MANAGER.SWITCH_CONSUMER_GROUP_FOR_USER('SQL_GY','LOW_GROUP');
3 END;
4 /
PL/SQL procedure successfully completed.

這個是針對某個USER的所有session都換到某個RESOURCE CONSUMER GROUP
你可以根據是不是離峰時間來調整CONSUMER GROUP
設到DBA_JOBS裡面,如果你有需要設計到CREATE額外的GROUP的話請自己去查手冊
我目前只要不是線上的我就給你LOW_GROUP

SQL> BEGIN
2 DBMS_RESOURCE_MANAGER.SWITCH_CONSUMER_GROUP_FOR_SESS(1080,5967,'LOW_GROUP');
3 END;
4 /
PL/SQL procedure successfully completed.


這是個很慘的例子,基本上我的機器硬體不強.
但是AP的SQL又出奇的複雜.(嗯,這不是稱讚他們)
為了不要讓某個process影響整個系統,
我只好抓出這個session然後把它踢到LOW_GROUP去


不過我遇到過很荒謬的情形是,某次AP廠商寫出一個會LOOPING的程式,
整個簡直就DOS阻斷攻擊(Denial of Service)
廠商居然問我有沒有辦法去控制程式用的RESOURCE,
我實在很想跟他說:同學,你online的程式寫出這種東西來,
你要我把你的process降priority,那要是respond time變慢是要怎麼辦,博杯喔.
這個時候DBA其實要守住,不合理的不要想逞能。