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

MAKE UPDATES TO LOGPRIMARY LOGSECOND AND SOFTMAX IN HADR STANDBY TAKE
EFFECT AFTER YOU RESTART THE DATABASE AND DO TAKEOVER HADR

Produkt:
DB2 FOR LUW / DB2FORLUW / 970 - DB2
Problembeschreibung:
This APAR introduces a change whereby if you update any of the 
database configuration parameters LOGPRIMARY, LOGSECOND or 
SOFTMAX in an HADR (High Availability Data Replication) Standby 
database, the new values become 
effective for that database after you restart the database and 
do HADR takeover. 
 
With the change that this APAR introduces, your parameter 
changes will take effect 
after you do the following sequence of actions: 
 1) update any of the database configuration parameters 
    LOGPRIMARY, LOGSECOND or SOFTMAX on an HADR Standby 
    database, 
 2) restart the database, 
 3) do an HADR takeover (for example, using the command 
    TAKEOVER HADR), so that it becomes the HADR Primary 
    database.
Problem-Zusammenfassung:
**************************************************************** 
* USERS AFFECTED:                                              * 
* any user that wish to make db cfg update effective through   * 
* hadr takeover                                                * 
**************************************************************** 
* PROBLEM DESCRIPTION:                                         * 
* The original APAR  was created for a fix in response to      * 
* theNestle request  of the ability to update the db           * 
* configsetting for LOGPRIMARY, LOGSECOND and SOFTMAX through  * 
* HADRtakeover operation, i.e. update the config on the        * 
* standbyand rebounce the standby followed by a takeover to    * 
* make theupdate effectiveon the new primary.                  * 
**************************************************************** 
* RECOMMENDATION:                                              * 
* apply thx fix pack                                           * 
****************************************************************
Local-Fix:
verfügbare FixPacks:
DB2 Version 9.7 Fix Pack 1 for Linux, UNIX, and Windows
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

Lösung
The fix was provided in v91fp8 and automerged into v97
Workaround
keiner bekannt / siehe Local-Fix
Weitere Daten
Datum - Problem gemeldet    :
Datum - Problem geschlossen :
Datum - der letzten Änderung:
22.10.2009
08.03.2010
08.03.2010
Problem behoben ab folgender Versionen (IBM BugInfos)
9.1.FP8,
9.7.
Problem behoben lt. FixList in der Version
9.7.0.1 FixList