详解Oracle RAC性能调整

全局热块冲突是RAC平台经常出现的一种等待事件，这种等待如果比较严重的话，会对系统的性能产生十分重大的影响，甚至导致数据库被短时挂住。全局热块冲突和普通的热块冲突类似，普通的热块冲突是在一个单节点上多个会话访问相同的数据块导致的等待事件。如果大量会话访问某个或某些特定的数据块，那么 这些数据块被称为热块。相比单实例环境，全局热块冲突的危害更大，因为全局的热块需要在实例间进行传递。严重的全局热块冲突会导致系统性能急剧下降。

最典型的案例就是，如果某个应用要对某张表进行大批量的数据插入，而且插入的进程都跑在一个节点上，那么这个系统可能会出现一些buffer busy waits等待事件，不过不会产生很严重的性能问题。

RAC 上解决gc buffer busy的常用方法之一：

对表结构做一个调整，来彻底解决这个问题。我们重新对表进行分区，使之成为一个复合分区表，在这张表上加入一个字段 inst_id，也就是实例编号，这个字段作为主分区字段，按照这个分区做范围分区后，再设置msg_id的hash分区。调整后的表结构如下：

Create table qstore
{
MSG_ID   VARCHAR2(64 BYTE)  NOT NULL，
DOCE_ID  VARCHAR2(100 BYTE) NOT NULL,
DOC_KEY  VARCHAR2(100 BYTE) NOT NULL,
BUS_NAME  VARCHAR2(100 BYTE) NOT NULL,
MODULE_NAME  VARCHAR2(100 BYTE) ,
CATEGORY  VARCHAR2(64 BYTE) ,
SUB_CATEGORY VARCHAR2(64 BYTE) ,
DOC_SIZE NUMBER(11)  DEFAULT 0,
CREATE_TIME DATE,
MODIFY_TIME DATE,
EXPIRED_TIME DATE,
DOC_FLAG
Inst_id  number
}initrans 20 pctfree 20 tablespace TS_DATA_EAI
PARTITION BY RANGE(inst_id)
 SUBPARTITION BY HASH(msg_id) SUBPARTITIONS 8
 (PARTITION p1 VALUES LESS THAN (2)),
 (PARTITION p1 VALUES LESS THAN (3));

inst_id 的值就是 插入进程连接到的实例的ID，这样调整后，在1号节点上插入的数据将全部被插入到inst_id=1的分区，插入操作就不会产生大量的global cache request了。这种做法也是在RAC上解决gc buffer busy 的常用方法之一。即可以方便通过交换分区的方式对历史数据进行归档，而且可以通过HASH分区来减少buffer busy wait和 HW锁等待。

当两个节点对相同的表做跟新操作的时候，这些块需要在两个节点之间不停的传输，这就是我们常说的RAC实例间的热块，如果一个应用系统本身热块冲突比较严重，那么这个系统升级为RAC后，这些热块很可能变成实例级的，实例级的热 块会导致比单实例环境下更为严重的后果，在一般情况下，会导致系统性能下降，严重的时候会甚至导致系统被短暂的挂起。优化这种应用，关键是减少实例级的热块，减少数据块在实例之间传输。

一个很简单的方法，使相同的实例插入的数据存储在同一个分区里，这样这些数据就不需要在实例间做传输了。这实际上是一个典型的应用架构设计的问题，这种设计，再多实例的应用环境中，应该从底层架构就被考虑。

当会话想要访问缓冲存储器中的数据块，而该数据块正在被其它会话使用时产生buffer busy waits事件。其它会话可能正在从数据文件向缓冲区存储器度曲同样的数据块，或正在缓冲存储器中对其进行修改。为了确保读取器会话拥有与获得所有更改或无更改的数据块一致的映像，正在修改该数据块的会话在其标题中标记一个标志，让其他会话知道有一个更改正在进行而等候更改的的完成。视图v$waitstat不是OWI的组件，但其为没一类缓冲区提供了有用的等待统计。遭遇buffer busy等待事件最常见的缓冲区类为块、段标题、撤消块、撤消标题。

转自: