Cloning a DB2 Database Server

I’ve built new servers in half a dozen different ways. One of the ways most favored these days, especially by the other Engineers on my team is cloning. Whether it’s an Amazon EC2 copy or VM Ware that you’re using, some method of taking an image of an existing server and turning it into a new server seems to be gaining popularity.

What I’m talking about in this post is NOT cloning a database – using redirected restore or db2move or whatever to get a database from one server to another, but the whole server level. I’m also not going to discuss the technical elements of how to us Amazon or VM Ware’s tools to do the actual cloning – I’ll write that off to the SA sphere of influence. What I do want to talk about is the DB2-specific details on what you need to do to make such copies possible.

First, let’s make it clear that my experience in this area is with DB2 9.7 on Linux (RedHat, SuSe). So take my advice here in that context. I remember attempting to clone back on 8.2, and having major issues – including being unable to apply a FixPack to the cloned servers. I can’t recommend cloning for 8.2 if you’re still stuck on 8.2.

Before You Clone

Before you take a copy that a clone is to be made from, it is best if you stop DB2 entirely. It may work if you don’t, but it’s just not as certain. DB2 has always (ok, at least back to version 5 where my experience starts) supported taking database files and copying/backing them up/moving them while the database is down, but not while the database is running (that’s what online backup is for). If you try it while DB2 is up, at a minimum, you’ll have to go through crash recovery when the database comes back up – and it is possible that you may even have to restore the database. I’m always surprised with how stable DB2 is and how infrequently that happens, but still.

Settings to Change

Once the server has been copied and you bring it up somewhere else, there are still some things that you may have to do.

The main issues you’re likely to see are related to the server name change. In fact, this document can be helpful, and has details for windows, which my post doesn’t detail: http://www-01.ibm.com/support/docview.wss?uid=swg21258834 In my experience, you’re likely to have to make changes in two places: the DB2 registry and the db2nodes.cfg.

DB2 Registry

It is a variable that you almost never mess with, but if you do a db2set -all, one of the parameters that you will see set is called DB2SYSTEM. It looks like this:

$ db2set -all |grep g
[g] DB2FCMCOMM=TCPIP4
[g] DB2SYSTEM=svq00db01z.domain.com
[g] DB2INSTDEF=db2inst1
[g] DB2ADMINSERVER=dasusr1

Chances are that most DBAs have never even changed the [g] parameters. You have to change this as root. To do that, you’ll need to su to root or login as root, and then source the db2profile and use the command:

# . /db2home/db2inst1/sqllib/db2profile
# db2set -g DB2SYSTEM=svs00db01z.domain.com

Of course the path for the db2profile will vary. It is in the instance owner’s home directory under the sqllib sub directory.

The document I linked to above has a slightly different command which I haven’t tested myself.

Check the output of db2set again – you should be all set. You’ll have to restart the instance(db2stop/db2start) for the change to take effect.

db2nodes.cfg

The other place you need to check the server name is in the db2nodes.cfg file. While we usually only associate db2nodes.cfg with a multi-partition database (DPF or EEE), it is still there and used for single partition databases. Assuming you’re working with a single partition database, you’ll only have one line to change, which will look something like this:

0 svq00db01z.domain.com 0

Here, you’ll just have to edit the file with vi or your favorite text editor to change the server name to the new server name.

0 svs00db01z.domain.com 0

Chances are you won’t have been able to start db2 before making these changes. They won’t take effect until the next db2start.

DB2 Info Center Entry on db2nodes.cfg: http://www.ibm.com/support/knowledgecenter/SSEPGG_9.7.0/com.ibm.db2.luw.qb.server.doc/doc/t0006350.html

Changing Names

I have a strong dislike for having two databases with the same name. I’m usually supporting about 6 clients at once (more like 12 if you count covering for my co-workers), each with a minimum of 4 databases and a maximum of 100 databases. In order to help me not make basic human mistakes, I like all the databases to have different names. This helps me not accidentally do something on the wrong environment.

And someone is thinking “yeah, but how often does that happen?” I have one client that actually has two databases with the same name. They’re on different VPNS, but still. Last night, I accidentally applied changes on one that belonged on the other. Because I had a database backup before I made the changes, and they were both QA systems, it wasn’t a major problem – I reversed the mistake easily. While that’s the first time in at least 2 or 3 years, these kind of human mistakes happen, and if we can prevent them using different database names, all the better.

So I like to keep all database names different – you can still easily restore one database into another. To change the database name, the db2relocatedb command is really, really easy to use. You create a cfg file, which for a database name change looks like this:

> cat relocatetempdb.cfg
DB_NAME=TESTDB,DBTEMP
DB_PATH=/db_data
INSTANCE=db2inst1
NODENUM=0

And then you execute the relocatedb command like this:

> db2relocatedb -f relocatetempdb.cfg
Files and control structures were changed successfully.
Database was catalogued successfully.
DBT1000I  The tool completed successfully.

You’ll also have to consider what other things you want to change – is your log directory in a custom location that includes the database name? Archive logs? If the data itself is in a location that includes the database name, you may want to consider a redirected restore instead of the relocatedb option laid out above. I’m lucky in that most of my implementations are one-database->one-instance->one-server. I like to keep everything consistent.

Obviously, the cloning gets more complicated the more you have to change. Changing the instance name would require dropping and re-creating the instance and then either re-cataloging or restoring the database (and copying all instance-level settings using db2cfexp/db2cfimp).

Especially when you have the install scripted, a complete new build sometimes seems easier. If you ask me, installing DB2 is the easiest and least time consuming part of a build.

References:

Technote on changing the hostname of a DB2 server: http://www-01.ibm.com/support/docview.wss?uid=swg21258834
DB2 Info Center Entry on db2nodes.cfg: http://www.ibm.com/support/knowledgecenter/SSEPGG_9.7.0/com.ibm.db2.luw.qb.server.doc/doc/t0006350.html
developerWorks Article on db2relocatedb: http://www.ibm.com/developerworks/data/library/techarticle/dm-0407schlamb/