性能与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