Database Software

Hello,

IHAC who needs to get a standby in place as soon as possible. We're running into some confusing problems with the creation of a RAC physical standby for a RAC primary.

Please accept my apologies if some of this info is vague. We are working in a sensitive environment and I'm unable to provide more specific info because of security/firewall requirements.

The procedures in Metalink note #380449.1 were followed to attempt to create a standby for this RAC environment. The environment consists of a 2 cluster node primary RAC environment and a 2 cluster node standby environment.

Some history:

Using note 380449.1, the customer created the standby environment and proceeded to create the data guard standby using RMAN's backup and duplicate database commands specified in the note. The customer originally used the DB_FILE_NAME_CONVERT and LOG_FILE_CONVERT parameters since the standby devices did not duplicate the primary. They encountered problems with starting the managed recovery process after the duplicate was completed because the standby database did not recognize the data and redo log files. After checking both of the CONVERT parameters, the customer had only specified the parts of the path that were different on each instance. We then modified the parameters to include the full path for each parameter which would be more reliable. After this was done, the standby was reverted to it's orignal state before the duplicate had been run and we attempted to duplicate the database again. All duplicate status information reflected that the convert procedure was running successfully. There were no indications to any problem whatsoever. But when attempting to begin the managed recovery process on the standby, we again ran into problems with the datafiles actually being placed in the wrong disk group. (ie: there are two disk groups, ASMGROUP#1, and ASMGROUP#2. The index files should be located in GROUP1 and the data files should be located in GROUP2.). All data files are being directed to GROUP2. The redo logs, although directed to and created in the correct disk group are also not recognized when attempting to start the standby. Errors in the alert log are as follows for all redo logs:

ORA-00313, ORA-00312, ORA-17503, and ORA-15173.

Errors in the alert log are are follows for the data files:

ORA-1157, ORA-1110, ORA-17503, ORA-15012.

We then attempted to reconfigure the standby server so it duplicated the primary environment in order to eliminate the need for the FILE_CONVERT parameters. After this was done, when the duplicate command was run, all data files were placed in group#2. This was reflected in both the duplicate database status info and the alert log on the standby. The redo logs were all listed as invalid and caused problems as well.

It seems that the original paths that are in the RMAN backup are being ignored and it looks like the DB_CREATE_FILE_DEST parameter is being used for the file creation instead. This is causing a big problem because it's not what's in the control file.

I'm hoping that someone can point me in the right direction in regards to finding a resolution for this problem. My experience with dataguard is fairly strong, but I have no RAC/ASM experience and am not sure what I can look for on that side of the issue.

One question I have is related to the DB_CREATE_FILE_DEST parameter. I was wondering if it would be worth a try to turn it off the duration of the standby creation to see if the files would be placed in their correct respective directories and then turn it back on once the standby configuration has been completed successfully?

We have also opened tar #6272965.992 on this issue as well, but so far, we're still struggling.

Please include my oracle email in any replies.... beth.rumpf@oracle.com

Thanks very much in advance for your consideration and help.

Beth Rumpf