Re: compress/compact database?

No.

It's been explained how to do it.... export/drop/import/resize. Or move/resize/move.

HJR "Winbatch" <winbatch_at_techie.com> wrote in message news:aat5jl$arl$1_at_bob.news.rcn.net...
> If we could get back to my original question :), Is there a way to tell
> the database to reorder/sort the data in the datafiles by extent? (Sort
of
> like a defragmentation command?) This way I could return to my quasi
> chronological ordering and begin deleting away?
> "Howard J. Rogers" <dba_at_hjrdba.com> wrote in message
> news:aasiph$k6u$1_at_lust.ihug.co.nz...
> > Gawd! Yeah, that's a doozy, and far too common. The idea of monkeying
> around
> > with the only thing standing between you and data loss is truly scary.
> >
> > Regards
> > HJR
> >
> > "Sean M" <smckeownNO_at_BACKSIESearthlink.net> wrote in message
> > news:3CD1CD67.6EA5A421_at_BACKSIESearthlink.net...
> > > "Howard J. Rogers" wrote:
> > > >
> > > > No, it is supported (well, you can certainly do it, anyway). But I
> agree
> > > > entirely: it's a daft thing to do in my book. Partly for the reasons
> you
> > > > give. Partly because compression doesn't come free: decompressing
> > requires
> > > > CPU cycles. Partly because compression algorithms are a potential
> source
> > of
> > > > future corruption and errors, possibly. Partly because disk space is
> > > > relatively cheap.
> > >
> > > Agreed, for all of the above reasons. I'm even nervous of the
> > > relatively common practice of compressing archive logs before running
> > > them to tape. Scares me, mostly due to the possibility of
> > > corruption/errors, etc.
> > >
> > > Regards,
> > > Sean
> >
> >

>
> Received on Fri May 03 2002 - 05:20:32 CDT