Re: UNIX root backup/SAN disk image vs. Oracle Hot Backups

JEDIDIAH wrote:

>>>>
>>>> I've nothing much to add except that if you're going to break a mirror
>>>> in order to grab a backup, you don't actually have to shut the database
>>>> down but can instead use the suspend (and resume) statements.
>>> 
>>> Why not just put all the tablespaces in backup mode?
>>
>>
>> How many tablespaces have you got?
>>
>> So how long do you think it would take you to put all of them into hot
>> backup mode?
>>
>> (And whereas your answer might be "seconds", someone else's might be
>> "minutes").
>>
>> And all the time you're trying to get all of them into hot backup mode,
>> the first ones that got there are generating block-sized redo.
>>
>> That's why.

We're not talking about how fast your disk backup mechanism is. We're trying to answer your question 'why not just put all tablespaces into hot backup mode [instead of use the 'alter database suspend' command]. The answer was: because issuing several hundred 'alter tablespace begin backup' commands will take time, whereas one 'alter database suspend' command doesn't.

The scenario being canvassed is that you don't actually start backing anything up until the entire set of tablespaces is in hot backup mode. So the speed with which you can actually carry out the backup is irrelevant: we haven't got to that part yet! And that was my point: you get to that part very quickly when you only have one command to issue (be that the suspend command I mentioned, or 10g's 'alter database begin backup' command).  

> The problem of "oh my god, my talblespaces are in hot backup mode" is
> a problem that Oracle has already supposedly solved.

Of course it was solved. Way back in version 8.0. Provided you're using RMAN. Which isn't the case being discussed here.

> It's not uncommon for
> more conventional backup practices to keep a tablespace in backup mode for
> minutes. So that alone isn't necessarily a problem.

It is, actually. If you have tuned your log subsystem to a particular rate of activity, then the hot backup mode can swamp it. Very easily, and very quickly.

> Typically, shutting down for a cold backup is considered far more
> problematic.

"Problematic" is a woolly word that has very little real informational content, so it's wise not to use it in discussions such as these. Particularly since it isn't true.

If you are 24x7 then shutting down for a cold backup isn't "problematic", it's totally out of the question. If you have a maintenance window where you can shut down the database to do a cold backup, then a cold backup isn't "problematic", but the easiest and simplest method of backing up your database. If the cache warmup afterwards is an issue for performance in your particular environment, then the cold backup isn't "problematic", it is unsuitable for your business requirements and shouldn't be used.

There is nothing "problematic" about any backup method, and certainly not in a generic sense. Everything is either appropriate or not for your specific business needs. Cold backups are 100% appropriate for an awful lot of databases, and totally inappropriate for an awful lot of others. But you don't (sensibly at any rate) continue to perform ANY backup method if you find it has "problems"!

HJR Received on Sat Sep 18 2004 - 19:36:13 CDT