[20210519]是否可能导致DML失效.txt

--//生产系统,检查alert日志：
Mon May 17 17:15:42 2021
Errors in file /u01/app/oracle/diag/rdbms/dbcn/dbcn2/trace/dbcn2_j000_27318.trc:
ORA-12012: 自动执行作业 12 出错
ORA-20000: YOU CAN NOT TRUNCATE or DROP BIN$Bo/SlefRJ3fgU2ljqMCCgg==$0 TABLE!
ORA-06512: 在 line 6
ORA-06512: 在 "SYS.INSERT_DOCTOR_LOGS", line 17
ORA-06512: 在 line 1
Mon May 17 17:20:42 2021
Errors in file /u01/app/oracle/diag/rdbms/dbcn/dbcn2/trace/dbcn2_j000_31575.trc:
ORA-12012: 自动执行作业 12 出错
ORA-20000: YOU CAN NOT TRUNCATE or DROP BIN$Bo/SlefRJ3fgU2ljqMCCgg==$0 TABLE!
ORA-06512: 在 line 6
ORA-06512: 在 "SYS.INSERT_DOCTOR_LOGS", line 17
ORA-06512: 在 line 1

--//我检查SYS.INSERT_DOCTOR_LOGS存储过程发现并没有truncate以及drop操作，在line 17的位置是一条insert+select语句.
--//仔细看才发现删除对象应该是回收站的对象。
--//这样一定是对应表空间紧张,递归触发了删除回收占对象的操作。
--//我们系统存在触发器防止开发误操作删除或者truncate对象。
--//解决方法很简单,临时系统禁止触发器，然后删除执行如下：

show recyclebin
purge recyclebin;

--//这个job每5分钟调用一次,出现错误几乎都是job调用的错误,平时的执行程序是否有可能这样的递规导致插入失败吗?我测试看看.

1.环境:
SCOTT@book> @ ver1
PORT_STRING                    VERSION        BANNER
------------------------------ -------------- --------------------------------------------------------------------------------
x86_64/Linux 2.4.xx            11.2.0.4.0     Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production

CREATE OR REPLACE TRIGGER SYS.TRI_PREVENT_DROP_TRUNCATE
   BEFORE TRUNCATE OR DROP
   ON DATABASE
DISABLE
BEGIN
   --//dbms_output.put_line( ora_dict_obj_type);
   IF     ora_dict_obj_type IN ('TABLE', 'SEQUENCE')
      AND ora_dict_obj_owner = 'SCOTT'
      AND ORA_DICT_OBJ_NAME NOT LIKE 'SYS\_JOURNAL\_%' ESCAPE '\'
      AND ORA_DICT_OBJ_NAME NOT LIKE 'SYS\_EXPORT\_SCHEMA_%' ESCAPE '\'
      AND ORA_DICT_OBJ_NAME not in ('SCHEDULER$_PROGRAM_ARG','SCHEDULER$_JOB_ARG')
   THEN
      raise_application_error
      (
         -20000
        ,'YOU CAN NOT TRUNCATE or DROP ' || ora_dict_obj_name || ' TABLE!'
      );
   END IF;
END;
/

CREATE TABLESPACE SUGAR DATAFILE
  '/mnt/ramdisk/book/sugar01.dbf' SIZE 10M AUTOEXTEND ON NEXT 1M MAXSIZE UNLIMITED
LOGGING
ONLINE
EXTENT MANAGEMENT LOCAL AUTOALLOCATE
BLOCKSIZE 8K
SEGMENT SPACE MANAGEMENT AUTO
FLASHBACK ON;

2.测试:
create table tx tablespace sugar as select * from all_objects;
create table ty tablespace sugar as select * from all_objects where rownum<=10000;
drop table ty ;

alter TRIGGER SYS.TRI_PREVENT_DROP_TRUNCATE enable ;

SCOTT@book> update tx  set owner=lpad('a',30,'a');
update tx  set owner=lpad('a',30,'a')
       *
ERROR at line 1:
ORA-00604: error occurred at recursive SQL level 2
ORA-20000: YOU CAN NOT TRUNCATE or DROP BIN$wwsnD9s9ot3gU05kqMACuQ==$0 TABLE!
ORA-06512: at line 9

SCOTT@book> select * from tx where rownum=1;
OWNER  OBJECT_NAME          SUBOBJECT_  OBJECT_ID DATA_OBJECT_ID OBJECT_TYPE         CREATED             LAST_DDL_TIME       TIMESTAMP           STATUS  T G S  NAMESPACE EDITION_NAME
------ -------------------- ---------- ---------- -------------- ------------------- ------------------- ------------------- ------------------- ------- - - - ---------- ------------
SYS    ICOL$                                   20              2 TABLE               2013-08-24 11:37:35 2013-08-24 11:47:37 2013-08-24:11:37:35 VALID   N N N          1

--//晕，昏不知道是否已经导致一些应用程序的逻辑出现错误。
--//我5月19号发现我当天就处理了。我看了alert日志，最早的出现时间是Mon May 17 16:19:20 2021

$ grep -B3 "TRUNCATE"  alert_XXXX.log | head -
Mon May 17 16:19:20 2021
Errors in file /u01/app/oracle/diag/rdbms/dbcn/dbcn2/trace/dbcn2_j001_31423.trc:
ORA-12012: 自动执行作业 12 出错
ORA-20000: YOU CAN NOT TRUNCATE or DROP BIN$Bo/SlefRJ3fgU2ljqMCCgg==$0 TABLE!
--
Mon May 17 16:21:30 2021
Errors in file /u01/app/oracle/diag/rdbms/dbcn/dbcn2/trace/dbcn2_j000_33439.trc:
ORA-12012: 自动执行作业 12 出错
ORA-20000: YOU CAN NOT TRUNCATE or DROP BIN$Bo/SlefRJ3fgU2ljqMCCgg==$0 TABLE!
--

--//几乎都是关联这个job，问题不大。如果再过一段时间报错，估计可能问题就很大。

SELECT *
  FROM (  SELECT DISTINCT recording_date_time
            FROM xxxxxxxx
           WHERE recording_date_time BETWEEN '2021/05/17 16:19:20'
                                         AND '2021/05/19 16:19:20'
        ORDER BY recording_date_time)
 WHERE rownum <= 4;

RECORDING_DATE_TIME  
---------------------
2021-05-17 17:30:37  
2021-05-17 17:35:37  
2021-05-17 17:40:37  
2021-05-17 17:45:37  

--//不清楚purge的触发机制，很明显有一段时间的记录没有插入，其它dml也没有影响。继续测试环境的测试：

SYS@book> alter TRIGGER SYS.TRI_PREVENT_DROP_TRUNCATE disable ;
Trigger altered.

SCOTT@book> update tx  set owner=lpad('a',30,'a') ;
84825 rows updated.

SCOTT@book> commit ;
Commit complete.

--//OK,正常dml，以后在维护中给注意这种特殊情况的出现可能导致的dml无法执行。
--//实际上最可怕的是我们的用户出现这样的错误如果是零星的错误，根本不会往上级汇报，我们程序一个变态的业务逻辑就是出现错误
--//有一个错误的弹出窗口可以让用户选择继续，我开始多次反映这样怎么能让用户选择继续，业务逻辑如何保证，你能保证你的业务在
--//这样的情况下能正常进行吗，直到我自己操作我才明白我们的应用软件有多么的垃圾，因为不这样做，这样软件要不断的退出与登录
--//，任何用户都忍受不了这样的操作模式。