214 DB2 Deployment Guide
5.1 Introduction
From a high level view of deploying a pre-configured database, there are four
tasks to perform:
򐂰Create the database.
򐂰Create the database layout — buffer pools, table spaces, and so on.
򐂰Create the database objects — tables, views, stored procedures, and so on.
򐂰Populate tables with data.
We can do these tasks in many different ways. One way is simply to restore a
backup image — then it all will be in place at once. The opposite approach is to
perform the steps one by one using the data definition language (DDL)
statements to create the database and the database objects, then use the SQL
statements to populate the tables.
In between these two extremes, there are a number of different methods to
choose from. We concentrate on the methods that use tools provided by DB2,
such as load and import.
There are many different aspects to take into account before we can decide on
which method to use. Here are some of the key aspects:
򐂰Are the source and target operating systems the same?
򐂰Is the deployment to replace an existing database, to make changes to an
existing database, or to create a new one?
򐂰What amount of data must be deployed?
Let us take a look at the pros and cons of the two main approaches, using a
backup image or using scripts.

Using a backup image

Using a backup image is the easiest way to deploy a pre-configured database.
However, there are some limitations that we have to take into account:
򐂰Compatibility on OS level: The target environment must be the same as the
one where the backup image was created:
– A backup image from a Windows environment cannot be restored on a
UNIX environment.
– A backup from a 32-bit UNIX system cannot be restored on a 64-bit UNIX
environment.