sitemap

RSS地图

收藏本站

设为首页

Oracle研究中心

当前位置:Oracle研究中心 > 运维DBA > Oracle性能优化 >

【案例】Oracle优化时使用outlines但SQLID执行计划错误原因

时间:2016-11-20 14:31   来源:Oracle研究中心   作者:网络   点击:

天萃荷净 Oracle研究中心案例分析:运维DBA反映在优化Oracle数据库时遇到使用了outlines,但是SQLID执行仍然出现执行计划错误的情,导致大量的read by other session等待,严重影响业务,最后通过revoke和grant来解决了。

本站文章除注明转载外,均为本站原创: 转载自love wife & love life —Roger 的Oracle技术博客
本文链接地址: cursor_sharing+outline的问题

下面的问题就是如何去找到当时的问题所在?换句话说,当时的那个sql语句为什么不走index scan而选择低效的full table scan呢

错误的执行计划如下:
Plan hash VALUE: 1414349908
-----------------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                        | Name                   | ROWS  | Bytes |TempSpc| Cost (%CPU)| TIME     | Pstart| Pstop |
-----------------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                 |                        |       |       |       |   100K(100)|          |       |       |
|   1 |  SORT ORDER BY                   |                        |   157K|    16M|    35M|   100K  (2)| 00:20:03 |       |       |
|   2 |   HASH UNIQUE                    |                        |   157K|    16M|    35M| 96389   (2)| 00:19:17 |       |       |
|   3 |    HASH JOIN                     |                        |   157K|    16M|       | 92578   (2)| 00:18:31 |       |       |
|   4 |     TABLE ACCESS FULL            | ACCT_ITEM_TYPE         |  2817 | 73242 |       |    15   (0)| 00:00:01 |       |       |
|   5 |     HASH JOIN                    |                        |   157K|    12M|       | 92561   (2)| 00:18:31 |       |       |
|   6 |      TABLE ACCESS FULL           | BILLING_CYCLE          |   156 |  3900 |       |    15   (0)| 00:00:01 |       |       |
|   7 |      HASH JOIN                   |                        |   158K|  8647K|       | 92544   (2)| 00:18:31 |       |       |
|   8 |       TABLE ACCESS BY INDEX ROWID| A_PAY_OWE_STATE        |     3 |    21 |       |     2   (0)| 00:00:01 |       |       |
|   9 |        INDEX RANGE SCAN          | INDX_PAYMENT_METHOD_01 |     3 |       |       |     1   (0)| 00:00:01 |       |       |
|  10 |       PARTITION HASH SINGLE      |                        |   368K|    17M|       | 92538   (2)| 00:18:31 |   KEY |   KEY |
|  11 |        TABLE ACCESS FULL         | ACCT_ITEM_OWE          |   368K|    17M|       | 92538   (2)| 00:18:31 |   KEY |   KEY |
-----------------------------------------------------------------------------------------------------------------------------------

下面是正确的执行计划:
Plan hash VALUE: 2474252999

-----------------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                                | Name                   | ROWS  | Bytes | Cost (%CPU)| TIME     | Pstart| Pstop |
-----------------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                         |                        |       |       |   198 (100)|          |       |       |
|   1 |  SORT ORDER BY                           |                        |    52 |  5304 |   198   (3)| 00:00:03 |       |       |
|   2 |   HASH UNIQUE                            |                        |    52 |  5304 |   197   (2)| 00:00:03 |       |       |
|   3 |    HASH JOIN                             |                        |    52 |  5304 |   196   (2)| 00:00:03 |       |       |
|   4 |     HASH JOIN                            |                        |    52 |  4004 |   181   (2)| 00:00:03 |       |       |
|   5 |      TABLE ACCESS BY INDEX ROWID         | A_PAY_OWE_STATE        |     3 |    21 |     2   (0)| 00:00:01 |       |       |
|   6 |       INDEX RANGE SCAN                   | INDX_PAYMENT_METHOD_01 |     3 |       |     1   (0)| 00:00:01 |       |       |
|   7 |      MERGE JOIN                          |                        |   121 |  8470 |   178   (1)| 00:00:03 |       |       |
|   8 |       TABLE ACCESS BY INDEX ROWID        | BILLING_CYCLE          |    70 |  1470 |     4   (0)| 00:00:01 |       |       |
|   9 |        INDEX FULL SCAN                   | PK_BILLING_CYCLE       |   157 |       |     1   (0)| 00:00:01 |       |       |
|  10 |       SORT JOIN                          |                        |   132 |  6468 |   174   (1)| 00:00:03 |       |       |
|  11 |        TABLE ACCESS BY GLOBAL INDEX ROWID| ACCT_ITEM_OWE          |   132 |  6468 |   173   (0)| 00:00:03 | ROW L | ROW L |
|  12 |         INDEX RANGE SCAN                 | IDX_ACCT_ITEM_ACCT_ID  |   132 |       |     9   (0)| 00:00:01 |       |       |
|  13 |     TABLE ACCESS FULL                    | ACCT_ITEM_TYPE         |  2845 | 71125 |    15   (0)| 00:00:01 |       |       |
-----------------------------------------------------------------------------------------------------------------------------------

