A fix is available
APAR status
Closed as program error.
Error description
When castout does put the entire object into LPL, the LRSN range is supposed to cover all of the updates that aren't yet on DASD - because we're going to purge all of the pages from the GBP. And in this case, the LRSN range was in fact wrong because it didn't cover the missing insert.
Local fix
N/A
Problem summary
**************************************************************** * USERS AFFECTED: DB2 data sharing users. * **************************************************************** * PROBLEM DESCRIPTION: Lost updates in data sharing, following * * LPL recovery, when the entire table * * space, index, or partition had been * * put into LPL by DSNB5PCO. * * * * Corrupted data can result in any of * * the following symptoms: * * - Incorrect output, INCORROUT. * * - ABEND04E RC00C90101, RC00C90102, * * RC00C90105, or RC00C902xx in * * various CSECTs. * * - Data/index inconsistencies reported * * by the CHECK INDEX utility. * * - Page regression reported by the * * DSN1LOGP utility. * * * * Alternatively, an ABEND04E RC00C90101 * * may occur during the LPL recovery * * itself, leaving the object in LPL. In * * this case, the object can only be made * * available again by using the RECOVER or * * REBUILD utility. * **************************************************************** * RECOMMENDATION: * **************************************************************** The pageset castout code (dsnb5pco) may under certain unusual conditions put an entire object into LPL. This occurs when castout was requested for an object that wasn't opened, or during abend recovery. The beginning LRSN for the LPL log range is set based on the oldest page in the Group Buffer Pool, but that may be incorrect since an older page may have been written since that value was last determined. If the LRSN is too high, the LPL recovery will miss applying log records and either abend during the log apply, or else leave some data down-level.
Problem conclusion
The code which maintains the GBP recovery LRSN snapshot, used by castout when adding an object to LPL, has been modified to consider the member restart recovery LRSNs as well as the minimum page LRSN - just as is done when determining the beginning LRSN for GRECP recovery.
Temporary fix
********* * HIPER * *********
Comments
APAR Information
APAR number
PI62667
Reported component name
DB2 OS/390 & Z/
Reported component ID
5740XYR00
Reported release
B10
Status
CLOSED PER
PE
NoPE
HIPER
YesHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
2016-05-17
Closed date
2016-06-14
Last modified date
2016-07-04
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
UI38682 UI38683
Modules/Macros
DSNB1CNE DSNB1GBS DSNB1GC1 DSNB5PCO
Fix information
Fixed component name
DB2 OS/390 & Z/
Fixed component ID
5740XYR00
Applicable component levels
Fix is available
Select the PTF appropriate for your component level. You will be required to sign in. Distribution on physical media is not available in all countries.
[{"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSEPEK","label":"Db2 for z\/OS"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"11.0","Edition":"","Line of Business":{"code":"LOB10","label":"Data and AI"}},{"Business Unit":{"code":"BU054","label":"Systems w\/TPS"},"Product":{"code":"SG19M","label":"APARs - z\/OS environment"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"11.0","Edition":"","Line of Business":{"code":"","label":""}}]
Document Information
Modified date:
04 July 2016