Down Chunk

Gentlepersons: My understanding of Down Chunks is less than complete! I would invite comments or further explanations. On p. 13-15 of 7.3 Admin Guide, it says "You can prevent the database server from markng a dbspace as down while you investigate disabling I/O errors." 1) How? 2) Also, if a disabling error occurs (else there would be nothing to investigate, per above quote), wouldn't IDS already have decided whether said error was "destructive" or "nondestructive"? If destructive, wouldn't chunk already be marked down? And, if nondestructive, there would be no reason to "prevent the database server from marking" the dbspace down, since nondestructive, disabling errors don't cause a chunk to be marked down. Obviously I'm confused here. Something is wrong with my thinking. 3) Would an incorrectly pointed chunk link be seen by IDS as a destructive, disabling error? I would tend to think yes-- (else, how would IDS know the difference between a bad link and bad data?) 4) If a chunk is marked down as a result of a bad chunk link, is it still necessary to go through motion of restore, or will correcting link and bouncing server correct it? (Obviously, this question is meaningless if a chunk is never marked down as a result of bad chink link) Thanks to all Informix gurus, who may comment. David Grove Alaska Dept. Health & Social Svcs.

David Grove wrote: > > Gentlepersons: > > My understanding of Down Chunks is less than complete! I would invite > comments or further explanations. > > On p. 13-15 of 7.3 Admin Guide, it says "You can prevent the database server > from markng a dbspace as down while you investigate disabling I/O errors." > > 1) How? Set ONDBSPACEDOWN to 2 (WAIT) and the engine will hang when it detects a repeatable I/O error on a chunk. You would then correct the problem, assuming it is correctable, and run onmode -O to release the engine. > 2) Also, if a disabling error occurs (else there would be nothing to > investigate, per above quote), wouldn't IDS already have decided whether > said error was "destructive" or "nondestructive"? If destructive, wouldn't > chunk already be marked down? And, if nondestructive, there would be no > reason to "prevent the database server from marking" the dbspace down, since > nondestructive, disabling errors don't cause a chunk to be marked down. > Obviously I'm confused here. Something is wrong with my thinking. IDS makes no such determination. If it detects an I/O error that it cannot get around by retrying the request (I think it actually tried 7 times) it just sets the chunk's status as down and continues as determined by ONDBSPACEDOWN. There is not determination of whether the error is harmful or harmless. All errors are considered harmful. > 3) Would an incorrectly pointed chunk link be seen by IDS as a destructive, > disabling error? I would tend to think yes-- (else, how would IDS know the > difference between a bad link and bad data?) Sort of. Yes in addition to the I/O errors the engine performs several internal consistency checks on each page read from the chunks which, in part, can determine that a chunk has been mislinked, or even crosslinked to another chunk in the same or a different instance: o The page's header timestamp matches the timestamp at the end of the page. Since an Informix page (2-4K) is larger than a normal physical disk block this checks that the entire page was written out to disk when the page was last updated. o The page's page number in the page header is the page number that was expected. This is the primary detection of a misdirected chunk link. o The page's page type flags are as expected (ie we did not read an index page when we expected a data page) and matches the tables bitmap entry for the page (not exactly the same thing as 'as expected'). > 4) If a chunk is marked down as a result of a bad chunk link, is it still > necessary to go through motion of restore, or will correcting link and > bouncing server correct it? (Obviously, this question is meaningless if a > chunk is never marked down as a result of bad chink link) Correct. If the chunk has been marked down you need to correct the link and run onspaces -s to mark the chunk back online then release the engine if it is hung. If the ONDBSPACEDOWN prevented the status change then you should just need to release the engine. Unless the engine is offline you should not need to bounce it. If the engine is offline because the ROOTDBS first chunk is marked down you will not be able to mark it up since the engine must be online to run onspaces and the engine will not start with a rootdbs chunk marked down. In this case you will have to call tech support or muck with the flags in the reserved pages, both the current and backup pages on both the primary and mirror root chunks, yourself which is definitely not recommended and tech support will be VERY reluctant to get your butt out of the sling if you attempt it and ^*&% it up. Art S. Kagel