效能與RAC 讀書筆記

效能與RAC

1.sequence
RAC環境的sequence是全域性維護的，如果使用sequence需要注意order屬性，order屬性是為了

sequence的值保證順序變化。所以需要使用到sequence時oracle必須從資料字典中查出上一個值，

產生值，再更新資料字典。對RAC環境性效能影響非常明顯。所以要儘量在家cache值，這樣減少

sequence本身在例項間傳遞，有助於減少索引塊的競爭。

2.索引塊競爭
資料塊是oracle的基本儲存單元，記錄本身在資料塊內是無序存放的，但是索引卻必須順序存

放在索引資料塊當中。如果應用是insert操作密集型的，這個索引塊會在例項間頻繁傳遞，消耗寶

貴的cache fusion資源。
如果採用sequence作為索引，可以透過增大sequence cache大小的方法，儘量減少例項對索引

塊競爭訪問。還可以考慮使用reverse index。reverse index，比如資料值是123，則記錄索引時

要反過來變成321；下一個記錄是124，索引值反過來是421，這樣索引項就可能分散到不用的索引

塊中。從而減少例項間競爭。

3.undo block
當執行select語句時，oracle的“讀一致性”要確保語句看到的資料是select時發出的狀態，

如果有資料塊在select後被修改，或者資料塊上有活動事務，oracle會利用undo tablespace內容

構造read consistent資料塊。如果是索引掃描，索引塊修改頻率遠大於資料塊本身的修改率。因

此也可能導致CR索引塊在例項間大量傳遞。
為了減少undo block競爭，除了採用以上“索引塊競爭”中分散索引塊的方法外，還要儘量使

用小事務，以減少對CR的需要。

4.全表掃描
在RAC中訪問資料塊時，先從本地的data buffer cache中尋找，然後利用cache fusion在其他

例項中尋找，最後才從磁碟中讀取。如果經常使用全表掃描，勢必會造成資料塊在例項間頻繁傳遞

，加劇cache fusion的壓力。因此RAC中應該儘量減少全表掃描，或者使用分割槽技術儘量分散例項

的資料請求。

5.cache fusion效能指標。
RAC的效能主要取決於cache fusion的效能，因此對RAC的效能分析重點是叢集互聯的效能分析

，衡量cache fusion效能指標常用有以下幾種。

global cache service等待事件：

SQL> select INST_ID,EVENT,p1 file_unmber,p2 block_nimber,wait_time
2 from gv$session_wait
3 where event in('gc buffer busy','global cache busy');

no rows selected

一致性(CR)讀,判斷CR效率的SQL語句如下：
SQL> select b1.inst_id,b2.value "recevied",b1.value "recevied time",

((b1.value/b2.value)*10) "avg receive time (ms)"
2 from gv$sysstat b1,gv$sysstat b2
3 where b1.name = 'gc cr block receive time'
4 and b2.name = 'gc cr blocks received'
5 and b1.inst_id = b2.inst_id;

INST_ID recevied recevied time avg receive time (ms)
---------- ---------- ------------- ---------------------
1 612 182 2.97385621
2 176 35 1.98863636

ORACLE建議AVG Receive time 小於15ms，則current read效率正常。
在RAC環境下，所有的資料塊都是透過cache fusion方法處理的，因此多了許多cache fusion特有

的等待事件。
(1)在RAC的cache fusion環境下，每個例項要請求一個資料塊都要透過GCS、GES來獲得。每次請求

一個資料塊都會產生GC Current/Cr Request這個事件，這個事件本身只有一個佔位符，並不代表

真正的等待。

(2)GC Current/Cr 2/3 Way這個事件描述的請求一個資料塊，請求立即被滿足沒有發生等待。根據

請求的資料塊型別可以分成current和CR兩類，而根據返回路徑又可以分為2way 3way。

(3)gc current/cr grant這個事件也是代表資料塊的請求立即獲得響應，沒有等待。當向resource

master發出請求時，resource master透過GRD發現目前還沒有例項擁有資料塊的快取，所有

resource master同意該請求。也就是請求例項可以從磁碟讀入到SGA。這個事件和前一個事件的區

別就在於是否有資料塊的快取。

(4)gc current/cr block busy、gc current grant busy。gc current/cr block/grant

congested 這些事件和前面不帶busy的事件相對，分別代表，請求沒有立即被滿足，由於資源衝突

而發生等待。

AWR

啟用AWR

資料庫的初始化引數STATISTICE_LEVEL也控制著AWR對統計資料的手機，這個引數有如下3個取值。其中typical是預設值。

SQL> show parameter statistics_level

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
statistics_level string TYPICAL

basic：不做資料收集，相當於關閉AWR
TYPICAL:收集資料庫自動管理的所有資料
ALL：除了收集TYPICAL資料外，還包括OS的統計資料和執行計劃的資料

修改AWR配置
AWR預設是每個小時收集一次統計資訊，收集到的統計資料保留7天，這些配置資訊可以從DBA_HIST_WR_CONTROL檢視中檢視，可利用dbms_workload_repository包來修改這個配置。

SQL> select * from DBA_HIST_WR_CONTROL;

DBID SNAP_INTERVAL RETENTION TOPNSQL
---------- --------------------------------------------------------------------------- --------------------------------------------------------------------------- ----------
1235046404 +00000 01:00:00.0 +00007 00:00:00.0 DEFAULT

修改：
dbms_workload_repository.modify_snapshot_settings (retention=>21600,interval=>30);
這個例子是每半小時收集一次，收集到的資料保留15天。

產生AWR報告

最常用是使用$ORACLE_HOME/rdbms/admin/awrrpt.sql