From Oracle9i, Oracle supply resumable space allocation to enable you to suspend large operations instead of receiving an error, it gives you a chance to fix the problem while the operation is suspended.
Resumable Space Allocation applies to following three conditions:
out of space
maximum extents reached
Space quota exceeded
You can set the RESUMABLE_TIMEOUT initialization parameter to a nonzero value to enable Resumable Space Allocation, or issue the following command:
SQL> alter session enable resumable timeout 3600;
It's means that the session can be suspended in 3600 seconds, you can recover the error in the 3600 seconds. Otherwise, the session raises a exception. If you do not specify the time-out period, the default time-out interval is 7200 seconds.
You can also give a name to Resumable Space Allocation. For example:
SQL> alter session enable resumable timeout 3600 name 'resumable test';
However, you can query them through the DBA_RESUMABLE and USER_RESUMABLE views.
For example:
SQL> revoke unlimited tablespace from hr;
Revoke succeeded.
SQL> alter user hr quota 10M on users;
User altered.
SQL> conn hr/hr
Connected.
SQL> create table te as select * from all_objects;
Table created.
SQL> insert into te
2 select * from all_objects;
insert into te
*
ERROR at line 1:
ORA-01536: space quota exceeded for tablespace 'USERS'
SQL> conn / as sysdba
Connected.
SQL> alter system set resumable_timeout=3600 scope=both;
System altered.
SQL> conn hr/hr
Connected.
SQL> insert into te select * from all_objects;
Then, the session has been suspended, the user would not receive any error. But in the alert log, as a DBA, you would see the following message:
statement in resumable session 'User HR(55), Session 131, Instance 1' was suspended due to
ORA-01536: space quota exceeded for tablespace 'USERS'
According to these, you can find out the user, the session id, instance id and the error number relative to the suspended session. Otherwise, you can query the DBA_RESUMABLE view for more detail information.
SQL> select user_id, session_id, instance_id, status, timeout, start_time, name, error_number from dba_resumable;
USER_ID SESSION_ID INSTANCE_ID STATUS TIMEOUT START_TIME NAME ERROR_NUMBER
---------- ---------- ----------- --------- ---------- -------------------- -------------------- ------------
55 131 1 SUSPENDED 3600 07/22/08 20:13:16 User HR(55), Session 1536
131, Instance 1
The V$SESSION_WAIT view also tracked the session.
SQL> select sid, event, time_waited from v$session_event where event like '%statement suspended%';
SID EVENT TIME_WAITED
---------- ---------------------------------------------------------------- -----------
131 statement suspended, wait error to be cleared 116832
Connect the database with another session:
SQL> conn /as sysdba
Connected.
SQL> alter user hr quota 100m on users;
User altered.
Immediately, the first suspended session perform the insert, and the alert log give the following message:
Tue Jul 22 20:30:26 2008
statement in resumable session 'User HR(55), Session 131, Instance 1' was resumed
The stauts of the session in the DBA_RESUMABLE view has changed to NORMAL.
SQL> select user_id, session_id, instance_id, status, timeout, start_time, name, error_number from dba_resumable;
USER_ID SESSION_ID INSTANCE_ID STATUS TIMEOUT START_TIME NAME ERROR_NUMBER
---------- ---------- ----------- --------- ---------- -------------------- -------------------- ------------
55 131 1 NORMAL 3600 07/22/08 20:13:16 User HR(55), Session 0
131, Instance 1
A suspended statement can be forced to activate the SERVERERROR exception by using the DBMS_RESUMABLE.ABORT() procedure. While the procedure execute successfully, the suspended session aborted, and the alert log tracked the following message:
Tue Jul 22 21:03:27 2008
statement in resumable session 'User HR(55), Session 131, Instance 1' was aborted
