Re: Oracle 8i (8.1.7.0.1) + Redhat Linux 7.2 = Cannot create tablespace file > 2 gb

"Joe Salmeri" <JoeSalmeri_at_comcast.net> wrote in message news:Fg_S8.173467$_j6.8951031_at_bin3.nnrp.aus1.giganews.com...
> In 7+ years of managing Oracle databases I have only had one incident
where
> the database became corrupt and that was because of a hardware failure,
not
> because of a bug in the operating system or in Oracle. I guess I have
just
> been EXTREMELY lucky.
>
> In the scenerio you describe I would not have a warm comfort level
restoring
> that one datafile. What would happen if there were tables in that bad
> tablespace that had referential integrity to other tables in another
> tablespace?
>

Well, hopefully, with 7+ years of experience behind you, you'll know that nothing will happen. The magic of applying archives.

I honestly can't believe that for the sake of 1 corrupt block, or one lost file, you'd want to restore an entire 16Gb tablespace (or worse).

HJR
> Not sure what the 4gb boundary you are referring to is, but I have had NT
> 4.0 filesystems that were 40 gb in size that never experienced any
problems.
>
>
> "Niall Litchfield" <n-litchfield_at_audit-commission.gov.uk> wrote in message
> news:3d1c6b90$0$231$ed9e5944_at_reading.news.pipex.net...
> > "Joe Salmeri" <JoeSalmeri_at_comcast.net> wrote in message
> > news:BNXS8.424576$Gs.31492095_at_bin5.nnrp.aus1.giganews.com...
> > > And how is physically backing up 5 2000mb datafiles any different than
> > > backing up 1 10000mb datafile?
> > > Either way the same amount of data is backed up.
> >
> > Its way different if one data file becomes corrupt. Then you have a
> restore
> > of 2gb not 10. Not to mention that a say 32gb datafile has 7 chances to
> > exactly extend to a 4gb boundary
> >
> >
> > --
> > Niall Litchfield
> > Oracle DBA
> > Audit Commission UK
> > *****************************************
> > Please include version and platform
> > and SQL where applicable
> > It makes life easier and increases the
> > likelihood of a good answer
> >
> > ******************************************
> >
> >
>
>
Received on Fri Jun 28 2002 - 15:17:31 CDT