今天系统反应较慢，出现了大量的read by other session事件，查看该sql语句并没有优化方案。可以采取的就是改写sql语句了（其中后续采取的也就是修改sql语句的功能）。不过个人比较关心的是这个read by other session为什么会大量出现在file 2上。

相比以前做awr报告，其实如果系统某段时间反应较慢，做ash报告也是一个很不错的选择，ash的报告相对于小范围时间内的采样更加清晰明确，从ash报告的top事件里面，发觉都在file 2一个回滚段上。

Read by other session等待事件主要集中在了file 2上，也就是回滚表空间的回滚段上，这个信息查看了undo表空间的大小和使用程度，发现已经数据文件使用率达到了98%，由于使用的默认的单个数据文件而且设置的自动扩展无限制，数据文件已经达到了30g。

对于回滚段的使用比较集中，也就会出现两个会话同时读取数据从disk到buffer时出现的，该等待事件在10g中单独列出，看来是由于session读取数据时把数据并发的读取导致，也算作一个热点快事件。（热点块不一定是普通的block，也有可能是undo造成的）

如果调整上肯定优先采用对sql语句进行调整，减小逻辑读，也就减小了数据读取的竞争了，加大buffer cache大小、减小磁盘读取的概率，因为内存的读取比磁盘快很多，相应的竞争也就会减少很多。

下面介绍一下经常用的查询热点块的sql语句：

SELECT E.OWNER, E.SEGMENT_NAME, E.SEGMENT_TYPE

FROM DBA_EXTENTS E,

(SELECT *

FROM (SELECT ADDR, TS#, FILE#, DBARFIL, DBABLK, TCH

FROM X$BH

ORDER BY TCH DESC)

WHERE ROWNUM < 11) B

WHERE E.RELATIVE_FNO = B.DBARFIL

AND E.BLOCK_ID <= B.DBABLK

AND E.BLOCK_ID + E.BLOCKS > B.DBABLK;

再通过v$sqltext等视图联合segment_name来获取热点块的sql语句，看是否对其进行适量的调整和修改。

还是回到上述问题file 2竞争压力大，新建了undo表空间，分散了多个数据文件，让其减少同一时间使用同一undo段的概率，不过仔细想想这个很可能只能轻微的减小压力，甚至可以说微乎其微，不过还是建议分开多个数据文件和磁盘来减小IO冲突。

这个案例其实说到底我们应该通过sql语句来修改，对于一些IO消耗比较大的sql语句进行程序上面的修改，让其减少读取undo段的概率，也就是最大的程度的减少了file 2的read by other session的竞争。

调整了代码和重新设置了sga参数，启动的时候一段时间内出现了Buffer exterminate事件，

该事件是由于在asmm下sga的动态自动调整导致的，该事件描述的是会话在读取已经收缩的sga中的buffer导致，该事件出现时很有可能是因为shared pool突然使用概率增加了，通常随之出现的是一系列的硬解析，想想后续重新启动了数据库和调整了代码，硬解析增加了shared pool使用需求增加。

如果该等待事件确定为引起了性能的平静，那么可以采取解决方案是：禁用asmm功能，或者设置buffer cache的最小值防止过度收缩。不过该等待事件一般不会出现较长的时间。

[@more@]