For our current pet project we’ve decided to use DB2 Express-C as a database back-end. The choice is made, so our junior developers could practice their art on databases that resemble enterprise databases more than MySQL or Postgres. (We have already ruled out SAPDB/MaxDB on previous occasions.)

First off the system I’m trying to install the server is remotely located, and doesn’t have any kind of X on it. This rules out all kind of graphical installs, but I never was fond of those anyway.

The system is running a Debian testing, with pretty strict firewall rules.

The install went easy, but with a few glitches. First off I’ve downloaded the installer from IBM. This required my PartnerWorld password, so I guess it’s not as easy to get as it seems. Then I’ve unpacked the installer and went on to install as root (this is usual for most installs, but almost mandatory for IBM products) This turned out to be a mistake later, as Express-C is different from other enterprise DB2-s. It’s preferred to be installed as a DB user, unless you want to run several instances on a given machine (not common for a single-shot pet-project).

The install went on fine with the console mode, and as a nice feature, even the text-mode installer shows a time estimate for each step.

After installing the application several times, I went to read some documentation, as I couldn’t find any of the tools I was used to on DB2 EE 8.2. The IBM Infocenter is always a good idea to look up such informations, see the one I looked at here.

Unfortunately all manuals described the startup as a simple process, all starting with the usual loading of DB2 profile, and then starting up the db with the db2start command. Unfortunately it always threw an error message, which turned out to be a problem with the default shared memory size. The simple solution is to add the lines:

kernel.msgmni = 1024
kernel.shmmax = 268435456


to the /etc/sysctl.conf file and then applying the changes with the

sysctl -p

command.

The db then started up fine, but as it turned out I should not be running the non-root installation, as that only permits local “APP” level connections.

So I’ve created the system users dasadm, db2inst for later use.

mkdir /data/db2
adduser --system dasadm --home /data/db2/dasadm
touch /data/db2/dasadm/.profile
chown dasadm.nogroup /data/db2/dasadm/.profile
adduser --system db2inst --home /data/db2/db2inst
touch /data/db2/db2inst/.profile
chown db2inst.nogroup /data/db2/db2inst/.profile

Then the entire DB was reinstalled using the root user.

Creating an admin server

The admin server is used to monitor, and manage your DB2 instances on a system. To create and start service, issue the commands:

chsh dasadm -s/bin/sh
DB2_HOME/instance/dascrt dasadm


There seems to be some error on the current version of DB2, the admin server keeps sending messages like:
The state of instance 'dasadm' gcf module '/opt/ibm/db2/V9.5/das/lib/libdb2dasgcf.so.1' is OPERABLE (OFFLINE).
I could not yet locate the actual reason, but to disable this message it’s great to turn the db2fmd off. That can be achieved by commenting out the respectable lines in the inittab, and then reloading the inittab with:

init q

I’ll keep this off until I find some way to work around the current problem.

Creating a db instance

The DB2 instance was created and started using the following commands, as root:
DB2_HOME/instance/db2icrt -u db2inst db2inst
DB2_HOME/instance/db2istrt -u db2inst db2inst


command. When using the command one must make sure the provided ID actually HAS A SHELL! Of course it took me quite a while to find that out.

Getting the Control Center to work

First off I thought it would be a good idea to just forward the DB2CC X11 output to my computer.

To get X forwarding on the server I tried doing what I read here. After installing the xauth package I was able to forward my favorite X application (xteddy) through to my desktop. There still seems to be a problem, that the window content is not forwarded, even thought the bear shaped window appears. However when I switch over to another user (root and then to db2inst) it simply fails to forward the X. It turned out that the xauth must be copied over to the user that is to be authorized using a command like:

xauth -f /home/MYUSER/.Xauthority extract /root/.Xauthority :0


I could not however use this, to extract the xauth from my user directly to the db2inst user.

Cutting the crap, I’ve got fed up with the xauth, so I just thrown in a shell for the db2inst user, and authorized my user to log-in remotely. Then X11 forwarding worked straight away, and I was able to forward the db2cc without any problem. It’s quite slow, but what the heck?

The speed problem can be helped a bit by adding a -C (compress) parameter to the ssh. It speeds the connection up almost to the level of running it on the local network through my ADSL connection.

Summarizing

After wasting hours on trying to set things up I got some problem starting up the administrator instance, being unable to trace it down to the root of the problem, I uninstalled the entire installation, wiped the install directory and started up the install in graphical mode as root with copying the X authorization as described above.

The installer was running for about 5 minutes, and created and configured the  basic DB instance.