Oracle SQL執行計劃異常的處理方法

這篇文章主要介紹“Oracle SQL執行計劃異常的處理方法”，在日常操作中，相信很多人在Oracle SQL執行計劃異常的處理方法問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”Oracle SQL執行計劃異常的處理方法”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

現象：
下面語句一直以來都比較高效，執行計劃用了索引范圍掃描后經歷三次嵌套循環，可在2秒內返回結果，但今天經同事反映卻走了1分多鐘!

原SQL語句：

Select * From (Select Rownum As Rownumber__, t.*
          From (Select T1.Orderdate As "OrderDate",
                       T1.Status As "Status",
                       T1.Ordercode As "OrderCode",
                       T1.Sumamt As "SumAmt",
                       T1.Ordertype As "OrderType",
                       T1.Questiondesc As "QuestionDesc",
                       T1.Ordersource As "OrderSource",
                       T2.Accepter As "Accepter",
                       T2.City As "City",
                       T1.Isquestion As "IsQuestion",
                       T1.Issplit As "IsSplit",
                       T1.Salemode As "SaleMode",
                       T1.Stockout As "StockOut",
                       T2.Encmobile As "EncMobile",
                       T2.Encphone As "EncPhone",
                       Decryptbykey(T2.Mobilephone) As "MobilePhone",
                       T2.Province As "Province",
                       T3.Checkercode As "CheckerCode",
                       T3.Iscancel As "IsCancel",
                       T3.Ischeck As "IsCheck",
                       T3.Isclose As "IsClose",
                       T3.Isfinish As "IsFinish",
                       T1.Ischange As "IsChange"
                  From Xs_Order T1                  Join Xs_Orderpsaddress T2                    
                  On T1.Ordercode = T2.Ordercode                  Join Xs_Orderstatus T3                    
                  On T1.Ordercode = T3.Ordercode                 
                  Order By T1.Ordercode Desc) t         
                  Where "OrderDate" >= :Orderdate0           And "StockOut" = :Stockout1) Temp
                  Where Rownumber__ > 0and Rownumber__ <= 20

后來查看執行計劃，執行計劃變成：

分析：
由于后面兩個表是大表，全表掃描導致大量的IO消耗，該語句采用了綁定變量，如果把綁定變量調整為常量后，執行計劃正常走了索引連接，執行后返回也是在2秒內。曾經以為是綁定變量窺探異常問題，后來把表的統計信息重新更新后，問題依舊，接著運行SQL TUNNING包，概要只建議說要啟用并行，但全表掃描并沒有消除，考慮到代價太高就放棄，于是想用DBMS_SPM包來載入該語句：

BASELINE:
declare
l_pls number;
begin
l_pls := DBMS_SPM.LOAD_PLANS_FROM_CURSOR_CACHE(
sql_id=> 'a0wawpy5hfrt3',
plan_hash_value => 2253704843,    --注意這里的2253704843是我用常量帶入后正常的PLAN_HASH_VALUE
enabled         => 'YES');
end;

執行后，發現語句還是走了錯誤的執行計劃，曾經考慮想用捕捉基線的方式進行演化，但由于該語句帶綁定變量，會話級比較難搞，所以想到用包刪除共享池里的該執行計劃，讓它重新進行硬解析：操作如下：

exec dbms_shared_pool.purge('0000000DE5E6B808,2332516131', 'c')

–第一個參數為v$sqlarea中address和hash_value，第二個為cursor類型)

處理后執行計劃重新產生，并自動應用了2253704843這個執行計劃，查詢效率正常：

到此，關于“Oracle SQL執行計劃異常的處理方法”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！