SQL Profiles-Part I-阿里云开发者社区

开发者社区> 余二五> 正文

SQL Profiles-Part I

简介:
+关注继续查看

Oracle 11g从发布到现在,也有几个年头了。而在国内来说,Oracle 10g仍然是主流,甚至一些电信运营商的核心系统仍然在使用9i。作为Oracle 10g的一项新特性,SQL Profiles被使用得并不太多。不管是在论坛、个人的BLOG还是其他一些地方,SQL Profiles的介绍也相对较少。对我个人来说,已经在多个优化场合中使用SQL Profiles,在这里向大家介绍SQL Profiles,就是希望能够了解Oracle数据库的这一功能。

SQL Profiles可以说是Outlines的进化。Outlines能够实现的功能SQL Profiles也完全能够实现,而SQL Profiles具有Outlines不具备的优化,个人认为最重要的有2点:

  • SQL Profiles更容易生成、更改和控制。
  • SQL Profiles在对SQL语句的支持上做得更好,也就是适用范围更广。

关于这2方面的优点,我后面会详细地阐述。

现在我在使用Outlines的场合,均使用SQL Profiles来替代。有一次准备对1条SQL语句使用Outline进行执行计划的稳定,结果使用Outline之后,系统出现大量的library cache latch的争用,不得不关闭Outline的使用,但是改用SQL Profiles不再有这个问题。这或许是个BUG,不过既然能用SQL Profiles代替,也就没再深入去研究这个问题。

使用SQL Profiles无非是两个目的:

  • 锁定或者说是稳定执行计划。
  • 在不能修改应用中的SQL的情况下使SQL语句按指定的执行计划运行。

那么SQL Profile到底是什么?在我看来,SQL Profile就是为某一SQL语句提供除了系统统计信息、对象(表和索引等)统计信息之外的其他信息,比如运行环境、额外的更准确的统计信息,以帮助优 化器为SQL语句选择更适合的执行计划。这些说法显得比较枯燥,还是来看看下面的测试。

首先建2个测试表:

  1. SQL> create table t1 as select object_id,object_name from dba_objects where rownum<=50000;  
  2.   
  3. 表已创建。  
  4.   
  5. SQL> create table t2 as select * from dba_objects;  
  6.   
  7. 表已创建。  
  8.   
  9. SQL> create index t2_idx on t2(object_id);  
  10.   
  11. 索引已创建。  
  12.   
  13. SQL> exec dbms_stats.gather_table_stats(user,'t1',cascade=>true,method_opt=>'for all columns size 1');  
  14.   
  15. PL/SQL 过程已成功完成。  
  16.   
  17. SQL> exec dbms_stats.gather_table_stats(user,'t2',cascade=>true,method_opt=>'for all columns size 1');  
  18.   
  19. PL/SQL 过程已成功完成。  

然后看看下面这一条SQL:

  1. SQL> select t1.*,t2.owner from t1,t2 where t1.object_name like '%T1%' and t1.object_id=t2.object_id;  
  2.   
  3. 已选择29行。  
  4.   
  5. 执行计划  
  6. ----------------------------------------------------------  
  7. Plan hash value: 1838229974  
  8.   
  9. ---------------------------------------------------------------------------  
  10. | Id  | Operation          | Name | Rows  | Bytes | Cost (%CPU)| Time     |  
  11. ---------------------------------------------------------------------------  
  12. |   0 | SELECT STATEMENT   |      |  2498 | 99920 |   219   (4)| 00:00:03 |  
  13. |*  1 |  HASH JOIN         |      |  2498 | 99920 |   219   (4)| 00:00:03 |  
  14. |*  2 |   TABLE ACCESS FULL| T1   |  2498 | 72442 |    59   (6)| 00:00:01 |  
  15. |   3 |   TABLE ACCESS FULL| T2   | 49954 |   536K|   159   (2)| 00:00:02 |  
  16. ---------------------------------------------------------------------------  
  17.   
  18. Predicate Information (identified by operation id):  
  19. ---------------------------------------------------  
  20.   
  21.    1 - access("T1"."OBJECT_ID"="T2"."OBJECT_ID")  
  22.    2 - filter("T1"."OBJECT_NAME" LIKE '%T1%')  
  23.   
  24. 统计信息  
  25. ----------------------------------------------------------  
  26.           0  recursive calls  
  27.           0  db block gets  
  28.         932  consistent gets  
  29.           0  physical reads  
  30.           0  redo size  
  31.        1352  bytes sent via SQL*Net to client  
  32.         385  bytes received via SQL*Net from client  
  33.           2  SQL*Net roundtrips to/from client  
  34.           0  sorts (memory)  
  35.           0  sorts (disk)  
  36.          29  rows processed  

