ORA-01555故障解决案例

最新推荐文章于 2024-11-26 16:19:37 发布

转载最新推荐文章于 2024-11-26 16:19:37 发布 · 201 阅读

文章标签：

针对批量加载数据时出现ORA-01555错误的问题，通过调整执行计划和使用提示避免了bitmap转换，将处理时间从3小时缩短到10分钟。

   一个客户在批量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/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/354732/viewspace-721265/