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

DB2START RESTART NEEDS SERIAL FAILOVER CODE RE-USE FROM V91 IN V97
(Parallel failover getting Time out errors or SQL6031N )

Produkt:
DB2 FOR LUW / DB2FORLUW / 970 - DB2
Problembeschreibung:
Customers migrating from v91 to v97 are facing difficulties when 
trying to setup high availability (HA) environments. They are 
accustomed to using v8 and v91 methods for node fail-over. 
 
The functionality introduced in v95 and later for failover is: 
 
If no port 0 exists on the target machine (that is, no nodes are 
currently associated with it), then there are two steps to 
fail-over: 
1. Serially move any node from the source machine that is not 
port 0 to the target at port 0. 
2. In parallel, move all remaining nodes (or one by one if so 
desired with port 0 on source being last) 
 
If there does exist nodes on the target machine already, this 
operation does not require the serial step. All nodes can be 
moved in parallel. 
 
To move nodes in parallel, follow the following is necessary: 
 
Given: 
0 one.ca.ibm.com 0 
1 one.ca.ibm.com 1 
2 one.ca.ibm.com 2 
 
Port 0 non-existent on target machine 
1. Serial 
$ db2start dbpartitionnum 2 restart hostname two.ca.ibm.com port 
0 
2. In Parallel 
$ db2start dbpartitionnum 1 restart hostname two.ca.ibm.com port 
1 & 
$ db2start dbpartitionnum 0 restart hostname two.ca.ibm.com port 
2 & 
 
Port 0 exists on target machine 
In Parallel 
$ db2start dbpartitionnum 2 restart hostname two.ca.ibm.com port 
1 & 
$ db2start dbpartitionnum 1 restart hostname two.ca.ibm.com port 
2 & 
$ db2start dbpartitionnum 0 restart hostname two.ca.ibm.com port 
3 & 
 
Otherwise the following error will occur: 
 
SQL6031N Error in the db2nodes.cfg file at line number "3". 
Reason code "13". 
 
Also when trying to start on the target machine a node that is 
port 0 on the source machine first, the failover might appear to 
hung showing timeout errors in the db2diag.log: 
 
FUNCTION: DB2 UDB, base sys utilities, sqleGetSpinLock, probe:40 
DATA #1 : String, 64 bytes 
Waited for other mlns to complete(mlns,elapsed time in seconds): 
DATA #2 : Hexdump, 4 bytes 
0x0FFFFFFFFFFF74C8 : 0000 000A .... 
DATA #3 : Hexdump, 4 bytes 
0x0FFFFFFFFFFF74CC : 0000 000C .... 
... 
FUNCTION: DB2 UDB, base sys utilities, sqleGetSpinLock, probe:50 
DATA #1 : String, 88 bytes 
Time out in port zero host restart,while waiting for other mlns 
on sam 
host to complete 
DATA #2 : Hexdump, 4 bytes 
0x0FFFFFFFFFFF74C8 : 0000 000A .... 
DATA #3 : Hexdump, 4 bytes 
0x0FFFFFFFFFFF74CC : 0000 00F0 
 
The functionality for v9.5 and later introduced a parallel start 
feature, which means that logical port 0 will have to be moved 
last, not first. 
 
This APAR will allow for the old v9.1 behaviour to be available 
in v9.5 and later
Problem-Zusammenfassung:
**************************************************************** 
* USERS AFFECTED:                                              * 
* ALL                                                          * 
**************************************************************** 
* PROBLEM DESCRIPTION:                                         * 
* The default behaviour will be Parallel:                      * 
*                                                              * 
*                                                              * 
*                                                              * 
* Use the following to turn on the Parallel feature:           * 
*                                                              * 
* db2set DB2_PMODEL_SETTINGS=SERIAL_RESTART:FALSE              * 
*                                                              * 
* The Serial is reset by:                                      * 
*                                                              * 
* db2set DB2_PMODEL_SETTINGS=SERIAL_RESTART:TRUE               * 
**************************************************************** 
* RECOMMENDATION:                                              * 
* Upgrade to DB2 Version 9.7 Fixpack 2                         * 
****************************************************************
Local-Fix:
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 9 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 9a for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 10 for Linux, UNIX, and Windows

Lösung
Problem was first fixed in DB2 Version 9.7 Fixpack 2
Workaround
keiner bekannt / siehe Local-Fix
Bug-Verfolgung
Vorgänger  : APAR is sysrouted TO one or more of the following: IC66750 IC67253 
Nachfolger : 
Weitere Daten
Datum - Problem gemeldet    :
Datum - Problem geschlossen :
Datum - der letzten Änderung:
01.03.2010
23.04.2010
18.02.2011
Problem behoben ab folgender Versionen (IBM BugInfos)
9.7.FP2
Problem behoben lt. FixList in der Version
9.7.0.2 FixList
9.7.0.3 FixList
9.7.0.3 FixList