作者:dbtan |【转载时请以超链接形式标明文章出处作者信息】


从v$sqltext中追踪:

在数据库出现瓶颈时,通常可以从v$session_wait找到那些正在等待资源的Session,通过Session的sid,联合v$session和v$sqltext视图可以捕获这些Session正在执行的SQL语句。

数据库运行缓慢,转换为数据库语言就是数据库可能经历了等待,那么可以通过v$session_wait(从Oracle 10g,v$session视图可以取代v$session_wait的这一诊断功能)视图来入手。查询v$session_wait获取各进程等待事件:

winks@CCDB> select sid,event,p1,p1text from v$session_wait ;
       SID EVENT                                     P1 P1TEXT
---------- --------------------------------- ---------- -----------
       801 db file sequential read                    7 file#
       849 db file sequential read                    7 file#
       902 SQL*Net message to client         1413697536 driver id
       943 db file sequential read                    7 file#
       973 db file sequential read                    7 file#
      1019 Space Manager: slave idle wait             0 Slave ID
      1067 rdbms ipc message                        500 timeout
...
271 rows selected.

对于本案例,通过以上输出发现大量db file scattered read及db file sequential read等待,并且全表扫描的等待都位于文件号7的数据文件上。显然全表扫描操作成为系统最严重的性能影响因素。

说明:
db file scattered read(DB文件分散读取)这种情况通常显示与全表扫描相关的等待。当数据库进行全表扫时,基于性能的考虑,数据会分散(scattered)读入Buffer Cache。如果这个等待事件比较显著,可能说明对于某些全表扫描的表,没有创建索引或者没有创建合适的索引,可能需要检查这些数据表已确定是否进行了正确的设置。
然而这个等待事件不一定意味着性能低下,在某些条件下Oracle会主动使用全表扫描来替换索引扫描以提高性能,这和访问的数据量有关,在CBO下Oracle会进行更为智能的选择,在RBO下Oracle更倾向于使用索引。

- The End -