MC/SG Two nodes cluster

[kholikt]

Hi,

I have two nodes MC/SG cluster running oracle. We are patching the passive server with some new oracle patch, as such there is a new initora file. According to my DBA, the file need to convert to binary but only can be done after the startup of oracle database.

So I think the safest way is to halt the cluster package and cluster nodes. From the passive node, I will activate the VG and mount all the oracle file system.

vgchange -a y myvg
vgchange -c n myvg

Once the DBA finished all the necessary, I will then deactivate the VG and start MC/SG in the passive node.

This should corrupt the file system right as the MC/SG package is stopped first on the active node and all volume group are deactivated.

[Steven E. Protter]

Shalom kholikt,

I'm kind of wondering whats being converted to binary here. The configuration files for the SG cluster, part of those are binary, but the scripts are text.

the init.ora file is a text file and doesn't get converted to anything as far as I know.

If the oracle upgrade/patch involves a data conversion, please be sure to only run that once. There is only one database instance, sitting on shared storage that needs to be converted.

My recommendations on doing this:

If possible, halt the cluster completely, install the update on both nodes, convert the data one one of the nodes as if it was the active node.

If you can't bring down the cluster:
Remove the passive node from the cluster. Do the oracle patch, have the node re-join the cluster.

Then halt the active node, to the patch and do any data conversion if needed.

if there is no update to the data as part of the patch:

Take the passive node out of the cluster, upgrade/update oracle.

Put the passive node back in the cluster.

Fail oracle over to the passive node.

Repeat the update on what was the active node.

This is what is known as a rolling upgrade and it can be done without downtime.

Lastly: Get a good cold backup of the oracle binaries and data before doing ANYTHING.

SEP

[melvyn burnard]

I always thougt the init.ora file was a text ascii file, so this is new to me.
Anyway, if you DO need to stop th edatabse, then there is no need to halt the cluster.
Simply halt the package, and leave the cluster running.
This enabkles you to activate the vg WITHOUT having to do vgchange -c n etc.
Simply vgchange -a e, mount any files systems etc. Do the work, unmount any file systems, vgchange -a n.

[Duncan Edmonstone]

I assume your DBA is talking about an oracle spfile yes? This is indeed the bianry equivalent of the init file - it has the advantage that most parameters can be changed 'on the fly' without stopping the database.

That said, I can't really understand why you need to muck about with Serviceguard to make this change (unless Serviceguard is actively monitoring your database?)

Presumably the tasks are:

1) Stop Database
2) Apply patch
3) Start database with new init file
4) convert init file to spfile
5) halt database
6) Start database with spfile

If serviceguard *is* monitoring you database processes, yo will either need to a) suspend monitoring (this depends on whether someone was bright enough to put a check for a maintenance flag in your monitoring script) until your changes are complete.
-or-
b) If you can't suspend monitoring you will need to stop the serviceguard package and manually mount the appropriate filesystems (no need to stop the cluster though)
- Stop the package using cmhaltpkg - vgchange -a e myvg
- mount /dev/myvg/lvolN /mntpoint (or whatever)

HTH

Duncan