Hi guys

I always wondered how the heck a RMAN backup could be restored to Oracle EBS environment. Last two years, I spent considerable time learning Oracle database technology, especially about the backup and restore procedures (learning a lesson after a disaster)

We have the following approach towards Oracle EBS backup:

Daily RMAN hot backup (Friday’s exempted as we do a full cold backup), with 7 days retention policy.

Weekly cold backup for both application and database tiers

Cold backup is written to a backup server, then copied to an external drive (USB attached). This way the cold backup remains in 3 different places.

Usually whenever a fresh clone requested, we were building them against the latest cold backups. Many cases a Friday cold backup clone is NOT what the consultants want, they need much recent data on a Thursday! This has forced me to start pondering over google to find a properly written document to support my own experiments and not like other areas of database, the availability of decent documents were scarce!

So I approached one of my APPS DBA friends, who was always there to help me & readily made me available with a document that he used for his specific environment. After some tweaks I was able to successfully restore the RMAN BACKUP to Oracle EBS environment without troubles (Well, the time it took were much more than that from a cold backup cloning)

I assume, if you are going through this write-up, you have the below setups:

1. Single instance Oracle EBS R12 Deployment
2. You are using Oracle 11g R2
3. You are on LINUX
4. You already have a cloned instance, properly configured SPFILE & listener services
5. You have environment parameters set and called through .bash_profile(s)

Steps

copy RMAN files from Production server to TEST server using SCP. The document asks me to create the same path structure, haven’t tried other options yet. For example, the Production server has /u03/RMAN/DAILYBKP for the daily RMAN backups, hence I made the same available with TEST instance as well. The below command copies the RMAN backups those are one day older from the current date to TEST instance.

time scp `find -maxdepth 1 -type f -mtime -1` root@erptest.xyz.com:/u03/RMAN/DAILYBKP

Once the files are copied, shutdown both application and database instances respectively.

Delete the .dbf files (data files) from the “apps_st/data/” folder.

Example, my TEST server has the data files here “/u01/oratest/TEST/db/apps_st/data”, so I did a rm -rf * here to remove all the files available in this folder. We’ve approximately 500GB data files in this folder.

Once the files are deleted, open a terminal and switch to Oracle database user. Source the environment incase if the .bash_profile is not set to.

Issue “sqlplus / as sysdba” command

Startup the database in not mounted state

startup nomount

Start another terminal and switch to Oracle database user. Now let us start RMAN recovery

Before attempting the RMAN duplicate, make sure the ORACLE user has full ownership on the backup folder. If not, RMAN will start reporting the controlfile not found & other associated errors and the duplication will fail.

I’ve a cronjob, executed as root to copy the rman files everyday to TEST instance, hence the default ownership on the backup folder is set to root, that I realized today (4th Feb 2019) while trying to duplicate the database!

rman auxiliary /

That should connect you to RMAN duplicate database mode.

Now, the most important few things. The RMAN backup will have datafile names associated with path information. For example, my production server keeps the datafiles in the absolute path “/u05/oraprod/PROD/db/apps_st/data/”, where in my TEST server has the cloned database instance over “/u01/oratest/TEST/db/apps_st/data”. So we will have to rename the database files prior they are restored. The RMAN run command set that you will create will take care of renaming the files.

Create a RMAN command set like below (adjust accordingly)

My production instance database name is “PROD” and my TEST instance name is “TEST”, so the duplicate database command should be adjusted accordingly.

run
{
ALLOCATE AUXILIARY CHANNEL c1 DEVICE TYPE disk;
ALLOCATE AUXILIARY CHANNEL c2 DEVICE TYPE disk;
ALLOCATE AUXILIARY CHANNEL c3 DEVICE TYPE disk;
ALLOCATE AUXILIARY CHANNEL c4 DEVICE TYPE disk;
duplicate database to "TEST" backup location '/u03/RMAN/DAILYBKP' nofilenamecheck
db_file_name_convert=('/u05/oraprod/PROD/db/apps_st/data/','/u01/oratest/TEST/db/apps_st/data/')
LOGFILE
GROUP 1 (
'/u01/oratest/TEST/db/apps_st/data/redo01a.log',
'/u01/oratest/TEST/db/apps_st/data/redo01b.log'
) SIZE 1000M ,
GROUP 2 (
'/u01/oratest/TEST/db/apps_st/data/redo02a.log',
'/u01/oratest/TEST/db/apps_st/data/redo02b.log'
) SIZE 1000M ,
GROUP 3 (
'/u01/oratest/TEST/db/apps_st/data/redo03a.log',
'/u01/oratest/TEST/db/apps_st/data/redo03b.log'
) SIZE 1000M ,
GROUP 4 (
'/u01/oratest/TEST/db/apps_st/data/redo04a.log',
'/u01/oratest/TEST/db/apps_st/data/redo04b.log'
) SIZE 1000M ;
RELEASE CHANNEL c1;
RELEASE CHANNEL c2;
RELEASE CHANNEL c3;
RELEASE CHANNEL c4;
}

You may keep the RMAN RUN commands saved in a text file for future use!

At the RMAN prompt execute the newly created RMAN RUN command set. It is going to be a long wait, the bigger the database, the more time you wait for the restoration to happen.

Wait until the RMAN processes are finished. You should be back to RMAN prompt

From a SQL Plus session, shutdown the database

Now restart the database at mount state.

startup mount

Disable Archive logging prior doing anything else

SQL> alter database noarchivelog;

Shutdown the database. Now we will do the post cloning activities against the database instance.

Switch to the appsutil/clone/bin over $ORACLE_HOME path. Example “/u01/oratest/TEST/db/tech_st/11.2.0/appsutil/clone/bin”

Issue the following:

perl adcfgclone.pl dbTechStack

Input details for your instance and complete the post cloning activities. This shouldn’t take much time!

Once the post cloning activities are completed, switch to ..install/TEST_erptest folder, example: “/u01/oratest/TEST/db/tech_st/11.2.0/appsutil/install/TEST_erptest”

Start SQLPlus from this location and execute “adupdlib.sql”

SQL> @adupdlib.sql so

Once the procedure run finishes, issue COMMIT

Commit;

Run Autoconfig for your Application instance and you should be online soon.