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