根据前面文章的测试，可以发现，是由于用户引发的SUSPEND事件导致一个存在编译错误的触发器执行，从这个触发器执行以后，当前会话不在尝试调用触发器。

下面通过TRACE来比较三种不同的情况：

SQL> DROP TABLE T_TRIGGER;

表已删除。

SQL> CREATE TABLE T_TRIGGER (INFO VARCHAR2(20));

表已创建。

SQL> CONN / AS SYSDBA
已连接。
SQL> DROP TRIGGER TRI_SUSPEND;

触发器已删除。

SQL> CREATE OR REPLACE TRIGGER TRI_SUSPEND
  2  AFTER SUSPEND ON DATABASE
  3  DECLARE
  4   PRAGMA AUTONOMOUS_TRANSACTION;
  5  BEGIN
  6   INSERT INTO YANGTK.T_TRIGGER VALUES ('SYS TRIGGER');
  7   COMMIT;
  8  END;
  9  /

触发器已创建

SQL> CONN YANGTK/YANGTK
已连接。
SQL> DROP TRIGGER TRI_SUSPEND;

触发器已删除。

SQL> CREATE OR REPLACE TRIGGER TRI_SUSPEND
  2  AFTER SUSPEND ON DATABASE
  3  DECLARE
  4   PRAGMA AUTONOMOUS_TRANSACTION;
  5  BEGIN
  6   INSERT INTO T_TRIGGER VALUES ('YANGTK TRIGGER');
  7   COMMIT;
  8  END;
  9  /

触发器已创建

SQL> ALTER SESSION ENABLE RESUMABLE TIMEOUT 300;

会话已更改。

SQL> ALTER SESSION SET EVENTS '10046 TRACE NAME CONTEXT FOREVER, LEVEL 12';

会话已更改。

SQL> CREATE TABLE T_BIG (ID NUMBER)
  2  TABLESPACE YANGTK
  3  STORAGE (INITIAL 250M);
CREATE TABLE T_BIG (ID NUMBER)
*
第 1 行出现错误:
ORA-30032: 挂起的 (可恢复) 语句已超时
ORA-01659: 无法分配超出 27 的 MINEXTENTS (在表空间 YANGTK 中)

SQL> ALTER SESSION SET EVENTS '10046 TRACE NAME CONTEXT OFF';

会话已更改。

首先记录正常情况下的TRACE信息，随后是出错时的TRACE信息，为了方便对比结果，这里重新连接，好得到新的TRACE文件：

SQL> CONN YANGTK/YANGTK
已连接。
SQL> TRUNCATE TABLE T_TRIGGER;

表被截断。

SQL> DROP TRIGGER TRI_SUSPEND;

触发器已删除。

SQL> CREATE OR REPLACE TRIGGER TRI_SUSPEND
  2  AFTER SUSPEND ON DATABASE
  3  DECLARE
  4   PRAGMA AUTONOMOUS_TRANSACTION;
  5   V_RESULT BOOLEAN;
  6   V_ERROR_TYPE VARCHAR2(32767);
  7   V_OBJECT_TYPE VARCHAR2(32767);
  8   V_OBJECT_OWNER VARCHAR2(30);
  9   V_TABLESPACE_NAME VARCHAR2(30);
 10   V_OBJECT_NAME VARCHAR2(128);
 11   V_SUB_OBJECT_NAME VARCHAR2(128);
 12  BEGIN
 13   V_RESULT := DBMS_RESUMABLE.SPACE_ERROR_INFO(
 14    V_ERROR_TYPE,
 15    V_OBJECT_TYPE,
 16    V_OBJECT_OWNER,
 17    V_TABLESPACE_NAME,
 18    V_OBJECT_NAME,
 19    V_SUB_OBJECT_NAME);
 20   INSERT INTO T_TRIGGER VALUES ('YANGTK TRIGGER');
 21   COMMIT;
 22  END;
 23  /

警告: 创建的触发器带有编译错误。

SQL> ALTER SESSION ENABLE RESUMABLE TIMEOUT 300;

会话已更改。

SQL> ALTER SESSION SET EVENTS '10046 TRACE NAME CONTEXT FOREVER, LEVEL 12';

会话已更改。

SQL> CREATE TABLE T_BIG (ID NUMBER)
  2  TABLESPACE YANGTK
  3  STORAGE (INITIAL 250M);
CREATE TABLE T_BIG (ID NUMBER)
*
第 1 行出现错误:
ORA-04098: 触发器 'YANGTK.TRI_SUSPEND' 无效且未通过重新验证
ORA-01659: 无法分配超出 27 的 MINEXTENTS (在表空间 YANGTK 中)

SQL> ALTER SESSION SET EVENTS '10046 TRACE NAME CONTEXT OFF';

会话已更改。

下面删掉错误的TRIGGER，然后再次生成TRACE，记录发生错误后，Oracle在后台做了哪些操作：

SQL> DROP TRIGGER TRI_SUSPEND;

触发器已删除。

SQL> ALTER SESSION SET EVENTS '10046 TRACE NAME CONTEXT FOREVER, LEVEL 12';

会话已更改。

SQL> CREATE TABLE T_BIG (ID NUMBER)
  2  TABLESPACE YANGTK
  3  STORAGE (INITIAL 250M);
CREATE TABLE T_BIG (ID NUMBER)
*
第 1 行出现错误:
ORA-01659: 无法分配超出 27 的 MINEXTENTS (在表空间 YANGTK 中)

SQL> ALTER SESSION SET EVENTS '10046 TRACE NAME CONTEXT OFF';

会话已更改。

对比三次操作生成的TRACE信息，发现对于最后一次的调用，Oracle根本没有去尝试读取任何触发器相关的信息。其实，不只是Oracle没有读取触发器的信息，Oracle实现上根本就没有进入SUSPEND的状态，换句话说，如果SUSPEND触发器失效的时候被调用，不是简单的阻止SUSPEND触发器再次被调用，而是使得当前会话无法在进入SUSPEND状态。

当前会话采用何种方式都无法在进入SUSPEND状态，即使关闭RESUMABLE，再重新打开：

SQL> ALTER SESSION DISABLE RESUMABLE;

会话已更改。

SQL> ALTER SESSION ENABLE RESUMABLE TIMEOUT 300;

会话已更改。

SQL> SELECT * FROM T_TRIGGER;

INFO
--------------------
SYS TRIGGER

SQL> CREATE TABLE T_BIG (ID NUMBER)
  2  TABLESPACE YANGTK
  3  STORAGE (INITIAL 250M);
CREATE TABLE T_BIG (ID NUMBER)
*
第 1 行出现错误:
ORA-01659: 无法分配超出 27 的 MINEXTENTS (在表空间 YANGTK 中)

SQL> SELECT * FROM T_TRIGGER;

INFO
--------------------
SYS TRIGGER

由于TRACE文件太大，且绝大部分内容都与当前问题无关，这里就不贴出结果了。不过发现一个有趣的现象，第一次操作由于进入了SUSPEND状态，等待了5分钟的时间，导致TRACE文件最大，居然有70多万行。根据TRACE的内容可以看到，Oracle处于SUSPEND的状态下，并非只是简单的等待，而是会不断的重新检查当前系统十分有足够的空间来完全当前处于SUSPEND状态的操作。