2018年 精彩优化系统的总结

 

 

WXSJJS数据优化

WXSJJS数据库整体情况看其CPU压力都很小，及时业务高峰期，CPU使用率也不高。  压力表现在IO上面 高峰期300M/S ， 通过压力高峰期观察 发现离散IO， 顺序IO压力都比较大。 经过分析主要压力来源于业务执行的SQL。
 分析多份AWR 报告发现 核心业务需要大量建立临时表， 大部分临时表的名称也是随机的。 而用analysis 方法收集统计信息的， 其缺点100% 采样，不收集直方图。 
也造成分析时IO压力过大， 并且分析后数据倾斜情况下无法保证执行计划相对正确。 于是提供对应的收集统计信息策略。保证分析时采样比例合理，并且也能稳定执行计划。
另外关键大表没有索引， 调整为建立关键联合索引， 使得索引全扫描代替全表扫描。 
SQL中也有关联更新，大面积数据更新。  分别优化成批量更新，大面积数据更新改成少量+多次数据更新。 
经过调整后期，观察到高峰期完成大致相同的业务量 IO只需要 20M/S。  应用人员也反应 业务效率稳定高效。 

ZJ数据集市数据库优化
ZJ数据集市数据库中IO压力比较高。  通过业务高峰期多份AWR报告分析后得出，服务器总体内存 500G 但是数据库内存只有 120G （SGA 100G, PGA 20G ）. 
业务高峰期经常出现过 总体PGA 不够用，用磁盘空间，当成PGA使用。  也发现buffer 命中率较低，其标志着大量数据在内存中找不到，不得不从磁盘找数据。 也出现热点数据反复从buffer cache 中刷出的情况。
建议扩大数据库内存 目前是SGA扩大到 240G  PGA扩大到 40G。  扩大后问题明显 比较好转。

业务方面较多的 表，索引，并行度比较大， 因为并行导致执行计划出错。比如索引本身是走范围扫描的，但是并行度加大后， 倾向于走索引快速全扫描等。统一关闭并行后 SQL执行计划相对高效。
业务中也有大量的临时表，临时表没有统计信息， 也使得SQL执行计划不稳定，  通过收集统计策略及时收集统计信息 保障执行计划等。SQL中也有关联更新，大面积数据更新。  分别优化成批量更新，大面积数据更新改成少量+多次数据更新。
后期观察到IO 压力减缓很多。 项目组也反应业务要高效稳定的多。


ZWQD数据库优化， 

该系统整体情况良好， SQL总体情况也比较稳当， 偶尔出现性能不稳定情况，

现在已经查明数据倾斜的情况下，并且SQl语句中有隐式装换问题导致走错执行计划。目前已经定时收集统计信息+ 建议部分SQL调整，或者建立索引保证正确的执行计划。 
另外ZWQD，晚间定时任务需要大力度清洗数据， 观察到这些任务中修改不是批量修改。其执行速度较慢，近2小时/次，使得日志量较大，  SCN号增速较快。
目前已经建议改成 批量修改。  速度提高到 1分钟/次。  日志量大幅度下降， SCN号增速放缓很多。


XXB数据库优化

XXB数据库整体也比较良好， 只是在7 8月，出现一年中相对较高的业务高峰， 其CPU使用率较高。  分析高峰时间查询SQL特征得知， 这些相对执行频繁的SQL，中缺少索引。 在业务高峰期执行频率增大数倍。导致CPU 压力较高。 
 有的甚至高达8万次/H .，本身准备热点数据分割，IO分流等方式。  但是业务层面做了数据清理等， 解决了主要性能问题。
  有的关键业务对时间查询力度较大， 其基本上是查询最新1天的数据量。频繁出现"谓词越界"，因为统计信息的收集力度没有跟上， 导致CBO错误认为没有数据等.... 目前通过建立索引+ 收集统计信息策略而且部分重要SQL绑定执行计划等。

3 道措施保障关键业务性能等等.... 

后期也观察到 业务高峰期 CPU压力下降50%。



SOLZX数据库优化

SOLZX整体比较良好， 有一些特殊业务SQL， 对时间查询有特殊要求， 比如每次都是查询今天的数据量， 有些需要按照时间倒叙排序。 
虽然也有统计信息收集策略但是， 这些策略都是在晚间业务低峰时候收集。  因此查询的时间 > 收集统计信息时间， 因此数据库认为 查询的时间段没有数据，从而走了时间索引， 但是正真这段时间数据还很多。  从而没有走选择性更好的字段的索引。 

正因为这点， 目前需要加大统计信息的收集力度，让数据库能评估出更好的执行计划。 而且另外也用 sqlprofile 固定了部分 

SQl（SQL文本相对稳定，而且数据分布均衡）的执行计划。 两道措施保障执行效率。  



srdb 数据库优化

srdb 数据库性能比较稳定， CPU压力， IO压力都比较小， 只是IOPS 略微有点高， 逻辑读比较高，11G/S, 

通过业务高峰期AWR报告分析得出， 关键业务SQL， 返回的数据量很小，但是单次逻辑读却很大。 而且这些表都是小表，虽然单次执行效率还可以，但是次数太多
最终导致逻辑读过高。 

通过对字段过滤条件使用频率 + 字段选择性综合评估 建立适合索引。  使得大部分全表扫描变成 索引扫描。

使得 业务高峰期逻辑读下降近 90% 左右。  .

 

。。。。。。