“read by other session”等待事件引发的数据库性能问题

今天上午接到某客户电话，说他们的生产库从8:00开始，监控就报CPU资源使用率非常高，最高可达99%，虽然业务还没有挂，但是数据库非常慢，性能出现问题。客户的库是10g单实例，我远程给客户做了AWR报告，下面来具体分析：

首先，DB Time非常高，是平时正常情况的好几倍时间，从这一点上就能判断确实存在一定的性能问题

再看top 5等待时间，排在第一位的就是“read by other session”，占据了总DB Time的36.1%，这个等待事件说明了什么？

来看一下官方的定义:

read by other session Definition: 

When information is requested from the database, Oracle will first read the data from disk into the database buffer cache. If two or more sessions request the same information, the first session will read the data into the buffer cache while other sessions wait.  

当对数据库进行数据查询请求时，Oracle首先会从磁盘读取数据到db buffer cache中，如果第2或者更多的会话请求相同的信息，那么当第1个会话读取数据的时候，其他会话只能够等待。

In previous versions this wait was classified under the “buffer busy waits” event.  However, in Oracle 10.1 and higher this wait time is now broken out into the “read by other session” wait event. Excessive waits for this event are typically due to several processes repeatedly reading the same blocks, e.g. many sessions scanning the same index or performing full-table scans on the same table. Tuning this issue is a matter of finding and eliminating this contention.  

在Oracle早期版本中(before 10g)，这个等待被归类在“buffer busy waits”等待时间下。然而，等到了10.1及后续版本中，就变为“read by other session”等待事件了。该事件引起的 大量 等待通常就是因为几个进程重复读取相同的数据块，如：许多会话扫描相同的索引或对某些相同的表做全表扫描，调优这类问题就是要找出并消除这些冲突。

If this happens too often the performance of the query or the entire database can suffer. Typically this is caused by contention for “hot” blocks or objects so it is imperative to find out which data is being contended for.

如果这个等待时间经常出现，查询性能乃至整个数据库都会受影响。很明显这时热块或对象争用引发的，迫切需要找出哪些数据存在争用。

从总的时间统计中可以看到，SQL语句执行花费的时间是排在第一位的，占据了DB Time的95.18%

服务统计中，逻辑读也是相当的高，这也是导致CPU资源被大量消耗的原因之一（逻辑读、排序操作等）

服务等待的统计，同样说明了问题，实例存在较 多的User I/O等待事件

SQL语句读取统计中，发现排在最前面的，物理读最高的是SQL Id为“d23c2k1pzb593”对应的这个SQL语句，对应的是客户应用系统的程序，具体语句就不写出来了，语句中用到了很多子查询和大量视图，然后进行多表连接，并且是用union all来进行连接，势必要产生很多本来可以避免掉的数据块的读取， SQL语句仍有优化的空间。 而当同时有多个session去运行该程序的话，很有可能造成"read by other session"的等待事件

从AWR中也找出逻辑读最高的对象所属的owner，表空间以及对象名等

针对会话具体是那个对象，哪个文件，哪个块以及哪个对象产生了争用，可以通过SQL语句进行查询：

--首先查询该等待时间对应的文件号，块号和class号

SELECT p1 "file#", p2 "block#", p3 "class#" 
FROM v$session_wait
WHERE event = 'read by other session';

--更具刚才查询到的信息，进一步查询段名和段的类型（通常是表）

SELECT relative_fno, owner, segment_name, segment_type 
FROM dba_extents 
WHERE file_id = &file 
AND &block BETWEEN block_id AND block_id + blocks - 1;

另外，还可以从以下几方面着手处理该问题：

1. 调优低效SQL查询

2. 从热块重新分布数据

3. 调整PCTFREE和PCTUSED参数

4. 减小数据块大小

5. 优化索引