自调优内存管理器的问题

    这个已经添加了，但是重启后还是有报错。收起

还没解决？
有没有尝试这个:
对于每一个instance，设置下面的注册表变量然后重启instance
db2set DB2STMM=GLOBAL_BENEFIT_SEGMENT_COMPATIBLE:YES收起

    报告版主，没有这个目录。收起

pls use ls -lt /dev/shm to check the output . if have some outputs ,pls paste here .收起

$ db2greg -dump
I,DB2,9.5.0.3,db2inst1,/db2/db2inst1/sqllib,,1,0,/db2/wsii/V9.5,,
S,DAS,9.5.0.3,/db2/wsii/V9.5/das,lib/libdb2dasgcf.a,,3,, ,,
I,DAS,9.5.0.3,db2as1,/db2/db2as1/das,,1,,/db2/wsii/V9.5/das,,
S,DB2,9.5.0.3,/db2/wsii/V9.5,,,3,0,a,1332933201,0

    此外，还发现有一个error

 
2012-08-17-15.47.10.812104-060 E8181A666          LEVEL: Error
PID     : 270468               TID  : 772         PROC : db2acd 0
INSTANCE: db2inst1             NODE : 000
EDUID   : 772                  EDUNAME: db2acd 0
FUNCTION: DB2 UDB, Health Monitor, HealthIndicator::update, probe:500
MESSAGE : ADM10500E  Health indicator "Monitor Heap Utilization" 
          ("db2.mon_heap_util") breached the "upper" alarm threshold of "95 %" 
          with value "117 %" on "instance" "db2inst1".  Calculation: 
          "((db2.mon_heap_cur_size/db2.mon_heap_max_size)*100);" = "((458752 / 
          393216) * 100)" = "117 %".  History (Timestamp, Value, Formula): "()"

收起

Problem(Abstract)

STMM errors "STMM unable to attach to shared memory" are seen in the db2diag.log while DB2 installation or downgrading activity,
Symptom

STMM error are seen while performing the following activities

1. Downgrading the DB2 version from V9.7 to V9.5

2. Installation of DB2 V9.7 exist on the server where there are instances of Version 9.5

The following STMM error can be seen in the db2diag.log

2012-03-07-11.14.54.251966+060 I21192E551 LEVEL: Error
PID : 25944 TID : 46912883386688PROC : db2sysc
INSTANCE: db2itest NODE : 000 DB : LRDB
APPHDL : 0-394 APPID: *LOCAL.DB2.120307101154
AUTHID : DB2ITEST
EDUID : 29 EDUNAME: db2stmm (LRDB)
FUNCTION: DB2 UDB, Self tuning memory manager, stmmAttachToShm,
probe:2656
MESSAGE : ECF=0x90000001=-1879048191=ECF_ACCESS_DENIED
Access denied
DATA #1 : String, 39 bytes
STMM unable to attach to shared memory.
Cause

1. In case of downgrading of DB2 this happens because of entries remaining in the /shm folder


2. In case of V9.7 installation this happens because there is no instance created at the time and STMM is not able to attach to the instance

Environment

AIX 6.1 and Linux

DB V 9.5 and DB2 V 9.7

Diagnosing the problem

In case of DB2 downgrade execute the below command to find the V9.7 entries

ls -al /dev/shm

Here should see the following named shared memory segment:
-rw-------  1 root     pdxdb2 4096 2012-04-03 06:17 DB2_SELF_TUNING_MEMORY_MANAGER_CROSS_INSTANCE_SHARED_        MEMORY_SEGMENT

In case of V9.7 installation, execute the below command
db2greg -dump

db2greg -dump output :
-----------------------------------------------------------------------              
sen-swcdbs1/edudata/db2inst1>db2greg -dump                                          
V,DB2GPRF,DB2SYSTEM,sen-swcdbs1,/edusys/db2/V9.7,                                    
V,DB2GPRF,DB2FCMCOMM,TCPIP4,/edusys/db2/V9.7,                                       
S,DB2,9.7.0.3,/edusys/db2/V9.7,,,3,0,a,1303477081,4                                 
V,DB2GPRF,DB2SYSTEM,sen-swcdbs1,/edusys/db2/V9.7/FP5,                                
S,DB2,9.7.0.5,/edusys/db2/V9.7/FP5,,,5,0,,1326094319,1                              
V,DB2GPRF,DB2FCMCOMM,TCPIP4,/edusys/db2/V9.7/FP5,                                    
I,DB2,9.7.0.3,db2inst1,/edudata/db2inst1/sqllib,,1,0,/edusys/db2/V9.7,,              
V,DB2GPRF,DB2INSTDEF,db2inst1,/edusys/db2/V9.7,                                      
I,DB2,9.7.0.3,db2inst2,/edudata/db2inst2/sqllib,,1,0,/edusys/db2/V9.7,,              
I,DB2,9.7.0.3,db2inst3,/edudata/db2inst3/sqllib,,1,0,/edusys/db2/V9.7,,              
I,DB2,9.7.0.3,db2inst4,/edudata/db2inst4/sqllib,,1,0,/edusys/db2/V9.7,,  

Resolving the problem

In case of downgrade, remove the remains from the /shm folder with the 'rm' command and restart the instance.

In case of V9.7 installation either create a test instance on the 9.7 version or remove the installation of 9.7 and restart the 9.5 instances.

Related information收起

Problem(Abstract)

