home clear 64x64
en blue 200x116 de orange 200x116 info letter User
suche 36x36
Neueste VersionenFixList
11.1.0.7 FixList
10.5.0.9 FixList
10.1.0.6 FixList
9.8.0.5 FixList
9.7.0.11 FixList
9.5.0.10 FixList
9.1.0.12 FixList
Haben Sie Probleme? - Kontaktieren Sie uns.
Kostenlos registrieren anmeldung-x26
Kontaktformular kontakt-x26

DB2 - Problembeschreibung

Problem IC64773 Status: Geschlossen

DB2 INSTANCE MAY TRAP DUE TO RARE TIMING CONDITIONS INVOLVING TRUSTED
ROUTINES

Produkt:
DB2 FOR LUW / DB2FORLUW / 970 - DB2
Problembeschreibung:
**NOTE this APAR does not address all scenarios where these 
symptoms may occur, please see APAR IC77201, fixed in DB2 
Version 9.7 Fix Pack 5, which covers additional scenarios** 
 
DB2 may trap in a rare sequence of unpredictable events 
involving trusted routines. 
 
Most trusted routines link with and load the DB2 client library 
(libdb2), which creates an "application-side" private memory 
manager in the DB2 server process. 
This process-wide memory manager survives until all agents 
unload their routines. 
The routines can be cached for long periods of time and are only 
unloaded at specific points in processing (for example, 
processing a disconnect). 
When the "application-side" memory manager/area is deallocated, 
all of its memory is usually decommitted (0'd), and will always 
be available for reuse for different purpose (memory contents 
will change at some point). 
 
The problem can be introduced shortly after agent 
recycling/reuse. 
Depending on the agent's history, its private "server-side" 
thread-specific memory area may get deallocated on agent 
recycling, which is normal. 
Depending on the agent's history and the current new request 
(involving a trusted routine), an agent may end up allocating 
all its subsequent important server-side memory from the wrong 
"application-side" memory manager. 
This is the problem fixed by the APAR, the fix corrects this. 
 
This still may not result in any problem.  The agent may 
continue to allocate memory - unrelated to trusted routine 
execution - from the wrong memory area. 
The application-side memory manager may persist for a long 
period of time (unrelated to the "problem" agent's processing). 
This keeps the wrongly allocated memory valid, during which the 
"problem" agent may get fully recycled or terminates, and the 
problem is not exposed. 
 
If, however, the application-side memory manager is deallocated 
while the agent is in its problem state, important memory areas 
are deallocated and the agent will trap.  Various symptoms may 
occur depending on where it is executing. 
 
The problem is more exposed on DPF systems due to differences in 
agent reuse/recycling. 
 
 
Below is an example of what may appear in a DB2 diagnostic trap 
file, however, other stack traces may be possible. 
 
<StackTrace> 
-------Frame------ ------Function + Offset------ 
0x09000000061FE3B8 sqloCrashOnCriticalMemoryValidationFailure + 
0x1C 
0x0900000006206618 
sqloCrashOnCriticalMemoryValidationFailure@glue5C2 + 0x1C 
0x09000000060FAB10 sqlofmblkEx + 0x1C 
0x09000000068213A8 sqldReleaseWorkAreaMem__FP8sqeAgentiUlPUl + 
0x1B4 
0x0900000006821130 sqldTermAgent__FP8sqeAgent + 0xC8 
0x090000000682186C AppDisassoc__8sqeAgentFiT1 + 0x198 
0x09000000068DA1D0 
sqleUCagentConnCleanup__FP8sqeAgentP14db2UCconHandlebT3 + 0xAC 
0x09000000068D983C RunEDU__8sqeAgentFv + 0x218 
0x09000000068D949C EDUDriver__9sqzEDUObjFv + 0x94 
0x09000000068DF390 sqloEDUEntry + 0x4 
</StackTrace>
Problem-Zusammenfassung:
**************************************************************** 
* USERS AFFECTED:                                              * 
* All systems                                                  * 
**************************************************************** 
* PROBLEM DESCRIPTION:                                         * 
* See Error Description                                        * 
**************************************************************** 
* RECOMMENDATION:                                              * 
* Upgrade to a DB2 level containing this APAR                  * 
****************************************************************
Local-Fix:
WORKAROUND: 
Invoke a trusted routine through a persistent connection on 
every database partition. 
eg. 
export DB2NODE=<db partition> 
db2 connect to <database> 
db2 values dayofweek"(current timestamp)" 
<leave the connection in this state>
verfügbare FixPacks:
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 8 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 9a 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

Lösung
Problem first fixed in DB2 Version 9.7 Fix Pack 2
Workaround
keiner bekannt / siehe Local-Fix
Weitere Daten
Datum - Problem gemeldet    :
Datum - Problem geschlossen :
Datum - der letzten Änderung:
23.11.2009
14.06.2010
03.11.2011
Problem behoben ab folgender Versionen (IBM BugInfos)
9.7.FP2
Problem behoben lt. FixList in der Version
9.7.0.2 FixList