一周优化总结

这一周 在搞oracle 性能优化。

哥记得 哥刚刚接手这个 项目时候， 发现有SQL  居然跑出了400 多分钟的时间，200，100 ， 70 多分钟，很多的， 南京分区的一个 什么流程 跑了 7， 8 个小时。

于是哥 开始着手优化。  其实我做优化 心里 自然是要一把尺子的， 首先看 系统 数据量， dba_segements 这个表， 大致是什么表最大等等.... 。  再看服务器的硬件配置。  内存多少，IO 性能如何， 存储空间多大，    这个其实都不需要  彻底了解， 了解大概 就差不多了，  比如 哥用并发搞定的一个案例，  该案例是删除数据的SQL， 删除用了 24分钟， 最简单的删除，  SQL 语句上面 已经无法优化了，  undo 表空间 也是足够的。 我当时 想跟 我们的项目经理 说了， 这个删除 的速度 其实还可以接受， 谁知项目经理   说这个需要优化的， 那我提出了一个 观点， 用硬件资源来换取一定的时间，  之前是因为 哥看过服务器  能接受的 最大  并发数了，   开4个进程 稳稳的， 于是哥开了  4个 并发 ， 至于到底用到了几个， 哥 没有关注，  最后 这个 我们几个在生产库中测试了，  6分钟 左右删除。 于是项目经理 接受了这个优化方案。    哥但是想想  之前  400多分钟的  SQL都接受了，24分钟 需要优化？？？？

还有一个 感觉 哥要做抽自己 嘴巴的，  乱说话导致的。  哥 当时 在优化也没有在意，    项目经理说插入 不该怎么慢的啊， 我说怎么了啊， 他说 插入速度 太慢了， 我看了一眼，发现 哥优化了的一个案例，  我说这个优化过了，  这个大概插入 150M 数据，    这个库 每秒 插入 50M 左右的数据，   至少  插入40M是稳稳的，  于是项目经理说 那 这个 你把他优化了吧.....  我 这个才意识到问题的严重性，      41分钟啊....  优化 到 秒 ，  什么概念？？？  其实我们项目  我也知道  至少 这个时候 不会 很苛刻，  只要优化到 10来分钟 差不多了。   于是哥的挑战来了，     经过排查 ， 发现大量索引 碎片，  大量的索引 在插入后 排序 花费时间， 于是 哥想到了， 思路。 什么都不要做 ， 就是搞一下索引  速度应该能到 十几分钟级别，  第2天      暂停生产库 ， 搞索引， 第三天傍晚  看效果 ，  结果 真的在  秒级， 大概 30多秒吧，  （ 其中 不排除哥做了其他方面的优化，  降低了oracle的负载了 ）。  这两个案例是在 知道了服务器  性能方面的参数 做出的性能 调整。

 监控业务核心业务表， 这个可以监控到，   我们只需要在 oracle  负载 并不是很强时候， 哥的意思是  ，核心表 和非核心 表分离，最典型的是  核心读写 文件的分离。   能保证非核心业务 能在  核心业务 进行之前结束， 或者是 在 其  结束后 搞。  不过这个哥 还没有来得及实现。估计会很快搞这个的。

 监测回滚段过于庞大，   在做这个优化时，超大量的数据更改， 几乎是全表更改， 关联更改。 一个方案是  拆分更改逻辑， 所谓更改 无非是先 找到数据， 然后改数据，其过程中必然 导致使用 undo 表空间，    那其很大，必然导致性能问题， 哥改的这些 SQL 都是  几十分钟的，  于是哥 先用hash join  查询数据， 然后每次 提交10000 条数据，

更改再更改 下一个10000条， 结果  3秒左右，   几十分钟到  3秒的，性能的提升。 还是很显著的...   

数据表减肥，   这个性能 肯定提升，  当时哥问了一下， 说这个表太大了， 要删除数据的， 这个肯定不行，删除数据 在生产库？？？   项目经理说的好， 这个叫 历史数据转储。 200万数据， 转储150 万数据，  性能能不提升？？

业务表，查询条件统计， 我们起码要知道  那些索引建的是有意义的， 之前哥看到好多索引 建的都 不知道是干嘛的， 有些列上面的等值过滤 用了10000多次，  有的只用了7  8次， 有的这个列上面的值  全是1，  有的列上面的值 很不均衡，但这些列上面有索引。  组合索引的引导列  上面的选择性 是100%。分区表上面 明显可以搞分区索引的。

那第二步 在 v$sql ， 和sql 的历史表，以及v$sql  和历史表中 查询 用到的 索引， 在排除一下得到没有用到的索引。  

第三步  在开索引监控， 看看 业务周期看看开索引监控 中到底有没有用到这个，  第四  步 在吧没有用到的索引删除。

哥现在走到 第三步。   估计第四步很快就会走的。      哥在删除 索引后对  insert 性能提升 效果 大大的。

比如也有个优化 是基于系统的理解上面 出现的， 我们业务发生时间是 白天，但是系统收集统计信息是在白天。 如果是大量的 insert ， update 呢？？ 统计信息大大的不准确，导致错误的执行计划， 哥遇到的一个， oracle 以为 这个表只有一条数据（其实有5万多条     走了 NL， 结果哥改成hash ， 发现 性能 提升了 100多陪 。  这个有在前面的说过。

 最近也优化了点SQL， 典型的是 开始 规范化了，  写了 基本分页的框架， 这个已经共享出来了。。。

 

具体的 SQL 优化， 看SQL， 看完SQL 看SQL执行计划。 具体问题 具体对待 。知道并行提升效率， 不要动不动 就搞一个并行。hints   会用， 但不要滥用。

今天由于是周五， 明天不上班，看不到 陆续的优化结果了， 也看到项目经理腿抖的，  眼睛是不是的小的咪一下， 就问了一下  这周性能如何？？？  他说

性能不错， 以前 南京地区的流程跑了 7， 8 个小时， 现在一个多小时 出来了。 估计是 1小时不过20分吧，要过了 估计他会说 一个半小时。  

我看了 至少现在没有 说 有超过100分钟的了， 有个76分钟的， 60多分钟的没有  50多分钟的 2， 3 个。 30多分钟 大概  也有 2， 3 个吧，   哥的现在的任务是 搞35分钟以上的。 哥看的 好像超不过 7个， 

对此 哥特意花了 大概1个小时 记录哥的心得， 以后看看的.......