记某客户无纸化数据库一次性能优化

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

背景

无纸化系统作为客户的核心业务办公系统。是以互联网技术为载体。也是企业实现信息化的技术基础。 系统高度智能化设计,在多种重复繁琐的工作通过无纸化办公系统大力度减少业务人员工作量。

数据库作为无纸化系统的关键,更是需要极高的稳定性、实时性、可用性、高效性。

该系统在信息化高速发展中重要性日益突出,尤其业务在大数据环境下快速发展与变革,也随之带来了许多挑战。

数据量,并发量明显提高。而用户对性能的要求也进一步提高。

分析

在业务人员的大力度支持下,全面了解系统的业务特点,性能瓶颈。发现业务高峰期CPU负载压力过高,CPU使用率超过 90%。业务人员也反应很多模块出现超时。用户体验不爽。

通过调查发现IO的吞吐量不高,才10M/S. IO延迟5MS以下,还可以接受。

进一步确定到系统压力在逻辑读上面。比如我们选取某一典型时间段CPU使用率以及逻辑读数据曲线图。


业务高峰期AWR报告分析:

TOP等待事件中”db file sequential read”最高, 该等待事件一般是和索引扫描(除了index fast full scan),和索引回表造成的。 这种现象表示需要优化TOP SQL。我们对TOPSQL的优化取得了重要突破。

通过和业务深入交流发现有些配置表,大概30M左右, 数据几乎不会修改,但是在AWR发现配置表却有40% 的磁盘IO。我们通过把两个配置表keep 到内存中, 而从KEEP POOL的命中情况看,KEEP POOL上产生了36%的逻辑读,产生了巨大的作用。

我们也调查中很多重要索引存在很多碎片,比如:

索引 索引字段 索引体积 重建后体积
IDX_COMPARE_BILL COMPARE_BILL

784M

20M

IDX_PARAM_ID PARAM_ID

1076M

97M

PK_ZORDERP PARAM_ID

2744M

168M

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

SQL 优化前 优化后
ghc2umryhw6fc 3158次/h,34S/次。

0.96S/次

ftu8xknzkpcg0 4123次/h, 35S /次

0.86S/次

ghc2umryhw6fc 3859次/h, 32S/次

0.96S/次

4wf3dpxgpyqk8 984次/h, 8S/次

0.82S/次

通过优化后我们看SQl,效果非常明显, 业务人员明显感受到效率提升很多。我们也要看整体效果

整体表现:

CPU使用率:

逻辑读:

优化前 优化后
CPU使用率 70%左右,经常90%+

10%左右,偶尔40%+而且时间极短

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

20万逻辑读/S,偶尔55万逻辑读/S

SQL 优化前 优化后
ghc2umryhw6fc 3158次/h,34S/次。

0.96S/次

ftu8xknzkpcg0 4123次/h, 35S /次

0.86S/次

ghc2umryhw6fc 3859次/h, 32S/次

0.96S/次

4wf3dpxgpyqk8 984次/h, 18S/次

0.82S/次

未经允许不得转载:Oracle一体机用户组 » 记某客户无纸化数据库一次性能优化

相关推荐