For batches, the SQL handles are hash values based on the SQL text. For database objects such as stored procedures, triggers or functions, the SQL handles are derived from the database ID, object ID, and object number. plan_handle is a hash value derived from the compiled plan of the entire batch.
http://blogs.msdn.com/b/sqlprogrammability/archive/2007/01/09/2-0-sql-handle-and-plan-handle-explained.aspx
Sql_Handle and Plan_Handle Explained
标签:tab hand logs number com explain for compile led
小编还为您整理了以下内容,可能对您也有帮助:
获取SQL执行计划的常见几种方法
1. 预估执行计划 - Explain Plan
Explain plan以SQL语句作为输入,得到这条SQL语句的执行计划,并将执行计划输出存储到计划表中。
首先,在你要执行的SQL语句前加explain plan for,此时将生成的执行计划存储到计划表中,语句如下:
explain plan for SQL语句
然后,在计划表中查询刚刚生成的执行计划,语句如下:
select * from table(dbms_xplan.display);
注意:Explain plan只生成执行计划,并不会真正执行SQL语句,因此产生的执行计划有可能不准,因为:
1)当前的环境可能和执行计划生成时的环境不同;
2)不会考虑绑定变量的数据类型;
3)不进行变量窥视。
2. 查询内存中缓存的执行计划 (dbms_xplan.display_cursor)
如果你想获取正在执行的或刚执行结束的SQL语句真实的执行计划(即获取library cache中的执行计划),可以到动态性能视图里查询。方法如下:
1)获取SQL语句的游标
游标分为父游标和子游标,父游标由sql_id(或联合address和hash_value)字段表示,子游标由child_number字段表示。
如果SQL语句正在运行,可以从v$session中获得它的游标信息,如:
select status, sql_id, sql_child_number from v$session where status='ACTIVE' and ....
如果知道SQL语句包含某些关键字,可以从v$sql视图中获得它的游标信息,如:
select sql_id, child_number, sql_text from v$sql where sql_text like '%关键字%‘
2)获取库缓存中的执行计划
为了获取缓存库中的执行计划,可以直接查询动态性能视图v$sql_plan和v$sql_plan_statistics_all等,但更方便的方法是以sql_id和子游标为参数,执行如下语句:
select * from table(dbms_xplan.display_cursor('sql_id',child_number));
3)获取前一次的执行计划:
set serveroutput off
select * from table(dbms_xplan.display_cursor(null,null,'ALLSTATS LAST'));
3. 查询历史执行计划(dbms_xplan.display_awr)
AWR会定时把动态性能视图中的执行计划保存到dba_hist_sql_plan视图中,如果你想要查看历史执行计划,可以采用如下方法查询:
select * from table(dbms_xplan.display_awr('sql_id');
4. 在用sqlplus做SQL开发是(Autotrace)
set autotrace是sqlplus工具的一个功能,只能在通过sqlplus连接的session中使用,它非常适合在开发时测试SQL语句的性能,有以下几种参数可供选择:
SET AUTOTRACE OFF ---------------- 不显示执行计划和统计信息,这是缺省模式
SET AUTOTRACE ON EXPLAIN ------ 只显示优化器执行计划
SET AUTOTRACE ON STATISTICS -- 只显示统计信息
SET AUTOTRACE ON ----------------- 执行计划和统计信息同时显示
SET AUTOTRACE TRACEONLY ------ 不真正执行,只显示预期的执行计划,同explain plan
5. 生成Trace文件查询详细的执行计划 (SQL_Trace, 10046)
SQL_TRACE作为初始化参数可以在实例级别启用,也可以只在会话级别启用,在实例级别启用SQL_TRACE会导致所有进程的活动被跟踪,包括后台进程及所有用户进程,这通常会导致比较严重的性能问题,所以在一般情况下,我们使用sql_trace跟踪当前进程,方法如下:
SQL>alter session set sql_trace=true;
...被跟踪的SQL语句...
SQL>alter session set sql_trace=false;
如果要跟踪其它进程,可以通过Oracle提供的系统包DBMS_SYSTEM. SET_SQL_TRACE_IN_SESSION来实现,例如:
SQL> exec dbms_system.set_sql_trace_in_session(sid,serial#,true) --开始跟踪
SQL> exec dbms_system.set_sql_trace_in_session(sid,serial#,false) --结束跟踪
生成trace文件后,再用tkprof 工具将sql trace 生成的跟踪文件转换成易读的格式,语法如下:
tkprof inputfile outputfile
10046事件是SQL_TRACE的一个升级版,它也是追踪会话,生成Trace文件,只是它里面的内容更详细,
获取SQL执行计划的常见几种方法
1. 预估执行计划 - Explain Plan
Explain plan以SQL语句作为输入,得到这条SQL语句的执行计划,并将执行计划输出存储到计划表中。
首先,在你要执行的SQL语句前加explain plan for,此时将生成的执行计划存储到计划表中,语句如下:
explain plan for SQL语句
然后,在计划表中查询刚刚生成的执行计划,语句如下:
select * from table(dbms_xplan.display);
注意:Explain plan只生成执行计划,并不会真正执行SQL语句,因此产生的执行计划有可能不准,因为:
1)当前的环境可能和执行计划生成时的环境不同;
2)不会考虑绑定变量的数据类型;
3)不进行变量窥视。
2. 查询内存中缓存的执行计划 (dbms_xplan.display_cursor)
如果你想获取正在执行的或刚执行结束的SQL语句真实的执行计划(即获取library cache中的执行计划),可以到动态性能视图里查询。方法如下:
1)获取SQL语句的游标
游标分为父游标和子游标,父游标由sql_id(或联合address和hash_value)字段表示,子游标由child_number字段表示。
如果SQL语句正在运行,可以从v$session中获得它的游标信息,如:
select status, sql_id, sql_child_number from v$session where status='ACTIVE' and ....
如果知道SQL语句包含某些关键字,可以从v$sql视图中获得它的游标信息,如:
select sql_id, child_number, sql_text from v$sql where sql_text like '%关键字%‘
2)获取库缓存中的执行计划
为了获取缓存库中的执行计划,可以直接查询动态性能视图v$sql_plan和v$sql_plan_statistics_all等,但更方便的方法是以sql_id和子游标为参数,执行如下语句:
select * from table(dbms_xplan.display_cursor('sql_id',child_number));
3)获取前一次的执行计划:
set serveroutput off
select * from table(dbms_xplan.display_cursor(null,null,'ALLSTATS LAST'));
3. 查询历史执行计划(dbms_xplan.display_awr)
AWR会定时把动态性能视图中的执行计划保存到dba_hist_sql_plan视图中,如果你想要查看历史执行计划,可以采用如下方法查询:
select * from table(dbms_xplan.display_awr('sql_id');
4. 在用sqlplus做SQL开发是(Autotrace)
set autotrace是sqlplus工具的一个功能,只能在通过sqlplus连接的session中使用,它非常适合在开发时测试SQL语句的性能,有以下几种参数可供选择:
SET AUTOTRACE OFF ---------------- 不显示执行计划和统计信息,这是缺省模式
SET AUTOTRACE ON EXPLAIN ------ 只显示优化器执行计划
SET AUTOTRACE ON STATISTICS -- 只显示统计信息
SET AUTOTRACE ON ----------------- 执行计划和统计信息同时显示
SET AUTOTRACE TRACEONLY ------ 不真正执行,只显示预期的执行计划,同explain plan
5. 生成Trace文件查询详细的执行计划 (SQL_Trace, 10046)
SQL_TRACE作为初始化参数可以在实例级别启用,也可以只在会话级别启用,在实例级别启用SQL_TRACE会导致所有进程的活动被跟踪,包括后台进程及所有用户进程,这通常会导致比较严重的性能问题,所以在一般情况下,我们使用sql_trace跟踪当前进程,方法如下:
SQL>alter session set sql_trace=true;
...被跟踪的SQL语句...
SQL>alter session set sql_trace=false;
如果要跟踪其它进程,可以通过Oracle提供的系统包DBMS_SYSTEM. SET_SQL_TRACE_IN_SESSION来实现,例如:
SQL> exec dbms_system.set_sql_trace_in_session(sid,serial#,true) --开始跟踪
SQL> exec dbms_system.set_sql_trace_in_session(sid,serial#,false) --结束跟踪
生成trace文件后,再用tkprof 工具将sql trace 生成的跟踪文件转换成易读的格式,语法如下:
tkprof inputfile outputfile
10046事件是SQL_TRACE的一个升级版,它也是追踪会话,生成Trace文件,只是它里面的内容更详细,
sqlserver占用内存过高,清理办法
SQL Server对服务器内存的使用策略是用多少内存就占用多少内存,只用在服务器内存不足时,才会释放一点占用的内存,所以SQL Server 服务器内存往往会占用很高。
Sql Server运行时候的缓存:
1.数据缓存:执行个查询语句,Sql Server会将相关的数据页(Sql Server操作的数据都是以页为单位的)加载到内存中来, 下一次如果再次请求此页的数据的时候,就无需读取磁盘了,大大提高了速度。
2.执行命令缓存:在执行存储过程,自定函数时,Sql Server需要先二进制编译再运行,编译后的结果也会缓存起来, 再次调用时就无需再次编译。
清除缓存的命令(直接执行第四个命令清除所有缓存):
DBCC FREEPROCCACHE --清除存储过程相关的缓存
DBCC FREESESSIONCACHE --会话缓存
DBCC FREESYSTEMCACHE('All') --系统缓存
DBCC DROPCLEANBUFFERS --所有缓存
注意:清除了缓存,不会释放SQL Server所占用的内存,所以需要通过修改SQL Server内存或重启SQL Server服务器来释放内存。
修改SQL Server内存:
优化:使用以下语句查找出什么语句占内存最高,针对占内存高的语句进行优化
SELECT SS.SUM_EXECUTION_COUNT,
T.TEXT,
SS.SUM_TOTAL_ELAPSED_TIME AS '总和时间',
SS.SUM_TOTAL_WORKER_TIME AS '执行耗时',
SS.SUM_TOTAL_LOGICAL_READS AS '总和逻辑读数',
SS.SUM_TOTAL_LOGICAL_WRITES AS '总和逻辑写'
FROM (SELECT S.PLAN_HANDLE,
SUM(S.EXECUTION_COUNT)SUM_EXECUTION_COUNT,
SUM(S.TOTAL_ELAPSED_TIME)SUM_TOTAL_ELAPSED_TIME,
SUM(S.TOTAL_WORKER_TIME)SUM_TOTAL_WORKER_TIME,
SUM(S.TOTAL_LOGICAL_READS)SUM_TOTAL_LOGICAL_READS,
SUM(S.TOTAL_LOGICAL_WRITES)SUM_TOTAL_LOGICAL_WRITES
FROM SYS.DM_EXEC_QUERY_STATS S
GROUP BY S.PLAN_HANDLE
) AS SS
CROSS APPLY SYS.dm_exec_sql_text(SS.PLAN_HANDLE)T
ORDER BY SUM_TOTAL_LOGICAL_READS DESC
转自: https://www.cnblogs.com/LuoEast/p/8398406.html