Informix - Problem description
Problem IT17067 | Status: Closed |
ASSERT FAILED PAGE CHECK ERROR OR SEGMENTATION VIOLATION POSSIBLE AFTER HAVING PERFORMED A SHRINK OPERATION | |
product: | |
INFORMIX SERVER / 5725A3900 / B70 - IDS 11.70 | |
Problem description: | |
The test case developed for this problem presents itself in different ways depending on the version of the server it seems. On 11.70 it can be possible that after a shrink operation happens on a table with an attached index (the shrink must release pages) further actions on this table which cause it to expand again (so it would have to grow out of the extents left after the shrink) might cause assert failed page check errors. In the assert failure file you would likely see the following type information: 08:55:58 bfcheck: bad page: pg_flags #### != type 0x10 When you look at the page header you might notice that the page offset for the page address matches disk, but that page offset does not belong to the table the error is being reported again. This is happening because of an internal cache of buffer information is not being invalidated after the shrink so that when the table grows again (after the shrink) the old cache information might be accidentally referenced again but this old information is pointing to pages which are no longer part of the current tables extents. Thus the likely page check/bfcheck bad pg_flags assertion. At this point, if the server would be restarted, the issue is resolved as there is no physical corruption (which would normally be what a page check/bfcheck error would normally indicate). On version 12.10 the problem presents differently (different type of assert failed) and also in 12.10 the index on the table has to be a detached index, as the shrink operation is not allowed to execute on a table with an attached index. So in 12.10, if you have a table and a detached index, and you run the shrink fragment operation on the index partition, and it gives up pages, and again, you then grow the index (so it has to extend again) if it doesn't re-grab the same pages, the same bad cache information can happen. However, on 12.10, it would seem the type of failure that is seen is a SEGV, to the assert failed looks more like this: Assert failed: No Exception Handler with a stack trace that looks like this: bycmpr() bycompare() updp_shuffle() btcpybck() btusearch() btadditem() rsbtadditem() fm_idxinsert() fmwrite() aud_sqiswrite() chkrowcons() addone() insone_next() doinsert() sq_putinsert() sqmain() | |
Problem Summary: | |
**************************************************************** * USERS AFFECTED: * * All Users * **************************************************************** * PROBLEM DESCRIPTION: * * See Error Description * **************************************************************** * RECOMMENDATION: * * Update to IBM Informix Server 11.70.xC9 * **************************************************************** | |
Local Fix: | |
Solution | |
Workaround | |
not known / see Local fix | |
Timestamps | |
Date - problem reported : Date - problem closed : Date - last modified : | 15.09.2016 09.06.2017 09.06.2017 |
Problem solved at the following versions (IBM BugInfos) | |
11.70.xC9 | |
Problem solved according to the fixlist(s) of the following version(s) |