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: 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] 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

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.


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 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 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:

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

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.


Technote on changing the hostname of a DB2 server:
DB2 Info Center Entry on db2nodes.cfg:
developerWorks Article on db2relocatedb:

Ember Crooks
Ember Crooks

Ember is always curious and thrives on change. She has built internationally recognized expertise in IBM Db2, spent a year working with high-volume MySQL, and is now learning Snowflake. Ember shares both posts about her core skill sets and her journey learning Snowflake.

Ember lives in Denver and work from home

Articles: 554


  1. Thanks for sharing this. That is a very useful post, as always.

    As you say, it is not advisable to clone when you the database is in use.

    An alternate to shutting down the database is to use SET WRITE SUSPEND command before cloning and then on the cloned database, using db2inidb (with relocate using option, if required).
    If your underlying system clone runs only for a few seconds, then you may be able to get away with your website users not even noticing the “downtime”.



    • Great, thanks for this. Most of the cloning I tend to do is spinning off additional development environments so I forget nifty commands like set write suspend.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.