我们可以发现,区别就在是否使用了index IDX_ACCT_ITEM_ACCT_ID,进而导致整个执行计划差别非常之大,还可以看到正常的情况下使用了merge join。

处理问题的思路是这样的:

1. 首先查看outline是否正常使用


SQL> SELECT owner,name,used,version,ENABLED FROM DBA_OUTLINES
  2  WHERE owner='ACCT';

OWNER     NAME                           USED VERSION       ENABLED
--------- ------------------------------ ------------------- --------
ACCT      SYS_OUTLINE_11091615175537003  USED 10.2.0.4.0    ENABLED

-- outline正常。

2. 检查outline定义是否包含INDEX hint IDX_ACCT_ITEM_ACCT_ID.


SQL> SELECT ol_name, hint#, hint_text
  2  FROM OUTLN.ol$hints
  3  ORDER BY ol_name, hint#;

OL_NAME                        HINT# HINT_TEXT
------------------------------ ----- ------------------------------------------------------------------------------------------
SYS_OUTLINE_11091615175537003      1 USE_HASH(@"SEL$5DA710D3" "D"@"SEL$1")
SYS_OUTLINE_11091615175537003      2 USE_HASH(@"SEL$5DA710D3" "A_PAY_OWE_STATE"@"SEL$2")
SYS_OUTLINE_11091615175537003      3 USE_MERGE(@"SEL$5DA710D3" "A"@"SEL$1")
SYS_OUTLINE_11091615175537003      4 LEADING(@"SEL$5DA710D3" "H"@"SEL$1" "A"@"SEL$1" "A_PAY_OWE_STATE"@"SEL$2" "D"@"SEL$1")
SYS_OUTLINE_11091615175537003      5 FULL(@"SEL$5DA710D3" "D"@"SEL$1")
SYS_OUTLINE_11091615175537003      6 INDEX_RS_ASC(@"SEL$5DA710D3" "A_PAY_OWE_STATE"@"SEL$2" ("A_PAY_OWE_STATE"."PAYMENT_METHOD"))
SYS_OUTLINE_11091615175537003      7 INDEX_RS_ASC(@"SEL$5DA710D3" "A"@"SEL$1" ("ACCT_ITEM_OWE"."ACCT_ID"))
SYS_OUTLINE_11091615175537003      8 INDEX(@"SEL$5DA710D3" "H"@"SEL$1" ("BILLING_CYCLE"."BILLING_CYCLE_ID"))
SYS_OUTLINE_11091615175537003      9 OUTLINE(@"SEL$2")
SYS_OUTLINE_11091615175537003     10 OUTLINE(@"SEL$1")
SYS_OUTLINE_11091615175537003     11 UNNEST(@"SEL$2")
SYS_OUTLINE_11091615175537003     12 OUTLINE_LEAF(@"SEL$5DA710D3")
SYS_OUTLINE_11091615175537003     13 ALL_ROWS
SYS_OUTLINE_11091615175537003     14 OPTIMIZER_FEATURES_ENABLE('10.2.0.4')
SYS_OUTLINE_11091615175537003     15 IGNORE_OPTIM_EMBEDDED_HINTS

15 ROWS selected.   

从INDEX_RS_ASC(@"SEL$5DA710D3" "A"@"SEL$1" ("ACCT_ITEM_OWE"."ACCT_ID"))看,outline是有的。

3. 检查相关的对象在故障期间之前是否做过相应的ddl操作


