Re: Extent Q and could be possible architecture Q

William Rice wrote: > > >===== Original Message From "dios" <adiosadios@crosswinds.net> ===== > >This is not a newbie FAQuack! Obnoxio need not get grumpy, nor start a new > >wantonly useless but amusing thread, ending in some gross observations > >about, well, you get the drift. > > > >Yes I researched the FM, still acronym'ed at RTFM, but technically I did not > >R E A D it. :-))) (that's my quivering double chins in case you are a > >newbie and need the verbal cue) > > > >What are the benefits and drawbacks of re-mapping table/extents using the > >various methods: > > > >1. This lists regularly expounded method of export, re-size the first and > >next extent, import. (results in complete extent re-mapping) > >2. Issuing a cluster index (to remove non-contiguous space), issue alter > >fragment on table xxx in dbspace xxx, issue uncluster index. (results in > >approx 50% reduction in extents but no change to initial or next extent). > >3. Using ontape to drop and restore the db (in my small 4 g production db > > >test db results in all fragments fitting into one extent but next size still > >remains at old setting and must be changed manually). > > I didnt think an ontape would actually change the extent size... > I always trusted what I had heard and never tested it, are you sure this > works? It does not. There is a #3 though: 3. Using ALTER FRAGMENT ON TABLE <tabname> INIT IN <dbspacename>; after ALTER TABLE NEXT SIZE...; will tend to be the fastest method even if you want to reorg into the same dbspace. Art S. Kagel