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 IT02292 Status: Geschlossen

SLOW INDEX INSERT/UPDATE PERFORMANCE IN DB2 ESE FOR DATABASES WHICH HAVE
BEEN RESTORED FROM DB2 PURESCALE INSTANCES

Produkt:
DB2 FOR LUW / DB2FORLUW / A50 - DB2
Problembeschreibung:
This applies only to databases which have been backed up from a 
DB2 pureScale instance and restored to a DB2 Enterprise Server 
Edition instance.  Updates/Inserts to very large tables with 
indexes in these databases may be slow due to searching through 
all the index space map pages to find a free page in the index 
object even though there are no free pages available. 
 
The reason for this is that the use of Pseudo Used pages in the 
index object may cause the count of free pages in the index 
object to fall below zero and thus be treated as a very large 
number.  All the index space map pages are then searched for a 
free page since it appears as though some free pages exist in 
the object.  No free page will be found so the object will be 
extended, but the next time a free page is required each space 
map page will be searched again.  This could happen if there 
were Pseudo Used pages in the index object space map pages after 
the database is restored to the DB2 Enterprise Server Edition 
instance.  Pseudo Used pages exist naturally in the index object 
space map pages in DB2 pureScale databases. 
 
To determine if this could be the cause of slow performance for 
inserts/updates into large tables with indexes, the following 
command may be issued and the resulting binary file can be sent 
to DB2 Support for analysis: 
 db2pd -db <wsdb> -dmsdbcb 
If DB2 Support determines that the freePageCnt for the index 
object of the table(s) is larger than the number of pages in the 
object then this is likely the cause of the performance issues.
Problem-Zusammenfassung:
**************************************************************** 
* USERS AFFECTED:                                              * 
* User migrating a database from a DB2 pureScale instance to a * 
* DB2 Enterprise Server                                        * 
* Edition instance                                             * 
**************************************************************** 
* PROBLEM DESCRIPTION:                                         * 
* See Error Description                                        * 
**************************************************************** 
* RECOMMENDATION:                                              * 
* Upgrade to DB2 version 10.5.0.4.                             * 
****************************************************************
Local-Fix:
Deactivating (DEACTIVATE DATABASE <database>) and re-activating 
the database (eg REACTIVATE DATABASE <database> or CONNECT TO 
<database>) will resolve the problem for those tables where all 
the Pseudo Used pages from the index objects have now been used. 
To determine if all of the Pseudo Used pages in an index object 
have been used, issue db2dart command against all the space map 
pages in the index object. 
 
Applying the APAR fix will resolve the problem for all tables.
verfügbare FixPacks:
DB2 Cancun Release 10.5.0.4 (also known as Fix Pack 4) for Linux, UNIX, and Windows
DB2 Version 10.5 Fix Pack 9 for Linux, UNIX, and Windows

Lösung
The problem is first fixed in DB2 version 10.5.0.4.
Workaround
keiner bekannt / siehe Local-Fix
Weitere Daten
Datum - Problem gemeldet    :
Datum - Problem geschlossen :
Datum - der letzten Änderung:
05.06.2014
05.06.2014
05.06.2014
Problem behoben ab folgender Versionen (IBM BugInfos)
Problem behoben lt. FixList in der Version
10.5.0.4 FixList