SQL> SELECT OWNER,OBJECT_NAME,SUBOBJECT_NAME,LAST_DDL_TIME,STATUS
  2  FROM dba_objects
  3  WHERE OBJECT_NAME='ACCT_ITEM_OWE';

OWNER    OBJECT_NAME      SUBOBJECT_NAME         LAST_DDL_TIM STATUS
-------- ---------------- ---------------------- ------------ -------
COMM     ACCT_ITEM_OWE                           02-MAR-09    VALID
ACCT     ACCT_ITEM_OWE    P_ACCT_ITEM_OWE_0      28-FEB-09    VALID
ACCT     ACCT_ITEM_OWE    P_ACCT_ITEM_OWE_1      28-FEB-09    VALID
ACCT     ACCT_ITEM_OWE    P_ACCT_ITEM_OWE_2      28-FEB-09    VALID
ACCT     ACCT_ITEM_OWE    P_ACCT_ITEM_OWE_3      28-FEB-09    VALID
ACCT     ACCT_ITEM_OWE    P_ACCT_ITEM_OWE_4      28-FEB-09    VALID
ACCT     ACCT_ITEM_OWE    P_ACCT_ITEM_OWE_5      28-FEB-09    VALID
ACCT     ACCT_ITEM_OWE    P_ACCT_ITEM_OWE_6      28-FEB-09    VALID
ACCT     ACCT_ITEM_OWE    P_ACCT_ITEM_OWE_7      28-FEB-09    VALID
ACCT     ACCT_ITEM_OWE    P_ACCT_ITEM_OWE_8      28-FEB-09    VALID
ACCT     ACCT_ITEM_OWE    P_ACCT_ITEM_OWE_9      28-FEB-09    VALID
ACCT     ACCT_ITEM_OWE                           19-SEP-11    VALID

12 ROWS selected.

SQL> SELECT OWNER,OBJECT_NAME,SUBOBJECT_NAME,LAST_DDL_TIME,STATUS FROM
  2  dba_objects WHERE OBJECT_NAME='IDX_ACCT_ITEM_ACCT_ID';

OWNER       OBJECT_NAME             SUBOBJECT_NAME    LAST_DDL_TIM STATUS
----------- ----------------------- ----------------- ------------ -------
ACCT        IDX_ACCT_ITEM_ACCT_ID                     28-FEB-09    VALID

检查发现, 9月18号并无DDL操作。

4. 查询该SQLID是否存在多个child NUMBER或存在多个执行计划

   昨天下午查询v$sql已经找不到那个SQLID了,通过如下查询发现:

SQL> SELECT sql_id,CHILD_NUMBER,SQL_TYPE_MISMATCH,OPTIMIZER_MISMATCH,OUTLINE_MISMATCH,BIND_MISMATCH,STATS_ROW_MISMATCH
  2  FROM V$SQL_SHARED_CURSOR
  3  WHERE SQL_ID='&id';                                                                   

Enter VALUE FOR id: 4u9y643v2k8fw                                                                                   
OLD   2: FROM V$SQL_SHARED_CURSOR WHERE SQL_ID='&id'                                                                
NEW   2: FROM V$SQL_SHARED_CURSOR WHERE SQL_ID='4u9y643v2k8fw'                                                      

SQL_ID        CHILD_NUMBER S O O B S                                                                                
------------- ------------ - - - - -                                                                                
4u9y643v2k8fw            0 N N N N N                                                                                
4u9y643v2k8fw            1 N N Y N N                                                                                
4u9y643v2k8fw            2 N N N N N                                                                                
4u9y643v2k8fw            3 N N Y N N                                                                                
4u9y643v2k8fw            4 N N Y N N                                                                                
4u9y643v2k8fw            5 N N Y N N                                                                                
4u9y643v2k8fw            6 N N N N N                                                                                
4u9y643v2k8fw            7 N N N N N                                                                                
4u9y643v2k8fw            8 N N N N N                                                                                
4u9y643v2k8fw            9 N N N N N                                                                                
4u9y643v2k8fw           10 N N N N N                                                                                
4u9y643v2k8fw           11 N N N N N                                                                                
4u9y643v2k8fw           12 N N N N N                                                                                
4u9y643v2k8fw           13 N N N N N                                                                                
4u9y643v2k8fw           14 N N N N N                                                      Oracleо                          
4u9y643v2k8fw           15 N N N N N                                                                                
4u9y643v2k8fw           16 N N N N N                                                                                
4u9y643v2k8fw           17 N N N N N                                                                                
4u9y643v2k8fw           18 N N N N N                                                                                
4u9y643v2k8fw           19 N N N N N                                                                                
4u9y643v2k8fw           20 N N N N N                                                                                

