一年多没有来了，换个工作，又一次碰到了oracle这个难啃的骨头。在个人努力了几个工作日无果的情况下，不得不再次来到这个it坛子来，跟大神们求一个解药。

目前状态是这样的，我是某甲方，需要跟踪N个乙方的系统，其中有3个系统部署在同一个oracle服务器上。这个oracle配置应该还不错，32G内存，8盒的两台热备机器。

应该使用的是几分钟一个差异快照的方式，具体我并不是DBA，不清楚。甚至我连登录这台机器的权限都没有，干脆看不了服务器的状态。

---引子(可以略过)-----------------------------------------------------------------

有个比较sb的供应商做了一个这样的设计，各种历史表(目前2个最主要的，数量级均在5千万~1亿之间，按理说并不大)但

1、不加主键(这个可以理解，反正单表查询)，

2、不加索引(这个无法理解)，

3、在tomcat启动的时候，“同步”来一遍group by 加排序第一的数据，写入java的内存

因为2,3两条组合拳，导致每次tomcat启动一次，恨不得要跑半个小时到一个小时。

我当时一万只(**马)跑过，真想废了他们，但闲的无事，做做雷锋，帮他们建立了一个索引，

开始的时候用了并行parallel,有个常用查询10分钟变成30秒，然后给优化了一下历史数据，进行了一下梯度缩减存储，

还没有执行完毕，从5000万搞到3000万左右记录(目标是1000万)，从30秒变成了2秒，我就去领导那里邀功了，

当天效果确实不错。

后来一天，我发现，当我的梯度缩减程序执行过程中，整个oracle不健康了，好多系统的用户来投诉系统慢，

我就终止了自己的程序，并把并行给撤出了，这时其它系统有了好转。但我本来2秒一次的查询又变成10到40秒。

---------引子结束--------------------------------------------------------------------

正题

噩梦算不上，但最近睡得不舒服。

其它几个系统虽然不来投诉了，但另外几个开发商过来投诉说，oracle变慢了。

我不知道是否与我之前的行为有关，虽然我已经终止了那个缩减程序。

我一共做过的事情有如下一些：

1、检查表空间的情况，给原来全部挤在一起的某个系统的两个大表分别移动到两个单独的表空间中，其日志也移动到两个单独的表空间中(建立了4个新的表空间)

但并没有建立分区表空间，毕竟不是我开发的系统。(所有表空间都正常，没有占满的情况，都有自增空间，服务器空间也足够)

2、检查了索引的层次，发现2000万记录，仅2层，我表示不理解，按道理如果btree2层就2000万，单层的宽度要有10000左右，这个数量级检索起来能快吗？(当然不排除我的理解有误，它有隐藏的层级)

但我没有做任何处理，因为重建索引已经没有意义，而且这个索引压根就是我建立的

3、让服务机管理者检查服务器的负载，发现cpu和内存占有都不高，当时也怀疑过，是否oracle有个什么计算单元数量配置的小了？但我确实不懂这块

4、抽查了几个时间段的服务器锁情况。发现某个时间段，有个客户的oracle用户建立了一个锁能锁住它之外用户的其它几个user的执行，但看其语法，就是正常的批插入语句，查看了一下那个表，不过10万条记录

而且并不是更新，就是插入，也就是说，一天也就千条。不见得是这个程序影响的。

我想问一下的是，按照大神们的排查过程，通常应该做一些什么事情，能够让这个服务器找到病症所在，重新活跃起来！！！

另外，这些表都是客户系统的，我无法改造变成读写分离、或者分表的设计，我无法轻易修改源代码，虽然可以看到源代码，但要让他们修改，编译，发布。否则人家就不维护了。

我是否应该直接找个oracle的DBA过来给维护一下？但我听说今年已经找过一次了，最好别给领导添乱了。