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

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