Re: RMAN internal`s mechanism

orazon_at_dbnet.co.il (Ofer Razon) wrote in message news:<74c5bf11.0403030934.4bf11310_at_posting.google.com>...
> > Every block has a last change number - which is the SCN
> > at the last change plus a counter that goes from 1 to 254.
> > rman knows when the SCN when it last did a backup, reads
> > each block, and checks the last change number.
> >
> > > My goal is to use the same mechanism to find which blocks were changed
> > > since the last check.
> > >
> >
> > Possible - so long as you knew the SCN when rman started (or perhaps
> > when it started each file, or tablespace - that's a little detail that I'm
> > not
> > so sure on; the file would be the obvious choice). The last change SCN
> > is in a fixed location in the block, so you could write some 3GL code to
> > scan each file and pick it out from each block. I am curious to know why
> > you want to do this.
>
> Thanks.
> Do you know about any existing piece of code that scans the datafiles
> and process them?
>
> I`m trying to find a solution to synchronize two copies of a datafile
> : One is older than the other at about a week.
> The synchronization must be very effective and must do as less writes
> at the target as it can.
> My current solution is to open both of the files as binary files, go
> block by block (I set the block size) and compare the data. Only if
> the data read is different - I update the block at the target with the
> data from the source.
> The issue is that this solution must go and read both of the files.
> I`m looking for a way to make it work better....
>
> Thanks,
> Ofer.

How are you handling fractured blocks? Are you talking about copies of datafiles that were made during a hot backup? Even then RMAN is dependent on recovery with redo to fix it.

http://download-west.oracle.com/docs/cd/B10501_01/server.920/a96566/rcmconc1.htm#462396

jg

--
@home.com is bogus.
http://money.cnn.com/2004/03/04/technology/dell_ceo/index.htm