Hopefully my last dataguard topic - Failover & reinstate

Question

So I have a 10.2 setup with a primary and physical standby.
I've configured dataguard broker and it all looks good.
Now I'm trying to test failover. I shutdown the primary, executed a failover command in dgmgrl to failover to the standby and it's up and running....
I can't get the new standby (old primary) to reinstate. All I get is ORA-16653: failed to reinstate database. The docs say if it fails, you have to go through the steps to create a standby database as you did at the start of this entire process.
Okay, well from where I'm sitting, all of the settings are already done (since I set them all on the primary before it was disabled), so the only thing I should need is to get a standby control file from the primary and copy it in...but it still won't reinstate. I copied the database from primary over to secondary...still won't. I can mount it but cannot select from any of the v$ views. I've restarted the listener, no help.
The way this is configured, is I have the exact same instance name on two different servers. The only difference between them is the unique_db_name (band & bandbackup). I created tnsnames entries on each box that correspond to the unique names.
I guess I don't see why this is so hard. I have two databases, the current primary is originally a copy of the old primary which had all of the needed alters run on it. The only difference was in the spfile settings (opposite unique_db_names for delivery) and I've verified those are set. What am I missing?

Answer 1

Look, here's what I do to reinstantiate a failed standby:
1. Remove all the DataGuard configuration including DataGuard parameters in Primary and Standby init files.
2. Change the DB_UNIQUE_NAME of the Primary to what it should be (BAND, for you)
3. Put every tablespaces in turn in BACKUP mode and rcp their DATAFILEs to remote standby host.
4. Create a standby controlfile, rcp it to remote standby host.
5. Multiplex the standby controlfile as needed
6. Create a pfile from the primary spfile and change needed parameters (LOG_ARCHIVE_DEST_n, DB_UNIQUE_NAME) to reflect it's a STANDBY database now.
Transfer this pfile to remote standby host and build a spfile from it
7. Startup the standby in mount mode, check the necessary archive log files to bring it to a concistent point in time.
Because the rcps and other processes can take time it's a fuzzy copy of the main database. Then rcp the archived redo logs to the standby and "recover standby database until cancel".
Once this is done, put the standby in recover managed mode, check if MRP is started up (from v$bgprocess) and check apply status (from v$managed_standby).
8. choose a LOG_ARCHIVE_DEST_n from the Primary and set a SERVICE to the new standby.
Then switch current logfile. Check the sending status in alert log. Check on standby host the archive is received.
9. check apply progress in v$managed_standby
10. no step 10 all is OK.And this has always worked for me!
About your other question: "what does the DG Broker do?"
The GB Broker, as for me helps in mainly 2 points:
. Check the configuration. It monitors if everything is ok, and ensores log sending and in max protection mode the shutdown of the primary if standby is unrechable, and so on.
. Enables the switchover option, which isn't available without a DG Broker (IIRC).
Good Luck,
Yoann.