Serviceguard Issue

[shruti_1]

We have installed Serviceguard on two HP-UX systems. When we are shutting down the primary servers the volumes are getting mounted on the standby server however oracle does not start automatically. We need to manually start the oracle. Can anyone help me on this what could be an issue

[Steven E. Protter]

Shalom shruti,

Even though you don't state the OS version or the ServiceGuard Version, I have an idea.

Check the log files on the standby and main node in /etc/cmlcuster

The oracle script is either not copied on the second node or is producing errors at start time.

To some degree diagnostics are in /var/adm/syslog/syslog.log

SEP

[Chan 007]

Hi

What is the problem, generally listener will be the problem. check your /etc/services.

In act it is too wide to know what is your problem. Give more details.

Chan

[shruti_1]

how do i verify whether its a listener problem in /etc/services.

[shruti_1]

do we have some work around for switching the database and listener in HP cluster(M/C service guard PART NO B3935DA) oracle is 9i Ver 9.0.1

[melvyn burnard]

check the package configuration on both nodes. Is it the same? what does the startup look like on the "good" node in comparison to the "bad" node? check the package logs/.
It sounds like there is a problem with your configuration.

[Arunkumar.B]

HI Shruti,


Its Seems to be problem with Package Control Script.


Check /etc/cmcluster/pkgname/pkgcntl.sh

In that you will find the startup & shutdown Customer Defined Parameter.Check the Script over there. Is there any hash ????



Cheers
Arunkumar.B

[Rita C Workman]

Shruti,

Melvyn has point you where you need to look, the package cntl logs where your ascii and cntl files are. Generally something like.../etc/cmcluster/packages/pkg.cntl.log

Read this log and it will tell you what it did or didn't do. If your pkg starts up oracle on your original node, then copy that cntl file over to the other node. And make sure that any other files you need to start are there and ready that may be 'outside' the package. That's often what it is...some script existing on something that wasn't copied over to the failover node. That's why it is best to keep everything possible within the package, so you don't hit these kind of things.

Rgrds, and let us know...
Rita

[Kent Ostby]

Please post the "good" control.log files from the primary machine and the "bad" control.log files from the secondary machine.

That will give us an idea of where we can start to look for differences.