This content has been marked as final. Show 9 replies
this means, that you had a "lost write" on a disk. So your disk information is not o.k. and your diskgroup is corrupted.
It seems your replication software did not work correctly and forgot to sync everything.
For the future I recommend DataGuard instead of relying on storage mirroring for DR.
Even though bad for you, this is a perfect use case, why Oracle Data Guard is recommended for disaster recovery, and storage mirroring is not....
However good thing is, that if it it just the FAST or Flash Recovery Area, that you should still have a functional DB, and just your disk based backup (including one control file + one redolog member) got corrupted. You should be able to get the database mounted and running without the FLASH diskgroup.
Thanks for the valuable information.
As the storgae level replication is too fast , we are opting for the storage level replication.
Could you please help how i can bring the database up without having the +FLASH DG.
Thanks a lot.
if this is not a cluster, then RMAN will help you. (Identifying the possible problem).
Since your FLASH is corrupted, first thing I would do is create a new diskgroup in ASM. I would at the moment prefer, not to take the same disks as the FLASH diskgroup. Maybe use a new LUN for the time beeing. After everything is finished, you still can decide to reuse the defect disks.
If this is single instance, than it is pretty easy:
=> Mount the DATA diskgroup (which you already did).
=> Mount the newly created diskgroup
=> Call RMAN and try to startup the DB.
=> Do a "list failure" in RMAN, which will very likely tell you, that one controlfile copy is missing
=> Do an "advise failure" in RMAN, which tells you the plan how to recreate the second controlfile (probably need to exchange the FLASH diskgroup in the statement).
=> Then again try to startup and use list and advise failure, which then will tell you what to do with the redologs.
After this is done, you will likely have to change the DB_RECOVERY_DEST to the new diskgroup.
Thanks for your reply.
More Information about the production and DR environment
Production Environment is a 2 node RAC. As it is 11g R2, Oracle Grid Infrastructure is installed.
DR Environment is a Single Server where Oracle Grid Infrastructure for a Standalone Server and Oracle Database Software are installed.No Database Instance created.
Please let me know your valuable points in proceeding further.
As the replication is a third party storage replication, Oracle will not provide support.
ouch. Again use data guard. You will find lots of information on how the setup has to be done and how it is handled.
Doing storage mirroring with RAC on one side, and single node on the other side, is not an easy tasks, which can be answered in a forum thread.
There are as far as I know no technical whitepaper identifying this kind of implementation you can refer to. Maybe other have found something.
Since you already were able to mount the Data diskgroup at the standby side (but not flash), you are at least one step further.
However as indicated above, this already identifies a major problem of your DR. No information what else can go wrong.... Maybe next time it is both diskgroups, and then the solution won't work at all.
The first starting point would be how to recover a single instance database from a RAC database.
HowTo Restore RMAN Disk backups of RAC Database to Single Instance On Another Node (Doc ID 415579.1)
However since you have datafiles and spfile, you don't need the recovery. You can access the spfile on the Data diskgroup.
However you need to change some setting in the spfile, before you can continue.
We did a replication of the DATA and FLASH Disk Groups again from production environment and we are able to mount the 2 disk groups.
Now i have DATA and FLASH in the DR site.
My Plan is as follows.
1. Create an instance in DR Server using oradim.
2. Create the pfile from production db and remove the RAC related parameters.
3. Using the edited pfile bring up the instance in DR to no mount state.
4. Use RMAN and connect to the catalog.
5. Restore/Recover the control file and datafiles.
6. Open the database using resetlogs.
the issue i am facing now is while trying to startup the instance using the edited pfile (step 3) getting the following error.
ORA-00439: feature not enabled: Real Application Clusters
ORA-01078: failure in processing system parameters
Please let me know your valuable suggestions.
Edited by: 944470 on Feb 7, 2013 7:28 AM
post the contents of your pfile.
You still have a parameter, which identifies it as a RAC DB.
Probably you still have 2 UNDO Tablespaces or similar....
Thanks a lot Sebastian for your quick reply.
Now i am able to start the instance in nomount
Issue was with one parameter. It is cluster_database. After setting Cluster_Database=FALSE i am able to start the instance in nomount.
I will keep posted about the issues i am facing.
Following is my updated pfile content
I recovered the databases successfully.
Used the almost the same method of duplicating a database.
Important changes made
1. In the initialization parameter of DR Database, mentioned the parameter CLUSTER_DATABASE=FALSE
2. Created a instance using oradim
3. startup the instance in nomount using the pfile
3.a Some database instances throwed error related to recovery of particular datafile. In those case, used the command recover datafile <filenum>;
3.b In Some databases, got ORA-600 errors. Used the command Recover database;
4. Create spfile from pfile=<location of new pfile>;
5. Add the databases to the Grid Infrastructure using srvctl add database -d <dbname> -o <Oracle_Home>
Once more, thanks sebastian for your valuable comments.