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