|
Problem IC67285
|
Status: Closed |
DB2 HEALTH MONITOR MAY GENERATE "LEVEL: INFO" MESSAGES IN THE DB2DIAG.LOG WHEN THE DIAGLEVEL IS 3 OR LOWER. |
| product: |
DB2 FOR LUW / DB2FORLUW / 970 - DB2 |
| Problem description: |
"LEVEL: Info" messages should be written to the db2diag.log only
if the DB2DIAGLEVEL is set to 4.
It is possible however in some situations for the DB2 Health
Monitor to generate such messages at DIAGLEVEL 3 or lower. Here
are some examples:
==============================================
2000-01-01-00.00.00.000000+000 I1234567890ABC LEVEL: Info
PID : 123456 TID : 123 PROC : db2hmon
0
INSTANCE: db2inst1 NODE : 000
APPID : *LOCAL.db2inst1.012345678901
FUNCTION: DB2 UDB, DRDA Communication Manager, sqljcReceive,
probe:30
RETCODE : ZRC=0x8136001C=-2127167460=SQLZ_RC_NO_CONNECTION,
SQLT_SQLJC
"No connection"
2000-01-01-00.01.00.000000+000 I1234567890ABC LEVEL: Info
PID : 123456 TID : 456 PROC : db2hmon
0
INSTANCE: db2inst1 NODE : 000
APPID : *LOCAL.db2inst1.012345678902
FUNCTION: DB2 UDB, DRDA Communication Manager, sqljcReceive,
probe:30
DATA #1 : String, 336 bytes
CALL STACK:
[0] 0x090000000094B334 sqljcReceive__FP10sqljCmnMgr + 0x6DC
[1] 0x090000000094C014 sqljrDrdaArDisconnect__FP7UCintfc + 0x2E0
[2] 0x09000000008F955C sqleUCdisconnect + 0x84
[3] 0x090000000089770C sqleUCappConnectReset + 0x15C
[4] 0x09000000008973CC
CLI_sqlDisconnect__FP15CLI_CONNECTINFOP5sqlcaP19CLI_ERRORHEADERI
NFO + 0x124
..............................................
2000-01-01-00.00.00.000000+000 I1234567890ABC LEVEL: Info
(OS)
PID : 123456 TID : 123 PROC : db2acd
0
INSTANCE: db2inst1 NODE : 000
FUNCTION: DB2 UDB, oper system services, sqloSSemP, probe:3
MESSAGE : ZRC=0x83000024=-2097151964
CALLED : OS, -, semop
OSERR : EIDRM (36) "Identifier removed"
DATA #1 : unsigned integer, 4 bytes
847249501
DATA #2 : unsigned integer, 4 bytes
1
CALLSTCK:
[0] 0x0900000000E5610C .sqlccrecv_fdprpro_clone_39 + 0x70
[1] 0x00000001104FFABC ?unknown + 0xFFFFFFFF
[2] 0x090000000850C774 ?unknown + 0xFFFFFA2F
[3] 0x0900000000C4D24C sqljcReceive__FP10sqljCmnMgr + 0xBC
[4] 0x0900000000C4FAF0
sqljrDrdaArDisconnect__FP14db2UCinterface + 0x170
[5] 0x0900000000BCC414 sqleUCappDetach + 0x34
[6] 0x0900000000BF8998 sqledtin__FP5sqlca + 0xA0
[7] 0x0900000000BF879C sqledtin_api + 0x5C
[8] 0x0900000008436114 updateRefreshSets__15hiDataCollectorFv
+ 0x254
[9] 0x0900000008428D30 hmonMainLoop__FP14HmonMainStruct +
0x734
==============================================
Please Note:
In version 8 the name of Health Monitor process is "db2hmon" and
in version 9 it is "db2acd".
A typical scenario when this may be encountered is after
changing the DIAGLEVEL to 4 online in order to gather some
diagnostic information and then reverting to the prior
DIAGLEVEL.
The Health Monitor process may continue to operate at DIAGLEVEL
4 after the reversion of the DIAGLEVEL. |
| Problem Summary: |
****************************************************************
* USERS AFFECTED: *
* All users of version 9.7 on Linux, Unix andWindowsplatforms. *
****************************************************************
* PROBLEM DESCRIPTION: *
* "LEVEL: Info" messages should be written to *
* thedb2diag.logonly if the DB2DIAGLEVEL is set to 4.It *
* ispossible however in some situations for the *
* DB2HealthMonitor to generate such messages at DIAGLEVEL 3 *
* orlower.Here are *
* someexamples:==============================================200
* LEVEL:InfoPID : 123456TID : 123 PROC *
* :db2hmon 0INSTANCE: db2inst1NODE : 000APPID *
* :*LOCAL.db2inst1.012345678901FUNCTION: DB2 UDB, *
* DRDACommunication Manager, sqljcReceive,probe:30RETCODE *
* :ZRC=0x8136001C=-2127167460=SQLZ_RC_NO_CONNECTION,SQLT_SQLJC"N
* I1234567890ABCLEVEL:InfoPID : 123456 TID *
* : 456PROC :db2hmon 0INSTANCE: db2inst1 NODE *
* :000APPID : *LOCAL.db2inst1.012345678902FUNCTION: DB2 *
* UDB,DRDA Communication Manager, sqljcReceive,probe:30DATA #1 *
* :String, 336 bytesCALL STACK:[0] *
* 0x090000000094B334sqljcReceive__FP10sqljCmnMgr + 0x6DC[1] *
* 0x090000000094C014sqljrDrdaArDisconnect__FP7UCintfc *
* +0x2E0[2]0x09000000008F955C sqleUCdisconnect + *
* 0x84[3]0x090000000089770C sqleUCappConnectReset + *
* 0x15C[4]0x09000000008973CCCLI_sqlDisconnect__FP15CLI_CONNECTIN
* LEVEL:Info (OS)PID : 123456TID : 123 PROC *
* :db2acd 0INSTANCE: db2inst1NODE : 000FUNCTION: DB2 UDB, oper *
* system services,sqloSSemP, probe:3MESSAGE : *
* ZRC=0x83000024=-2097151964CALLED: OS, -, semopOSERR : *
* EIDRM (36) "Identifier removed"DATA#1 : unsigned integer, 4 *
* bytes847249501DATA #2 : unsignedinteger, 4 *
* bytes1CALLSTCK:[0] *
* 0x0900000000E5610C.sqlccrecv_fdprpro_clone_39 + 0x70[1] *
* 0x00000001104FFABC?unknown + 0xFFFFFFFF[2] *
* 0x090000000850C774 ?unknown +0xFFFFFA2F[3] *
* 0x0900000000C4D24CsqljcReceive__FP10sqljCmnMgr + *
* 0xBC[4]0x0900000000C4FAF0sqljrDrdaArDisconnect__FP14db2UCinter
* 0x170[5] 0x0900000000BCC414 sqleUCappDetach + *
* 0x34[6]0x0900000000BF8998 sqledtin__FP5sqlca + *
* 0xA0[7]0x0900000000BF879C sqledtin_api + *
* 0x5C[8]0x0900000008436114updateRefreshSets__15hiDataCollectorF
* +0x254[9] 0x0900000008428D30 *
* hmonMainLoop__FP14HmonMainStruct+0x734========================
* version 8 the name of Health Monitor process is"db2hmon"and *
* in version 9 it is "db2acd".A typical scenariowhen this may *
* be encountered is afterchanging the DIAGLEVELto 4 online in *
* order to gather somediagnostic informationand then reverting *
* to the priorDIAGLEVEL.The Health Monitorprocess may continue *
* to operate atDIAGLEVEL 4 after thereversion of the *
* DIAGLEVEL. *
****************************************************************
* RECOMMENDATION: *
* Upgrade to DB2 UDB Version 9.7 FixPak 2 or higher levels. *
**************************************************************** |
| Local Fix: |
-- 1. Restart DB2 Health Monitor manually.
Stop the "db2hmon/db2acd" process manually and wait for a few
minutes until a new "db2hmon/db2acd" process is started
automatically.
E.g. on Linux/Unix platforms, issue "kill -9 <PID>"(where <PID>
is the "db2hmon/db2acd" process ID) to stop Health Monitor. A
few minutes later a new "db2hmon/db2acd" process will be
started.
-- 2. Restart the DB2 instance.
The Health Monitor is restarted automatically with the instance. |
| available fix packs: |
DB2 Version 9.7 Fix Pack 2 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 3 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 3a for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 4 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 5 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 6 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 7 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 9a for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 8 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 9 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 10 for Linux, UNIX, and Windows
|
| Solution |
First fixed in DB2 UDB Version 9.7 FixPak 2. |
| Workaround |
-- 1. Restart DB2 Health Monitor manually.
Stop the "db2hmon/db2acd" process manually and wait for a few
minutes until a new "db2hmon/db2acd" process is started
automatically.
E.g. on Linux/Unix platforms, issue "kill -9 <PID>"(where
<PID> is the "db2hmon/db2acd" process ID) to stop Health
Monitor. A few minutes later a new "db2hmon/db2acd" process
will be started.
-- 2. Restart the DB2 instance.
The Health Monitor is restarted automatically with the instance. |
| Timestamps |
Date - problem reported :
Date - problem closed :
Date - last modified :
| 19.03.2010
31.05.2010
31.05.2010 |
| Problem solved at the following versions (IBM BugInfos) |
9.7.
|
| Problem solved according to the fixlist(s) of the following version(s) |
| 9.7.0.2
|
 |
