Subscribe

SMO-- Cloning Prod Best Practices

[ Edited ]

We have been using SMO for a while now and have a mixed environment with windows Oracle DB's(iSCSI) and Linux Oracle DB's(NFS). I have done pretty well with the help of our DBA on getting the Profiles created and setting up the DB's in a OFA layout, and scheduling backups. We are now looking to the cloning feature and are a little concerned with a couple of things. My experiance with FlexClones is next to none.

The questions I have are on the following setup: RedHat Linux, NFS, Oracle OFA layout, SMO 3.0.2.  So here are the Questions I have with SMO:

1. We have are DB's in Archive Mode and are running Snaps Daily with 7day retention. As you are well aware SMO doesn't handle the Obsolete archive logs. So we have created a script to delete the Obsolete archive logs. Problem is that the data is still retained in the Snap Thus using up the volume space. Does this mean I must calculate the volume size to handle at least 7 days worth of Archive Logs? We are talking anywhere from 16-30gb of archive logs a day. Suggestions on optimizing this space?

2. Best practices for Production DB's Clones. We have been manually Tarring up Production DB's and placing them on new volumes for Development and Testing. If the Development is going to last several month's before a new clone is needed, should we refrain from using SMO-Clones as the Snapshot will have to be retained(Busy) until the clone is deleted, thus tying up valuable space on the volume.  Is it best to only clone Dev/Test DB's and/or mirror the production DB to a New volumes? Should any Clone be kept for extended periods of time.

3. Cloning E-Business Suite. This process is very fragil as we have found out and so far been unsuccessfull in accomplishing. The App Tier has to be cloned/copied along with the cloning of the DB. Is there any procautions that we are missing? We are unable to connect the App Tier to a Clone even when Successfull.

Thats if for tonight but I know we will have more questions to be discussed(just can't think of them right now.). Thanks for any help given!

Re: SMO-- Cloning Prod Best Practices

Hi Richard,

i'll try with the 1st question only this time (I guess second was already answered)

"As you are well aware SMO doesn't handle the Obsolete archive logs."

That's not true, actually SMO takes snapshots of archive log location(s?). You have to have archived redo logs as part of your online backup  of Oracle, becasue without those you are not able to recover to some consistent point during restore. Technically it means that SMO/SMSAP during restore connects to the snapshot of archive log volume and applies  those redo logs to the recovered instance SINCE the starting hot-backup.. so need (per single SMO backup) only a few archive logs to actually bring Oracle to the state of the backup (it needs to apply those logs to bring Oracle to consistent/non-hot-backup mode so that it acutally is able to open). The best way to save space would be:

1) delete obsolete archivelogs

2a) run hot-backup via SMO(take the snapshots)

2b) actually SMO will cause a several log switches

2c) and take snapshot of Oracle archive log location

The question is about synchronizinng 1+2a+2b+2c. In my opinion the best ways are: 1) SMO+RMAN+cronjob or 2) manual cronjob script (calling smo manually) 3) find a way of running some command from SMO before taking hot-backup (i don't know of any scripting entry before doing hot-backup, other than PM/DFM pre-backup script, but you didn't state anything about PM so i guess you are not using it)

NOTE: you cannot have just simple cronjob that is going to remove archived redo logs, because this cronjob might remove some files during SMO backup run and thus backups would fail.

Hope that helps.

-Jakub.

Message was edited by: jakub.wartak