Re: Hot backups

"we never know when exactly the concurrent logs and out folders are backed up" 

But we do know.
If you recover the file system first, all you have to do is look at the last log and output file. You will get both the request id and the database point in time (the timestamps in the log and output files are from the database time) that the request completed. If your hot backup includes archive logs that span the entire file system backup you can recover your database to pretty much the exact point in time that the log and output directories were backed up.
With a linear backup such as tar, or backup software like Backup Exec, the log and output directories may not be in sync with each other which is a different problem. You can go with the earlier of the two, or you could manually sync them up from production, or if perfect synchronization is critical, you could (and should) investigate taking file system snapshots (LVM, SAN, Veritas, etc.) for a more globally- consistent file system backup.
Point is, as long as you have your archive logs, you can recover the database anywhere you like. By recovering the file system first, you can see exactly what time that should be. 

Chuck Edwards
Blue Gecko, Inc
http://www.bluegecko.net/oracle-apps/dba



On Feb 19, 2009, at 11:29 AM, Sriramulu, Jayakumar wrote:
“Bottom line, it doesn't matter exactly when the database backup finishes; what matters is you have brought the recovered (or cloned) database up to the same point in time as the end of the file system backup.”
I agree . But in either case with hot backup , we cannot get both the file system and database in sync. ( Even if you recover the database close to the point in time when the apps stack backup completed, we never know when exactly the concurrent logs and out folders are backed up, so technically the database recovery point in time should match the time when the concurrent log and out folders backup completed ) 

  Thanks for the explanation.

         Jay
From: ora-apps-dba-bounce@xxxxxxxxxxxxx [mailto:ora-apps-dba-bounce@xxxxxxxxxxxxx ] On Behalf Of Chuck Edwards 
Sent: Thursday, February 19, 2009 1:20 PM
To: ora-apps-dba@xxxxxxxxxxxxx
Subject: Re: Hot backups
Starting the database backup later is what can can cause the inconsistency.
As long as you recover the database to a point in time that is close to when the file system backup is finished, you will have reasonable consistency between the concurrent manager logs and output and FND_CONCURRENT_REQUESTS. If you start a database backup after the apps stack, you will have to recover DML to FND_CONCURRENT_REQUESTS that is not in your file system backup. 

For example:
1. You back up the file system. The backup completes at 8:00am. At 8:00am, the latest concurrent request ID is 90000. 2. You now start the database backup AFTER completing the file system backup (8:00am or later). The db backup completes at 11:00am and the latest concurrent request ID is now 90500. 3. When you recover the file system (for a clone or whatever) the $APPLCSF directories will only contain logs and output up to request 90000 because that was the latest request id at the time the backup completed. 4. When you recover the database hot backup, your database will reflect the concurrent request ID from the END of the hot backup. 90500 in this case. You will have lost the actual output and log files of 500 requests, but it will look like they are there in the application. 

On the other hand:
1. You start a hot database backup that completes at 8:00am. The last concurrent request ID is 90000 and the last database log sequence number is 100. 2. You then back up the file system, which completes at 11:00am and the last concurrent request ID is now 90500. You also note the current database log sequence number is 112. 2a. You add database logs 101 - 112 to your already completed hot db backup. 3. You recover the file system (for a clone or whatever) and the $APPLCSF directories contain logs and output up to request 90500 this time. 4. You recover the hot database backup ALL THE WAY UP TO LOG 112; The latest concurrent request ID in FND_CONCURRENT_REQUESTS is now also 90500. Everything is in sync because you recovered the database to the same point in time that the file system backup completed.
Bottom line, it doesn't matter exactly when the database backup finishes; what matters is you have brought the recovered (or cloned) database up to the same point in time as the end of the file system backup. 

Hope that helps,

Chuck Edwards
Blue Gecko, Inc
http://www.bluegecko.net/oracle-apps-dba



On Feb 19, 2009, at 10:05 AM, Sriramulu, Jayakumar wrote:
I would think taking database hot backup ( at the end or ) slightly later than the apps stack backups would be better as the concurrent jobs’ logfile and outfile details would be in the database this way. Otherwise the logfile and outfiles would be in the apps stack backups but the corresponding table entries will not be in the database backup. 

       Thanks,
         Jay
From: ora-apps-dba-bounce@xxxxxxxxxxxxx [mailto:ora-apps-dba-bounce@xxxxxxxxxxxxx ] On Behalf Of Chuck Edwards 
Sent: Thursday, February 19, 2009 9:38 AM
To: ora-apps-dba@xxxxxxxxxxxxx
Subject: Re: Hot backups
The order doesn't matter much as long as they are done at roughly the sane time. If you are backing up the database hot (which you should) back up the database first, and capture the last archive log as soon as the file system backups are complete. You will the have a complete backup that includes all database changes up to the completion of your file system backups.
Hot backups will require you to create the database and perform an incomplete recovery (either manually or via RMAN). This is not very difficult and gives you more control over what point in time your clone represents.
One note: It's rarely necessary to clone the RDBMS_ORACLE_HOME, IAS_ORACLE_HOME, and 8.0.6_ORACLE_HOME; These file systems do not change much and application patches do not affect them. You should back them up, but there isn't usually a reason to re-copy them to downstream environments every time you clone unless something has changed (e.g. you applied an RDBMS patch, a new Developer 6i patchset etc.) 

Chuck Edwards
Blue Gecko, Inc.
http://www.bluegecko.net/oracle-apps-dba



On Feb 19, 2009, at 1:06 AM, Dwyer, Brian wrote:

***************************************************************************
Internet email is not to be treated as a secure means of communication.
North Yorkshire Police monitors all internet email activity and content. 

This communication is intended for the addressee(s) only.

Please notify the sender if received in error. Unauthorised use or

disclosure of the content may be unlawful. Opinions expressed in this

document may not be official policy. Thank you for your co-operation.

***************************************************************************


Hello
Looking at implementing hot backups on our 11.5.9 system running on Solaris.
Do you backups the APPL_TOP / COMMON_TOP/ IAS_ORACLE_HOME / 8.0.6_ORACLE_HOME / RDBMS_ORACLE_HOME before you backup the database files or do you do it the other way? 

And how does a hot backup affect the way that you do a clone?

Cheers

Brian


__________________________





_____________________________






_____________________________

Other related posts: