全局热块冲突(摘自老白的RAC日记)

最新推荐文章于 2024-04-30 20:18:32 发布

czmmiao

最新推荐文章于 2024-04-30 20:18:32 发布

阅读量250

点赞数

分类专栏： RAC/DG/OGG 文章标签：数据库

本文链接：https://blog.csdn.net/czmmiao/article/details/84445906

版权

RAC/DG/OGG 专栏收录该内容

64 篇文章 0 订阅

订阅专栏

全局热块冲突是RAC平台经常出现的一种等待事件，这种等待如果比较严重的话，会对系统的性能产生十分重大的影响，甚至导致数据库被短时挂住。
全局热块冲突和普通的热块冲突类似，普通的热块冲突是在一个单节点上多个会话访问相同的数据块导致的等待事件。如果大量会话访问某个或某些特定的数据块，那么这些数据块被称为热块。相比单实例环境，全局热块冲突的危害更大，因为全局的热块需要在实例间进行传递。严重的全局热块冲突会导致系统性能急剧下降。
最典型的案例就是，如果某个应用要对某张表进行大批量的数据插入，而且插入的进程都跑在一个节点上，那么这个系统可能会出现一些buffer busy waits等待事件，不过不会产生很严重的性能问题。如果这个应用负载均衡方式分布在不同的节点上，那么从STATSPACK/AWR报告中，我们可能看到下面的情况：
    Top 5 Timed Events
    Avg %Total
    ~~~~~~~~~~~~~~~~~~
    wait   Call
    Event                                 Waits    Time (s)
    (ms)   Time Wait Class
    ------------------------------ ------------ -----------
    ------ ------ ----------
    buffer busy waits                    17,149      12,743
    743   37.3 Concurrenc
    gc buffer busy                       21,057      12,328
    585   36.1    Cluster
    enq: HW - contention                 19,571       7,155
    366   20.9 Configurat
    CPU time                                          1,253
    3.7
    gc current block 2-way              207,726         525
    3    1.5    Cluste
              -------------------------------------------------------------
对于这种情况，需要在应用的底层进行设计。比如有一种很常用的方法，就是在某张表中设计一个INSTANCE_ID字段，在插入数据时，每个实例插入的数据中都带有INSTANCE_ID，然后按照INSTANCE_ID对这张表进行分区，两个实例之间的gc buffer busy争用就会大幅度地减少。下面就是通过这种方式优化后的AWR报告。
Event   Waits   Time(s) Avg Wait(ms)    % Total Call Time   Wait Class
CPU time        1,334       92.3
log file sync   554,591 334 1   23.1    Commit
log file parallel write 536,004 106 0   7.3 System I/O
gc cr multi block request   449,571 85 0   5.9 Cluster
wait for scn ack    417,500 73 0   5.1 Other
从上面的报告可以看出，gc buffer busy消失了。
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实例间的热块，如果一个应用系统本身热块冲突比较严重，那么这个系统升级为RAC后，这些热块很可能变成实例级的，实例级的热块会导致比单实例环境下更为严重的后果，在一般情况下，会导致系统性能下降，严重的时候会出现类似海南这个案例的现象，
甚至导致系统被短暂的挂起。优化这种应用，关键是减少实例级的热块，减少数据块在实例之间传输。
老白使用的是一个很简单的方法，使相同的实例插入的数据存储在同一个分区里，这样这些数据就不需要在实例间做传输了。这实际上是一个典型的应用架构设计的问题，这种设计，再多实例的应用环境中，应该从底层架构就被考虑。在实际的工作中，老白经常会碰到类似的案例，
不过绝大多数情况下，很难像老白这次这么幸运的解决，因为系统上线后，甚至系统运行了几年之后才可能暴露出这个问题，这个时候，如果要采用今天的方法去优化就十分困难了。