If you have the 'mon_compression_estimates' task installed and
enabled in your sysadmin:ph_task table, you can occasionally see
following type of assertion failure in the StorageMGR thread:
12:07:01 SCHAPI Estimate Compression for
testdb:"informix".pk_tab1 started
12:07:01 SCHAPI Starting Estimate on table
'testdb:"informix".pk_tab1' partnum 200045
12:07:01 Assert Failed: ptmap
12:07:01 IBM Informix Dynamic Server Version 12.10.FC2
12:07:01 Who: Session(255, informix@, 0, 0000000000000000)
Thread(349, StorageMGR, 0, 1)
File: rspartn.c Line: 3816
12:07:01 Results: Could not complete operation on
'testdb:"informix".tab1'
12:07:01 Action: Run 'oncheck -cDI testdb:"informix".tab1'
12:07:01 stack trace for pid 4424 written to
C:\PROGRA~1\Informix\1210fc2\tmp\af.54503c5
12:07:27 See Also:
C:\PROGRA~1\Informix\1210fc2\tmp\af.54503c5, shmem.54503c5.0
12:07:43 ptmap
12:07:45 SCHAPI Estimate Compression for table
'testdb:"informix".pk_tab1' succeeded.
12:07:45 admin_fragment_command('fragment estimate_compression
','2097221') succeeded
The stack of the StorageMGR thread is this:
afhandler
affail_interface
ptmapx
buffget
rssample_index_for_index_compression
rscCommand
docompress_rsam_op
docompress_op
th_init_initgls
startup
and the AF file reports a bad page number:
12:07:01 ptmap: bad pagenum = 2810 -- only 2810 pages
12:07:01 ptmap(partnum 200045, logpage 2810) error
The problem can occur only on index partitions which meet all
the conditions below:
- during their lifetime had at least 500 pages used
- their 'Number of pages used' is equal to 'Number of pages
allocated' in the 'oncheck -pt dbname:tabname' output
- they don't contain at least 2000 key values on their leaf
pages
Example of such a partition:
oncheck -pt testdb:tab1
TBLspace Report for testdb:informix.tab1
Physical Address 2:526
Creation date 08/19/2015
11:50:53
TBLspace Flags 8902 Row
Locking
TBLspace contains VARCHARS
TBLspace use 4 bit bit-maps
....
Number of data pages 0
Number of rows 0
....
Index pk_tab1 fragment partition datadbs in DBspace
datadb
....
Number of pages allocated 2810
Number of pages used 2810
....
Index Usage Report for index pk_tab1 on
testdb:informix.tab1
Average Average Average
Level Total No. Keys Free Bytes Del Keys
----- -------- -------- ---------- --------
1 1 0 4068 0
----- -------- -------- ---------- --------
Total 1 0 4068 0
Such a situation can for example happen after deleting all (or
majority of) rows from the table, when the index key entries are
removed from existing indexes, but 'Number of pages used' for
each index is kept at its previously achieved maximum (which is
expected behavior). |
- if the table has no rows, you can run 'truncate table
<tabname>' SQL command, which resets the 'Number of pages used'
value to a real value
- if there are rows in the table, drop and recreate all the
indexes defined on the table |
