Host-based backup of VMware vSphere VMs.
Post Reply
i3uln
Novice
Posts: 9
Liked: never
Joined: Jan 03, 2022 8:13 am
Full Name: BUHYUN SONG
Contact:

Recover databases by changing Oracle RAC (ASM) to Oracle Standalone

Post by i3uln »

CaseNumber: # 05858828

We succeeded in RMAN backup of Oracle RAC through scripts and plug-ins, and we are going to proceed with the recovery test.
Oracle RAC is using ASM functionality. (Deployed the Veeam rman plugin)

However, the customer wants a recovery test with Oracle Standalone rather than an Oracle RAC environment.
p2p recovery through Veeam recovery media, DBA attempted to recover the database after changing from Oracle RAC to Oracle Standalone and setting up ASM configuration, but the recovery failed (log collection failed).

Some instances are recovered, but others are not.
In my opinion, there is a missing part in the ASM Disk groups configuration.

I would like to proceed with RMAN recovery from Oracle RAC backup to Oracle Standalone, is there any additional confirmation?
Andreas Neufert
VP, Product Management
Posts: 6707
Liked: 1401 times
Joined: May 04, 2011 8:36 am
Full Name: Andreas Neufert
Location: Germany
Contact:

Re: Recover databases by changing Oracle RAC (ASM) to Oracle Standalone

Post by Andreas Neufert »

RMAN based restores do not depend on anything Veeam beside the connection.
Can you please post the RMAN commands/script that you use for restore here so that we get an idea on what the process looks like?
rkp1977
Lurker
Posts: 1
Liked: never
Joined: Oct 20, 2023 11:25 am
Full Name: Raj Patel
Contact:

Re: Recover databases by changing Oracle RAC (ASM) to Oracle Standalone

Post by rkp1977 »

HI Guys,
We have been migrating RAC database (2 node only) using this approach. Where in, we shutdown RAC db, shutdown node 2, detach ASM disks from node 2, shutdown node 1, finish replication of disks to the target disks, start node 1, start Oracle instance on it, attach node 2 to the disks, start Oracle instance on node 2.

This approach has worked for migrations of many RAC db's, but lately in last migration, when we started db on target disks, we get error of datafile checkpoint change advanced (not in and higher than the last one recorded in CF and Redo logs) - ORA-01207. We couldnt move way forward thru this situation, even engaged ORacle Support to assist in this recovery scneario. Datafiles were not fuzzy too. Then as backout, shutdown vms on the target and started them with the source disks (they were intact), RAC db started without any issues.

ORacle says -As per the diagnostic data collected, it was found that the controlfile and redo logs were older versions then expected. datafiles were more recent
This is not a case of checkpoint moving back or forward. The storage replication gave you different versions of different files from different point-in-times.
There is no further evidence to collect at Oracle level since the entire activity has happened OUTSIDE of Oracle.
You should pursue this with the storage vendor.

I am wondering if Vsphere replication approach to convert RAC db to standalone for storage migration purpose has any pitfalls or not. It has worked for us in some, but has failed in this instance.

Thanks
Rai
PetrM
Veeam Software
Posts: 3229
Liked: 520 times
Joined: Aug 28, 2013 8:23 am
Full Name: Petr Makarov
Location: Prague, Czech Republic
Contact:

Re: Recover databases by changing Oracle RAC (ASM) to Oracle Standalone

Post by PetrM »

Hello Raj and Welcome to Veeam R&D Forums!

Do I understand correctly that you used Veeam replication job to replicate disks? If it was native vSphere replication, I'd suggest asking this question on VMware Communities.

Also, it's worth clarifying how Oracle support made this conclusion:
The storage replication gave you different versions of different files from different point-in-times.
In fact, it seems strange that it worked fine for many migrations but failed for one of them. If the issue came from the storage vendor, all migration attempts would fail.

Thanks!
Post Reply

Who is online

Users browsing this forum: No registered users and 99 guests