ORA-01555故障解決案例

         一個客戶在批量ORACLE 9.2.0.7平臺上一直無法批量載入處理資料，資料加

載執行了3個小時多，報ORA-01555錯誤。

        通常出現該錯誤，第一個反應是UNDO表空間太小，我將表空間增加了1/3，增

加了undo _rention數值，依然報錯。我意識到不是undo空間不夠，通過監控，證實

了我的想法。應該是批量載入儲存過程語句有問題。

      通過v$sql_plan監控儲存過程的執行計劃，發現以下執行計劃有問題，具體如下：

1、語句大體如下：
 delect xxx  from tabA
 where  條件關係
 and exist (select 1 from tabB where 條件關係）
 and exist (select 1 from tabC where 條件關係）

tabA的索引： indx_tabA
tabB的索引： indx_tabB
tabC的索引： indx_tabC

2、通過v$sql_plan語句檢視執行計劃
select p.hash_value||'-'||p.child_number "statement_id",
            p.cost  "cost",
            p.io_cost  "io cost",
            p.cardinality "card",
            lpad(' ', 2*(level-1))||p.operation||' '||p.options||' '||p.object_name 
            "Operation"
from v$sql_plan p
where p.address in (select address from v$sql_plan
         where id=0 and cost is not null)
and  p.address in (select address from v$sql_plan
         where object_owner = sys_context('USERENV', 'CURRENT_SCHEMA'))
 start with p.id=0
connect by prior p.id=p.parent_id
and prior p.address=p.address

從執行計劃中我們發現，通過B-TREE索引進行bitmap的轉化，bitmap conversion

from rowid和bitmap conversion to rowid，這意味著優化器將indx_tabA和子查詢

indx_tabB和indx_tabC進行index_combine操作，造成了執行計劃錯誤。為此制定

了三個方案進行測試：

1、在引數檔案設定_b_tree_bitmap_plans=false
2、修改和重建索引
3、在語句中新增hint避免bitmap轉化

第一個方案，在測試機上測試，執行計劃正常，也能正常載入資料，但生產機不能停機，所以暫不採用；

第二方案，因為程式是從總局下發，分局原則上不允許對索引進行修改。

我自能採用第三方案，修改語句如下：

delete /* push_subq */  from tabA
where  條件關係
 and exist (select /* no_unnest*/ 1 from tabB where 條件關係）
 and exist (select /* no_unnest*/ 1 from tabC where 條件關係）

執行計劃按照我希望進行執行，整個批量載入發費10分鐘左右。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/354732/viewspace-721265/，如需轉載，請註明出處，否則將追究法律責任。