IBM manual Introduction, Using a backup image, 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.

214DB2 Deployment Guide