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

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
>
>
Received on Mon Sep 11 2000 - 11:34:47 CDT