UES (998, 'Description for 998');

      -- Force invalid insert.
      INSERT INTO at_test (id, description)
      VALUES (999, NULL);
    EXCEPTION
      WHEN OTHERS THEN
        log_errors (p_error_message => SQLERRM);
        ROLLBACK;
    END;
    /

    PL/SQL procedure successfully completed.

    SELECT * FROM at_test WHERE id >= 998;

    no rows selected

    SELECT * FROM error_logs;

            ID LOG_TIMESTAMP
    ---------- ---------------------------------------------------------------------------
    ERROR_MESSAGE
    ----------------------------------------------------------------------------------------------------
             1 28-FEB-2006 11:10:10.107625
    ORA-01400: cannot insert NULL into ("TIM_HALL"."AT_TEST"."DESCRIPTION")


    1 row selected.

    SQL>

From this we can see that the LOG_ERRORS transaction was separate to the anonymous block. If it weren't, we would expect the first insert in the anonymous block to be preserved by the commit statement in the LOG_ERRORS procedure.
由此可知，LOG_ERRORS事务被分割为自治块。如果不是，我们可以期待在自治块插入的第一个数据被LOG_ERRORS存储过程的提交语句后保留。

Be careful how you use autonomous transactions. If they are used indiscriminately they can lead to deadlocks, and cause confusion when analyzing session trace. To hammer this point home, here's a quote from Tom Kyte posted on my blog (here):
小心你使用自治存储过程的方式。如果你胡乱使用，可能会引起死锁，同时在分析跟踪事务时引起冲突。下面是Tom Kyte在我的博客里提供的一些建议：

    ... in 999 times out of 1000, if you find yourself "forced" to use an autonomous transaction - it likely means you have a serious data integrity issue you haven't thought about.


    Where do people try to use them?

        * in that trigger that calls a procedure that commits (not an error logging routine). Ouch, that has to hurt when you rollback.
        * in that trigger that is getting the mutating table constraint. Ouch, that hurts *even more*

    Error logging - OK.

    Almost everything else - not OK.