最近在AIX 6.1上安装了一套RAC，实施得不多，遇到不少问题，记录一下：

OS版本：

HOST_NAM_1:/#oslevel -s
6100-04-02-1007

HA版本：

HOST_NAM_1:/#lslpp -l cluster.*
  Fileset                      Level  State      Description         
  ----------------------------------------------------------------------------
Path: /usr/lib/objrepos
  cluster.adt.es.client.include
                             5.5.0.0  COMMITTED  ES Client Include Files
  cluster.adt.es.client.samples.clinfo
                             5.5.0.0  COMMITTED  ES Client CLINFO Samples
  cluster.adt.es.client.samples.clstat
                             5.5.0.1  COMMITTED  ES Client Clstat Samples

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

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
          -------------------------------------------------

近期对本地网某系统做了一次恢复测试，将整个恢复过程简单记录一下：

执行truncate partition时报错：

SQL> alter table EC_IOM_OCMDRDER_TBL 
truncate partition E_I_O_T_2009_APR update global indexes
            *
ERROR at line 1:
ORA-00604: error occurred at recursive SQL level 1
ORA-08102: index key not found, obj# 6958, dba 113254602 (2)

最近一次在AIX上布署RAC环境，前期安装还算顺利，虽然也遇到些小问题，不过最终都安装成功了。在升级到10.2.0.4，打上Bundle Patch后，发现一些CRS服务无法启动了。

曾经写过一篇文章：对比前后执行计划，发现问题。当系统出现异常语句，在分析语句前，我常会先查查这个语句的历史执划信息，看看是否发生变化，何时发生了变化。如果发生了变化，就可以找出以前的执行计划，与当前的执行计划进行对比，看看有什么不同，是新建、删除了索引？是bind peeking的原因？还是表长时间没有分析？
之前的文章写的是9i的系统，可以使用statspace报告获得相关信息，现在总结下10G的，使用的是AWR报告中的信息，主要是查询以下三个视图：
DBA_HIST_SQL_PLAN、DBA_HIST_SQLSTAT、DBA_HIST_SNAPSHOT。

故障现象：相同的语句，在实例1上运行正常，实例二上长时间的“buffer busy waits”在等待某个块。

检查数据库时发现，60几个会话都在执行一条长时间语句，并且都集中在实例1上，迟迟不能结束：

通过索引返回查询，避免TABLE ACCESS BY INDEX ROWID，这时不去读表，与表数据的存放无关，有时能起到优化SQL的作用。

总结一个去年由于Paging Space不足导致系统挂起的案例。
监控报警，数据库挂起，无法连接，检查主机告警时，发现大量Paging Space不足的告警。

10G开始，引入mutexes机制用以代替library cache pin
关于mutexes的一些解释：
转自http://space.itpub.net/?uid-756652-action-viewspace-itemid-348176

Mutexes are new thing in 10.2 and they enable shared access to objects in somewhat similar manner than shared latches, that every successful get of particular mutex will increment its value and release will decrement. When the count is zero, no-one has the mutex and it is safe to get it in exclusive mode too. However they are more fine grained than kgl latches and provide better waiting mechanism as far as I understand.