Re: Backup trends (2): HOT or COLD

On 2004-04-09, Howard J. Rogers <hjr_at_dizwell.com> wrote:
> On 9 Apr 2004 14:29:28 -0400, JEDIDIAH <jedi_at_nomad.mishnet> wrote:
>
>> On 2004-04-03, Howard J. Rogers <hjr_at_dizwell.com> wrote:
> [snip]
>
>>>
>>> So yes, it has lots of nice features. But those are merely incidental
>>> to the
>>> real reason why you should use RMAN in preference to O/S scripts:
>>> performance. RMAN doesn't cause the database to generate 20 or 30 times
>>> the
>>> amount of redo per transaction that O/S hot backups do. RMAN doesn't
>>> hammer
>>
>> Certainly a valid point.
>>
>>> one data file to death before moving on to another, but instead
>>> multiplexes
>>> across many datafiles, little bits being taken from each one in turn.
>>> RMAN
>>
>> This is a just a simple coding and configuration issue.
>
> The "cp" command takes an argument that specifies 'the first X bytes of a
> file', does it? Or 'the next Y bytes after that'?

This sort of functionality isn't required for the features specified. The equivalent of an interleaved tarball isn't necessary to achieve parallelism.

>
> Didn't think so.
>
> In which case, no "simple coding" on your part is going to resolve the
> issue.
>
> RMAN is NOT doing a cp. That's the point.

Yes. It makes the resulting product remarkably more complicated to deal with pretty much requiring that RMAN be used to pull it apart again.

>
>> If you take our
>> korn coding as seriously as the rest of your DBA duties, this should
>> never be a problem.
>>
>>> parallelises in a way no O/S script never could. And you can throttle
>>> the
>>> I/O rate up or down for RMAN to minimise the impact on the production
>>> database or to maximise the speed at which the backup is done.
>>
>> Any of this can be crudely estimated using less complicated tools.
>
> I'm not talking about estimating I/O rates. I'm talking about *setting* an
> I/O rate so that the backup operation does not hog hard disk resources to
> the exclusion of performance by ongoing regular users. Does the "cp"
> command take an I/O rate argument?

It doesn't need to. This is Unix. You can use the other n-thousand utilties on the system to determine the impact of your cp's and act accordingly.

>
> It's pretty sad if you think RMAN in 9i is "complicated".
>
> How complicated is "backup database;"??

It's quite complicated should you ever desire to pull apart the end result with a hex editor. I don't view Oracle as the whole world. It's simply not prudent.

-- 
The public has a right to free music. It's part of the bargain that
was originally made with musicians and publishers. It's time that the   |||
debate was shifted to reflect that. Robber Barons and their Toadies    / | \
are distracting us from the original facts of the situation.