今天一个很偶然的时间里，我想看看我们的系统有没有异常，其中某个检查点是通过下面这个SQL进行的：

SQL> SELECT local_tran_id,
  2         state,
  3         fail_time
  4    FROM dba_2pc_pending
  5  /

LOCAL_TRAN_ID          STATE            FAIL_TIME
---------------------- ---------------- ---------
31.16.528671           collecting       25-FEB-10

通常情况下，我关注更多地是业务数据异常，很少动手检查此类底层的问题，也不会发现任何异常，但是这次，它来了。当然，在我发现下面这个错误之前，它丝毫不是个问题：

SQL> commit force '31.16.528671';
commit force '31.16.528671'
*
ERROR at line 1:
ORA-02058: no prepared transaction found with ID 31.16.528671

SQL> exec dbms_transaction.purge_lost_db_entry('');
BEGIN dbms_transaction.purge_lost_db_entry(''); END;

*
ERROR at line 1:
ORA-30019: Illegal rollback Segment operation in Automatic Undo mode
ORA-06512: at "SYS.DBMS_TRANSACTION", line 65
ORA-06512: at "SYS.DBMS_TRANSACTION", line 85
ORA-06512: at line 1

一种可能的情况是连接的远程数据库或DBLINK此时不可用，由于最近系统修改比较多，且数据不重要，已经没有追查线索的必要了。解决办法参考Metalink [ID 290405.1]：

1.) alter session set "_smu_debug_mode" = 4;
2.) commit; -- so that the call to DBMS_TRANSACTION.PURGE_LOST_DB_ENTRY is the first
                  -- step of the transaction
3.) execute DBMS_TRANSACTION.PURGE_LOST_DB_ENTRY('local_tran_id');

如果业务数据并不重要，那么解决办法非常简单。这里觉得有点遗憾的是，过去了如此许久才发现问题。基本上，我们的监控处于最原始的手工阶段，这也是为什么我最近评估各类自动化监控系统的主要原因之一。我曾发过一个感叹：

我觉得，如果出一本数据库监控专题的书籍肯定会火，专门介绍如何设置度量和策略，介绍每个监控点。其实这类监控范围，也或许代表了DBA工作职责和经验的体现吧。(via Twitter)

企业的信息化是一个渐进的过程，我们因需求而变化。之前，我们曾经希望有一整套的现成的方案告诉我们如何监控，需要监控什么。但是现在，我基本上可以肯定，每个企业的情况都不相同，寻求一套普适的方案并不值得推荐，因需而定，这才是一个正常的成长过程。

所以我收回之前的Tweet……

Update
1. 将零碎的知识整理成系统性的规范，并进行有序管理，这是当前应该做的事。但是常常独木难支，并且缺少一套有效的知识管理系统来支撑这种渐进的优化。

2. 近日陆续梳理ERP系统的方方面面，发现很多待优化的模块，也发现了很多日常工作中完全可能避免的性能问题。将个人的良好经验形成团队的规范行为，是一个不断积累的过程。尤其的，可以将一些常规项目集成到监控系统中去。

3. 有时候，让功能顾问去解决功能问题可能是个错误的选择，他们更倾向于面对业务问题。纯技术顾问也解决不了，需兼而得之。

……