Customer has a Solaris Clusterware, The customer sees the semtimedop() system call returning EAGAIN when running "shutdown immediate" on their database on one cluster node. This is expected when the shared resource that the semaphore is protecting is unavailable. The shared resource is only being used by Oracle processes, so we need to know what the resource is and what the other processes are doing with it. MOS doc 760968.1 isn't helpful. A Solaris crash dump taken when the database shutdown problem was occurring showed no signs of an OS issue so database assistance is needed.
We have tried to capture the following trace, but the trace is empty , and we 're stuck since then.
SQL> alter session set events '10046 trace name context forever,level 12';
SQL> alter session set events '10400 trace name context forever, level 1';
SQL> shutdown immediate;
don't you think it is about time you upgraded to something that hasn't been out of support since 2007 (almost 6 years ago...???). Hopefully you don't have any CC information stored in that db as there has not been any security updates since before it went to de-support.
What I would like to know is how did you even get 9i to install on Solaris 10? IIRC, that is not even a supported OS/Oracle version configuration. As for your current problem,
Worked on Clusters many years ago. ... But I thought that a SHUTDOWN ABORT was required by most clusterware vendors. The SHUTDOWN IMMEDIATE might take too long for the Failover to be successful in a required timeout / SLA.
Hemant K Chitale