1.1.1. 6月8日 ITL等待引发的RAC性能问题
从这几天的情况来看，虽然说系统性能还很不错，不过我从IO和CPU的性能趋势上，已经感觉到了不妙。我习惯于每天把STATSPACK报告中的关键数据采集到一个EXECL表格里，定期生成一个折线图来查看趋势。这几天我明显看到折线的斜率在持续增加，以我的经验，这是很不好的先兆。今天早上和老万在QQ上聊了几句，和他说了我的担心。老万随后又咨询了一下Richard，Richard认为目前IO上升只是因为这几天的系统负载在不断增长，IO系统经过前一段时间的优化已经有了数倍的提升，肯定可以确保不会成为瓶颈。
看样子老万也是被最近良好的系统状态迷住了眼睛，对我的判断也开始将信将疑了。在这种情况下我也不好多说什么，反正主动权也不在我手里，就由着Richard折腾吧，如果折腾好了，那大家都消停了，如果出问题了，我再出面吧。
老万和我聊了几句就出去开会了，我正准备离开，突然小吴给我的MSN发来一个消息：
老白：帮下忙，我这里出大问题了。一套3节点的RAC系统，最近这几天总是会莫名其妙的变慢甚至HANG住，有时候几分钟，有时候10多分钟。重启应用后也不能解决问题，过一段时间又出问题了。
今天关了一个节点，只剩下两个节点，系统反而稳定了，一上午都没有出现HANG主的现象，不过本来三个节点的业务压在两个节点上，两个节点的的CPU都快100%了，内存也有点不够用。用户很着急，想尽快找到问题的原因，尽快解决了，然后把第三个节点也用起来。
我马上看了看他发过来的AWR报告：
Instance Efficiency Percentages (Target 100%)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Buffer Nowait %: 99.57 Redo NoWait %: 99.99
Buffer Hit %: 98.06 In-memory Sort %: 100.00
Library Hit %: 99.81 Soft Parse %: 99.73
Execute to Parse %: 21.28 Latch Hit %: 99.86
Parse CPU to Parse Elapsd %: 57.16 % Non-Parse CPU: 97.01。
从命中率上看，各项指标都还算正常，BUFFER NOWAIT的比例略微偏低一些。TOP 5 EVENTS是：
Top 5 Timed Events
~~~~~~~~~~~~~~~~~~ % Total
Event Waits Time (s) Ela Time
-------------------------------------------- ------------ ----------- --------
enqueue 1,872,325 85,528 39.87
buffer busy global cache 218,188 34,053 15.88
db file sequential read 1,366,797 20,368 9.50
log file sync 499,127 20,099 9.37
buffer busy waits 216,884 9,241 8.97
从TOP 5 EVENTS上来看，ENQUEUE等待占近40%，buffer busy global cache等待占15.88%，这是典型的全局热块冲突现象。看样子解决热块冲突是最终解决问题的关键。我看了一下热块冲突相关的等待情况：
|
Class
|
Waits
|
Total Wait Time (s)
|
Avg Time (ms)
|
|
data block
|
108,5360
|
10200
|
9
|
|
1st level bmb
|
7930
|
10
|
1
|
|
undo header
|
2820
|
0
|
0
|
|
2nd level bmb
|
560
|
0
|
0
|
|
segment header
|
520
|
0
|
0
|
|
undo block
|
3
|
0
|
0
|
看样子热块冲突主要集中在数据块上，看样子又免不了要调整表的存储结构。我又往下看了看锁等待情况的分析：
Avg Wt Wait
Eq Requests Succ Gets Failed Gets Waits Time (ms) Time (s)
-- ------------ ------------ ----------- ----------- ------------- ------------
TX 568,022 568,098 5 81,688 1,031.33 84,247
US 1,170,363 1,170,362 0 806,425 1.12 901
SQ 247 247 0 25 11,396.24 285
CF 6,252 6,249 3 190 256.92 49
HW 2,787 2,787 0 1,162 2.10 2
从锁等待的情况来看，主要的等待还是TX锁，从这里也可以为我刚才的热块冲突导致问题提供一个旁证。锁等待过高的原因不是因为Oracle内部锁，而是因为TX事务锁导致。小吴他们在故障发生的时候还走了HANGANALYZE和SYSTEMSTATE DUMP。从HANGANALYZE上我们看不到任何异常的地方，把SYSTEMSTATE DUMP用ass.awk分析后也没有发现很明显的问题。主要的等待是TX和BUFFER BUSY GLOBAL CR和BUFFER BUSY WAIT。
我问小吴故障出现时有没有检查过V$LOCK，小吴说当时都看了，主要都是TX锁。我问小吴当时有没有留意TX锁的LMODE是多少，小吴马上翻看了一下日志，说大多数是6，不过也有不少是4。LMODE=4是共享模式，LMODE=6是排他模式。如果存在大量的LMODE=4的锁请求，那说明可能ITL存在等待现象，因为LMODE为4一般来说可能是ITL等待或者等待索引页节点分裂。于是我让小吴检查一下ITL等待的情况：
set line 132
col statistic_name format a30 trunc
SELECT T.OWNER, T.OBJECT_NAME, T.OBJECT_TYPE, STATISTIC_NAME, T.VALUE value
FROM v$segment_statistics T
WHERE t.STATISTIC_NAME = 'ITL waits'
AND t.VALUE > 0 order by value;
这个查询排在前几位的对象都是我们需要关注的。从查询的结果来看，排在前面的10几张表和索引都有大量的ITL等待。于是小吴检查了一下这几张表，发现这些表的存储参数中initrans都是2，pctfree都是缺省的10。看样子问题很明显了，initrans是导致问题的元凶。我建议他们把这些表和索引的inittans加大为10，并且最好把相关的表和索引都重建一下。小吴说其中有几张表基本上只做insert ，不会做UPDATE和DELETE操作，是不是只需要修改参数，不需要重建了，那几张表都是分区表，最小的也有7、8个G。
我想了想，INITRANS参数修改后，新的数据块中这个参数就会起作用，而老的数据块不会生效，所以需要对表进行重组才能彻底解决问题。而像小吴说的那种情况，老的数据块很少会做DML操作，表不重组问题也不大。不过索引还是需要REBUILD的，否则索引上的ITL争用也可能会导致问题。
小吴马上修改了这些表和索引的参数。索引重建和部分表的重组工作只能等晚上停了应用再做了。和小吴分析了半天才发现已经是下午的3点多钟了，午饭还没吃，不过一点饥饿的感觉都没有，看样子也没必要去吃午餐，只能晚上多吃点了。这样的生活习惯，人不胖才怪呢。
1.1.2. 6月9日 ORA-8104
昨天和小吴处理了一个RAC的性能故障，昨晚上小吴他们重建了部分表和索引，上午10点多钟小吴给我打了电话，他说今天3个节点都开了，从上午的ASH和AWR报告情况来看，BUFFER BUSY GLOBAL CR和ENQUEUE等待得到了很大的改善，现在排在TOP 5 EVENTS第一位的是CPU TIME了。
小吴看到今天系统的状态，觉得RAC优化方面需要考虑的问题太多了。小小的ITL居然会引起如此严重的问题。确实是，在单机环境下，这些等待往往只是导致系统变慢而已，但是在RAC环境下，如果这些等待严重了，后果要严重的多。在RAC环境下，除了INITRANS外，FREELISTS ，FREELIST GROUPS，PCTFREE等参数都是需要关注的，如果设置不合理，都可能导致严重的性能问题。
今天没什么事，和小吴聊了会天，随便在楼下吃了点午饭，想想下午也没什么事了，就跑到旁边的游泳池游了会泳。由于是下午，泳池里没几个人，水也挺干净，不过少了养眼的漂亮妹妹，游起来也觉得比较枯燥。刚游了两个来回就觉得有点困了，于是在躺椅上眯了一会。醒来一看，已经是下午4点多钟了，急忙换好衣服，一边拿着棉签抠着耳朵，一边拿出手机看了看了一下，发现有10个未接电话。
我还没来得及查看哪来的电话，又有一个电话打了进来。电话是小吴打来的，他们上午的时候发现了一个索引的ITL等待十分严重，于是趁着中午业务比较少，对这个索引做了一个在线重建（REBUILD ONLINE），两点多钟的时候，他们发现业务有点慢，怕是这个索引重建引起的，于是就杀掉了做REBUILD索引的进程。没想到杀掉进程后麻烦就大了，有一个业务不停的报ORA-8106，他们判断这个报错可能和中断的REBUILD ONLINE有关，于是想再次重建这个索引，可是一做REBUILD ONLINE，就报ORA-8104错误，这个索引无法REBUILD了，而且想删除掉后重建也不行了。这个错误已经持续了快3个小时了，目前他们让前台暂时手工处理那个业务，等修复后补录数据。
ORA-8104是一个十分常见的错误，总有一些心急的DBA半路杀掉正在做REBUILD ONLINE的会话，而每次杀掉REBUILD ONLINE的会话，都会经历一个噩梦。由于在做索引在线重建的时候，可能相关的表还在变化，Oracle需要记录这个索引的相关变化，因此Oracle会创建一张临时表来记录这些变化，等索引重建完成后再删除这张临时表，这张临时表的名字为SYS_JOURNAL_<INDEX的OBJECT_ID>。REBUILD ONLINE刚刚开始的时候就会去创建这张日志表，但是如果创建日志表的时候，发现这张表已经存在了，就可能会报ORA-8104，并无法继续做REBUILD ONLIE（普通的REBUILD会检查索引的FLAG标志和这张表，如果冲突，也会失败）。如果REBUILD ONLINE被中途杀掉了，那么这张表和IND$中的FLAGS不会被自动清除，必须由SMON来清除。而SMON每个小时会进行一次类似的清除工作，SMON做清除前首先要锁住日志表，如果这个索引相关的表还在变化，那么SMON可能无法锁住这张表，如果SMON锁表失败，就会放弃这次清理工作，等一个小时后再来清理。这样一来，在业务较为繁忙的生产系统上，可能SMON永远都没有机会清除这张日志表。我就曾经碰到一个客户，这个错误持续了3、4天才恢复。
在ORACLE 10G中，Oracle提供了一个存储过程来代替SMON做手工清除（DBMS_REPAIR.ONLINE_INDEX_CLEAN），只要不停的重复执行这个存储过程，就可能清除失败的索引。不过如果是9i的数据库就很麻烦了。去年我曾经碰到一个客户，他们也是做了核小吴他们类似的操作，导致系统出现故障，没办法重启了数据库都没有解决问题。后来我建议他们手工清除了日志表，并且修改了索引的FLAGS。手工解决这个问题分为两个步骤：
1、手工删除日志表：
Permalink
DBA日记 第二部 (42) 优化实施
Posted on 九月 16, 2009 by 白鳝
1.1.1. 6月19日 实施优化
早上9点多钟我被一阵电话铃声惊醒，一想到昨天晚上做的工作，我感觉不太妙。昨天晚上10点开始，我们对系统进行了一些调整，主要是把几张碎片较为严重的表做了重建，然后REBUILD了部分索引。
昨天的优化包含几个部分，第一部分是参数的调整，把SHARED_POOL_SIZE从3G加大到了4G，同时把SESSION_CACHED_CURSORS从100加大到150，这部分工作在昨天下班前就做完了，我首先把spfile做了一个备份，然后用alter system命令直接修改了SPFILE的内容，只要数据库重启一下这些参数就可以生效了。
第二部分工作是把一些常用的PL/SQL对象KEEP到共享池里，这些对象包括一些系统的包和一些开发商开发的包，还有几个触发器。这些PL/SQL对象执行的频率十分高，但是也经常有RELOAD现象出现。KEEP的脚本我事先写好了，并且放在了服务器上，只要数据库重启后执行一下就可以了。KEEP部分SQL的工作比较麻烦，需要找到HASH VALUE和ADDRESS，因此需要第二天业务跑一段时间后再做，我已经把查找ADDRESS的脚本写好，只要跑一下就可以生成出DBMS_SHARED_POOL.KEEP的脚本出来。
第三部分工作是整理存在碎片的表，由于只有4、5张1、200M的表，所以这部分工作也比较简单，我们准备直接使用move来处理，不过为了安全起见，我们在做MOVE之前先通过exp对这几张表进行了备份。备份完成后，直接执行aleter table <owner.table> move;然后rebuild一下这张表的索引，然后重新分析一下表和索引。
第四部分工作是REBUILD一下索引，事先我已经把REBUILD索引的脚本都编写好了。实施的步骤是首先加大PGA_AGGREGATE_TARGET为4G，然后执行脚本REBUILD索引，最后对这些索引进行重新分析，最后把PGA_AGGREGATE_TARGET修改回原来的值。加大PGA_AGGREGATE_TARGET可以提高排序的性能，这对于提高索引重建的速度有较大的帮助。
这些操作都是十分常规的优化操作，所以我们也没有做特殊的准备。晚上10点钟开始停应用，10点半的时候开发商告诉我应用已经全部停了，首先关闭了listener，然后检查了一下操作系统中是否还有前台进程，通过ps -ef|grep "LOCAL=NO"发现还有10多个前台进程没有正常退出，于是我用
ps -ef|grep "LOCAL=NO" |awk '{ print "kill -9 " $2}'|sh
清理掉了所有的前台进程，然后开始了今天的工作。由于今天整理的表都比较小，最大的一张表也不过200M左右，所以今天我们只是在整理前通过exp工具将要整理的表都导出，然后直接采用ALTER TABLE ... MOVE进行整理，而没有采用以前常用的先RENAME然后再创建新表，插入数据的做法。MOVE表，重建索引，分析表和索引，整个工作不到一个小时就完成了。
REBUID索引比较耗时，在近100G的WORKORDER表上有7个索引，REBUILD这张表上的索引就花了1个多小时，还好我们有5个小时的停机时间。不过总的来说一切都比较顺利，2点半我就收工了。由于我是通过VPN连上去的，所以所有的操作都是由现场的小马实施，我只是通过MSN和小马进行协调和沟通。
今天早上不到9点钟，小马就又回到公司了，老万手下只有这么一个DBA，他也够辛苦的了。小马一上班就发现系统的活跃会话数量不太正常，平时一般来说9点左右的时候活跃会话数在100-120之间，今天早上活跃会话数量在150左右。他马上检查了一下cpu的使用情况，发现CPU使用率明显高于昨天，平均值居然达到了85%，甚至有时还出现了IDLE为0的现象。
我听小马一说，就感觉到可能是昨天的优化操作出问题了，于是我马上打开电脑通过VPN连了过去。使用glance一看，确实是CPU的使用率明显比昨天高了不少，通过OEM的健康性图表观察，发现BUFFER GET的数量也比昨天多了很多，从OEM的平均事务响应时间图表来看，平均事务响应时间变化不大，在1.4秒左右波动，比昨天还是略高。不过从健康性图表上看到，主要的等待事件和昨天差不多，主要是db file sequential read，在TOP等待事件里，并没有出现共享池相关的等待事件，通过闩锁图表来看，共享池的相关闩锁还算正常，争用比昨天小。看到这里我感觉一块石头落了地，只要不是共享池的调整出现了负面影响，那么基本上可以确定是某些SQL的执行计划发生了变化，因为我们昨天做的操作也只会影响到这两个方面。
于是我马上做了一个6级的STATSPACK采样，并且和9点的SNAP生成了一份报告。从报告上看，排在BUFFER GET前几位的SQL里出现了几条陌生的语句，这几条语句以前都没有出现在BUFFER GET相关的TOP SQL里的。看样子就是这几条语句出了问题。我看了一下，在10分钟里，这几条语句分别执行了几十次到几百次不等，每次执行的BUFFER GET的数量在10万到60万之间，还有一条执行了30多次的SQL，每次执行的BUFFER GET的数量达到220万。
看样子昨天为了节省时间，只重新分析了处理过的相关表和索引，而并没有对所有的表重新做一次分析，这导致了部分SQL的执行计划改变。于是我马上又做了一个6级的STATSPACK采样，然后把这几条SQL的SQL报告生成来了。
打开一个SQL报告正准备认真分析分析，老万的电话打了进来。我感觉老万很紧张：“老白，好像出问题了，昨天的优化非但没有见到好的效果，反而情况更恶化了”。
我告诉老万，昨天晚上只分析了相关的表，导致了部分执行计划发生了改变，这个问题不大，我分析一下，然后把相关的表重新分析一下就应该没问题了。今天晚上争取再把系统中其他的表都分析一下，昨晚已经把系统中最大的3张表都重新分析过了，剩下的表估计5、6个小时就能全分析了。
“老白，那你快想想办法，尽快解决这个问题，10点钟系统负载就高了，别顶不住了”，老万还想继续罗素，被我打断了：“万科，我正在分析呢，你就别添乱了，10点前肯定搞定它”。
放下老万的电话，我继续分析SQL报告。发现这几条SQL都有一个特点，都是通过NESTED LOOP连接，而且这些SQL都和WORKORDER,FEEDBACK相关，连接的表中大多数包含了2、3张小表。于是我检查了这几张和这些SQL相关的小表，发现这些小表的统计数据都是3个月前的，从dba_tables来看，这几张表都只有10来条记录，是十分小的表。这些表走NESTED LOOP也很正常。难道是这些表的数据发生了变化。于是我对这几张表做了一个SELECT COUNT(*)。这么一查，就发现了问题了，这几张表的数据和DBA_TABLES里的统计数据有了较大的差异，一张以前分析的时候只有12条记录的表，现在居然有100多条记录了。看样子这就是导致执行计划发生变化的原因了。
于是我马上对这几张小表做了一个分析，分析操作刚完成，我就发现平均事务响应时间的曲线突然下降了。曲线波动的中心点从1.4秒下降为1秒了。我马上用vmstat检查了一下CPU的使用情况，发现CPU的使用率明显下降了，平均使用率在60%左右，看样子问题已经解决了。
中午的时候，我分析了一下10点到11点的STATSPACK报告，发现TOP SQL中的几个SQL的平均每次执行的BUFFER GET数量均有少量的下降，这是昨天晚上优化的效果，共享池方面的改善不是很明显。平均每秒的CPU开销也略有下降，大约在1017厘秒左右，昨天的优化目的已经基本达成。
下午我在STATSPACK报告里又发现了一个存在异常的SQL，检查了一下发现还有一张参照表存在类似的问题，对这张表做了分析后，这个SQL就从TOP SQL中消失了。下午3点到4点这段时间，CPU使用率一直保持在70%左右，从STATSPACK报告上看，CPU used by this session的值为1065。我给老万打了个电话，告诉他优化效果不错，CPU使用率下降了5%，老万听了也很高兴。
晚上的时候，我收到了老万的一个邮件，对我表示感谢。邮件的最后，老万希望我能够再拿出点压箱底的东西来，再做几次优化，这样他心里也能踏实点。我给他回复说，优化是整体工程，象昨天这种单方面的优化效果不会特别好。经过前一段时间的优化，目的已经基本达成，没必要再画蛇添足了。如果要优化，明年我们做个大的，通过对底层应用的优化，一劳永逸的解决这个系统的问题。
回了邮件没过多久，就收到了老万的回复。回复很简单，只有一句话：“收到，经费问题我想办法”。
Permalink
DBA日记 第二部 (41) 按下了葫芦浮起了瓢
Posted on 九月 15, 2009 by 白鳝
1.1.1. 6月18日 按下葫芦浮起了瓢
昨天系统运行很正常，IO明显好转，CPU使用率虽然也有所上升，不过一直在60-70%之间波动，偶尔突破80%，不过最高的时候也没有超过85%。昨天老万和我还特意冒充业务人员在QQ群里说今天系统用的真爽，此话一出应者云集，大家都对系统的情况表示满意。不过也不乏忧患意识比较强的人，他们担心这又是昙花一现。在QQ群里愉快的聊了聊天，我和老万又在网上聊了一会。老万问我今年的业务高峰这个系统应该没问题了吧。我说应该差不多了，目前系统已经日处理单量接近15万单了，业务部门预计今年的最高日单量也不过15万，这个系统应付每天15万单还是绰绰有余的。老万最后问我，如果系统出问题，那会出在什么地方，我想了想说，如果出问题，也许应该是在CPU上吧，如果真的每天的单量超过20万的话。
今天早上起得很早，7点多就睡不着了，起床后一边打开电视，一边打开电脑收邮件。小马把昨天的Statspack报告发过来了，顺便还留了一句留言：“昨天截止晚上18点的单量居然突破性的达到了17万单，这是这个系统有史以来处理的最高日单量，系统状态良好，平均事务响应时间为1.13秒。”
看到这个信息，我下意识的感到有点什么不对劲，昨天的最高单量居然超过了17万单，这已经远远超出了业务部门评估的最高日单量。我连忙打开下午3点到4点的STATSPACK报告，看了看CPU used by this session，这份报告里这个指标的值是1184，也就是说平均每秒钟的CPU消耗达到11.84秒，对于一个16 CPU的系统来说，意味着在3点到4点期间的平均CPU使用率为75%，这是最近这段时间以来最高的。
昨天我还和老万聊到CPU可能会是下一个出问题的地方，而老万还对于20万的单量表示怀疑，昨天老万还颇具调侃意味的说：“如果真能达到每天20万单，那今年我们的奖金就大大的有了”。从昨天超过17万单的数字来看，这20万单也确实不是不可能的事情。我急忙通过VPN拨到系统上，查了一下昨天截止到临晨12点的总单量，统计结果让我大吃一惊，昨天处理的总工单量居然达到了不可思议的18万2千多单。
吃过早饭后，我又登上系统看了看，往常8点半开始业务逐渐增多，到10点钟达到高峰，11点后业务量开始回落，直到下午2点开始回升，到下午3、4点钟达到一天中的最高峰。6点后，业务量开始减少。今天早上8点半的时候，系统的CPU就已经达到了60%，比前几天高出不少，看样子今天系统的负载也会很高。
我给老万打了个电话，老万也正在看着昨天的统计数据发呆，我打电话过去的时候，他刚刚和业务部门的人通过电话，业务部门说今年天热的早，而且华北、西北、华中、东北地区持续高温的天数比往年长20天左右，因此造成了今年空调、冰箱、风扇和热水器销售的井喷，生产那边也在拼命加班，所以今年的工单量到底增长多少，现在还在测算中，不过据现在保守估计，高峰时突破20万工单已经不是悬念了。
对于20万工单这个新的情况，我和老万都感到了压力，以目前系统的情况来看，CPU还真有点悬。老万问我有没有什么简单的办法，能够减少CPU的使用率。我想了想，要想减少CPU的使用率，最好还是修改应用，不过在目前的情况下，想简单的调整一下来实现这个目标，唯一可行的就是整理一些常用的中等规模表的碎片，重建索引，添加几个索引，改善一些常用SQL的性能。和老万商量好后，我们决定今天晚上申请4个小时的停机时间，把几张一直想整理的碎片较多的表整理一下，并且重建WORKORDER和FEEDBACK表等几张和工单相关的大表的索引。鉴于目前IO系统状况较好，因此我建议如果CPU确实比较危险了，那么可以把部分KEEP POOL中的索引和表放回DEFAULT POOL，甚至可以减少一些DB CACHE的大小，从而以增加IO开销来平衡CPU负载。不过现在还没有危机到这一步，暂时可以作为一个备选预案保留。
今天上午业务高峰期的CPU平均使用率已经达到了70%以上，偶尔也有CPU超过90%的情况出现。中午12点多的时候统计了一下工单量，居然已经接近8万，看样子今天全天突破18万是肯定的了。
我下午又分析了一下，发现共享池的争用也很厉害，SHARED POOL和LIBRARY CACHE的相关闩锁争用较为严重，闩锁争用导致的等待占总等待的6.5%，闩锁争用会导致不必要的CPU资源消耗，看样子优化一下共享池也可以减轻一些CPU的负担。于是我马上又做了一个调整共享池的方案，共享池从3G加大到4G，并且把部分常用的PL/SQL对象和SQL语句通过dbms_shared_pool.keep PIN到共享池中。由于这个操作需要重启数据库，因此我和老万商量了一下，把停机时间从4个小时增加到5个小时。
下午CPU使用率一度高达80%左右，不过从系统的各项指标来看，都很正常，平均事务响应时间也保持在1.2秒左右，下午3点到4点的平均每秒事务数量超过了70，这也是这段时间以来的一个高峰。下午的时候老万又给我打了个电话，他对CPU的情况十分担忧，我只能安慰他，从目前来看，日工单量已经超过了18万，按往年的惯例，7、8月份业务最高峰的时候，顶多比现在高20%左右，而目前CPU资源还有20%多的空闲，增加15-20%的业务量，虽然会出现一些轻微的瓶颈，平均事务响应时间可能会有所下降，不过估计也能保持在2-3秒之间。通过我们今晚的一些优化，估计可以减少5%的CPU使用率，这样就为渡过业务高峰奠定了基础。等10月份高峰过了，我们再考虑启动一个全面优化的项目，在明年业务高峰到来前，这个系统的问题就可以彻底解决了。
听了我的分析，老万悬着的心放下了不少，不过他对今天晚上的优化又多了一丝期望，他问我今晚还能做点什么，他可以申请的最大停机窗口是8小时，如果能做，就尽可能多做一些，随着业务高峰的来临，今后要想申请停机也会越来越困难。我想了想，目前能做的事情也就这么多了，这种关键的生产系统，只有最有把握的操作才敢去做，否则做出问题来就麻烦了。
快下班的时候，我把优化实施方案发给了老万他们，临下班的时候，小马通过MSN向我建议说，既然共享池有争用，是不是可以设置CURSOR_SPACE_FOR_TIME为TRUE，这样可以减少SQL分析。我告诉小马，这个参数虽然可以减少软分析，不过这个参数会导致某个会话在退出前，使用过的CURSOR被PIN在共享池里，时间长了会导致共享池出现严重的碎片。因此现在一般情况下都会通过SESSION_CACHED_CURSORS，而尽可能不要使用CURSOR_SPACE_FOR_TIME。我们的系统是三层结构的，WEBLOGIC通过连接池访问数据库，在连接池的设置上，MIN和MAX设置是一样的，也就是说我们采用了长连接的方式，几乎所有的连接是不会断开的。一旦我们使用了CURSOR_SPACE_FOR_TIME，那么共享池可能会出现严重的碎片化情况，严重的情况会导致宕机。
小马听了我介绍了这个参数，恍然大悟的说“我刚才在网上GOOGLE到一篇介绍减少共享池争用的文章，里面就介绍了通过设置这个参数来优化共享池，没想到还有这种副作用。看样子今后看GOOGLE的东西还是要慎重”。
Permalink