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

From: Andrew Allen <ajallen_at_mailhost.det.ameritech.net>
Date: Sat, 29 Sep 2001 01:35:45 GMT
Message-ID: <3BB52545.1919AE9B@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 Fri Sep 28 2001 - 20:35:45 CDT