被公司一位开发经理叫过去,说某省移动的法务平台数据库响应缓慢。
看了下有2个症状:
1,出现大量的latch:cache buffers chains等待。
2,CPU占用100%。
而大量latch:cache buffers chains等待的出现,一般有下面3个原因。
1,低效的SQL造成了大量逻辑读(逻辑读主要消耗CPU)。
对于这种情况,可以找出TOP SQL进行优化。
2,存在热块(通过x$bh可以找出是哪些热块被频繁访问)。
对于该情况,可以找出相关的热块所对应的表,看看程序里对应于该表的SQL是否存在问题,如果SQL执行有问题,则需要对SQL进行优化,也可以通过增加pctfree来减少一个block存储的记录数。
3,bug。
取出awr报告,看了看TOP GET SQL,
发现若干条SQL都存在问题,很多可以走索引的查询都走了FTS。
通过对低效的SQL进行优化进行解决。
看了metalink上的对热块的解决方案:
In order to reduce contention for this object the following mechanisms can be put in place:
1) Examine the application to see if the execution of certain DML and SELECT statements
can be reorganized to eliminate contention on the object.
2) Decrease the buffer cache -although this may only help in a small amount of cases.
3) DBWR throughput may have a factor in this as well.
If using multiple DBWR's then increase the number of DBWR's.
4) Increase the PCTFREE for the table storage parameters via ALTER TABLE
or rebuild. This will result in less rows per block.
5) Consider implementing reverse key indexes
(if range scans aren't commonly used against the segment)
有一点不解,减小buffer cache 怎么可以解决热点块的问题呢?