ALTER FRAGMENT goes walkabout

IDS 9.21 FC4 on HP-UX 11.11 Can anyone explain to me how ALTER FRAGMENT ... INIT IN DBSPACE actually does its stuff? I've a 32GByte table which I want to reorgainse, to get all the free space contiguous. I can't use HPL, as there is a known bug in 9.21 that makes the unloads (but not loads) run very slowly. I ran the ALTER FRAGMENT, and it took 32 hours. When I dropped the 10 indexes it took 100 minutes to run the ALTER FRAGMENT on the data. The index rebuilds took on average 45 minutes, giving a total time for the whole operation of 450 + 100 minutes = 9h 10m. I used the same ONCONFIG, and the same PSORT/NPROCS settings for the ALTER FRAGMENT as for the CREATE INDEXES. Just wondered if anyone could shed some light on what ALTER FRAGMENT may have been doing. From what I can tell from onstat -D, onstat -u and looking at the timestamps on the directories listed in PSORT_DBTEMP, it seems to follow a similar process of data move first, follow by index build. I started from the same BCV copy of live data, so the difference cannot be attributed the first operation clearing up the data, or the target disk space being les fragmented or anything like that. UK Tech Support, whilst as helpful as they could be, couldn't really offer any insight I hadn't already worked out for myself. thanks Neil

Neil Truby wrote: > [stuff] hmmm - is your engine setup in such a way as to encourage PDQ index builds? If so, perhaps the ALTER FRAGMENT is not triggering the much faster PDQ builds?