They dont take rman backups because of the size of the database and rely on bcv backup technology
From what I understand, PowerHA is a cluster technology for IBM AIX and BCV is a backup technology based on volume snapshot and mirroring. Your customer may have a disaster recovery to restore the whole enchilada, but without RMAN, Oracle database recovery, restore and other useful options are out of scope. Sorry, but your customer seems to have spent more money on hardware and licensing instead of a reasonable system admin and DBA.
Anyway, storage for the purpose of backup is cheap and not a good excuse for rejecting RMAN. Oracle 10g is obsolete, but can still provide a solution. If the customer cannot afford any downtime then I think RMAN duplicate and creating a physical standby database is a good solution. The only downtime will be when converting the standby to primary.
Other than that, without RMAN, I'm afraid you will have to shutdown the database and use the ASMCMD copy command to copy the data files to the ASM diskgroups.
You may not be able to use RMAN DUPLICATE because it didn't support FROM ACTIVE DATABASE in 10.2 (unless 10.2.0.5 has introduced the enhancement).
You could still use RMAN to COPY DATAFILE to ASM and then SWITCH DATAFILE and RECOVER DATAFILE (or SWITCH DATABASE and RECOVER DATABASE).
There will be downtime required for the RECOVER phase.
Hemant K Chitale
Yes, and which I questioned. The client has obviously spent a substantial amount of money for their BCV backup system, probably Symantec or EMC, which is for disaster recovery, but in my opinion does not qualify for a reasonable Oracle database backup. They might as well use the existing disk space to create a standby database instead. Disk space for the propose of RMAN does not have to be a SAN. Versatile and cheap storage solutions exist. You can get 2 TB HDD's for $100 and easily build a suitable storage system for RMAN, e.g. NAS.
I agree, using RMAN backup as copy is a good solution for ASM migration, provided the database runs in archivelog mode.
The following should be useful:
Thank you for all the responses.
When I said customer rely on bcv backup instead of rman because of size of database actually I meant the time it would take for rman to backup 30TB of database. Thats the reason they go for bcv backup.
I had posted the question in communities.oracle.com and got similar responses:
1. Use rman switch to copy
2. Use physical standby if ct can spare extra server
Perhaps using BCT (block change tracking) can speed up the process sufficiently. If change tracking is enabled, RMAN uses the change tracking file to identify changed blocks for incremental backup, thus avoiding the need to scan every block in the datafile. It actually works in a very similar fashion as the snapshot technology used in BCV. Of course an initial level 0 backup will still have to be performed.
>They might as well use the existing disk space to create a standby database instead
They would be using the "existing disk space" for the BCV clones.
BCV backups *are* a reasonable backup method for very large databases. However, imho, these backups must also be copied to tape to protect from storage failure.
>You can get 2 TB HDD's for $100 and easily build a suitable storage system for RMAN, e.g. NAS.
Yeah right ! Think of the organisation that is running a single database of 30TBs. And likely many other databases. They would have very strict data centre controls.
Hemant K Chitale
BCV uses copy on write technology and advanced mirroring techniques. A BCVs can be used to resync data or it can be detached from the active data storage and mounted separately for offline processing.
If a complete restore of an object or previous device clone is sufficient then it can be a quick disaster recovery. However, certain implementations, like EMC Timefinder/Snapshot are not suitable for disaster recovery since they rely on the existence of the original data source.
Anyway, I think BCV technology provides only a very limited way for Oracle database backup since it duplicates data errors and is not suitable for advanced rman database or tablespace restore and recovery. A 30 TB database can be time consuming for RMAN, which also depends on what kind of database it is and, for instance, how frequent a full backup is required, but it can be done.
Regarding NAS, it is just an example to show that affordable storage solutions exist and that it does not have to be expensive EMC storage. I do not see why such a solution cannot meet very strict data center controls in terms of technical aspects.