国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

有關11g關閉自適應游標需要注意的問題整理

IT那活兒 / 1437人閱讀
有關11g關閉自適應游標需要注意的問題整理
一. 為什么要關閉自適應游標


  • 可能會導致一定數量的硬解析

  • 可能會導致一定數量的額外的child cursor掛在同一個父游標下，這會增加軟解析、軟軟解析時查找匹配子游標的工作量

  • 為了存儲這些額外的子游標，shared pool在空間方面也會承受額外的壓力，需要額外的調整shared pool的大小


二. 如何關閉

如果因為開啟了自適應游標共享而導致系統產生了過多的子游標，進而導致shared pool空間緊張或者過多的mutex等待，則可以通過如下任意的一種方式來關閉自適應游標共享

  • 將隱含參數_optimizer_extended_cursor_sharing和_optimizer_extended_cursor_sharing_rel的值設為none，這樣就關閉了可擴展性游標共享。一旦可擴展性游標共享被禁，所有的子游標不能再被標記為綁定敏感，而綁定敏感是綁定感知的前提條件，一旦不能被標記為綁定敏感，則后續的綁定感知就無法進行

  • 將隱含參數_optimizer_adaptive_cursor_sharing的值設置為false，一旦這個值被設置的false，子游標就不能被標記為綁定感知，也就是說自適應游標被關閉了

當啟用綁定變量窺探之后，每次Oracle以硬解析的方式解析了使用綁定變量的目標SQL時，Oracle都會實際窺探（Peeking）一下對應綁定變量變量的具體輸入值，并以這些值為標準，來決定這些使用了綁定變量的目標SQL的where條件中的selectivity和Cardinality的值，并根據此信息來選擇該SQL的執行計劃，當綁定變量的目標SQL再次執行時（軟解析或者軟軟解析），即便此時對應綁定變量的具體輸入值和之前硬解析時對應的值不同，Oracle也會沿用之前硬解析所產生的解析數和執行計劃，而不會再次進行窺探的動作。


三. 案例演示

1.關閉參數

alter system set "_optimizer_adaptive_cursor_sharing"=none sid=*;
alter system set "_optimizer_extended_cursor_sharing"=none sid=*;
或者
alter system set "_optimizer_extended_cursor_sharing_rel"=false sid=*;

2.測試驗證

1) 創建測試表

create table t as select * from dba_objects;

2) 創建索引

create index t_id on t(status);

3) 執行以下SQL，收集統計信息

select count(*) from t where status=INVALID;
exec dbms_stats.gather_table_stats(dbmon,t,cascade=>true,no_invalidate=>false);

4）查看表status列是否已經收集統計信息，從下面查詢可以看到status已經有統計信息

SQL> select COLUMN_NAME,HISTOGRAM from dba_tab_col_statistics where owner=DBMON and table_name=T;

COLUMN_NAME                    HISTOGRAM
-------------------------------------   -------------------------
OWNER                                NONE
OBJECT_NAME                     NONE
SUBOBJECT_NAME              NONE
OBJECT_ID                            NONE
DATA_OBJECT_ID                 NONE
OBJECT_TYPE                      NONE
CREATED                               NONE
LAST_DDL_TIME                    NONE
TIMESTAMP                            NONE
STATUS                                   FREQUENCY
TEMPORARY                          NONE


COLUMN_NAME                    HISTOGRAM
--------------------------------------  --------------------------
GENERATED                           NONE
SECONDARY                           NONE
NAMESPACE                           NONE
EDITION_NAME                       NONE

5）使用綁定變量進行驗證測試

var b varchar2(20);

--當我們使用值INVALID，我們肯定是認為走索引

exec :b:=INVALID;

select count(distinct object_name) from t where status=:b;

--通過SQL執行計劃，確是和我們的想法是一樣的

-------------------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                      | Name     | Starts | E-Rows |E-Bytes| Cost (%CPU)| E-Time   | A-Rows |   A-Time   | Buffers |
-------------------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT               |          |      1 |        |       |    14 (100)|          |      1 |00:00:00.01 |      96 |
|   1 |  SORT AGGREGATE                |          |      1 |      1 |    66 |            |          |      1 |00:00:00.01 |      96 |
|   2 |   VIEW                         | VW_DAG_0 |      1 |    693 | 45738 |    14   (8)| 00:00:01 |    440 |00:00:00.01 |      96 |
|   3 |    HASH GROUP BY               |          |      1 |    693 | 22176 |    14   (8)| 00:00:01 |    440 |00:00:00.01 |      96 |
|   4 |     TABLE ACCESS BY INDEX ROWID| T        |      1 |    695 | 22240 |    13   (0)| 00:00:01 |    659 |00:00:00.01 |      96 |
|*  5 |      INDEX RANGE SCAN          | T_ID     |      1 |    695 |       |     2   (0)| 00:00:01 |    659 |00:00:00.01 |       3 |
-------------------------------------------------------------------------------------------------------------------------------------

--多次執行SQL，使該SQL為軟軟解析狀態

select count(distinct object_name) from t where status=:b;
select count(distinct object_name) from t where status=:b;

--替換綁定變量值VALID，根據數據的分布，我們肯定認為該SQL是走全表掃描的

