系统探查与优化建议报告.pptx

2012-11; 截至目前为止，业务追踪系统探查到问题，总结如下： 1、分区问题 2、索引问题 3、对象统计分析问题 4、业务开发问题 5、ORACLE问题 6、硬件问题 7、数据监控问题 ;分区问题： 1、分区建立的不合理，没有从系统和业务的角度进行建立。 2、对于历史数据没有做过处理，导致每次查询数据都会扫描这些数据，产生大量的IO。 3、存在许多应该建立分区的大表，没有建立分区。 4、没有分区索引;解决方案 1、统计需要建立的分区表，建立分区，超过1.5G的表 2、探查整理业务逻辑，从业务和开发的角度进行建立分区表；或者调整开发程序逻辑，尽量保证DML操作只访问指定的分区。 3、整理过期的数据，做好离线备份，进行历史数据清理，如：2010年之前的数据。 4、尽量保证业务查询不跨区，如果是不能保证跨区，则根据业务情况建立组合分区 5、由于ORACLE版本的问题，对于目前系统尽量不要做HASH分区 6、建立本地索引和全局索引 ;索引问题 1、探查业务逻辑SQL，有许多都是全表扫描。说明没有建立合理的索引 2、有些索引已经很久没有进行对象分析导致错误的执行计划。 3、对于开发没有从业务开发角度进行构建索引的战略方案 4、有些表索引太多而有效的太少，导致占用了大量的cpu、io的资源 ;解决方案、 索引重构策略步骤 1、根据大中型表全面搜集表的读取类型 2、根据选定的对象进行数据的离散程度探查 3、为特殊读取的数据类型选定索引 4、根据业务特定的条件建立组合索引和序列的选择 5、验证和测试 其他建议： 1、索引需要定期重建，以减少失效的索引和碎片。 ;对象统计分析的问题 1、对象统计信息混乱，对于同一对象会存在多条统计信息 2、对象统计信息过旧，导致错误的执行计划从而使程序执行慢 3、对于分区表好多只存在分区的统计信息而没有全局的统计信息，这也是导致程序慢的原因 4、部分常用的索引的索引没有统计信息。;解决方案 构建策略 首先清理过旧和无效对象统计分析 1、根据业务分析出哪些数据表数据变化高中低。 2、根据数据变化进行设定表分析包百分比、并行度 3、对于分区表要根据业务单独设定分析的粒度 4、根据业务数据探查分析，进行列值和索引的直方图分析;业务开发问题 1、根据目前业务sql探查，许多ETL过程已经非常大，一般的业务加工逻辑已经有10多页，而且经历至少4、5个版本的需求修改。 2、业务需求开发只是建立的功能上的开发，而没有站在系统的角度开发，导致功能添加上了，但是整理的业务处理效率下降了，这也是导致速度急剧下降的原因。 3、加工处理中有的临时表数据量过大，并且多次被引用，而且对于临时表的策略是没有建索引，这也是导致速度随之业务发展速度慢的原因;解决方案 1、通过分析业务对象逻辑，查出问题SQL,拆解sql加工逻辑。 拆解逻辑原则是：小SQL,大逻辑 2、建立业务功能变更和添加的业务加工策略，使其在不影响以前业务加工的基础上进行新的SQL的加工，这样做的好处就是保证以前的加工逻辑和效率没有问题，更好定位现在的系统慢的原因 3、对于系统内部加工的临时表要做定期的整理和历史数据的清理。 4、对于经常被引用的临时表，建立合适索引和对象统计分析策略 5、 在加工数据的时候可以采用rowid字段值进行数据的获取，可以建立唯一性索引，ROWID包含了表中记录的物理位置信息。可以采用基于ROWID的访问方式情况提高访问表的效率， 因此那些基于索引列的查询就可以得到性能的提高。 6、尽量使用局部范围扫描，在业务开发时候，尽量多的采用关键性的过滤条件减少数据扫描范围。 ;解决方案 7、对于经常进行delete操作的表，要定期进行批量降低高水位线。 8、对于统计分析型的系统，应该尽量少的用索引的hint，尽量通过对象分析CBO方式的执行计划。 9、对于大表尽量少用DISTINCT ，可以个EXISTS 进行替换 ;ORACLE系统优化 此优化依据ORACLE AWR ，通过报告探查以及SQL探查、业务分析得出： 1、加大PGA的大小，建议：PGA=14G 2、启动分区和大表的压缩属性，原则：数据变化量小，但数据总体量大的表。 3、建立ORACLE子分区，进行系统的再优化。 4、降低系统并行，原则：依据目前系统CPU和业务调度并行启动顺序 ;12;13;解决方案 1、目前的硬件环境是IBM P6 570,可以支持16颗cpu，目前我们的环境只安装了8颗cpu，所以可以再次扩展8颗 2、目前硬件环境中，我们的内存有32G，而数据用了24G，用了系统整体内存的80%左右，需要扩展内存，建议扩展到64G或者128G，可以有效减少IO 3、IO存在过载的情况，建议采用oracle asm存储的方式来分散io，减少系统维护量 ;