Re: Recovery practice

From: Holger Baer <holger.baer_at_science-computing.de>
Date: Tue, 19 Apr 2005 09:15:58 +0200
Message-ID: <d42b7g$jk9$1@news.BelWue.DE>

Frank van Bortel wrote:
> Holger Baer wrote:
>
[...]

>>Now I've got no 10g database in production use (the usual
>>customer constraints apply ;-) ), so I can't comment on the
>>practical use of this approach, but the OP is testing this
>>which is very good because he learns new things.
>>
>>Many of the replies he got might scare him or anybody else following
>>this thread from using this new feature, only because no one
>>really understood what he is doing.

> 
> 
> I hope not; read my last two lines: get used to it... you're doing OK.

Yes, that last comment was the exception to the general impression.

> 

>>Now I might wrongly accuse you and others as being ignorant, but
>>after following the thread sofar, this seems to be the case at
>>least with regard to this new feature of 10g.
>>

> 
> Well - you are correct as to my knowledge of this. I do need to
> (and actually *am*) play around with 10g RMAN.

To be fair: the documentation isn't terribly verbose as to what the backup ... for recover of copy feature is actually for. Basically the message is: Disk is cheap, so use it as your primary backup target (somehow that sounds familiar ;-) ).

> 
> 

>>Also, with regards to the timing of incremental backups: With
>>10g using the change tracking file feature, actually the incremental
>>backup might be faster, although again, I had no reason sofar to
>>test this (but if SHMBO allows, I'll give it a shot tonight).

> 
> 
> That's the whole point I was trying to make, too - with a FULL backup
> being so fast, I see no reason to skip to incremental, and loose
> time in the recovery process. Will see what a COPY does :)

But you don't loose the time. What you do is

(first run of the script): no level 0 backup found. Because we said that we need a 'backup ... for recover of copy' rman will create an image copy instead of a regular copy.

(second run of the script): incremental backup is done, and, if using block change tracking, really fast, too.

(third and consecutive runs): the incremental backup from the previous run is merged into the level 0 backup, then a new incremental backup is made.

In effect you have always an image copy at T-2 and a incremental backup at T-1 for any given T (T is your current Database, T-1 the time of the last backup, T-2 the backup before T-1).

And with block change tracking turned on (it's off by default) incremental backups really get fast: On my home pc the initial run of the script was around 2:30 Minutes and went down at the third run to something around 30 seconds. Now scale that up to some serious sized database and we might get back to makingin effect a full disk based backup within a given backup window.

Of course maybe that doesn't apply to everyone and no feature comes for free (the block change tracks must be kept), in extreme cases there will be no free resources to support block change tracking. So the usual disclaimer applies: One has to test in his own environment.

But the times of incremental backups ain't faster or you loose the time later on are definitely over.

Cheers,
Holger Received on Tue Apr 19 2005 - 02:15:58 CDT