oncheck -me Feature Request

OK, I've collected the comments of the discussion on oncheck -me, and my own correspondence with contact, and these are the results of my investigations: 1- oncheck -me was never intended for general release 2- it was not completed internally and is not completely safe, meaning a- it works as advertised, however b- there is little logging of its work so if it is interrupted or the server/system crashes you're hosed c- no logging means no rollback on interrupt or rollforward after a restore d- there is no integration with HDR or ER so the compression is not carried out on any replicant which would cause replication errors when log records of page updates were sent to the replicant later 3- as someone noted this is an extent compression only and not a full reorg so it does not release unused and emptied pages to the dbspace's free list. A full reorg using usual methods like: ALTER FRAGMENT ON TABLE/INDEX ... INIT IN ..., ALTER INDEX ... TO CLUSTER, or an unload/drop/create/reload would still be needed to release unused pages 4- the feature was dropped in IDS 9.4 due to issues with the new page numbering Having said that all, I think that this would be a great feature for IDS to have. Often a full reorg is not needed, unused pages were reserved for a reason and emptied pages will likely be reused, so that a quick extent compression is exactly what's called for. If enough of us enter a Feature Request for this functionality, obviously with the problems identified in 2b-d above resolved, we might see it in IDS 9.5 as a supported feature. Might not make it into 9.50UC1 in 2004-Q1 but perhaps in a UD1 release in 2004-Q3. The FR should specify something like: Requesting that a feature, similar in functionality to the RASHELP -me option to oncheck in IDS 7.31, to perform a high speed extent compression of a partition reducing the number of extents comprising the partition to a minimal count. This function should be interruptable using a minimum of locks and a minimum of logical log space during compression. Upon interruption the compression should leave the table in a usable condition either by completing a partial compression or by rolling back the operation, though a partially compressed result is preferred to a rollback in order to minimize the impact on database availability. The compression must replicate properly and safely through HDR and ER where appropriate and recovery after a crash through Fast Recovery or after a restore through logical log rollforward is also required. This can be implemented either as an option to oncheck as with the -me option or as DDL/DML through the SQL interface. The latter would be preferable. Art S. Kagel

On Wed, 22 Oct 2003 11:56:31 -0400, "Art S. Kagel" <kagel@bloomberg.net> wrote: Sounds like an online reorg . . . me too, me too.