Hi,
Since all molecules of the CPU October 2007 are marked as 'online applicable' to RAC
(nice wording, it means a rolling upgrade is possible, not that all instances stay
online during the patch...), I decided to test it. Clusterware did not have to be
patched, by the way.
Rolling upgrade worked, so far so good. During the whole process, users could work.
However, two big issues - which are not related to this specific CPU, but to the way
Oracle describes the patch process in case of RAC - came up.
First, shutdown transactional local does not wait for a transaction to commit or
rollback if the corresponding session was established via Oracle Net and a srvctl generated service name.
Quite common, not to say standard, in a RAC environment. Some tests revealed that in
case of local connects or Oracle Net connects via SID, the shutdown waited as it
should. The solution was to shutdown the listener of the instance to be patched, to issue
alter system disconnect session 'SID,SERIAL#' post_transaction;
for all sessions, wait until they failover and then issue shutdown. Not very
comfortable but it works.
The second issue was on the VIP. Oracle recommends to issue
srvctl stop nodeapps -n NODE_TO_BE_PATCHED
This, however, also stops the VIP and does NOT failover it to another node. Which
results in TCP timeouts for new connects and failovers (sessions seem to hang). The
solution here is to explicitly start the VIP on a fully available node, e.g. with
crs_start ora.NODE_TO_BE_PATCHED.vip -c FULLY_AVAILABLE_NODE