在DB2最重要的四个地址空间中，DBM1的作用就是进行实际的数据操作，增删改查都是在这个里面进行的。该地址空间的storage如果出现问题，可能会导致DB2地址空间的异常丅宕，为此我们今天来介绍一把。
Storage is allocated into different subpools which have unique
characteristics
– Storage acquired via MVS GETMAIN （类似于allocate）
– Storage released by MVS FREEMAIN （ 类似于free）
GETMAIN processing by DB2 components using DB2 storage manager
– Requests may be conditional or unconditional to DB2 storage manager
– "Short on Storage" condition can occur for both
– Individual DB2 threads (allied, DBAT) may abend with
04E/RC=00E200xx when insufficient storage available
e.g. 00E20003 & 00E20016
– Eventually DB2 subsystem may abend with abend S878 or S80A due to
non DB2 subsystem component (e.g DFP) issuing unconditional MVS getmain
DB2 getmains are MVS conditional getmains so are converted to DB2 abends e.g. 00E20016
DB2 DBM1 address space now has an addressing range of 16EB (“the beam”) based
on 64-bit addressing but
– Maximum of 16MB available “below the 16MB line”
– Maximum of 2032MB available “above the 16MB line” and “below the 2GB bar”
Practical maximum available to DB2 and specifically DBM1 address space is much less
– Typical 7-9MB available “below the line”
– Typical 800-1900MB available “above the line” and “below the 2GB bar
下面这幅图是典型的一个MVS(virtual)内存layout：
MVS Storage Overview
1 EXTENDED REGION SIZE (MAX) – QW0225RG
– Total theoretical amount DB2 has access to(DBM1 所能够访问的所有虚存)
31 BIT EXTENDED LOW PRIVATE – QW0225EL
– DB2 uses a small amount of Low private (bottom up storage)
DB2 code itself / reservation for pageset storage
31 BIT EXTENDED HIGH PRIVATE – QW0225EH
– DB2 mostly uses subpool 229 Key 7 (top down storage)
Other products also use address space storage
– Dataset opens / DFP
– SMF
ECSA – QW0225EC(单个系统上公用虚存主要用来进行地址空间之间的communication）
– Common storage area across all address spaces for a given LPAR
– Large ECSA size would be 1GB with typical sizes being 300-500MB
– Affects maximum available Extended Region
Biggest factor
– Some customers due to the needs of other products have huge ECSA leading to very small extended region size
e.g. extensive use of ECSA by IMS
– Generous over allocation for safety of ECSA and other common areas
– Common LPAR image for Sysplex (best practice)
DBM1的内存layout(virtual)
DB2 DBM1 Address Space Storage …
31-bit / 24-bit DB2 storage
– Getmained - QW0225GM
Compression Dictionaries and Bufferpools are now above the bar
EDM pool still getmained storage
– In V9, Skeleton Pool (SKCT/SKPT), Database Descriptors Pool(DBD), Global Dynamic
Statement Cache and part of CT/PT are all above the bar, only left part of CT/PT
staying below the bar
– Variable Storage - QW0225VR
Most interesting from a tuning perspective
Variable length blocks
Thread Storage mostly from variable pools
System Storage mostly from variable pools
Thread pools (AGL)
– Used by both System and User
– Identified in dumps and IF
Local Dynamic Statement Cache
31-bit / 24-bit DB2 storage …
– Fixed Storage - QW0225FX
Not usually so interesting from a tuning perspective
High performance storage
Fixed length blocks
– Stack Storage - QW0225GS
Save areas
Working program variables
Small amounts of high speed storage allocations
Cached in the DB2 address space to allow greater performance
Compressed only at full system contraction
Stacks are bigger since V8 (64K vs 20K)
Non-DB2 Storage
Not tracked by DB2
Non-DB2 storage is high private storage
TOTAL DBM1 STORAGE = TOTAL GETMAINED STORAGE QW0225GM
+ TOTAL GETMAINED STACK STORAGE QW0225GS + TOTAL FIXED
STORAGE QW0225FX + TOTAL VARIABLE STORAGE QW0225VR
NON-DB2 STORAGE= MVS 31 BIT EXTENDED HIGH PRIVATE QW0225EH – TOTAL DB2 DBM1 STORAGE
Used usually by MVS functions such as SMF
Parameter DETAIL in SMFPRMxx can cause storage become very large
– The big hit to DB2 in this area is the DDNAME tracking: allocation does not
realise that we have closed off a page set and reallocated it again
– SMF Type 30 subtype 4 and 5 will track all the DDNAMES
– Most environments do not need SMF Type 30 subtype 4 and 5
– Recommend NODETAIL
可用空间（这是DB2虚存监控的重点）
How much is left available in the address space
What is really left
QW0225RG – (QW0225EL + QW0225EH)
= EXTENDED REGION SIZE (MAX) –
(31 BIT EXTENDED LOW PRIVATE +31 BIT EXTENDED HIGH PRIVATE)
– Numbers directly obtained from z/OS
能影响地址空间虚存使用的因素：
Stack use (QW0225GS)
– Normal range is typically 100-300MB
– Compressed only at full system contraction
System agents (QW0225AS)
– Some agents once allocated are never deallocated
For example: P-lock engine, prefetch engine
– # engines: QW0225CE, QW0225DW, QW0225GW, QW0225PF,
QW0225PL
the counts of system agents in use
User threads (QW0225VR-QW0225AS)
– Typical user thread storage footprint can be 500KB to 10MB per thread depending on thread variety, whether thread reuse, and type of SQL used
For SAP threads is about10MB
For CICS threads is aobut 500KB
Number of threads obtained via (QW0225AT + QDSTCNAT)
– Note: QDSTCNAT is obtained via the IFCID 1 statistics record
IFCID 217 can be used to obtain specific AGL pools and their storage use
(QW02173T from data section 3)
空间过度使用的情况下，空间就需要释放：
Storage Overuse: DB2 Storage Contraction
When running low on extended virtual, DB2 begins system
contraction process which attempts to freemain storage
– Contraction can be
Normal
A sign of a poorly tuned system
3 critical numbers for contraction
– Storage reserved for must complete (e.g. ABORT, COMMIT) –
QW0225CR
= (CTHREAD+MAXDBAT+1)*64K +25M
– Storage reserved for open/close of datasets – QW0225MV
= (DSMAX*1300)+40K (space reserved in low private)
– Warning to contract – QW0225SO
= Max (5% of Extended Region Size, QW0225CR -25M)
– Storage Cushion = QW0225CR + QW0225MV + QW0225SO
虚存实存的概念：
Virtual vs. REAL Storage
Important subsystems such as DB2 should not be paging IN from
auxiliary storage (DASD)
– Recommendation to keep page in rates low (near zero)
– Monitor using RMF Mon III
内存监控：
Monitoring REAL Storage
Virtual storage only tells part of the story, real storage needs to be monitored
as much as Virtual storage
– Need to pay careful attention to QW0225RL (Real frames in use by DBM1)
and QW0225AX (Auxiliary frames)
Ideally QW0225RL should be significantly less than the amount of virtual
consumed
An indication of either (a) a DB2 code error or (b) an under provisioned
system will see
– 100% real frames consumed
It will be important to know how much real is dedicated to a given LPAR
– An extensive number of auxiliary frames in use (QW0225AX)
– Performance degradation
V9 – Shared object storage can only be monitored at the LPAR level so is
only accurate for a single DB2 LPAR assuming no other exploiters of shared
storage
REF:
