DB2 cataloging gave me a surprise yesterday. I was under the impression that you don't need to reboot a Unix machine in most cases, certainly not after any installation or configuration change. DB2 catalog (actually uncatalog) command made a dent to that impression.
To make my rant effective, let me quickly discuss what is cataloging.
When your application (WebSphere Portal Server in my case) has to access a remote database, it requires a db2 client installation on the local machine. You create databases on the remote database and "catalog" those databases defining a local "node" on the db2 client.
From this point on, the client uses tcp/ip to talk to the server. You issue all the db commands as if the database was local.
To catalog db2,
First you need to catalog the remote database on a local node:
db2 catalog tcpip node <nodename> remote <fully.qualified.db.server.name> server <port>
You can select an arbitrary name for nodename. You must use fully qualified server name and the port on which the database is running (typically 50000)
You can now catalog individual databases on the local machine
db2 catalog db <remote_db_name> as <local_alias_name> at node <node_name>
For example, to catalog wpsdb, you would issue
db2 catalog db wpsdb as wpslocdb at node wpsnode
From this point on, you will perform database operation on wpslocdb, which will actually manipulate data in wpsdb running on the remote database server.
Ok. So far so good. Why do I think db2 catalog is adamant? The answer is, in my case, catalog attached the remote server on the local node so "strongly" that it was very hard to "uncatalog." Yesterday, my team and I accidentally cataloged the production node on dev database. Having realized our mistake, we issued
db2 uncatalog node <node_name>
db2 uncatalog db <local_alis_name>
No success! The portal was still going against the dev database. We thought may be it caches the directory information. We terminated the backend process using terminate. Still no success. The portal was still going against the dev database. Finally we tried stopping and starting the database instance db2stop/db2start. No luck!
We finally gave up and decided to reboot the machine. After all we all use PCs running Microsoft OS in our daily lives! And to our surprise it did work. Not quite a surprise though. We knew it had cached the directory information somewhere and the reboot refreshed the cache. But I am still disappointed. We should not have had to reboot the machine but well, who can afford to spend time investigating when it's okay to reboot.
