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

On 2004-09-19, Howard J. Rogers <hjr_at_dizwell.com> wrote:
> 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.
>>
>> ...which all should be less of a problem if you have a disk backup
>> mechanism which is near instant.
>
> 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.

        ...which is likely to be a whole lot faster than many Oracle aware tape backup managers. This is especially true when the backup software is deployed enterprise wide and is thus subject to a great degree of server and device level contention.

>
> 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:

        Not at all. The problem is the time it takes to put tablespace(s) into backup mode + time it takes to backup the tablespace(s). If either of these is reduced to a trivial amount of time, and the other quantity is comparable to the backup window for a single tablespace then the solutions are interchangeable.

[deletia]
>> 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

        Log tuning is a problem regardless of whether or not you choose to make the problem a little harder by running v7 style backups.

[deletia]

-- 

	vi isn't easy to use.				 |||
							/ | \
	vi is easy to REPLACE.