Holger Baer wrote:
>> 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
Like I said: need to investigate on the COPY command.
Thanks for the RMAN 10g for Dummy's new features 101.
No pun intended!
--
Regards,
Frank van Bortel
Received on Tue Apr 19 2005 - 06:34:42 CDT
