Problems changing the IP address of a W2K3 system with 8.2

[Bernd Giegerich]

Hi,

we had a strange problem with DB2 8.2 Enterprise Edition on Windows
2003 (Standard) Server.

We installed DB2 8.2 (8.1.7) directly on a naked W2K3 system (no
migration, no update -> no leftovers from an older version on the
system).

After that, we had to change the IP address of the system. Same
network, only another IP (both in a.b.c.0/24). DB2 was down during
the change. We even rebooted the system with the DB2 services set to
"Manual Start" after the change.

Then we re-enabled the DB2 services to their original state
("Automatic" startup for most of them) and rebooted again.

After that, DB2 came up but we were unable to connect to any of the
databases, even from the server system itself. Same for another
system in the same network with a fresh Developer Client
installation, which had no problems before. CPU load and memory usage
showed idle values, we didn't find any warnings or errors in the
eventlog, but a "connect to xxx" just didn't return.

We had to recover quickly, so we deinstalled DB2, reinstalled it and
restored the backup we made before the change. That worked fine, so
we are not in trouble at the moment.

Tomorrow we will try to reproduce the problems in our testlab.
Anybody an idea, a possible reason? Do I have to prepare DB2 for such
a change? I was unable to find any hint in the documentation, any
hint would be appreciated...

Regards,
Bernd

[Philip Sherman]

Food for thought:
1. Does changing the IP address impact the W2K3 firewall?
2. How were your local (from the server) databases defined for access?
True local access or access as a remote, IP connected, system? If the
latter, then the firewall becomes a much larger suspect.

I assume that you did change the IP address of the server node on the
client because you gained access after the reinstall.

Phil Sherman
Bernd Giegerich wrote:

Hi,

we had a strange problem with DB2 8.2 Enterprise Edition on Windows
2003 (Standard) Server.

We installed DB2 8.2 (8.1.7) directly on a naked W2K3 system (no
migration, no update -> no leftovers from an older version on the
system).

After that, we had to change the IP address of the system. Same
network, only another IP (both in a.b.c.0/24). DB2 was down during
the change. We even rebooted the system with the DB2 services set to
"Manual Start" after the change.

Then we re-enabled the DB2 services to their original state
("Automatic" startup for most of them) and rebooted again.

After that, DB2 came up but we were unable to connect to any of the
databases, even from the server system itself. Same for another
system in the same network with a fresh Developer Client
installation, which had no problems before. CPU load and memory usage
showed idle values, we didn't find any warnings or errors in the
eventlog, but a "connect to xxx" just didn't return.

We had to recover quickly, so we deinstalled DB2, reinstalled it and
restored the backup we made before the change. That worked fine, so
we are not in trouble at the moment.

Tomorrow we will try to reproduce the problems in our testlab.
Anybody an idea, a possible reason? Do I have to prepare DB2 for such
a change? I was unable to find any hint in the documentation, any
hint would be appreciated...

Regards,
Bernd

[Bernd Giegerich]

Hi,

Food for thought:
thanks, I'm always hungry for that kind of food... :-)
1. Does changing the IP address impact the W2K3 firewall?
no, cause no firewall/filter was active. The OS was installed from
scratch, based on scripts and response files, as DB2 was. So I'm
pretty sure about the system state. After a reinstallation of DB2
(and only DB2) on the system, where we didn't change anything on
the base OS configuration, things worked well again - another
reason I don't believe in a firewall issue.

It didn't feel like a connectivity or address resolution problem,
but more like a problem of a part of the internal DB2 server
architecture. Uncataloging the DBs and cataloging them again did
work, but a connect still didn't return within a reasonable time.

I opened a call at IBM and expected a hint regarding a dbm config
parameter I didn't set at the right time, or a magical
"db2ChangeNodeAddressToMakeWorldANicePlaceToLi ve" or anything like
that, but the supporter was unable to reproduce the problem.

Today I built up a absolute identical test system, and tomorrow I
will try to get DB2 screwed up again. Fortunately we have enough
identical hardware available, the whole installation (including
DB2 with dbm and db config) was controlled by scripts and I have
full offline backups of the databases, taken directly before we
made the address change. I never had a better base to reproduce an
error - but I still pray that I will be able to do so...
I assume that you did change the IP address of the server node
on the client because you gained access after the reinstall.

....no reason to do so. The catalog entry pointed to the name, not
the address. The name got resolved without problems at that time -
one reason, why we took DB2 offline during the change. And again:
After a reinstallation of DB2 on the server system and a restore,
the client had no more problems...

I hope to get an idea during the tests tomorrow. Or, at least,
enough data for IBM to analyse the problem.

Regards,
Bernd

[Bernd Giegerich]

Hi,

just for the files: I got it. I was able to reproduce the problem and
found an also reproducable solution/work around.

After changing the IP addresses and bringing DB2 up again, I once had
to stop and restart HADR on the databases to get the system up and
running.

Deactivate the primary DB, stop HADR on it, deactivate the standby
DB, stop HADR on it. Then the same the other way: Start HADR on the
standby and then on the primary.

That's all, you don't have to re-initialize HADR, it's just stopping
and starting it. Only a few lines of SQL and some seconds to
compute...

Regards,
Bernd