sql profile介绍

末蓝、 2022-08-01 00:12 200阅读 0赞

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个测试表：

[view plain][] [copy to clipboard][view plain] [print][view plain] [?][view plain]

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：

[view plain][] [copy to clipboard][view plain] [print][view plain] [?][view plain]

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的成本：

[view plain][] [copy to clipboard][view plain] [print][view plain] [?][view plain]

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。  
但是实际的逻辑读是多少呢？

[view plain][] [copy to clipboard][view plain] [print][view plain] [?][view plain]

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：

[view plain][] [copy to clipboard][view plain] [print][view plain] [?][view plain]

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。

[view plain][] [copy to clipboard][view plain] [print][view plain] [?][view plain]

1.  SQL> execute dbms\_sqltune.accept\_sql\_profile(task\_name => :tuning\_task,replace => TRUE,force\_match=>true);  
2.    
3.  PL/SQL 过程已成功完成。

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

[view plain][] [copy to clipboard][view plain] [print][view plain] [?][view plain]

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″。

[view plain][] [copy to clipboard][view plain] [print][view plain] [?][view plain]

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实际上是些什么：

[view plain][] [copy to clipboard][view plain] [print][view plain] [?][view plain]

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。通过下面的数据可以看出区 别：

[view plain][] [copy to clipboard][view plain] [print][view plain] [?][view plain]

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一样的生成标准。

[view plain][] [copy to clipboard][view plain] [print][view plain] [?][view plain]

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的结果发现了什么？

[view plain][] [copy to clipboard][view plain] [print][view plain] [?][view plain]

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的执行计划，只是提供了更多、更准确的统计信息给优化器。看下面的测试：

[view plain][] [copy to clipboard][view plain] [print][view plain] [?][view plain]

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执行计划的稳定性。

[view plain]: http://www.laoxiong.net/sql-profiles-part.html#

发表评论取消回复

表情：

评论列表（有 0 条评论，200人围观）

还没有评论，来说两句吧...

相关阅读

相关 MySQL 5.5 SHOW PROFILE、SHOW PROFILES语句介绍

*SHOW PROFILE 和 SHOW PROFILES 语句显示 MySQL 数据库语句的资源消耗情况。需要注意的是：这两条命令均显示当前会话的SQL资源消耗情...

我就是我/ 2024年04月17日 23:56/ 0 赞/ 74 阅读

相关 SQL Server 之 SQL Server Profiler

今天遇到服务器CPU占用率一直90%多的问题，一查SQL Server占用的，但是这个服务器上又有很多个站点，所以不知道是哪个站点出的问题，于是就想到了SQL Server P

红太狼/ 2022年12月27日 02:22/ 0 赞/ 251 阅读

相关 Maven简介——profile介绍

原文地址http://haohaoxuexi.iteye.com/blog/1900568 4 profile介绍 4.1 profile简介

Love The Way You Lie/ 2022年08月18日 00:47/ 0 赞/ 79 阅读

相关 MySQL SQL剖析(SQL profile)

分析SQL执行带来的开销是优化SQL的重要手段。在MySQL数据库中，可以通过配置profiling参数来启用SQL剖析。该参数可以在全局和session级别来设置。对

女爷i/ 2022年08月13日 02:58/ 0 赞/ 160 阅读

相关 SQL Profiles-MANUAL

Manual管理SQL Profile步骤 1、针对目标sql使用脚本coe\_xfr\_sql\_profile.sql产生能生成其Manual类型的SQL Profil

谁践踏了优雅/ 2022年08月08日 05:26/ 0 赞/ 145 阅读

相关 SQL Profiles-AUTO

http://www.laoxiong.net/sql-profiles-part.html http://www.laoxiong.net/sql-profiles-pa

￡神魔★判官ぃ/ 2022年08月08日 05:26/ 0 赞/ 7 阅读

相关 coe_xfr_sql_profile.sql

SPO coe_xfr_sql_profile.log; SET DEF ON TERM OFF ECHO ON FEED OFF VER OFF HEA O

Bertha 。/ 2022年08月08日 05:26/ 0 赞/ 126 阅读

相关 sql profile介绍

Oracle 11g从发布到现在，也有几个年头了。而在国内来说，Oracle 10g仍然是主流，甚至一些电信运营商的核心系统仍然在使用9i。作为Oracle 10g的一项新特性

末蓝、/ 2022年08月01日 00:12/ 0 赞/ 201 阅读

相关 sql profile使用

在上一篇[《SQL Profiles-Part I》][SQL Profiles-Part I]，我向大家介绍了什么是SQL Profiles及其作用，如何使用SQL Tun

r囧r小猫/ 2022年08月01日 00:12/ 0 赞/ 211 阅读

相关 profile介绍

4 profile介绍 4.1 profile简介 profile可以让我们定义一系列的配置信息，然后指定其激活条件。这样我们就可以定义多个pr

素颜马尾好姑娘i/ 2022年07月16日 03:16/ 0 赞/ 155 阅读