oracle技术之系统触发器的应用顺序（四）
在写一个AFTER SUSPEND触发器的时候碰到了一个很有趣的现象。
通过TRACE检查问题的原因。
根据前面文章的测试，可以发现，是由于用户引发的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 (INITIAL250M);
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 (INITIAL250M);
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 (INITIAL250M);
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 (INITIAL250M);
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状态的操作。
oracle视频教程请关注:http://u.youku.com/user_video/id_UMzAzMjkxMjE2.html