RE: Extent Q and could be possible architecture Q

>===== 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? Thanks, Will ------------------------------------------------------------ This e-mail has been sent to you courtesy of OperaMail, as a free service from Opera Software, makers of the award-winning Web Browser, Opera. Visit us at http://www.opera.com/ or our portal at: http://www.myopera.com/ Your free e-mail account is waiting at: http://www.operamail.com/ ------------------------------------------------------------