我们最近有两台测试服务器在oci direct load期间出现下列异常:

ORA-38301:can not perform DDL/DML Over Object in Recycle Bin   11.2.0.4-LMLPHP

从表象上看,是我们在对表执行ddl操作,确实内部也是用了truncate table XXX,可是这个XXX并不是回收站里面的XXX。即使是purge dba_recyclebin之后,也可能还是会有这个问题,所以这个问题只能说和回收站有关、但是并不一定是该表本身被DDL的原因。目前已知除了直接对回收站中的表直接DDL之外(这一般用户不会直接进行,但是oracle后台的各种自身统计收集任务是允许这么做的),有可能是表空间中存在一些回收站,导致了XXX表和该表空间中已回收的对象存在空间争用(但是我看下了dba_data_files,可用空间是足够的);还有一个可能的已知原因是auto space advisor任务在跑。

前者可以通过下列语句清理:

purge tablespace XXX;

后者可以通过下列方式禁用:

begin
dbms_auto_task_admin.disable(client_name => 'auto space advisor',
operation => null,
window_name => null);
end;
/

伴随着ORA-38301,通常在alert.log里面会有日志:performing DML/DDL operation over object in bin. 但是他没有被当做ERROR或者WARNING来显示和对待。

我们的错误重放过程和https://knowledge.exlibrisgroup.com/Aleph/Knowledge_Articles/Oracle_message_in_alert_log%3A__%22performing_DMLDDL_operation_over_object_in_bin%22非常像,但是模拟不出来,有很多的帖子去模拟,比如http://www.xifenfei.com/2011/07/performing-dmlddl-operation-over-object-in-bin%E9%94%99%E8%AF%AF%E6%A8%A1%E6%8B%9F.html,实际上业务根本不是这么操作的,所以这些所谓的专家就是这么忽悠的,通常就是为了凑而凑。

至于ORA-39776,它纯粹是表象,需要看具体的cause。

参考:

https://blog.csdn.net/lansesl2008/article/details/16116749

http://zy8643954.iteye.com/blog/701831

04-16 19:07