这里省略了SELECT出来的具体数据,但是我们关心的是返回的结果行数、执行计划以及逻辑读这些信息。
首先从执行计划可以看到,这条SQL语句在2个表上都是全表扫描。在第1个表T1上,有 like ‘%T1%’这样的条件,导致只能全表扫描,这没有问题。但是第2个表,也是全表扫描,这里有没有问题呢?或者说是有没有优化的余地,答案显然是肯定的。
这里的问题在于执行计划ID=1的那一行,Oracle优化器评估T1 like ‘%T1%’返回的结果行数为2498行,即T1表总行数的5%,如果2个表采用index range scan+nested loop连接,oracle评估的成本会高于full table scan+hash join。下面可以看到Oracle优化器评估的index range_scan+nested loop的成本:

  1. SQL> explain plan for select /*+ use_nl(t1 t2) index(t2) */ t1.*,t2.owner   
  2.      from t1,t2   
  3.      where t1.object_name like '%T1%'   
  4.      and t1.object_id=t2.object_id;  
  5.   
  6. 已解释。  
  7.   
  8. SQL> @showplan  
  9.   
  10. PLAN_TABLE_OUTPUT  
  11. --------------------------------------------------------------------------------------  
  12. Plan hash value: 3787413387  
  13. --------------------------------------------------------------------------------------  
  14. | Id  | Operation                   | Name   | Rows  | Bytes | Cost (%CPU)| Time     |  
  15. --------------------------------------------------------------------------------------  
  16. |   0 | SELECT STATEMENT            |        |  2498 | 99920 |  5061   (1)| 00:01:01 |  
  17. |   1 |  TABLE ACCESS BY INDEX ROWID| T2     |     1 |    11 |     2   (0)| 00:00:01 |  
  18. |   2 |   NESTED LOOPS              |        |  2498 | 99920 |  5061   (1)| 00:01:01 |  
  19. |*  3 |    TABLE ACCESS FULL        | T1     |  2498 | 72442 |    59   (6)| 00:00:01 |  
  20. |*  4 |    INDEX RANGE SCAN         | T2_IDX |     1 |       |     1   (0)| 00:00:01 |  
  21. --------------------------------------------------------------------------------------  
  22. Predicate Information (identified by operation id):  
  23. ---------------------------------------------------  
  24.    3 - filter("T1"."OBJECT_NAME" LIKE '%T1%')  
  25.    4 - access("T1"."OBJECT_ID"="T2"."OBJECT_ID")  

从执行计划可以看到Oracle优化器评估的成本为5061,远远高于原来的219。
但是实际的逻辑读是多少呢?

  1. 统计信息  
  2. ----------------------------------------------------------  
  3.           0  recursive calls  
  4.           0  db block gets  
  5.         290  consistent gets  
  6.           0  physical reads  
  7.           0  redo size  
  8.        1352  bytes sent via SQL*Net to client  
  9.         385  bytes received via SQL*Net from client  
  10.           2  SQL*Net roundtrips to/from client  
  11.           0  sorts (memory)  
  12.           0  sorts (disk)  
  13.          29  rows processed  

加了HINT之后实际的逻辑读只有290,低于原始SQL的932。所以这里可以看出来,由于Oracle优化器过高地估计了T1表经过like操作过滤返回的行数,也就过高地估计了nest loop的成本,最终也就选择了不是最优的执行计划。

