Re: Defrag large fragmented table in 7.32

On Thu, 02 Feb 2006 18:11:05 -0500, "Art S. Kagel" <kagel@bloomberg.net> wrote: >cacunet@hotmail.com wrote: >>>2+2 RAID10 I hope! >> >> >>>OK, so the desired sequence of events is: >> >> >> >>>- BEGIN WORK; >>>- SET PDQPRIORITY 100; >>>- LOCK TABLE <tabname> IN EXCLUSIVE MODE; >>>- DROP INDEX <indexname>; >>>- ALTER TABLE <tabname> TYPE (RAW); >>>- ALTER FRAGMENT ON TABLE tablename INIT FRAGMENT BY ... >>>- ALTER TABLE <tablename> TYPE (STANDARD); >>>- CREATE ... INDEX <indexname ON <tablename>... >>>- COMMIT WORK; >> >> >> Yes, it's RAID10. >> >> So this means that the table being reorg will not be accessible by the >> users? >> How long do you estimate this process will run? I understand that >> there's a lot of different variables that can impact the run time, but >> I just want a rough idea of how long it will take assuming the rest of >> the chain in our system is on par with the rest of the world. > >Neil's right this is going to take time. If you absolutely cannot have this >table offline for more than a brief period, then you'll have to copy the >data to a new table in the new dbspace, create new matching indexes and >constraints with different names, then when you can get exclusive access and >keep the users off for a short time, rename the old table then rename the >new table to the old name. Once that's done you can drop the old table or >scan it for records added deleted and update since you made the copy. > Those deltas can be the hard part, though . . . . Would this be a good feature request . . . . online reorgs?? JWC