Forum Post: RE: Can the different worlds hear each other?

[George Potemkin]

I just don't know how easy any of it is to do. I would say it's easy because the code similar to the one we need already exists in other Progress functionality: 1) Promon could be run when shutdown is already initiated (as we can start an emergency shutdown after a normal one). So we could at least see what's going on during shutdown; 2) The issue with slow replication could be solved by asynchronous page readers on target db (they would be similar to the asynchronous page writers); 3) 'Idfix/scan records' could be multi-threaded. First of all, we can split the recid range into the chunks and run a separate thread for each chunk. Secondly (and more useful, IMHO) idxfix can be multi-threaded by indexes to check. Parent process could read only records, lock them and put them into a special buffer. Child processes could validate the index keys for the records stored in the buffer - one child process per index. When all index keys of a record are validated then the record should be unlocked and released from the buffer; 4) 'Idxfix/scan indexes' could support a selection by keys similar to the "dumpspecified" option of binary dump. So we would not need to scan the whole index if we already know the key range to check. Also it could be multi-threaded similar to the multi-threaded binary dump (though I dislike how this option was implemented for binary dump); 5) Idxfix could skip the locked records and check them later - similar to an online backup that does not write the blocks exactly in the same order they are stored in database. The only enhancement request that would be hard to implement is to enable db connections before the crash recovery is completed. Logically it looks simple: the redo/undo operations during crash recovery are very similar to the normal transaction activity (at least according to the recovery notes they generate). Hence in theory the crash recovery can coexist with the activity of the normal users. But as we know that the protocols used for BI file are very complicated and the changes in this area are very risky. And all above is not about the options that "would be nice to have". It's the options that big clients, IMHO, desperately need.

Continue reading...