这个案例放着很久了，最近又有遇到，小结了一下。
RAC环境下，主要是不同实例上handle地址（kglpnhdl or kgllkhdl）不同，所以如果pin/lock被不同的节点持有时，处理起来就略有不同，看下面这个例子：

半夜被叫醒，唉，最近真是没休息好。。。
说是表分析很慢，检查了一下，发现表分析的进程等待事件是enq: RO - fast object reuse。TYPE为RO的，p这个真没见过。检查持有锁的会话，居然是CKPT进程。查看CKPT进程的等待事件，一般都是rdbms ipc message，也正常啊。

在一个测试库上，同事进行了一些操作之后，UNDO表空间撑爆了，之后Shutdown immediate时HANG住了。shutdown abort，重启后做了很多操作，例如切换UNDO表空间、DROP原UNDO表空间、将UNDO表空间改为手工管理并将需要恢复的回滚段offline、drop等，这些操作不是失败就是无效，shutdown时依然Hang住。

最近一测试库上频繁遇到ORA-1652: unable to extend temp segment by 128 in tablespace TEMP，只要一进行性能测试，就报错。检查TEMP的使用情况，耗用最多的类型全是LOB_DATA，而且随着测试进行，一直往上涨。一开始以为是在存储过程中定义的LOB、CLOB变量，所占用的TEMP空间是无法自动释放导致的，虽然最终原因是在java代码中没有释放，但存储过程中的这个现象，还是值得记录一下的。

RAC环境，9208,节点2上library cache pin非常严重，以下是Statspack报告中Top 5等待事件：

Top 5 Timed Events
~~~~~~~~~~~~~~~~~~                                         % Total
Event                                   Waits    Time (s) Ela Time
-------------------------------- ------------ ----------- --------
library cache pin                     105,664     224,526    61.59
latch free                         31,566,620     110,585    30.33
CPU time                                           16,591     4.55
db file sequential read             1,308,510       6,532     1.79
enqueue                                36,749       4,587     1.26
          -------------------------------------------------

主机意外down机后，启数据库时，实例2正常启动，实例1启了半个多小时了，还是停在nomount状态，告警日志反复显示的是：

ARC1: Thread not mounted
ARC0: Thread not mounted

在DROP TEMP表空间时，会话长时间不能结束，查看等待事件为：

数据库日志中发现以下错误信息：