记客户某系统一次性能优化

作者简介:戴秋龙,拥有超过八年的电信、保险、税务行业核心系统ORACLE数据库优化,优化经验,具备丰富的行业服务背景。对Oracle数据库有深刻的理解,擅长数据库故障诊断,数据库性能调优。

背景

行销宝系统作为核心的应用系统,具有涉及业务领域多,并发访问量大,累计数据量大等特点。而且随着市场的变化,尤其是在大数据环境下,数据增量明显提高。而用户对性能的要求也进一步提高,给系统性能优化带来新的挑战。

分析

在业务人员的大力度支持下,全面了解系统的业务特点,性能瓶颈。发现业务高峰期CPU负载压力过高,一般业务高峰期50%左右,在”结算””稽查”等业务合算过程中,CPU使用率超过 90%。也通过调查发现IO的吞吐量不高,才6M/S. IOPS也很小。进一步确定到系统压力在逻辑读上面。比如我们选取某一典型时间段CPU使用率以及逻辑读数据曲线图。


业务高峰期AWR报告分析:

TOP等待事件中”db file sequential read”最高, 该等待事件一般是和索引扫描(除了index fase full sacn),和索引回表造成的。 这种现象表示需要优化TOP SQL。

TOPSQl分析:(这里只列出典型的三个)

SQL 执行频率 执行成本
5b3a7przhx4sc 5万次/半小时

2万逻辑读/次

55495fd93c886 4.4万次/半小时

2.8万逻辑读/次

d0sd7kxr6ga47 8千次/半小时

4.7万逻辑读/次

对象分析:

和业务组大力度的交流中发现有些索引碎片非常严重,如下

索引

索引字段

索引体积

碎片程度

IDX_STU_O_ID

STUD_ORDER_ID

964M

大约90%的碎片

INX_EXT_V_PARAM_ID

PARAM_ID

1376M

大约90%的碎片

PK_ZMKM_ORDER_EXT_VAL

EXT_VAL_ID

2744M

大约90%的碎片

INX_EXT_VAL

EXT_VAL

68M

大约60%的碎片

实施

分别整理系统分析文档,以及优化建议文档,和业务组展开深入讨论交流后决定实施优化。需要在业务低谷时间实施优化,实施过程中需要保障系统稳定的同时也要保证优化的平滑进行。

优化后:

业务高峰期整体表现:

优化前 优化后
CPU使用率 50%左右,偶尔90%+

12%左右,偶尔20%+

逻辑读 150万逻辑读/S,偶尔250万逻辑读/S

50万逻辑读/S,偶尔70+万逻辑读/S

索引 索引字段 索引体积 重建后体积
IDX_STU_O_ID STUD_ORDER_ID

964M

20M

INX_EXT_V_PARAM_ID PARAM_ID

1376M

104M

PK_ZMKM_ORDER_EXT_VAL EXT_VAL_ID

2744M

168M

INX_EXT_VAL EXT_VAL

68M

8M

TOPSQl分析:

SQL 执行频率 优化前 优化后
5b3a7przhx4sc 5万次/半小时

2万逻辑读/次

3千逻辑读/次,性能提升6倍

55495fd93c886 4.4万次/半小时

2.8万逻辑读/次

7千逻辑读/次,性能提升3倍

d0sd7kxr6ga47 8千次/半小时

4.7万逻辑读/次

3200逻辑读/次,性能提升10倍

未经允许不得转载:Oracle一体机用户组 » 记客户某系统一次性能优化

相关推荐