The physical limits of an SMS table space have been reached,
meaning the highest possible page has been allocated and used,
If there is an incoming request to extend this table space, for
example through an insert, DB2 will erroneously allocate a page
whose number is higher than the allowed maximum page number.
This fact will be concealed during runtime, except that
additional inserts into this table space will fail with
SQL1236N, which is a misleading error (should be SQL0659N).
However, the page whose number is higher than the limit will
continue to exist.
If the log record for the page in question needs to be replayed,
for example during rollforward or crash recovery, error SQL1042C
will be returned, and the database will be marked bad. The
following messages will be reported in DB2 diagnostic log:
FUNCTION: DB2 UDB, recovery manager, sqlpresr, probe:640
DATA #1 : String, 142 bytes
Crash recovery failed with rc -2080243703
LowtranLSN 0000062005C2C320 MinbuffLSN 0000062005C2C320
Recovery started on log file S0345262.LOG.
FUNCTION: DB2 UDB, base sys utilities,
sqeLocalDatabase::RecoverDatabase, probe:60
MESSAGE : ADM1532E  Crash recovery has failed with SQLCODE
"-1042".
EDUID   : 8356                 EDUNAME: db2redow (TEST)
FUNCTION: DB2 UDB, Common Trace API, sqlbfix, probe:621
MESSAGE : ZRC=0x84020009=-2080243703=SQLB_RC_PG_NUM_ERR
          "Page number exceeds max -8100"
          DIA8709E Segmented table page number was too high.
If SMS tablespaces are used and rollforward or crash recovery
fail with SQL1042C and DIA8709E, or INSERT fails SQL1236N,
please install this fix.
Reference: v9.5 APAR IZ35046 |
To prevent this problem from happening, please, move large SMS
tables to a large table space, then take another backup and
restore from the new image.
Otherwise, please, Roll Forward to a point in time before the
transaction log entry is replayed. |
