话说还在乙方混的时候，接到上级指示，给一个报表系统做性能调整，这个报表系统会每天从业务系统里面接受数据，聚合整理以后给报表提供数据。业务系统会在每天的8点把原始数据推送过来，我们的系统一般在晚上10点左右开工，要求在早上8点以前把数据整理好，保证用户早上8点以后就能查阅报表。
系统刚上线的时候，由于数据量小，运行的还比较正常，一般2-3个小时就能运行结束了，但是系统使用了几个月，数据慢慢变多了以后，性能问题就出现了，数据抽取过程的时间越来越长，客户也是非常的好说话，他们看报表的时间也从早上的8点推迟到中午，然后推迟到下午，知道最后推迟到下班的时候看。直到到了下班的时候都看不到，并且和第二天的业务系统数据推送冲突了，造成了数据冲突，因此要求我们公司来处理性能问题。
接到任务后，立刻开展工作，先说下最后的成果，经过一系列的调整，整个数据抽取过程从原先的二十多个小时，缩减到一个小时以内，效果还是蛮显著的，下面会分别讲讲整个过程中，我所使用的三板斧：
首先看下现行的系统，整个数据抽取是用存储过程实现的，业务逻辑也非常的简单，基本就是把原始数据按照业务发生时间做周-》月-》季度-》年的分层聚合，然后和多维数据集连接，获取结果后扔到最后的报表层所需要的表里面去，整个逻辑还是很简单的。唯一需要注意的是，业务表中提交过来的数据是有可能变化的，因此需要把现有的记录清除掉，然后重新抽取。
所以大多数的语句类似于
delete from ta where week='xxx';
insert into ta select * from tranTa where week='xxx';
我看了下数据库结构，所有的表都采用了传统的堆表。 有经验的兄弟看到这边大概就知道猜到我第一步要做什么了。
对，就是分区表，这样的一个系统，每次应用的时候几乎对某个时间周期内的数据做聚合，因此用索引效果是不明显的，采用时间分区表，有效的限制了FTS的范围，对这个环境而言可能是最最合适的了，
考虑清楚以后，立刻动手，把所有的相关表改成以周为单位的时间分区表，语句也可以修改成
Alter table ta truncate partition wk_xxx;
insert into ta select * from tranTa where week='xxx';
用truncate代替delete，也能有效的节省很多时间，且所有的数据在周分区里面，为后面的数据抽取打下了很好的基础，所有的全表扫描变成了分区扫描，性能提升不少。
这个过程中还有一个小插曲，由于之前的项目不是一个开发做的，有的开发对游标的使用情由独钟，居然在这种类似于数据仓库
系统的环境下使用游标做类似于ETL工具里面的router操作。
整个脚本类似于
declare cursor as select * from 原始大表 where week=xxx
循环
判断目标表中是否存在同id记录
存在就 用原始表update目标表，
不存在就 insert
循环结束
这个操作是一个经典的模拟router的操作，实现的脚本也没问题了，但是router的使用是有着非常特定的场景的，放在现在这样的一个类似于数据仓库的环境里面，就显得非常的不动脑子，很教条了，
全部被我粗暴的换成了之前描述的
alter table ta truncate partition wk_xxx;
insert into ta select * from 原始大表 where week=xxx；
这样一来，时间又缩短了不少。
然后继续看看数据库的配置，这样一个充斥这中间数据，全是大数据装载的环境，居然是开启了归档和全部做了logging的，
考虑到所有的数据其实都是从业务系统里面抽取的，数据丢失以后完全可以从业务系统重新获取。
在和甲方的DBA进行了充分的沟通后，请甲方的DBA帮忙把归档关闭，所有的表空间全部搞成了nologging,同时我把所有的表也改成了nologging,这样有效的节省了不必要的IO.
做个分层聚合的兄弟可能有过经验，那就是聚合后的数据的排序其实还是非常有规律性的。
Oracle11g里面的压缩表技术也比较的成熟了，分区表技术通过压缩技术减少空间的占用，可以大大的提升查询的性能。
正好个系统的数据库是11g的，经过测试以后，我把其中的几张超大的表，转换成了压缩表。 压缩率还是非常给力的。
这几张上百G的表，压缩以后都变成了30-40G左右，对这些标的分区扫描的时间也大大地缩短。性能得到了很大的提升。
经过上面几板斧下来，性能已经得到很大的提升，而且不用担心历史数据的影响了，时间也缩短到了3个小时左右，已经满足客户的预期了，不过我最后一板斧砍下去以后，时间从3个小时缩短到了一个小时以内，效果好的我自己的都受不了。
这个斧头其实也不神秘，很多兄弟都会用的，只是我的那台服务器的CPU太强劲了，是64核的，说到这，有兄弟已经猜到要干什么了
对，就是DBA常用的必杀技，开并发。不过这个必杀技还是要看场合的，一般并发量大，用户多，操作小的oltp场景用几乎没什么效果，有时候还有副作用。
但是在现在这个场景里，低并发（大多数情况下就一个连接），大数据量，爆强CPU，开并发实在是太合适了，不开真的是对不起自己，对不起公司，对不起客户，对不起党和国家。。。
查看了一下数据库参数，已经支持并发了，下面我要做的就是在语句前面加hint,显示的要求并发操作。 这个hin
t一加，世界瞬间就和平了，真个过程在1个小时内就收工了，以至于客户经常怀疑我们的过程是不
是没跑。
上面几板斧抡下来，基本就打完收工了，此次调优也获得了圆满成功。