Re: WHY index can corrupted???

Hi Art and all, I don't doubt that some of you have observed index corruption in logged databases after system crashes. If this was not caused by faulty hardware or os software that corrupts disk contents directly (index and data pages, log space, etc.) it should be considered an Informix fast recovery bug and should be fixed if possible. This should also apply to buffered logging. Michael Art S. Kagel wrote: > On Tue, 12 Aug 2003 22:01:38 -0400, miyaki wrote: > > There are several sources of index corruption generally in a few classes: > > Caused by bugs: > There was a known BTREE-CLEANER bug that would occassionally corrupt indexes but > I no longer remember what release(s) are affected. > > Caused by crashes: > If you use caching controllers and/or an intelligent disk farm there is a real > risk that a system crash can leave data in the cache. This may or may not be > flushed to disk eventually and you may or may not want it so flushed. Especially > prevalent after a controller failure. > > Caused by improper shutdown: > Often I've found corruption similar to what one normally finds after a system > crash following a supposedly graceful system shutdown/restart. This is caused > by the rc files sending a shutdown to the database and returning immediately > without waiting for the server to actually shutdown. The delayed shutdown can > be caused by a large number of dirty buffers not yet flushed or applications in > critical sections for which the server must wait before starting the checkpoint > preparatory to a shutdown. > > Caused by database logging mode: > UNLOGGED databases are at the highest risk for index corruption as the engine > has no way to recover a partially written index update after a crash or improper > shutdown. These are most likely to suffer corruption caused by the other > issues. > > BUFFERED LOG databases are still at some risk for corruption, especially if > there are no active UNBUFFERED LOG databases running in the same instance. This > is because a BUFFERED LOG database does not force the logical log buffer to > flush when committing a transaction. UNBUFFERED LOG databases always force a > logical log buffer flush immediately upon writing a COMMIT record to the logical > log buffer and so are rarely found to have a corrupted index. If you have a > mixture of BUFFERED and UNBUFFERED databases you may be OK if the UNBUFFERED > databases are rather active since the BUFFERED database records will be caught > up in the flushes forced by the UNBUFFERED database activity. > > Note that having databases that are UNBUFFERED LOG databases offers the > additional risk that the engine will not be able to restart after a crash > without tech support intervention. This can be caused when a commit requires > multiple writes to the logical logs and the commit is partially written to one > buffer which fills and is flushed, then the final COMMIT is written to the next > logical log buffer which is not immediately flushed before the system crashes. > On restart the engine will hang when it encounters the end of the logical log > in the middle of a partially written commit. > > Art S. Kagel > > > >>Hi all, >> >>OS : Sun Solaris 2.7 >>IDS : 7.31.UD5 >> >>Recently my database engine was crashed due to the index corruption. The >>engine was back up after repairing the index by using the oncheck command. I'm >>wondering why the index can be corrupted? In fact, I just performed the >>database re-org by using the dbexport-import at 3 months ago. >> >>Anybody knows the reason that may cause the index corruption??? >> >>Appreciate for the comments. >> >>TIA, >>MIyaki >> >>__________________________________ >>Do you Yahoo!? >>Yahoo! SiteBuilder - Free, easy-to-use web site design software >>http://sitebuilder.yahoo.com >>sending to informix-list > > sending to informix-list