IBM Support

Notification and additional details pertaining to APAR IT45318

News


Abstract

The purpose of this document is to provide more information about the problem described by APAR IT45318.

Content

The problem described by IT45318 relates to an issue that may occur during a checkpoint when the reserved pages are written to the root dbspace.  This defect is applicable only to the following releases of Informix Server:
12.10.xC16
12.10.xC16W1
14.10.xC9
14.10.xC10
14.10.xC10W1
14.10.xC10W2
or any special build containing the fix for APAR IT40986
Remediation
The APAR is fixed in these releases:
Background
The initial set of reserved pages, located on pages 0 - 11 of chunk 1, can accommodate only a limited set of information for logical logs, dbspaces and chunks. Once that available space has been filled a new extent will be allocated for these types of objects on an as-needed basis. The size of the extent will be in relation to the number of logical logs, dbspaces or chunks.
In an earlier performance enhancement these extended reserved page extents are written in blocks of up to 32 pages a time from memory not associated with the buffer pool. A problem with this enhancement meant that a check to find and clear pages in the buffer pool that had the same page addresses may not stop at the end of the allocated reserved page extent but continue until the end of the block size of 32. The effect of this is that pages in the buffer pool associated with other tables or indexes and located in the chunk just after an extended reserved page extent may be inadvertently cleared. If the page contains modifications that have not yet been flushed to the chunk then there is a risk that these may be lost during the next checkpoint.

How to identify the tables or indexes that are at risk
Examine the output of "oncheck -pe rootdbs" to identify extended reserved page extents that are larger than 32 pages. Where these extents are followed by table or index extents, calculate the number of pages that are at risk. This is determined as the result of
32 - mod(<size of reserved page extent in pages>, 32)
If the extended reserved page extent is an exact multiple of 32 pages then none of the pages following it are at risk.
In the following example output the number of at risk pages for the bar_instance table is 32 - mod(177, 32) = 15
 RESERVED PAGES                                      125368      177
 RESERVED PAGES                                      125545      177
 RESERVED PAGES                                      125722      177
 RESERVED PAGES                                      125899      177
 sysutils:'informix'.bar_instance                    126076      256    0x00100107   3
Take steps to avoid potential data loss
For each table or index identified as having pages at risk of data loss, determine whether the table has update activity. If the table's contents are static then the data loss problem described by this APAR will not apply. The reason for this is that, even though the at-risk pages will be removed from the buffer pool, they do not contain modified data and will be reloaded from the chunk the next time they are referenced. If the table does have update activity then consider an unload of the data, recreating the table in another dbspace and reloading. If this is done then an additional recommendation is to rename the original table rather than dropping it so that the space will not be reused. Once a version of the Informix server is installed containing the APAR fix then the old table may be dropped.
If the identified tables with at-risk pages are system catalogue tables then the associated database should be moved to another dbspace if possible. As with tables, consider renaming the old database so that the at-risk pages are not freed.
The oncheck -cID command can be used to help validate the integrity of tables identified as at risk. For database system catalogues also consider the oncheck -cc command.
If the pages following the extended reserved pages are currently free, then consider creating a dummy table and filling it with sufficient rows to cause the allocation of an extent with a large enough size to cover the range of at-risk page addresses.

Steps to reduce the risk
If any tables or dbspaces are identified that cannot be moved then consideration can be given to increase the LRU cleaning activity for the buffer pool containing the root dbspace. This is done by lowering the values for lru_min_dirty and lru_max_dirty for the relevant BUFFERPOOL onconfig parameter. Use the onstat -F command to monitor the LRU cleaning activity.
Avoid increasing the number of logical logs, dbspaces, or chunks, thereby eliminating any need to resize the extents for extended reserved pages which may result in them being moved to a different part of the root dbspace. This includes manual addition via an onmode command or using the sysadmin API or automatically via the AUTO_LLOG onconfig parameter for automatic addition of logical logs. Similarly, chunks may be added automatically when automatic space management is enabled with the SP_AUTOEXPAND onconfig parameter.
If an extended reserved page extent is currently followed by free space then avoid actions that may cause this space to be allocated such as creating new tables in the root dbspace or altering existing ones in a manner that increases the row size and may require the allocation of additional extents.
Avoid creating the syscdr database in the root dbspace.  When configuring Enterprise Replication, configure the storage of the syscdr database in a different dbspace. Refer to the documentation for the CDR_DBSPACE onconfig parameter.
If the sysadmin database is located in the root dbspace then a recommendation is to move it to a different dbspace. Refer to the documentation for the reset sysadmin SQL administration API command.

Monitoring
If it is not possible to restrict the creation of additional logical logs, dbspace or chunks then periodic monitoring of the location of the extended reserved pages extents shall be required. When automatic logical log addition or space management is enabled such allocations could occur at any time so one consideration is whether the automatic management may be disabled until a version of Informix server containing the APAR fix is installed.

[{"Type":"MASTER","Line of Business":{"code":"LOB10","label":"Data and AI"},"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSGU8G","label":"Informix Servers"},"ARM Category":[{"code":"a8m0z0000004CzeAAE","label":"Engine Internals->Checkpoint"},{"code":"a8m0z000000bmaLAAQ","label":"Informix System Admin->dbspaces\/storage"}],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"12.10.0;14.10.0"}]

Document Information

Modified date:
11 March 2024

UID

ibm17114124