21 ROWS selected.      

备注:这里的第2个O是指OUTLINE_MISMATCH。

可以发现该sqlid出现了多个child cursor,另外检查发现参数cursor_sharing设置为simlair了。

该sqlid SQL version肯定也较高。 

这里有一点让我不解的是,通过DBA_HIST_*相关视图查询,发现当时出问题的时候的sqlid的child NUMBER跟V$SQL_SHARED_CURSOR并不相同,当然这也不能完全说明问题,很可能SQL已经被FLUSH OUT多次了。

通过查hist视图,可以发现当时故障期间出现大量的READ BY other SESSION等待:

  EVENT                    COUNT(*) SESSION_ID SESSION SQL_ID        SQL_CHILD_NUMBER SQL_PLAN_HASH_VALUE FORCE_MATCHING_SIGNATURE TIME_WAITED
----------------------- --------- ---------- ------- ------------- ---------------- ------------------- ------------------------ -----------
db file scattered READ          1       1382 WAITING 4u9y643v2k8fw               18          1414349908                        0        4502
READ BY other SESSION           1       1398 WAITING 4u9y643v2k8fw               18          1414349908                        0        8099
READ BY other SESSION           1       1404 WAITING 4u9y643v2k8fw               18          1414349908                        0          89
db file scattered READ          1       1424 WAITING 4u9y643v2k8fw               18          1414349908                        0        8483
READ BY other SESSION           1       1633 WAITING 4u9y643v2k8fw               18          1414349908                        0       10470
READ BY other SESSION           1       2081 WAITING 4u9y643v2k8fw               18          1414349908               4.3893E+18        2047
READ BY other SESSION           1       2239 WAITING 4u9y643v2k8fw               18          1414349908                        0        5403
READ BY other SESSION           1        685 WAITING 4u9y643v2k8fw               18          1414349908                        0       11577
READ BY other SESSION           1       1094 WAITING 4u9y643v2k8fw               18          1414349908                        0        6340
READ BY other SESSION           1       1168 WAITING 4u9y643v2k8fw               18          1414349908               4.3893E+18        1427
READ BY other SESSION           1       1304 WAITING 4u9y643v2k8fw               18          1414349908                        0       12656

5. 查看sqlid是否使用了outline

SQL> SELECT SQL_ID,CHILD_NUMBER
  2  FROM v$sql_plan
  3  WHERE sql_id='4u9y643v2k8fw';

SQL_ID        CHILD_NUMBER
------------- ------------
4u9y643v2k8fw           12
4u9y643v2k8fw           12
.....
4u9y643v2k8fw           12
4u9y643v2k8fw            2
4u9y643v2k8fw            2
4u9y643v2k8fw            2
......
4u9y643v2k8fw            2
4u9y643v2k8fw            2

28 ROWS selected.

下午查询时只有NUMBER为2 12

SQL> SELECT info outline_name
  2    FROM (SELECT ROWNUM r, EXTRACTVALUE (VALUE (d), '/info') info
  3           FROM v$sql_plan p,
  4                TABLE (XMLSEQUENCE (EXTRACT (XMLTYPE (p.other_xml),
  5                                             '/other_xml/info'
  6                                            )
  7                                   )
  8                      ) d
  9          WHERE other_xml IS NOT NULL
  10           AND ID = 1
  11           AND sql_id = '4u9y643v2k8fw'
  12           AND child_number = 3)
  13 WHERE r = 4;

no ROWS selected

SQL> SELECT info outline_name
  2    FROM (SELECT ROWNUM r, EXTRACTVALUE (VALUE (d), '/info') info
  3            FROM v$sql_plan p,
  4                 TABLE (XMLSEQUENCE (EXTRACT (XMLTYPE (p.other_xml),
  5                                              '/other_xml/info'
  6                                             )
  7                                    )
  8                       ) d
  9           WHERE other_xml IS NOT NULL
  10            AND ID = 1
  11            AND sql_id = '4u9y643v2k8fw'
  12            AND child_number = 4)
  13  WHERE r = 4;

