客户数据库版本为9208 RAC FOR AIX，客户反应系统缓慢，检查告警日志，发现大量Library cache lock和Library cache load lock等待。
由于客户的原因，这个问题只是远程协助的方式帮忙检查了一下，因此没有留下任何的操作记录，这里只是简单描述一下问题。
客户反应数据库操作响应变慢，平时一个执行很快的基于主键的UPDATE操作也变得异常缓慢，且执行计划本身并未发生改变。
登录数据库后检查两个节点上的告警日志，并未发现任何异常报错。分别检查两个实例的等待信息，发现除了上面提到的大量Library cache lock和Library cache load lock以外，还有明显的gc等待。
但是随后发现，查询V$SESSION和GV$SESSION的结果居然没有区别，接着查询GV$INSTANTBCE视图，发现只有当前的实例存在，而此时恰好连接另一个节点的工具出现了断连，以至于我一度以为另外一个节点上的实例已经DOWN掉，但是随后重新登录到该节点上，发现数据库实例仍然存在，而且登录到数据库实例中也可以进行任何正常的操作。不过发现在当前节点所有的GV$视图都只会返回当前实例的信息，这与另外一个节点的情况完全一样。显然两个节点间的通信出现了问题，当前节点已经不清楚另外一个节点的状态的。
现在再去分析那些等待信息已经没有太多的意义了，因为整个数据库已经处于不正常的状态。不难推断，当前数据库的异常是由于节点间的通信异常导致。由于9i使用的操作系统的CLUSTER，还没有Oracle的clusterware，剩下只能由操作系统或硬件维护人员去进一步跟踪了。
最终数据库和系统在夜间闲时进行了重启操作，重启后数据库恢复正常，GV$视图的结果也恢复了正常。