C-ISAM Corrupted Indexes -- Why? (fwd)

> > Does anyone know of a possible cause or way of preventing corrupted > ISAM indexes? Corruption is a constant problem for us in the field. > > We are using Informix C-ISAM v3.10.00 w/ MS-DOS 3.3, both as a > single user and on Novell Netware 2.10a on various makes of XT, AT, > and 386 clones. C-ISAM is a Microsoft-C library. > > We are not able to research the problem in depth since we do not > have the C-ISAM source code (because Informix charges $40,000.00 > for it). > > Is corruption a common problem with all ISAM implementations? Would > we be better off switching to Btrieve (which claims to use "pre- > imaging" to self-correct any corruption)? And regarding Btrieve, does > anyone know how its performance compares with C-ISAM? > > Any advice or common experiences appreciated. > > """""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" > (Mr.) Kim Berry utgard!kimb@csusac.ecs.csus.edu QMA Inc > """""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" > Kim - Corruption is a general problem with ISAM products. Corruption happens because writes, updates, and deletes to an ISAM file often require changes to multiple data structures on the disk, frequently requiring multiple disk writes to accomplish. Most ISAM file managers do not incorporate a mechanism to insure that either: 1) all of the physical writes occur or 2) none of the physical writes occur - in other words, when an ISAM operation is interrupted for any reason, the logical group of physical operations in progress may be only partially completed - leaving the ISAM data structures on the disk in a corrupted state. More sophisticated relational database managers ( such as Informix Online - but NOT Informix Standard Engine ) guarantee that logical groups of physical disk operations are handled in an all or nothing fashion. This is done by means of logs (like the Online Physical Log) automatic checkpoint procedures and automatic recovery procedures (like the Online Fast Recovery) that are invoked whenever the database manager starts up. I don't know whether B-trieve has facilities to insure physical integrity or not. As far as minimizing your corruption problem: 1. Reduce interruption of ISAM procedures as much as possible. Make sure that user interrupts are handled by your application in such a way that ISAM procedures are not interrupted, and do what you can to prevent other sources of interruption like people turning off the computer in mid-write and power failures. Unfortunately, it is difficult to get MSDOS users not to turn off the machine whenever they feel like it. 2. Provide for adequate backup and recovery procedures - back up the files frequently, in a non-corrupted state. Make recovery easy - use tape rather than floppies. 3. If the big problems are centered on a network server, particularly if it involves shared data, you might want to consider migrating to a Unix server running a RDBMS engine (like Online), with your existing applications modified to interact with the database via SQL. Although performance is very, very dependent on the specifics of what you are doing, generally you will find that performance with Online, or sophisticated RDBMS engines from other vendors, would greatly exceed that of ISAM file managers. ------------ DHL WORLDWIDE EXPRESS ------------------------------------------- Greg Bryan gbryan@ssf-sys.dhl.com DHL Systems Data Administrator uunet!ssf-sys.dhl.com!gbryan San Francisco -------------------------------------------------------------------------------