9iRAC environment encounters library cache lock and library cache load lock wait

9in the irac environment, the library cache lock and library cache load lock wait FOR the client database version to be 9208 rac for aix. The customer's response system is slow and the alarm log is checked, A large number of Library cache locks and Library cache load locks are found to be waiting. Due to the customer's reasons, this problem is only a remote help to check, so there is no operation record, here is a brief description of the problem. The customer's response to database operations is slow. A primary key-based UPDATE operation that executes quickly also becomes abnormal and slow, and the Execution Plan itself has not changed. After logging on to the database at www.2cto.com, check the alarm logs on the two nodes. No exception is reported. Check the wait information of the two instances separately and find that there are significant gc waits in addition to a large number of Library cache locks and Library cache load locks mentioned above. However, it was found that the query results for V $ SESSION and GV $ SESSION were no different. Then, we queried the GV $ INSTANTBCE view and found that only the current instance exists, at this time, the tool connecting to another node was disconnected, So that I thought the instance on another node had been DOWN, but then I logged on to the node again, the database instance still exists and can be logged on to the database instance for any normal operations. However, it is found that all the GV $ views on the current node only return information of the current instance, which is exactly the same as that on the other node. Obviously there is a problem with the communication between the two nodes. The current node is not clear about the status of the other node. It doesn't make much sense to analyze the waiting information at www.2cto.com, because the whole database is in an abnormal state. It is not difficult to infer that the current database exception is caused by inter-node communication exceptions. Because 9i's operating system CLUSTER does not have the clusterware of Oracle, it can only be further tracked by the operating system or hardware maintenance personnel. In the end, the database and system are restarted during idle time at night. After the restart, the database returns to normal and the GV $ view returns to normal.