Re: Strategy question for 24X7, how to do cold backups?

Andrew,

Rather than backing up the archive logs from the log identified in Step 5 onwards, I would backup ALL archive logs generated since the last Hot Backup. Ideally, backup your archive logs to a different tape (that is, database hotbackup on one tape and archive logs and control file on another).

If you need to recover from my latest Hot Backup but find that the tape is unreadable/bad you could go back to the previous Hot Backup and roll-forward if the tape containing archive logs is good.

Because of constraints about how I can mount tapes (the job has to be automated, run at night and run with the system backups) -- I can only use 1 tape which contains both database files and archive logs. So, as additional precaution, my script also copies the archive logs to another server. In case the tape is bad, I can keep going backwards through hot backup tapes as far as 4 days and use the archive logs which are retained on the "backup" server to rollforward.

The backups also include the controlfile and the init.ora.

Hemant K Chitale
http://hkchital.tripod.com
"Andrew Allen" <ajallen_at_mailhost.det.ameritech.net> wrote in message news:3BB52545.1919AE9B_at_mailhost.det.ameritech.net...
> Galen Boyer wrote:
> >
> > All web clients want a 24X7 solution. Immediately, hot backups
> > are needed. But, then, for a true 24X7, one must keep a copy of
> > all of the redo logs from day one and a recovery would take quite
> > awhile (Maybe I'm wrong here and the question is moot). On
> > google, I am reading that one strategy is to configure a standby
> > database where the current database's redo logs are applied
> > against the standby. Then, if done correctly, a cold backup is
> > never needed? Even if it is, the standby can be used to produce
> > the cold backup?
> >
> > Am I on the correct path to the #1 solution for this and are
> > there other options as well for actually achieving 24X7?
> >
>
> I have read all of the other posts to date on this thread. I'm going
> back to the top of the thread so I do not appear to be responding to
> anyone in particular. Here is my take on this issue. Actually there
> are two issues, what do we mean by 24*7 and the preference for cold
> over hot backups.
>
> Let us tackle the 24*7 first. It has been my experience that nearly
> no users understand what they are asking for when they say 24*7.
> True 24*7 means NEVER coming down. Never coming down to do backups,
> never coming down to do schema changes. Never coming down to do
> Oracle software patches or updates. Never coming down to implement
> new application code. Never coming down, EVER. To do this requires
> at least two complete servers running in full bi-directional master
> to master replication in widely dispersed geographic sites. Ideally
> you will also have a third server that can be pressed into service
> when you must do synchronized changes to the main production
> servers. This kind of arrangement will allow you to bring down one
> database for cold backup. When I explain what true 24*7 service
> means most customers back off and explain that they just do not want
> the server to come down every night or weekend for backups and
> maintenance -- they will be happy if we can just schedule necessary
> outages when it is most convenient for them.
>
> Now for cold backups. What is the business reason for preferring
> cold backups over hot backups? Hot backups, if done correctly will
> be just as reliable and useable as cold backups. I have written a
> nice ksh to manage hot backups and it works just fine. Here is a
> brief outline of what it does.
> 1. check to make sure the database is operating in archive log
> mode. If not, we cannot do hot backup.
> 2. make a list of all tablespaces and their respective data files.
> 3. force a log switch
> 4. sleep for a while to let the archiver complete running
> 5. identify the newest archive log file and remember it. This will
> the first one we will have to include in our backup set.
> 6. step through the tablespace/data file list we made in step 2
> setting each tablespace into backup mode and copying off its
> details. when you get to the next tablespace in the list, take the
> current one out of backup mode and put the next one into backup
> mode.
> 7. force another log switch to write to the archive any transactions
> that occurred while the tablespaces where in backup mode.
> 8. sleep a while to let the writer complete.
> 9. identify the newest archive log file.
> 10. backup the control file to a named file.
> 11. copy the archived log files beginning with the one identified in
> step 5 and ending with the one identified in step 9.
> 12. copy the backed up control file.
> 13. copy the init.ora and any config.ora files you may have
> 14. tar, compress, etc. your backup set to tape.
>
> done.
>
> If you have a disk array like we use in our shop now you can do hot
> backups of a database of almost any size in less than five minutes.
> We use fully mirrored disks with a third mirror volume called a BCV
> or Business Continuity Volume. The hot backup scenario works like
> this:
> 1. do log switch.
> 2. put all tablespaces into backup mode
> 3. backup the control file to a named file
> 4. split the BCVs
> 5. take the tablespaces out of backup mode
> 6. spool the BCVs off to tape
> 7. reattach and resync the BCVs.
> EMC has a white paper on this which the wrote in conjunction with
> Oracle, IIRC.
>
> So here are two ways to achieve hot backups and maintain a
> CloseTo4=24*7 service.
>
> Just try real hard and you will get over the idea that there is
> something special about cold backups. There is not. In fact, hot
> backups allow the database to remain warm so you do not experience
> the performance degradation you have when you first bring up a
> database cold -- empty sga, etc.
>
>
> HTH
> --
> Andrew Allen
> Livonia, MI
> E- Mailto:ajalle_at_ameritech.net
Received on Sun Sep 30 2001 - 09:31:07 CDT