下面我们用Oracle的SQL Tuning Advisor来尝试这条SQL:

  1. SQL> var tuning_task varchar2(100);  
  2. SQL> DECLARE  
  3.   2    l_sql_id v$session.prev_sql_id%TYPE;  
  4.   3    l_tuning_task VARCHAR2(30);  
  5.   4  BEGIN  
  6.   5    l_sql_id:='4zbqykx89yc8v';  
  7.   6    l_tuning_task := dbms_sqltune.create_tuning_task(sql_id => l_sql_id);  
  8.   7    :tuning_task:=l_tuning_task;  
  9.   8    dbms_sqltune.execute_tuning_task(l_tuning_task);  
  10.   9    dbms_output.put_line(l_tuning_task);  
  11.  10  END;  
  12.  11  /  
  13. 任务_74  
  14.   
  15. PL/SQL 过程已成功完成。  
  16.   
  17. SQL> print tuning_task;  
  18.   
  19. TUNING_TASK  
  20. ---------------------------------------------------------------------------------------------------------  
  21. 任务_74  
  22.   
  23. SQL> SELECT dbms_sqltune.report_tuning_task(:tuning_task) FROM dual;  
  24.   
  25. DBMS_SQLTUNE.REPORT_TUNING_TASK(:TUNING_TASK)  
  26. --------------------------------------------------------------------------------  
  27. GENERAL INFORMATION SECTION  
  28. -------------------------------------------------------------------------------  
  29. Tuning Task Name                  : 任务_74  
  30. Tuning Task Owner                 : TEST1  
  31. Scope                             : COMPREHENSIVE  
  32. Time Limit(seconds)               : 1800  
  33. Completion Status                 : COMPLETED  
  34. Started at                        : 12/15/2010 09:56:02  
  35. Completed at                      : 12/15/2010 09:56:03  
  36. Number of SQL Profile Findings    : 1  
  37.   
  38. -------------------------------------------------------------------------------  
  39. Schema Name: TEST1  
  40. SQL ID     : 4zbqykx89yc8v  
  41. SQL Text   : select t1.*,t2.owner from t1,t2 where t1.object_name like '%T1%'  
  42.              and t1.object_id=t2.object_id  
  43.   
  44. -------------------------------------------------------------------------------  
  45. FINDINGS SECTION (1 finding)  
  46. -------------------------------------------------------------------------------  
  47.   
  48. 1- SQL Profile Finding (see explain plans section below)  
  49. --------------------------------------------------------  
  50.  为此语句找到了性能  
  51.   
  52.   Recommendation (estimated benefit: 46.62%)  
  53.   ------------------------------------------  
  54.   -考虑接受推荐的 SQL  
  55.     executedbms_sqltune.accept_sql_profile(task_name => '任务_74'replace =  
  56.             TRUE);  
  57.   
  58. -------------------------------------------------------------------------------  
  59. EXPLAIN PLANS SECTION  
  60. -------------------------------------------------------------------------------  
  61.   
  62. 1- Original With Adjusted Cost  
  63. ------------------------------  
  64. Plan hash value: 1838229974  
  65.   
  66. ---------------------------------------------------------------------------  
  67. | Id  | Operation          | Name | Rows  | Bytes | Cost (%CPU)| Time     |  
  68. ---------------------------------------------------------------------------  
  69. |   0 | SELECT STATEMENT   |      |    29 |  1160 |   219   (4)| 00:00:03 |  
  70. |*  1 |  HASH JOIN         |      |    29 |  1160 |   219   (4)| 00:00:03 |  
  71. |*  2 |   TABLE ACCESS FULL| T1   |    29 |   841 |    59   (6)| 00:00:01 |  
  72. |   3 |   TABLE ACCESS FULL| T2   | 49954 |   536K|   159   (2)| 00:00:02 |  
  73. ---------------------------------------------------------------------------  
  74.   
  75. Predicate Information (identified by operation id):  
  76. ---------------------------------------------------  
  77.   
  78.    1 - access("T1"."OBJECT_ID"="T2"."OBJECT_ID")  
  79.    2 - filter("T1"."OBJECT_NAME" LIKE '%T1%')  
  80.   
  81. 2- Using SQL Profile  
  82. --------------------  
  83. Plan hash value: 3787413387  
  84.   
  85. --------------------------------------------------------------------------------------  
  86. | Id  | Operation                   | Name   | Rows  | Bytes | Cost (%CPU)| Time     |  
  87. --------------------------------------------------------------------------------------  
  88. |   0 | SELECT STATEMENT            |        |    29 |  1160 |   117   (3)| 00:00:02 |  
  89. |   1 |  TABLE ACCESS BY INDEX ROWID| T2     |     1 |    11 |     2   (0)| 00:00:01 |  
  90. |   2 |   NESTED LOOPS              |        |    29 |  1160 |   117   (3)| 00:00:02  
  91.  |  
  92. |*  3 |    TABLE ACCESS FULL        | T1     |    29 |   841 |    59   (6)| 00:00:01 |  
  93. |*  4 |    INDEX RANGE SCAN         | T2_IDX |     1 |       |     1   (0)| 00:00:01 |  
  94. --------------------------------------------------------------------------------------  
  95.   
  96. Predicate Information (identified by operation id):  
  97. ---------------------------------------------------  
  98.   
  99.    3 - filter("T1"."OBJECT_NAME" LIKE '%T1%')  
  100.    4 - access("T1"."OBJECT_ID"="T2"."OBJECT_ID")  
  101.   
  102. -------------------------------------------------------------------------------  


上面代码中的sql_id是从v$sql来,对应的是没有加hint的SQL。
结果看起来非常棒,SQL Tuning Advisor为我们找到了理想的执行计划,T1表上经过谓词过滤后返回的行数评估为29,相当地精确。我们要做的就是Accept SQL Profile,接受这个SQL Profile。

  1. SQL> execute dbms_sqltune.accept_sql_profile(task_name => :tuning_task,replace => TRUE,force_match=>true);  
  2.   
  3. PL/SQL 过程已成功完成。  

那么我们再执行其他的类似SQL看看:

  1. SQL> select t1.*,t2.owner from t1,t2 where t1.object_name like '%T2%' and t1.object_id=t2.object_id;  
  2.   
  3. 已选择77行。  
  4.   
  5. 执行计划  
  6. ----------------------------------------------------------  
  7. Plan hash value: 3787413387  
  8. --------------------------------------------------------------------------------------  
  9. | Id  | Operation                   | Name   | Rows  | Bytes | Cost (%CPU)| Time     |  
  10. --------------------------------------------------------------------------------------  
  11. |   0 | SELECT STATEMENT            |        |    29 |  1160 |   117   (3)| 00:00:02 |  
  12. |   1 |  TABLE ACCESS BY INDEX ROWID| T2     |     1 |    11 |     2   (0)| 00:00:01 |  
  13. |   2 |   NESTED LOOPS              |        |    29 |  1160 |   117   (3)| 00:00:02 |  
  14. |*  3 |    TABLE ACCESS FULL        | T1     |    29 |   841 |    59   (6)| 00:00:01 |  
  15. |*  4 |    INDEX RANGE SCAN         | T2_IDX |     1 |       |     1   (0)| 00:00:01 |  
  16. --------------------------------------------------------------------------------------  
  17. Predicate Information (identified by operation id):  
  18. ---------------------------------------------------  
  19.    3 - filter("T1"."OBJECT_NAME" LIKE '%T2%')  
  20.    4 - access("T1"."OBJECT_ID"="T2"."OBJECT_ID")  
  21. Note  
  22. -----  
  23.    - SQL profile "SYS_SQLPROF_014b39f084c88000" used for this statement  
  24.   
  25. 统计信息  
  26. ----------------------------------------------------------  
  27.           1  recursive calls  
  28.           0  db block gets  
  29.         343  consistent gets  
  30.           0  physical reads  
  31.           0  redo size  
  32.        2840  bytes sent via SQL*Net to client  
  33.         385  bytes received via SQL*Net from client  
  34.           2  SQL*Net roundtrips to/from client  
  35.           0  sorts (memory)  
  36.           0  sorts (disk)  
  37.          77  rows processed  