no ROWS selected

SQL> SELECT info outline_name
  2    FROM (SELECT ROWNUM r, EXTRACTVALUE (VALUE (d), '/info') info
  3            FROM v$sql_plan p,
  4                 TABLE (XMLSEQUENCE (EXTRACT (XMLTYPE (p.other_xml),
  5                                              '/other_xml/info'
  6                                             )
  7                                    )
  8                       ) d
  9           WHERE other_xml IS NOT NULL
  10            AND ID = 1
  11            AND sql_id = '4u9y643v2k8fw'
  12            AND child_number = 5)
  13  WHERE r = 4;

no ROWS selected

SQL> SELECT info outline_name
  2    FROM (SELECT ROWNUM r, EXTRACTVALUE (VALUE (d), '/info') info
  3            FROM v$sql_plan p,
  4                 TABLE (XMLSEQUENCE (EXTRACT (XMLTYPE (p.other_xml),
  5                                              '/other_xml/info'
  6                                             )
  7                                    )
  8                       ) d
  9           WHERE other_xml IS NOT NULL
  10            AND ID = 1
  11            AND sql_id = '4u9y643v2k8fw'
  12            AND child_number = 2)
  13  WHERE r = 4;

OUTLINE_NAME
--------------------------------------------------------------------------------
"SYS_OUTLINE_11091615175537003"

SQL> SELECT info outline_name
  2    FROM (SELECT ROWNUM r, EXTRACTVALUE (VALUE (d), '/info') info
  3            FROM v$sql_plan p,
  4                 TABLE (XMLSEQUENCE (EXTRACT (XMLTYPE (p.other_xml),
  5                                              '/other_xml/info'
  6                                             )
  7                                    )
  8                       ) d
  9           WHERE other_xml IS NOT NULL
  10            AND ID = 1
  11            AND sql_id = '4u9y643v2k8fw'
  12            AND child_number = 12)
  13  WHERE r = 4;

OUTLINE_NAME
--------------------------------------------------------------------------------
"SYS_OUTLINE_11091615175537003"

可以看到,该SQL的当前的2个child cursor都是使用了outline的。

但是这说明不了问题,既然该SQL存在多个child cursor,那么必然存在多个plan hash VALUE值。

这里我们需要去查询那个出问题的sqlid对应的plan_hash_value所对应的执行计划。

虽然说是有awr快照,但是通过这个方式已经查不到信息了。

SELECT * FROM TABLE(dbms_xplan.display_awr('&sql_id','&child_number',NULL,'advanced'));

我这里使用的如下的查询方式:

SQL> SET long 1000000
SQL> SET linesize 200

SQL> SELECT plan_hash_value, XMLTYPE (other_xml).EXTRACT ('/*')
  2    FROM dba_hist_sql_plan
  3   WHERE sql_id = '4u9y643v2k8fw'
  4     AND plan_hash_value IN (1414349908)
  5     AND DBMS_LOB.SUBSTR (other_xml, 1000) LIKE '%
  6  /

PLAN_HASH_VALUE
---------------
XMLTYPE(OTHER_XML).EXTRACT('/*')
--------------------------------------------------------------------------------------------------------------------------------
     1414349908
<other_xml>
  <info TYPE="db_version">10.2.0.4info>
  <info TYPE="parse_schema"><![CDATA["ACCT"]]>info>
  <info TYPE="plan_hash">1414349908info>
  <peeked_binds>
    <bind nam=":IPAYMETH" pos="17" dty="2" pre="0" scl="0" mxl="22">c10cbind>
    <bind nam=":IACTION" pos="18" dty="2" pre="0" scl="0" mxl="22">c103bind>
    <bind nam=":SYS_B_16" pos="19" dty="1" csi="852" frm="1" mxl="32">313042bind>

