SQL优化【基础01】-生成执行计划及计划中参数列的含义

基础01-生成执行计划
--对于11G平时最常用的是table函数+dbms_xplan包,其它方式如autot traceonly也偶尔用,下面就来介绍dbms_xplan
--explan plan for...,这个只是预估计划,除非明显连接方式错误,否则有时帮忙并不大,所以最直接还是用dbms_xplan
方法(1) alter session set statistics_level=all;
exec sql;
select * from table(dbms_xplan.display_cursor(null,null,'allstats last'));

方法(2)
exec sql(加入hint /*+ gather_plan_statistics */)
select * from table(dbms_xplan.display_cursor(null,null,'allstats last'));

--最常用的几个参数,操作下便知
allstats last  --最后一次统计,不用漏了last,否则就是累加值了; 
all  --一般看计划,SQL_ID,PLAN_HASH_VALUE
advanced  --一般拿来看outline_data信息和绑定变量

--方法(1)示例
SQL> select * from v$version;

BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
PL/SQL Release 11.2.0.2.0 - Production
CORE    11.2.0.2.0      Production
TNS for Linux: Version 11.2.0.2.0 - Production
NLSRTL Version 11.2.0.2.0 - Production


SQL> alter session set statistics_level=all;

Session altered.

SQL> select  t1.status,t2.status
  2  from t1,t2
  3  where t1.object_id=t2.object_id
  4  and t1.object_id=99;

no rows selected

SQL> select * from table(dbms_xplan.display_cursor(null,null,'allstats last'));

PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
SQL_ID  581vna1k8tkk7, child number 0
-------------------------------------
select  t1.status,t2.status from t1,t2 where t1.object_id=t2.object_id
and t1.object_id=99

Plan hash value: 2959412835

----------------------------------------------------------------------------------------------------------------
| Id  | Operation          | Name | Starts | E-Rows | A-Rows |   A-Time   | Buffers |  OMem |  1Mem | Used-Mem |
----------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |      |      1 |        |      0 |00:00:00.01 |       3 |       |       |          |
|*  1 |  HASH JOIN         |      |      1 |      1 |      0 |00:00:00.01 |       3 |   963K|   963K|  150K (0)|
|*  2 |   TABLE ACCESS FULL| T2   |      1 |      1 |      0 |00:00:00.01 |       3 |       |       |          |
|*  3 |   TABLE ACCESS FULL| T1   |      0 |     12 |      0 |00:00:00.01 |       0 |       |       |          |
----------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - access("T1"."OBJECT_ID"="T2"."OBJECT_ID")
   2 - filter("T2"."OBJECT_ID"=99)
   3 - filter("T1"."OBJECT_ID"=99)

Note
-----
   - dynamic sampling used for this statement (level=2)


27 rows selected.

--方法(2)示例
SQL> select  /*+ gather_plan_statistics */t1.status,t2.status
  2  from t1,t2
  3  where t1.object_id=t2.object_id
  4  and t1.object_id=99;

no rows selected

SQL> @allstat--(放在文件中:select * from table(dbms_xplan.display_cursor(null,null,'allstats last'));)

PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
SQL_ID  27qqjb8bsq4vc, child number 0
-------------------------------------
select  /*+ gather_plan_statistics */t1.status,t2.status from t1,t2
where t1.object_id=t2.object_id and t1.object_id=99

Plan hash value: 2959412835

----------------------------------------------------------------------------------------------------------------
| Id  | Operation          | Name | Starts | E-Rows | A-Rows |   A-Time   | Buffers |  OMem |  1Mem | Used-Mem |
----------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |      |      1 |        |      0 |00:00:00.01 |       3 |       |       |          |
|*  1 |  HASH JOIN         |      |      1 |      1 |      0 |00:00:00.01 |       3 |   963K|   963K|  154K (0)|
|*  2 |   TABLE ACCESS FULL| T2   |      1 |      1 |      0 |00:00:00.01 |       3 |       |       |          |
|*  3 |   TABLE ACCESS FULL| T1   |      0 |     12 |      0 |00:00:00.01 |       0 |       |       |          |
----------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - access("T1"."OBJECT_ID"="T2"."OBJECT_ID")
   2 - filter("T2"."OBJECT_ID"=99)
   3 - filter("T1"."OBJECT_ID"=99)

Note
-----
   - dynamic sampling used for this statement (level=2)


27 rows selected.

--接下来看下执行计划这些参数的含义,直接上图看了;





  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
SQL执行计划变化告警是数据库性能监控的一种警报机制,用于监测SQL语句的执行计划是否发生变化。 当数据库系统在执行SQL语句时,会根据当前数据库的统计信息和索引等情况生成一个最优的执行计划,以提高查询效率。然而,由于数据库的数据量、索引状态、数据分布等因素的变化,可能会导致原来的执行计划不再是最优的。这种情况下,SQL的性能可能会下降,导致查询速度变慢。 为了及时发现这种情况,可以设置一个告警机制,当数据库监测到SQL执行计划发生变化时,会触发告警,通知管理员或负责人进行处理。 告警机制的实现方式可以有多种,例如使用数据库的触发器、定时任务或者监控工具等。一般来说,告警机制会记录SQL语句的执行计划,并与之前的执行计划进行对比。如果发现执行计划有明显的变化,如索引扫描方式的变化、表连接顺序的变化等,就会触发告警。 接收到告警后,管理员需要及时分析变化的原因,并根据实际情况做出相应的调整。可能的处理方式包括重新统计数据库的统计信息、重新优化SQL语句、优化索引、调整数据库参数等。 总之,SQL执行计划变化告警是一种有效的性能监控机制,能够及时通知管理员发现SQL执行计划的变化,进而进行相应的处理,提高数据库的性能和稳定性。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值