这一次,尽管我们更改了LIKE 后面的值,但是执行计划与SQL Tuning Advisor产生的执行计划完全一样。从执行计划的”Note“一节也可以看到,SQL Profile起作用了。SQL Profile的名字为”SYS_SQLPROF_014b39f084c88000″。

  1. SQL> select name,category,signature,type,status,force_matching from dba_sql_profiles;  
  2.   
  3. NAME                           CATEGORY                                   SIGNATURE TYPE      STATUS  FOR  
  4. ------------------------------ ------------------------------ --------------------- --------- ---------- ---  
  5. SYS_SQLPROF_014b39f084c88000   DEFAULT                          3960696072677096522 MANUAL    ENABLED    YES  

一些复杂的SQL,我经常会先通过SQL Tuning Advisor来分析一下,看能不能让Oracle自已找出一个更好的执行计划。

我们来看看,SQL Profiles实际上是些什么:

  1. SQL< select * from sys.sqlprof$attr;  
  2.   
  3.             SIGNATURE CATEGORY                            ATTR# ATTR_VAL  
  4. --------------------- ------------------------------ ---------- ----------------------------------------  
  5.   3960696072677096522 DEFAULT                                 1 OPT_ESTIMATE(@"SEL$1"TABLE"T1"@"SEL$ 
  6.                                                                 1", SCALE_ROWS=0.01161091426)  

从sys.sqlprof$attr这个数字字典里面,我们可以看到两样东西:signature和attr。
signature是什么?可以理解为与sql_id、sql_hash_value类似的值,用来标识SQL。在10g以上的版本中,查看v$sql的 定义就可以发现2列:exact_matching_signature、force_matching_signature。通过下面的数据可以看出区 别:

  1. SQL> select rownum,a.* from  
  2.   (select exact_matching_signature,force_matching_signature,plan_hash_value,sql_text  
  3.   from v$sql where sql_text like '%/*%xjs%' and sql_text not like '%v$sql%' order by 1) a;  
  4.   
  5.     ROWNUM EXACT_MATCHING_SIGNATURE FORCE_MATCHING_SIGNATURE PLAN_HASH_VALUE SQL_TEXT  
  6. ---------- ------------------------ ------------------------ --------------- --------------------------------------------------  
  7.          1      3939730931515200254     17443893418101517951      3617692013 select /* xjs */ object_name    from T1 where obje  
  8.                                                                              ct_name='t1'  
  9.   
  10.          2     10964210455693560558     11097449316038436385      3836375644 select /* xjs */ object_name    from T1 where rown  
  11.                                                                              um<=3  
  12.   
  13.          3     10964210455693560558     11097449316038436385      3836375644 select /* xjs   */ object_name    from T1 where ro  
  14.                                                                              wnum<=3  
  15.   
  16.          4     11217690300719901571       354482119692997204      3836375644 select /* xjs */ 2 from t1 where rownum<=1  
  17.          5     11974975582747367847       354482119692997204      3836375644 select /* xjs */ 1 from t1 where rownum<=1  
  18.          6     12941882703651921406     17443893418101517951      3617692013 select /* xjs */ object_name    from T1 where obje  
  19.                                                                              ct_name='T1'  
  20.   
  21.          7     17986178357953662359     11097449316038436385      3836375644 select /* xjs */ object_name    from T1 where rown  
  22.                                                                              um<=1  
  23.   
  24.          8     17986178357953662359     11097449316038436385      3836375644 select /* xjs */ OBJECT_NAME from T1 where rownum<  
  25.                                                                              =1  
  26.   
  27.          9     17986178357953662359     11097449316038436385      3836375644 SELECT /* xjs */ object_name    from T1 where rown  
  28.                                                                              um<=1  
  29.   
  30.         10     17986178357953662359     11097449316038436385      3836375644 select /* xjs */ object_name from t1 where rownum<  
  31.                                                                              =1  

从上面的数据可以看出:

  • 第2、3条SQL的exact_matching_signature相同,第7、8、9、10条SQL的exact_matching_signature相同。
  • 第2、3条SQL的force_matching_signature相同,第4、5条SQL的 force_matching_signature相同,第7、8、9、10条的SQL的force_matching_signature相同。第1、 6条SQL的force_matching_signature相同

有如下的结论:对SQL语句,去掉重复的空格(不包括字符常量),将大小写转换成相同,比如均为大写(不包括字符常量)后,如果 SQL相同,那么SQL语句的exact_matching_signature就是相同的。对SQL语句,去掉重复的空格(不包括字符常量),将大小写 转换成相同,比如均为大写(不包括字符常量),然后去掉SQL中的常量,如果SQL相同,那么SQL语句的 force_matching_signature就是相同的。但是例外的情况是:如果SQL中有绑定变量,force_matching_signature就会与exact_matching_signature一样的生成标准。

  1. SQL> select rownum,a.* from  
  2. (select exact_matching_signature,force_matching_signature,plan_hash_value,sql_text  
  3. from v$sql where sql_text like '%/*%xjs2%' and sql_text not like '%v$sql%' order by 1) a;  
  4.   
  5.     ROWNUM EXACT_MATCHING_SIGNATURE FORCE_MATCHING_SIGNATURE PLAN_HASH_VALUE SQL_TEXT  
  6. ---------- ------------------------ ------------------------ --------------- --------------------------------------------------  
  7.          1      5363536431331905229      5363536431331905229      3836375644 select /* xjs2 */ object_name    from T1 where obj  
  8.                                                                              ect_name='T1' and rownum<=:rn  
  9.   
  10.          2      5363536431331905229      5363536431331905229      3836375644 select /* xjs2 */ object_name    from t1 where obj  
  11.                                                                              ect_name='T1' and rownum<=:rn  
  12.   
  13.          3     12992689086515482106     12992689086515482106      3836375644 select /* xjs2 */ object_name    from t1 where obj  
  14.                                                                              ect_name='T2' and rownum<=:rn  

可以看到,现在exact_matching_signature与force_matching_signature完全一样了。
从force_matching_signature的特性,我们可以想到一个用途,用于查找没有使用绑定变量的SQL语句,类似于使用plan_hash_value来查找。

回到前面,accept_sql_profile这个过程,force_match参数设为TRUE,那么dba_sql_profiles中的 signature则是由SQL的force_matching_signature而来,否则便是exact_matching_signature。 对于Outlines来说,则只能是exact_matching_signature。从这个角度上讲,Sql Profiles比Outlines的使用范围更广,因为Sql profiles对没有使用绑定变量的SQL也支持得很好。值得注意的是,Sql profiles的force_match属性是不能更改的,只能在创建时指定,如果要更改,则只能重新创建改Sql Profile。

下面来看看sys.sqlprof$attr数据字典。这里面没有SQL Profile的名字,而是用的sql的signature。大家从attr_val的结果发现了什么?

  1. OPT_ESTIMATE(@"SEL$1"TABLE"T1"@"SEL$1", SCALE_ROWS=0.01161091426)  

可以看到,SQL Profiles的attr_val实际上就是一些Hints,这跟Outlines没有本质上的区别。只是SQL Profiles中的Hint,没有指定SQL使用哪个索引,也没有指定表的连接方法和连接顺序。这里只指定了T1表评估返回的行数,与原始的评估返回的 行数的放大缩小的倍数。2498*0.01161091426正好为29。这里就是告诉Oracle优化器,T1表经过谓语过滤后返回行数应该为评估的 0.01161091426倍。从这里可以看出,SQL Profiles并不会锁定SQL的执行计划,只是提供了更多、更准确的统计信息给优化器。看下面的测试:

  1. SQL> exec dbms_stats.set_table_stats('TEST1','T1',numrows=>5000000);  
  2.   
  3. PL/SQL 过程已成功完成。  
  4. SQL> explain plan for select  t1.*,t2.owner  
  5.   2       from t1,t2  
  6.   3       where t1.object_name like '%T1%'  
  7.   4       and t1.object_id=t2.object_id;  
  8.   
  9. 已解释。  
  10.   
  11. SQL> @showplan  
  12.   
  13. PLAN_TABLE_OUTPUT  
  14. ----------------------------------------------------------------------------------  
  15. Plan hash value: 1838229974  
  16. ---------------------------------------------------------------------------  
  17. | Id  | Operation          | Name | Rows  | Bytes | Cost (%CPU)| Time     |  
  18. ---------------------------------------------------------------------------  
  19. |   0 | SELECT STATEMENT   |      |  2903 |   113K|   448  (53)| 00:00:06 |  
  20. |*  1 |  HASH JOIN         |      |  2903 |   113K|   448  (53)| 00:00:06 |  
  21. |*  2 |   TABLE ACCESS FULL| T1   |  2903 | 84187 |   288  (81)| 00:00:04 |  
  22. |   3 |   TABLE ACCESS FULL| T2   | 49954 |   536K|   159   (2)| 00:00:02 |  
  23. ---------------------------------------------------------------------------  
  24. Predicate Information (identified by operation id):  
  25. ---------------------------------------------------  
  26.    1 - access("T1"."OBJECT_ID"="T2"."OBJECT_ID")  
  27.    2 - filter("T1"."OBJECT_NAME" LIKE '%T1%')  
  28. Note  
  29. -----  
  30.    - SQL profile "SYS_SQLPROF_014b39f084c88000" used for this statement  

将T1表的统计信息中的表行数改为500万,Oracle就会评估为返回5000000*5%*0.01161091426=2903行。这里执行 计划又变回为full scan+hash join。可以看到,虽然SQL Profile起作用了,但是并没有锁定执行计划。

小结:本文简单介绍了什么是SQL Profiles及其作用,如何使用SQL Tuning Advisor来生成SQL Profile,以及生成的SQL Profile产生的Hint。同时也介绍了SQL的signature。

下一篇将会介绍如何手工来为创建、生成SQL Profile,以及如何让SQL Profile也能像Outlines一样锁定SQL的执行计划,以保持SQL执行计划的稳定性。





本文转自 vfast_chenxy 51CTO博客,原文链接:http://blog.51cto.com/chenxy/896378,如需转载请自行联系原作者

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
redis cluster集群的数据分布原理
redis cluster集群的数据分布原理
5 0
使用Golang语言实现对指定存储桶的删除方法(下)
上一篇文章《使用Golang语言实现对指定存储桶的删除方法(上)》中介绍了删除存储桶前的校验逻辑,今天就来看一看,具体删除存储桶时的逻辑处理。通过上下两篇文章的介绍基本上就把删除存储桶的底层源码实现讲清楚了。正文我们直接进入正题,当删除存储桶时,大概需要三个层逻辑。具体情况,我们接下来单独介绍。
6 0
同事写了一个update,误用一个双引号,生产数据全变0了!
一、前言 最近经常碰到开发误删除误更新数据,这不,他们又给我找了个麻烦,我们来看下整个过程。
4 0
一条SQL查询语句是如何执行的?
还不知道SQL查询语句是如何执行的?看这篇,看不懂来打我吧
9 0
MyBatis 动态 SQL(认真看看, 以后写 SQL 就爽多了)
MyBatis 令人喜欢的一大特性就是动态 SQL。在使用 JDBC 的过程中, 根据条件进行 SQL 的拼接是很麻烦且很容易出错的。MyBatis 动态 SQL 的出现, 解决了这个麻烦。
7 0
为什么 ConcurrentHashMap 的读操作不需要加锁?为什么 ConcurrentHashMap 的读操作不需要加锁?
为什么 ConcurrentHashMap 的读操作不需要我们知道,ConcurrentHashmap(1.8)这个并发集合框架是线程安全的,当你看到源码的get操作时,会发现get操作全程是没有加任何锁的,这也是这篇博文讨论的问题——为什么它不需要加锁呢?加锁?为什么 ConcurrentHashMap 的读操作不需要加锁?
5 0
搞定全局ID生成器:SpringBoot2.x 集成百度 uidgenerator
不成功,最后自己一步一步升级引入依赖,修改增加接口注入来源,最后成功。 升级成功后的源码地址
7 0
搞定全局ID生成器:SpringBoot2.x 集成百度 uidgenerator
不成功,最后自己一步一步升级引入依赖,修改增加接口注入来源,最后成功。 升级成功后的源码地址
4 0
+关注
20382
文章
0
问答
文章排行榜
最热
最新
相关电子书
更多
《2021云上架构与运维峰会演讲合集》
立即下载
《零基础CSS入门教程》
立即下载
《零基础HTML入门教程》
立即下载