PLAN_HASH_VALUE
---------------
XMLTYPE(OTHER_XML).EXTRACT('/*')
--------------------------------------------------------------------------------------------------------------------------------
    <bind nam=":SYS_B_17" pos="20" dty="1" csi="852" frm="1" mxl="32">313044bind>
    <bind nam=":LACCTID" pos="21" dty="2" pre="0" scl="0" mxl="22">c6481504081c43bind>
  peeked_binds>
  <outline_data>
    <hint><![CDATA[IGNORE_OPTIM_EMBEDDED_HINTS]]>hint>
    <hint><![CDATA[OPTIMIZER_FEATURES_ENABLE('10.2.0.4')]]>hint>
    <hint><![CDATA[ALL_ROWS]]>hint>
    <hint><![CDATA[OUTLINE_LEAF(@"SEL$5DA710D3")]]>hint>
    <hint><![CDATA[UNNEST(@"SEL$2")]]>hint>

PLAN_HASH_VALUE
---------------
XMLTYPE(OTHER_XML).EXTRACT('/*')
--------------------------------------------------------------------------------------------------------------------------------
    <hint><![CDATA[OUTLINE(@"SEL$1")]]>hint>
    <hint><![CDATA[OUTLINE(@"SEL$2")]]>hint>
    <hint><![CDATA[INDEX_RS_ASC(@"SEL$5DA710D3" "A_PAY_OWE_STATE"@"SEL$2" ("A_PAY_OWE_STATE"."PAYMENT_METHOD"))]]>hint>
    <hint><![CDATA[FULL(@"SEL$5DA710D3" "A"@"SEL$1")]]>hint>
    <hint><![CDATA[FULL(@"SEL$5DA710D3" "H"@"SEL$1")]]>hint>
    <hint><![CDATA[FULL(@"SEL$5DA710D3" "D"@"SEL$1")]]>hint>
    <hint><![CDATA[LEADING(@"SEL$5DA710D3" "A_PAY_OWE_STATE"@"SEL$2" "A"@"SEL$1" "H"@"SEL$1" "D"@"SEL$1")]]>hint>
    <hint><![CDATA[USE_HASH(@"SEL$5DA710D3" "A"@"SEL$1")]]>hint>
    <hint><![CDATA[USE_HASH(@"SEL$5DA710D3" "H"@"SEL$1")]]>hint>

PLAN_HASH_VALUE
---------------
XMLTYPE(OTHER_XML).EXTRACT('/*')
--------------------------------------------------------------------------------------------------------------------------------
    <hint><![CDATA[USE_HASH(@"SEL$5DA710D3" "D"@"SEL$1")]]>hint>
    <hint><![CDATA[SWAP_JOIN_INPUTS(@"SEL$5DA710D3" "H"@"SEL$1")]]>hint>
    <hint><![CDATA[SWAP_JOIN_INPUTS(@"SEL$5DA710D3" "D"@"SEL$1")]]>hint>
  outline_data>
other_xml>

从上面的查询来看,当时是使用了outline,但是问题出在这里:
    <hint><![CDATA[FULL(@"SEL$5DA710D3" "A"@"SEL$1")]]>hint>
    <hint><![CDATA[FULL(@"SEL$5DA710D3" "H"@"SEL$1")]]>hint>
    <hint><![CDATA[FULL(@"SEL$5DA710D3" "D"@"SEL$1")]]>hint>
也就是说正常情况下,这3条当中至少有1条是ACCT_ID的index rang scan才对。

今天上午,和同事沟通,说又出问题了,同事将参数cursor_sharing调为exact了,即默认值。

虽然这样会导致很多sql语句的硬解析,但是听他说上午调整以后到11点时,还没出现问题。

跟itpub版主棉花糖ONE交流了一下,他认为很可能是outline和cursor_sharing的bug。   

但是我仍然觉得cursor_sharing可能不是真正的原因,因为ACCT_ID列是应用绑定变量列,
并不是通过参数cursor_sharing的设置来实现绑定变量的。

最后总结一下:

9i以后都不推荐再用outline了,感觉不太稳定,推荐使用sql profile来固定执行计划。至于最后的结论到底是outline的bug还是cursor_sharing=similar的bug,现在还确定不了,只是可能性非常大。

--------------------------------------ORACLE-DBA----------------------------------------

最权威、专业的Oracle案例资源汇总之【案例】Oracle优化时使用outlines但SQLID执行计划错误原因

本文由大师惜分飞原创分享,网址:http://www.oracleplus.net/arch/1297.html

Oracle研究中心

关键词:

Oracle SQL优化笔记

cursor_sharing+outline的问题

Oracle outlines使用案例

Oracle等待事件read by other session优化