v$sql? 表字段说明:
sql_id:唯一性标识;
sql_fulltext:SQL执行内容;
elapsed_time:消逝时间,即自然耗费的时间,单位是微妙,10的-6次方秒;
cpu_time:cpu花费时间,和cpu核数有关,单位是微妙,10的-6次方秒;
案例一:
? ? ? ? 新上线程序,表进行初始化1千万数据初始化完毕后,发现查询很卡。
执行的SQL:
SELECT *
FROM (SELECT tmp.*, rownum row_id
FROM (SELECT line_id
,header_id
,code_company
,code_cc
,expense_nature
,natural_account
,sub_account
/**
省略
*/
FROM tml_je_lines
WHERE (header_id = :1)
ORDER BY line_id ASC) tmp
WHERE rownum <= :2)
WHERE row_id > :3
查询 v$sql表和AWR报告,这个SQL大概每次执行时间耗费83s。tml_je_lines.header_id是有索引的,这个耗费时间有点不理解。?
重新收集这张表的信息
begin
-- Call the procedure
sys.dbms_stats.gather_table_stats(ownname => 'HDM',
tabname => 'TML_DMS_JE');
end;
查看sql_id:axj7d5gsay79n 的SQL执行路线,发现是系统还是对tml_je_lines做了全表扫描。
SELECT sys.dbms_xplan.display_cursor(sql_id => 'axj7d5gsay79n'
,cursor_child_no => 0
,format => 'TYPICAL')
FROM dual;
tml_je_lines.header_id对应的索引是OK,为什么它还是不走索引了。可能是以下原因:
? ? ?SQL查询需要分析耗费时间成本,生成最佳执行计划(根据索引和数据分布),?在执行相同的SQL时,在v$sql表中已经由该SQL,程序还是用走相同的执行计划,哪怕执行计划错误。所以我们需要去掉缓存里面sql_id:axj7d5gsay79n这条SQL的缓存,让它重新生成最佳执行计划。
清除缓存池的v$sql 该条数据。重新查询,发现每次耗费的时间就很短了。
SELECT 'begin sys.dbms_shared_pool.purge(''' || t.address || ',' ||
t.hash_value || ''',''c'');end;' sql_text
,sql_id
,address
,hash_value
,executions
,loads
,parse_calls
,invalidations
FROM v$sql t
WHERE t.sql_id = 'axj7d5gsay79n'
BEGIN
sys.dbms_shared_pool.purge('000000039E18DC28,4038008116', 'c');
END;
|