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这个执行计划，查询效率正常：

至此，问题完美解决！