ITPub博客

首页 > Linux操作系统 > Linux操作系统 > ORA-01555故障解决案例

ORA-01555故障解决案例

原创 Linux操作系统 作者:yezhibin 时间:2012-04-16 11:04:05 0 删除 编辑
         一个客户在批量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/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2008-12-18

  • 博文量
    159
  • 访问量
    505627