STMM errors "STMM unable to attach to shared memory" are seen in the db2diag.log while DB2 installation or downgrading activity,
Symptom

STMM error are seen while performing the following activities

1. Downgrading the DB2 version from V9.7 to V9.5

2. Installation of DB2 V9.7 exist on the server where there are instances of Version 9.5

The following STMM error can be seen in the db2diag.log

2012-03-07-11.14.54.251966+060 I21192E551 LEVEL: Error
PID : 25944 TID : 46912883386688PROC : db2sysc
INSTANCE: db2itest NODE : 000 DB : LRDB
APPHDL : 0-394 APPID: *LOCAL.DB2.120307101154
AUTHID : DB2ITEST
EDUID : 29 EDUNAME: db2stmm (LRDB)
FUNCTION: DB2 UDB, Self tuning memory manager, stmmAttachToShm,
probe:2656
MESSAGE : ECF=0x90000001=-1879048191=ECF_ACCESS_DENIED
Access denied
DATA #1 : String, 39 bytes
STMM unable to attach to shared memory.
Cause

1. In case of downgrading of DB2 this happens because of entries remaining in the /shm folder


2. In case of V9.7 installation this happens because there is no instance created at the time and STMM is not able to attach to the instance

Environment

AIX 6.1 and Linux

DB V 9.5 and DB2 V 9.7

Diagnosing the problem

In case of DB2 downgrade execute the below command to find the V9.7 entries

ls -al /dev/shm

Here should see the following named shared memory segment:
-rw-------  1 root     pdxdb2 4096 2012-04-03 06:17 DB2_SELF_TUNING_MEMORY_MANAGER_CROSS_INSTANCE_SHARED_        MEMORY_SEGMENT

In case of V9.7 installation, execute the below command
db2greg -dump

db2greg -dump output :
-----------------------------------------------------------------------              
sen-swcdbs1/edudata/db2inst1>db2greg -dump                                          
V,DB2GPRF,DB2SYSTEM,sen-swcdbs1,/edusys/db2/V9.7,                                    
V,DB2GPRF,DB2FCMCOMM,TCPIP4,/edusys/db2/V9.7,                                       
S,DB2,9.7.0.3,/edusys/db2/V9.7,,,3,0,a,1303477081,4                                 
V,DB2GPRF,DB2SYSTEM,sen-swcdbs1,/edusys/db2/V9.7/FP5,                                
S,DB2,9.7.0.5,/edusys/db2/V9.7/FP5,,,5,0,,1326094319,1                              
V,DB2GPRF,DB2FCMCOMM,TCPIP4,/edusys/db2/V9.7/FP5,                                    
I,DB2,9.7.0.3,db2inst1,/edudata/db2inst1/sqllib,,1,0,/edusys/db2/V9.7,,              
V,DB2GPRF,DB2INSTDEF,db2inst1,/edusys/db2/V9.7,                                      
I,DB2,9.7.0.3,db2inst2,/edudata/db2inst2/sqllib,,1,0,/edusys/db2/V9.7,,              
I,DB2,9.7.0.3,db2inst3,/edudata/db2inst3/sqllib,,1,0,/edusys/db2/V9.7,,              
I,DB2,9.7.0.3,db2inst4,/edudata/db2inst4/sqllib,,1,0,/edusys/db2/V9.7,,  

Resolving the problem

In case of downgrade, remove the remains from the /shm folder with the 'rm' command and restart the instance.

In case of V9.7 installation either create a test instance on the 9.7 version or remove the installation of 9.7 and restart the 9.5 instances.

Related information收起

有一个注册表变量，GLOBAL_BENEFIT_SEGMENT_COMPATIBLE，是和STMM share memory的权限相关的，但是它只在你机器上有多个版本的instance的时候才需要设置，而你说你机器只有一个db2copy和一个instance。。。不一定有用，但是你试试看吧：
db2set DB2STMM=GLOBAL_BENEFIT_SEGMENT_COMPATIBLE:YES  
设置完成后重启下instance。 另外你能否贴出db2greg -dump的输出？
关于GLOBAL_BENEFIT_SEGMENT_COMPATIBLE的解释可见infocenter
The GLOBAL_BENEFIT_SEGMENT_COMPATIBLE parameter only has a functional impact if the database_memory configuration parameter is set to AUTOMATIC for a database.

This parameter influences the permission settings of the STMM shared memory segment. It should only be set to YES on systems with multiple instances, where some of the instances are downlevel and have database_memory set to AUTOMATIC, in order to mitigate downlevel compatibility issues that impact the tuning of a database's overall database memory usage. A downlevel instance would be an instance belonging to any of the following DB2 releases and fix pack levels: DB2 V9.1 at all fix pack levels, DB2 V9.5 fix pack 7 and earlier, and DB2 V9.7 fix pack 4 and earlier.

For instances that are non-root DB2 installations, you should set this variable only if you want all instances on the system make use of the same STMM shared memory segment. Leaving this variable unset or set to NO will cause a non-root instance to use its own instance-specific STMM shared memory segment, which may impact the tuning of overall database memory usage for any databases with database_memory set to AUTOMATIC.

This registry variable is read once, during the DB2 instance startup. Note that you need to set this parameter across all the upgraded (that is, non-downlevel) instances and once set, you need to restart all upgraded instances.收起

    已经修改成固定值了，但是每个3分钟还是会报这个错误收起

    他是3a的，如果有APAR，那应该正好hit了。。。总之我觉得对instance memory不做限制相当危险，不管是哪个版本收起