Symptoms are typical of excessive memory usage problems. In a
fixed instance_memory environment, out of memory errors may
occur in various memory areas attempting to grow (SQL0973,
SQL0954, SQL0101, etc.). The memory leak only occurs in a DPF
environment, and it will only occur on non-coordinator
partitions (i.e. if member 0 always serves as the coordinator,
the leak will not occur there).
The private memory leak can be seen either in DB2 monitoring
tools (MON_GET_MEMORY_SET, db2pd -memsets, db2pd -dbptnmem
etc.). In order to identify that this APAR is applicable, the
scenario should apply (DDL on columnar tables in a DPF
environment), and the specific memory area/source should match
per below.
Scenarios:
a) db_migrate tool to migrate data from Netezza to IIAS
b) any DPF system with frequent DDL on columnar-based tables
Memory monitoring data details (on non-coordinator partitions):
1. The MON_GET_MEMORY_POOL routine will show the memory usage
growth in the "PERSISTENT_PRIVATE" memory pool
db2 "select MEMBER, MEMORY_POOL_USED from
table(mon_get_memory_pool('PRIVATE',null,-2)) where
MEMORY_POOL_TYPE='PERSISTENT_PRIVATE'"
2. memory block data will show a large number of allocations
from files starting with "sqqg":
db2pd -memblocks pid=`db2pd -edus | awk '/db2sysc PID/ {print
$3}'` sort
Total set Memory blocks sorted by size:
PoolID PoolName TotalSize(Bytes) TotalCount LOC File
0 170160264 4833 88
sqlqg_memory.C
0 52036632 9279 1412
sqlqg_misc.C
0 29584360 677 536
sqlqg_memory.C
0 6185624 1103 713
sqlqg_misc.C
0 3529600 4149 452
sqlqg_misc.C
... |
