[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無法執行。
--//實際上最可怕的是我們的使用者出現這樣的錯誤如果是零星的錯誤，根本不會往上級彙報，我們程式一個變態的業務邏輯就是出現錯誤
--//有一個錯誤的彈出視窗可以讓使用者選擇繼續，我開始多次反映這樣怎麼能讓使用者選擇繼續，業務邏輯如何保證，你能保證你的業務在
--//這樣的情況下能正常進行嗎，直到我自己操作我才明白我們的應用軟體有多麼的垃圾，因為不這樣做，這樣軟體要不斷的退出與登入
--//，任何使用者都忍受不了這樣的操作模式。