exec :b:=VALID;
select count(distinct object_name) from t where status=:b;

--通過SQL執行計劃，我們發現和我們的判斷是相反的，SQL還是走的索引。從buffers可以看到數據很大，應該走全表掃描

-------------------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                      | Name     | Starts | E-Rows |E-Bytes| Cost (%CPU)| E-Time   | A-Rows |   A-Time   | Buffers |
-------------------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT               |          |      1 |        |       |    14 (100)|          |      1 |00:00:00.11 |    1443 |
|   1 |  SORT AGGREGATE                |          |      1 |      1 |    66 |            |          |      1 |00:00:00.11 |    1443 |
|   2 |   VIEW                         | VW_DAG_0 |      1 |    693 | 45738 |    14   (8)| 00:00:01 |  51967 |00:00:00.10 |    1443 |
|   3 |    HASH GROUP BY               |          |      1 |    693 | 22176 |    14   (8)| 00:00:01 |  51967 |00:00:00.09 |    1443 |
|   4 |     TABLE ACCESS BY INDEX ROWID| T        |      1 |    695 | 22240 |    13   (0)| 00:00:01 |  85956 |00:00:00.05 |    1443 |
|*  5 |      INDEX RANGE SCAN          | T_ID     |      1 |    695 |       |     2   (0)| 00:00:01 |  85956 |00:00:00.02 |     206 |
-------------------------------------------------------------------------------------------------------------------------------------

--多次執行該SQL，執行計劃并沒有發生改變。

select count(distinct object_name) from t where status=:b;

-------------------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                      | Name     | Starts | E-Rows |E-Bytes| Cost (%CPU)| E-Time   | A-Rows |   A-Time   | Buffers |
-------------------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT               |          |      1 |        |       |    14 (100)|          |      1 |00:00:00.09 |    1443 |
|   1 |  SORT AGGREGATE                |          |      1 |      1 |    66 |            |          |      1 |00:00:00.09 |    1443 |
|   2 |   VIEW                         | VW_DAG_0 |      1 |    693 | 45738 |    14   (8)| 00:00:01 |  51967 |00:00:00.09 |    1443 |
|   3 |    HASH GROUP BY               |          |      1 |    693 | 22176 |    14   (8)| 00:00:01 |  51967 |00:00:00.07 |    1443 |
|   4 |     TABLE ACCESS BY INDEX ROWID| T        |      1 |    695 | 22240 |    13   (0)| 00:00:01 |  85956 |00:00:00.04 |    1443 |
|*  5 |      INDEX RANGE SCAN          | T_ID     |      1 |    695 |       |     2   (0)| 00:00:01 |  85956 |00:00:00.01 |     206 |
-------------------------------------------------------------------------------------------------------------------------------------

select count(distinct object_name) from t where status=:b;
-------------------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                      | Name     | Starts | E-Rows |E-Bytes| Cost (%CPU)| E-Time   | A-Rows |   A-Time   | Buffers |
-------------------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT               |          |      1 |        |       |    14 (100)|          |      1 |00:00:00.09 |    1443 |
|   1 |  SORT AGGREGATE                |          |      1 |      1 |    66 |            |          |      1 |00:00:00.09 |    1443 |
|   2 |   VIEW                         | VW_DAG_0 |      1 |    693 | 45738 |    14   (8)| 00:00:01 |  51967 |00:00:00.09 |    1443 |
|   3 |    HASH GROUP BY               |          |      1 |    693 | 22176 |    14   (8)| 00:00:01 |  51967 |00:00:00.07 |    1443 |
|   4 |     TABLE ACCESS BY INDEX ROWID| T        |      1 |    695 | 22240 |    13   (0)| 00:00:01 |  85956 |00:00:00.04 |    1443 |
|*  5 |      INDEX RANGE SCAN          | T_ID     |      1 |    695 |       |     2   (0)| 00:00:01 |  85956 |00:00:00.01 |     206 |
-------------------------------------------------------------------------------------------------------------------------------------

3. 總結

簡單描述：如果關閉自適應游標，含有直方圖信息的列使用綁定變量，目標SQL執行多次后（該SQL為軟解析或者軟軟解析狀態），后續綁定變量無論傳入任何值，都會沿用第一次執行SQL的執行計劃，即使這個執行計劃是錯誤的。和丁偉大哥觀察，移動業務都是關閉的，含有直方圖信息的列使用綁定變量需要注意是否存在執行計劃不準確的問題。


END



更多精彩干貨分享

點擊下方名片關注

IT那活兒

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/129783.html

相關文章

  • Oracle Linux And Oracle Database 11g R2 Intsallati

    摘要：最近工作中用到了作為測試的數據庫，在裝和折騰了很久，這篇文章就這兩點對大家分享一些我安裝過程中遇到的問題和注意點，暫時還未配置，稍后找時間補上現在網上找一篇好的文章好難，往往要在一個話題或技術上找多方資源東拼西湊，互相借鑒才能達成目的，原因 最近工作中用到了Oracle作為Intel測試的數據庫，在裝Oracle Linux和Oracle Database 11g R2折騰了很久，這...

    Flands 評論0 收藏0

發表評論

0條評論

IT那活兒

男|高級講師

TA的文章

閱讀更多
最新活動
閱讀需要支付1元查看
<