Re: Fragmentation with restore multiple channels
- From: Robert Hanuschke <robert.hanuschke@xxxxxxxxx>
- To: cichomitiko@xxxxxxxxx
- Date: Tue, 4 Sep 2012 15:23:37 +0200
Hi,
I agree with Tim fully, but thinking about the combination "rman and
fragmentation" at all left me wondering, maybe I learn something new...
I'm not immensely familiar with how rman works internally, but I was under
the impression that it does a block-by-block copy of whatever it backs
up/restores.
So I don't really see how even with incremental backups any kind of
fragmentation increase/decrease because of rman operations should be
possible. The data inside the blocks may be fragmented, but rman doesn't
look inside the blocks - does it?
Block is marked as changed in the tracking file - back it up.
Block is restored? Take that block from the last full backup. Replace the
block with the one of the incremental backup if there's a newer version (if
it even does that or takes the one of the incremental backup right away,
don't know). Same content / fragmentation as during the time of backup.
Also, even with non-default filesperset and section size settings - doesn't
rman restore just put block by block back to order where it copied them
from during backup? It shouldn't matter if I grab blocks 1, 2, 3, and 4
from slots A, B, C and D at the same time or sequentially and place blocks
1, 2, 3 and 4 back to their original order.
If it would indeed change anything in that regard, I'd expect rman to
reorganize the data as datapump does when using just one channel, 1 file
per set and everything else at default - which it doesn't.
Maybe my understanding is flawed here. If so, please tell me.
Best regards,
Robert
On Tue, Sep 4, 2012 at 12:52 PM, Radoulov, Dimitre <cichomitiko@xxxxxxxxx>wrote:
> On 04/09/2012 12:38, Kenneth Naim wrote:
> > Rman just allocates the number of datafiles by the number of datafiles
> so it
> > you have 120 files and 6 channels, each channel would eventually backup
> 20
> > files so no fragmentation is possible with a full backup.
>
> Bigfile tablespace multichannel backup with section size is another case,
> I don't know if that could lead to performance problems after a restore
> tough ...
>
>
> Regards
> Dimitre
> --
> //www.freelists.org/webpage/oracle-l
>
>
>
--
//www.freelists.org/webpage/oracle-l
Other related posts:
