今天下午发现逻辑备库有延迟，于是检查了一下，发现一直在应用一个很大的事物，期间不时有page out，最后竟然出现了ORA-04030: out of process memory ：

LOGSTDBY Apply process P005 pid=33 OS id=22584 stopped
Fri Jun 10 16:51:37 CST 2011
Errors in file /data/oracle/admin/bdump/orcl_lsp0_25503.trc:
ORA-12801: error signaled in parallel query server P005
ORA-04030: out of process memory when trying to allocate 4040 bytes (knas:shtrans,knas: rpc arguments)
ORA-04030: out of process memory when tryin
LOGSTDBY Analyzer process P003 pid=31 OS id=22580 stopped
LOGSTDBY Apply process P007 pid=37 OS id=22588 stopped
LOGSTDBY Apply process P008 pid=38 OS id=22590 stopped
LOGSTDBY Apply process P004 pid=32 OS id=22582 stopped
LOGSTDBY Apply process P006 pid=34 OS id=22586 stopped
Fri Jun 10 16:51:37 CST 2011
LOGSTDBY status: ORA-16222: automatic Logical Standby retry of last action
LOGSTDBY status: ORA-16111: log mining and apply setting up

于是想知道到底是什么事物导致的，从v$logstdby_process，v$session_longopt 都知道一直在进行一个事物，但是查不到是什么object上的。突然灵机一动，在逻辑备库上做了一个awr，发现一个语句执行了大概750万次update操作，终于知道了是什么表。另外，在primary也做了一个awr，发现是一个update语句更新了大概750万记录，估计是应用的动态sql没有控制好条件。

原本以为这个操作没有完成，但是后来检查了一下数据，发现数据全部被改了，还好这个字段不怎么变化的，要是这个是金钱怎么办？？？？设计、开发、测试？？how can this happen？？不过已发生，我们还得擦屁股。

1 还好我们的undo比较大，保留时间比较长，如果发现不及时，估计会被顾客给投诉死。恢复也可能就只能logminer了：

create table xxxx_0610 as select * from xxxx as of TIMESTAMP sysdate-0.1;

2 循环更新（要是这个是金钱怎么办？）：

DECLARE
      COUNt_v NUMBER:=0;
BEGIN
    FOR c IN (SELECT * FROM xxxx_0610 a WHERE a.ined=1)
    LOOP
        UPDATE xxxx
        SET xxxx.exptime=c.exptime
        WHERE xxxx.id=c.id;
        COUNt_v:=COUNt_v+1;

        IF(MOD(count_v,5000)=0)
        THEN
              COMMIT;
              dbms_lock.sleep(2);
        END IF;
    END LOOP;

    COMMIT;
END;

ITPub博客

oracle LOGICAL standby ORA-04030: out of process memory

最新文章