DB2 - Problembeschreibung
Problem IC99935 | Status: Geschlossen |
DB2IUPGRADE FAILURE WHEN DB2NODES.CFG CONTAINS VIRTUAL IP ADDRESSES | |
Produkt: | |
DB2 FOR LUW / DB2FORLUW / A50 - DB2 | |
Problembeschreibung: | |
Background of the problem ; - db2ckupgrade API does sqlestar() and then sqleatin() , sqleatin() fails if virtual host names are used AND sqleatin() is called after sqlestar() from the same ckupgrade app. The actual problem is in oss code sqloGetDftNodeNum() that compares a tcpip resolved host name to db2nodes.cfg node lines which is not a good comparison if virtual hostnames are used. It will fail to understand these 2 hosts are actually same hosts. There is a ssh/rsh solution executing this at remote node when db2rstar is used to do ssh/rsh in this host and figure out what it resolves and save it to a file. Then compare these values to match the host later instead of trying to do strcmp in db2nodes.cfg with tcpip resolve names. API -> blah() --> sqlestar() -> sqleatin() -> blah... Closer look : sqlestar() - > INITAPPENV- > CACHE NODE UNKNOWN -> (noDEfaultNodeKnown - IT IS NORMAL - db2start is not DONE yet) [ see detail#2 ] -> sqleatin() -> VOID (INITAPPENV : it is already done DOES NOT DO refersh node info) -> getDefaultnodeToAttachDBMS -> CACHED NODE IS STILL UNKNOWN - SQLEATIN -> FAILS on attaching DBMS. [detail #2] db2start creates a .dft file that has indeed default node number created in .dft file from port 0 detection. Now if you call another api indeed it would know the only reason above failure in sqleatin() never do multiple INITAPPENV from same app that might be calling 2 different db2 API in the same exe. and the point we bail out second time INITAPPENV we WONT refresh the nodes info from .dft file. If we were calling now a second time another API that has sqleatin() it would SUCCEED. SUCCESS CASE exe1 - sqlestar OR outright db2start exe2 - sqleatin exe1 + exe2 would work (sqleatin would refresh in initAPPENV) FAIL CASE exe3 - sqlestar + sqleatin (sqleatin would NOT refresh in initAPPENV ) if it were virtual ip it would fail... exe3 would fail The fix : inside sqlestart() after startup completes ok , but if node is still unknown in the cache of INITAPPENV then refresh this cache again. Limited and ugly workaround. | |
Problem-Zusammenfassung: | |
**************************************************************** * USERS AFFECTED: * * DPF instance * **************************************************************** * PROBLEM DESCRIPTION: * * See Error Description * **************************************************************** * RECOMMENDATION: * * Upgrade to version 10.5 fixpack 3. * **************************************************************** | |
Local-Fix: | |
change the entries in db2nodes.cfg from virtual ip to hostname | |
verfügbare FixPacks: | |
DB2 Cancun Release 10.5.0.4 (also known as Fix Pack 4) for Linux, UNIX, and Windows | |
Lösung | |
Fixed in version 10.5 fixpack 3. db2iupgrade succeeds with upgrading from v10.1 to v10.5 | |
Workaround | |
keiner bekannt / siehe Local-Fix | |
Weitere Daten | |
Datum - Problem gemeldet : Datum - Problem geschlossen : Datum - der letzten Änderung: | 07.03.2014 08.09.2014 08.09.2014 |
Problem behoben ab folgender Versionen (IBM BugInfos) | |
Problem behoben lt. FixList in der Version | |
10.5.0.4 |