Oracle-Rac环境下，压缩表带来的性能问题

原创已于 2025-03-14 13:03:52 修改 · 205 阅读

CC 4.0 BY-SA版权

文章标签：

于 2025-01-24 11:00:15 首次发布

18 篇文章

订阅专栏

是两节点同一条update语句，一样的执行计划，但是执行时间差了很多。同样一条update语句一节点执行效率要比二节点快很多。

update iih.bl_cg_ip set no_bb = '~' where id_ent = '1001Z81000000025KMG1'

①首先想到是否有大量的gc等待事件

一节点要去二节点的缓存中读块，但是网络有大量丢包或者错误包的问题，导致一节点效率低下，同时awr报告应该有大量gc等待事件

在这里插入图片描述

②通过dba_tables视图发现iih.bl_cg_ip 这张表为压缩表

dba_tables的COMPRESSION 和 COMPRESS_FOR字段可以看到表是否压缩以及级别

压缩是一项更适合于数据仓库环境的一项oracle 特性。压缩的好处包括以下两个方面：

1、节省存储空间，对应海量的数据来说非常有意义。

2、查询性能将会提高（不是绝对会提高），因为物理I/O 减少，并且提高了内存中数据块的命中率。

坏处

可能增加CPU 的负载。影响DML操作的性能。表中的碎片增多

压缩表，默认basic级别

alter table iih.bl_cg_ip move compress;


还原压缩表为非压缩状态
alter table iih.bl_cg_ip move  uncompress;

开始测试压缩表对update的影响

我们可以看到压缩表的db block gets比非压缩表高了9倍

在这里插入图片描述
也就是说，当我们对压缩表进行update操作的时候，读块会更多，这会引起大量的内部高并发下的冲突，以及大量资源开销

此时得出一个结论

1.压缩表导致我们访问的块9倍增长，导致了update语句执行慢，尤其是业务高峰区大量的update语句导致块争用现象严重