There could be occasions when as an apps DBA you would be asked to provide a fresh clone either over test or development environment to address a serious issue.

Rapid Clone hierarchy usually requires a DBA to pre-clone both application & database tiers, shutting down the source system and then souring the relevant folders to target system.

Today we are going to share a minor hack which could help you, when you cannot JUST shutdown a Production instance, however the cloned instance is a mandatory element to deal with a particular situation.

(Please note, this hack is ONLY applicable to situations where the backups were made without running PRE-CLONE or errors were raised stating

1. Control file creation failed : ORA-01503: CREATE CONTROLFILE failed
2. Certain database files were not recognized as part of the database : ORA-01565: error in identifying file)

Errors and example scenarios as mentioned with this thread

#cd /backup

#time tar –zcvf apps.tar.gz /u01/applprod/PROD/apps/*

(use “time” to check how much time the activity has taken)

Once the application tier has been tar balled

#time tar –zcvf db.tar.gz /u01/oraprod/PROD/db/*

Wait until the tar ball created

Now you can SCP the tar balls to your target system

scp –pr *.tar.gz root@targetsystem:/backup

The approximate time to transfer a database tar ball in 100GB size should be 33-35 minutes and the application tar ball in size 31GB around 9-10 minutes

Backup (if required after running the pre-clone) of your TEST/Development instance and delete the application and database folders (make sure you have shutdown the application and database instances)

#cd /u02/oratest/TEST/db

#rm –rf *

#cd /u02/appltest/TEST

#rm –rf *

Now extract the tar balls to respective base paths

#time tar –zxvf /backup/apps.tar.gz

We are already in the folder /u02/appltest/TEST so the application instance files will be extracted in the same location

Once the extraction is over, we can go ahead with extracting the database tier files

#cd /u02/oratest/TEST/db

#tar –zxvf db.tar.gz

Wait until the extraction part is over

The real hack starts from here

#cd /u02/oratest/TEST/db/tech_st/10.2.0/appsutil

#rm –rf *

Switch to source system (Aka Production instance)

#su – oraprod

If the .bash_profile has an exclusive call for the environment sourcing, your environment will be automatically sourced, else source it

Run pre-clone for the database tier now

$perl adpreclone.pl dbTier

Once the pre-clone activities completed successfully, switch to

$cd $ORACLE_HOME/appsutil

Create a tar file

$tar –zcvf appsutil.tar.gz *

Now move the new tar file to your TEST/Development instance

$scp –pr appsutil.tar.gz root@targetsystem:/backup

From the target system, move to

#cd /u02/oratest/TEST/db/tech_st/10.2.0/appsutil

Unzip the appsutil.tar.gz

#tar –zxvf /backup/appsutil.tar.gz

Once the files are extracted, change the ownership of the base path once again

#chown –R oratest:oinstall /u02/oratest

Change the access permissions

#chmod –R 777 /u02/oratest

Now as user “oratest” you can start the database tier cloning

#su – oratest

$cd /u02/oratest/TEST/db/tech_st/10.2.0/appsutil/clone/bin

$perl adcfgclone.pl dbTier

Once the database tier cloning completes successfully, you can proceed with application tier cloning, which doesn’t require any specific hacks

Side notes:

In my case I found that the “Gather schema statistics” program was missing from the scheduled jobs list. If you are experiencing slowness with your freshly cloned instance, it is highly recommended to run the said program prior going ahead with any other activities.

Make sure you would clear the cache under global configurations.

Hope you enjoyed another “hack” from us! Our sincere thanks and gratitude to Ravi Purbia (Sr. Apps DBA Consultant) who has provided us the details about this particular hack.

regards,

for Windows7bugs

admin