从v$sqltext中追踪

| 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 -