今天出现了较大量的latch free争用，通过后面的latch小节可以看到

                                           Pct    Avg   Wait                 Pct

                              Get          Get   Slps   Time       NoWait NoWait

Latch                       Requests      Miss  /Miss    (s)     Requests   Miss

------------------------ -------------- ------ ------ ------ ------------ ------

cache buffers chains        647,517,611    0.1    0.4   5416   20,999,665    1.4

cache buffers lru chain       1,079,718    1.4    0.6    501   19,674,712    7.7

library cache                36,397,178    4.2    0.7  35020      168,674   16.3

library cache load lock           6,312    0.0    1.0      0            0

library cache pin            17,880,285    0.6    0.6   1887            0

library cache pin alloca     12,409,710    0.6    0.7   2024            0

redo allocation               3,037,476    0.2    0.3     62            0

redo copy                            47  100.0    1.0     18    2,618,742    1.0

redo on-disk SCN                639,357    0.0             0            0

redo writing                    778,319    0.0    0.2      0            0

resumable state object               46    0.0             0            0

row cache enqueue latch     266,547,183    5.0    0.0    548            0

row cache objects           273,903,504    6.2    0.1  17014          765    9.8

sequence cache                  188,590    0.0    0.4      0            0

session allocation            4,084,373    0.9    0.6    852            0

session idle bit             30,229,860    0.1    0.5    400            0

session queue latch             913,072    0.0    0.1      0            0

session switching                    59    0.0             0            0

session timer                     1,241    0.0             0            0

shared pool                  23,095,605    4.2    0.2   2018            0

共享池和DB CACHE相关的闩锁都出现了一定的争用。这是CPU出现瓶颈的征兆，IO，内存，CPU都出现瓶颈，这个系统确实有点撑不住了。从Statspack报告来看

Statistic                                      Total     per Second    per Trans

--------------------------------- ------------------ -------------- ------------

CPU used by this session                   2,439,627          678.4         11.7

CPU used when call started                 2,401,482          667.8         11.6

 

每秒消耗的CPU是6784毫秒，而一个8 CPU的系统，最多只能提供8000毫秒的CPU时间，Oracle消耗了接近85%的CPU资源，比昨天又增加了几个百分点。我回了个邮件，让万科他们注意。

写完邮件，FOXMAIL提示我又有一封新邮件，打开邮件一看，原来是Richard的回信：

Jackson,

 

Mingyu did not give me your name so I will call you Jackson.

I would like to know if you have any specific recommendations for the

database at this system. Are there any tables that you recommend should have

additional indexes added, changes to the code to use indexes rather than

full table scans etc.

The oracle reports I have seen so far only speak of the requirement for

changes/improvements not how these should be done.

Thanks for the comments. I agree with you on the server performance issues. It is not a simple problem to resolve. 

Best regards

Richard

 

看样子洋哥们也发现了全表扫描的问题，通过前一阵子的优化，我已经解决了绝大多数全表扫描的问题，不过仍有一定数量的全表扫描无法避免，因为这个系统是一个c/s/s结构的系统，很多SQL都是根据客户端选择的条件动态生成的，为了确保一些主要的SQL能够通过索引完成，所以在很多模块中都使用了HINT。由于SQL是动态生成的，所以不可避免的会出现对于某些情况，HINT会导致更坏的执行计划。比如说客户端选择了一些过虑条件，生成出的SQL原本使用另外一个索引效率比较高，但是由于SQL中使用了强制HINT,这样就会导致这个SQL会使用错误的索引，反而增大了开销。这种由于程序缺陷导致使用错误的执行计划的情况十分普遍，由于这些情况属于非常用功能，因此虽然有些客户投诉性能问题，开发商也没有给予理会。由于应用架构的问题，开发商想要解决这个问题也十分困难，我曾经建议过他们取消HINT，但是开发商怕取消了HINT会导致常用模块性能下降而一直不敢按照我的建议去修改应用。

快下班的时候，万科打电话过来了，他看到我的邮件后有些着急，从今天的情况来看系统的压力稍微大一些，CPU就有点悬，今天他们观察到的业务最忙的时段，CPU经常冲到100%，r队列也达到了20以上。虽然CPU还没有真正出现瓶颈，但是看上去挺悬的。万科问我这几天能不能再做些优化，缓解一下CPU资源。

我告诉万科，我和明喻他们前后一阶段的合同已经结束，老外进场后，新的合同看样子明喻是不会和我签了。目前我真没办法出面做处理，一旦做好了，功劳算老外的，做不好我的责任就大了。

万科听我这么一说就有点着急，今天和Richard开完会后，万科就觉得有点不靠谱，搭测试环境，模拟生产环境，等试验做完，不知道猴年马月了，还不知道能不能找到解决方案呢。于是万科希望我在关键的时候能够帮下忙。

我说关键时刻我可以出手，但是必须让明喻找我，否则我师出无名。万科想了想，我说的也在理，只好遗憾的挂了电话。