Tuesday, 16 November 2010
PRCD-1119: Failed to create database because the database unique name matches that of database in the first 8 characters
There's a note on a site tracks all oracle error codes that say you have to check DB_NAME provided in srvctl command have to be sufficiently unique versus DB_UNIQUE_NAME. Ok, I've never taken care of these as usually I don't use difference between SID, INSTANCE_NAME, DB_NAME, DB_UNIQUE_NAME. Yes you work and define them different for some (many ?!) porpuses....if you really want.
With 11gR2 I've discovered in these days that many limits are reached if you want to have INSTANCE_NAME/SID different from DB_NAME/DB_UNIQUE_NAME. For example in both 18.104.22.168 and 22.214.171.124, DBCA lets you to define two different name, as always, but during instance creation and registration, cluster resources are created using DB_NAME and instance is started usind DB_NAME instance INSTANCE_NAME.
Also this error prevents you to have an instance called MYEXAMPL and DB_NAME called MYEXAMPL. You'll no able to register it. Why? I do not know.
If you use srvctl add database you'll raise this error. If you use crsctl add resource you'll be able to do it, but you'll never be able to start your database. I'm trying to debug it.
Monday, 15 November 2010
Question is really clear. I'm thinking about many environment where a two o three nodes cluster hosts different single instance databases. Actually standard cluster configuration requires a virtual IP (vip) for each managed instance in failover configuration. If you have a three nodes cluster with 10 databases you'll use about 13 IPs: 1 ip for each server (3 total) and 1 ip for each instance to bind each own listener over (10 total).
Today with SCAN technology you may, in part, simplify this configuration and reduce the number of ip address needed. But.... what about all other cluster resources? I want to say: oracle enterprise manager agent, scheduler agent, application software, etc ..? These can't take advantages of SCAN technologies and many times they can't discover that are working in a cluster environement ...
To go deep:
- Oracle EM Agent may work in a cluster way monitoring cluster target. This is from manual, I've tried in past without any interesting results
- Custom monitoring software may require to have a VIP
- Enterprise scheduler may require to have VIP if need to execute operations against the host where an instance is running
- Custom applications may also need to have a VIP because they are not able to understand if an instance is running on a host or another one
So, I think you should evaluate carefully all points before decide to left standard VIP per instance configuration