Re: How reliable is v$datafile.last_change table information? (working with R/O tablespaces)

I agree with Sybrand, except one minor thing: I would back up the data files of tablespace right after it is put in READONLY, not before!

And for the paranoid, it may be an idea to compare the modificiation time of the data files against the backup copies?

Sybrand Bakker schrieb:

> Which version are you using?
> In version 8 and upwards RMAN has been provided to take care of that.
> Also *readonly* tablespaces are exactly what they are: readonly; they are
> simply not written to.
> You should make a backup of that tablespace just before you set it to
> readonly, and put it in a safe vault.
> There is no need at all to include it in a hot backup.
>
> Regards,
>
> Sybrand Bakker, Oracle DBA
>
> "Lehmann" <Spaceboy_NOoneSPAM_at_hotmail.com> wrote in message
> news:968671660.829430_at_ns.cci.dk...
> > Hi
> >
> > I'm currently working on extending our hot-backup shell-script and need
 some
> > input regarding handeling READ ONLY tablespaces. Hope you can/will help!
> >
> > In my solution I check v$datafile.last_change# before and after I copy the
> > datafiles to ensure that the datafiles hasn't changes while I copied the
> > file w/o setting the tablespace "alter tablespace begin/end backup" (I
 only
> > copies files which needs to be copied). This works file, but I'm still a
 bit
> > concerned about the validity of the information retreived from v$datafile.
> > In case of a shutdown abort or a freaky instance failure, maby?!? - Can I
> > be sure that the SCN found in v$datafile is valid compared to the SCN in
 the
> > datafile header???? V$datafile reads the information from the controlfile,
> > so can situations occur, where the SCN represented in the controlfile
> > (v$datafile.last_change#) is different from the SCN in the datafile on
 read
> > only tablespaces?? I would think that Oracle has it all under control, but
 I
> > hate to be the guy who has to tell a client 5 a.m that he has lost 15GB of
> > data in his productionsystem due to a slight misunderstanding in the
 backup
> > procudure.
> >
> > Regards
> > Lehmann
> >
> >

--
To reply to me via email, please substitute the text no_spam with mailbox in the
return address.