Grid install may fail with “no network HB”

We have tried to install a new 11gR2 Grid (as for now it is and found a “wonderful” issue which is not obvious to diagnose. The cluvfy utility failed to check private network connectivity between the nodes. Both machines are in the same network, no firewall between them, each machine sees other one and itself by ping. The CSSD process had interesting message in its log:

clssnmvDHBValidateNCopy: node 1, nodename1, has a disk HB, but no network HB, ...

But IT is not a place for miracles, is it?

At last we have found the solution in the MOS Note 1212703.1. The main reason to fail was related to the new’s feature called “Redundant Interconnect Usage”. As those note described, “multicast based communication on the private interconnect is utilized to establish communication with peers in the cluster on each startup of the stack on a node”. But not every infrastructure allow to use multicast on default and therefore there is a patch which adds support of multicast on

The note 1212703.1 gives utility called mcasttest-tool to check it and appropriate patch 9974223. And good news is that you don’t have to reinstall the GI, just install this patch as documented. We succeeded with our install! 🙂

So before upgrading to check your environment, don’t let confuse you!

Posted in Oracle

One database – different platform names in a datafile headers…

… How it is possible?

Let’s imagine you need to migrate a database from HP-UX PA-RISC to HP-UX IA64, both are 64-bit. It’s easy as it is supported to have such mixed Data Guard environment according to the MOS document 413484.1 (for more detailed description regarding these platforms see 395982.1). You just create a physical standby and then perform a switchover. Total downtime is near several minutes, the task is done and all clients and bosses are happy.

Several years later you need to migrate the same database to the different platform, say Linux x68_64. As endianness is different it is not so simple as you wish, but there is Transportable Tablespaces and RMAN’s CONVERT command and you decided to perform conversion on the destination (I hope to describe all the challenge in other story). When converting on the destination host, you must specify the source platform with the FROM clause of CONVERT command. OK, the source platform is ‘HP-UX IA (64-bit)’, let’s do the thing:


RMAN-03002: failure of conversion at target command at ...
RMAN-06576: platform 'HP-UX (64-bit)' (3) found in header of datafile /path/to/file01 does not match specified platform name 'HP-UX IA (64-bit)' (4)

OK, RMAN says we have ‘HP-UX (64-bit)’ in a datafiles header. Let’s try:


RMAN-03002: failure of conversion at target command at ...
RMAN-06576: platform 'HP-UX IA (64-bit)' (4) found in header of datafile /path/to/file07 does not match specified platform name 'HP-UX (64-bit)' (3)

The problem is described in MOS Document 1067946.1: the headers were not modified during previous platform migration. The workaround is simple – convert datafiles created before migration as FROM ‘HP-UX (64-bit)’ and after migration as FROM ‘HP-UX IA (64-bit)’, or convert all the files on the source platform.

The main question I have after all: if RMAN so smart to know the platform when raises an error, why it couldn’t detect source platform without FROM clause?

Posted in Oracle, Transportable Tablespaces

Oracle docs for Kindle: did you know…

…that Oracle provides its official documentation in mobi and epub formats also?

This is amazing just because I have a Kindle 3 and some time ago I was looking for a proper way to convert my favorite articles from, but fortunately Oracle already did it for me.


Posted in Kindle, Oracle
Oracle ... as usual

Oracle by Laurent Leturgez

Carlos Sierra's Tools and Tips

Tools and Tips for Oracle Performance and SQL Tuning

Just another oracle developer

Coskan's Approach to Oracle

What I learned about Oracle

Oracle Scratchpad

Just another Oracle weblog

Oleksandr Denysenko's Blog

be prepared for The Future...