Re: Whatcha' wanta have?????

Keep moving us towards a no-down-time server as much as possible. Such as (some mentioned by others): - Online index build - without locking the table - A dirty read is used to build the index then logical log records are replayed to clean up keys that were added, rolled back, or deleted during the build. During the build the index is marked disabled and is reenabled once the build is completed. - Built-in table compression/reorg command that in a transaction rewrites rows filling partial and empty pages, releaseing empty extents and truncating extents that are partially used (perhaps with a given slack factor, but not neccessarily explicit say leave up to NEXT SIZE free in the last extent) - COMPRESS TABLE tablename <IN PLACE> ....; The IN PLACE option controls whether new extents are allocated to make the table more contiguous or existing extents are simply compressed. - Use the logical log rollforward from the online index build to make an online index/constraint enable option as long as the needed logical logs are still online. If not a full index rebuild is needed which an be performed using the full online index build code. - Better support for using ER for HA replication, perhaps a database level replication which would permit DDL to be replicated as well. - Support for multiple HDR replicants. - Support for concurrent connection to primary and at least one replicant and passing of transaction information in HDR from primary to replicant for seamless failover. If sufficient information and data has been passed to the replicant, then transactions can continue on the alternative connection unhindered assuming all the needed data has been passed from the primary (see later on). If a recovery rollback is triggered on the replicant that affects a particular transaction that transaction alone will receive a replication error and its transaction will be marked invalid. Missing data can be verified by the primary passing transaction management data OOB to the client. If the transaction progress stamp from the client is later than that which the replicant finds in its logs after taking over then the transaction is trashed due to data not transferred from the primary prior to failure. Basically then an open transaction, after a primary server failure, is handled more like a 2-Phase Commit problem with the client acting as transaction coordinator in part. If the client is lost the transaction has to be rolled back or committed regardless using standard lost connection rules. It might even be possible to support this in ER with sychronous replication. Art S. Kagel Madison Pruet wrote: > As a mild diversion from the IDS-DB2 conversion thread, its time for one of > my more favorite exercises. ;-) > > We are nearing the end of the coding cycle for IDS 9.5. We've got a whole > bunch of really cool stuff in place and - well - its time to get input from > you guys as to what you want to see in the 9.6 release. > > Now, I know that everyone's favorite thing is going to be "marketing", but > I'm in development. So I need to talk features and functionality. So feel > free to send them on in. > > Just an FYI - I'll be away for a while and won't be able to get email via my > comcast email address. But, I'll be following the newsgroup rather closely. > > Also, next week I'll be in some planning meeting. So getting responses back > fairly quickly would really help. > > Thanks > > M.Pruet > >