Databases

IBM® Business Process Manager uses several product databases that either are automatically migrated or must be manually migrated as part of the runtime migration procedure.

Database scopes

Note: Some of the features that were added in IBM Business Process Manager V7.5.1 (for example, Business Process Definitions) are not configured during the runtime migration procedure. Once you have completed the IBM Business Process Manager runtime migration procedure, create the tables for BPMN Process Server and Performance Data Warehouse databases.

Some of the IBM Business Process Manager product databases are cell-scoped and others are deployment target-scoped.

Common database

This database is cell-scoped, so when a deployment target such as a server, cluster, or non-clustered managed node in the cell is migrated to version 8.0.1, the database must be migrated also. In a mixed-version cell environment, this might result in pre-version 8.0.1 servers, clusters, and non-clustered managed nodes using the same instance of the database as version 8.0.1 servers, clusters, and non-clustered managed nodes.

Note:

If you are migrating from version 7.x, it is not necessary to perform a schema upgrade for the Common database. Refer to Migrating databases.
If you are migrating from version 6.2 or 7.0, you must create the databases for BPMN Process Server and Performance Data Warehouse.
If you are migrating from version 7.5.x, you must upgrade the Process Server and Performance Data Warehouse databases. Refer to Upgrading existing databases.

Business Process Choreographer database, Business Space database, Common Event Infrastructure database, and the Messaging Engine database

These databases are deployment target-scoped. They can be configured at a server or a cluster scope. If these databases are configured in a mixed-version cell environment, each server, cluster, or non-clustered managed node will have a unique instance of the database, and each instance will have schema and data that are unique to that version of the product. When each server, cluster, or non-clustered managed node is migrated, its unique instance of the database is migrated also as part of the runtime migration procedures.

Backups

The migration procedures include steps for backing up the product databases to enable them to be restored if schema migration or data migration fails.

Automatic and manual migration

The Common Event Infrastructure database and Messaging Engine database are automatically migrated by the runtime migration procedure when the profiles are migrated.

The Common database is automatically migrated in some situations as part of the runtime migration procedure and in other conditions manual migration is necessary. The Business Process Choreographer and Business Space databases require manual migration in all circumstances. In summary, you must update the databases manually using scripts provided with IBM Business Process Manager in the following circumstances:

If the server process does not have sufficient permissions (that is, if it has not been configured with a user ID with sufficient permissions for the Common database and the Business Process Choreographer database)
If you used non-default table spaces
If your migration source is configured with Business Space

More details on when and under what conditions the product databases should be manually migrated are captured directly in the runtime migration procedures.

Authorization

Because each of the database scripts require different database permissions, check whether you will be able to run all scripts using a single user ID, or whether your database administrator might have to run any of them.

For the Business Process Choreographer database scripts:
To run the upgradeTablespaces SQL script for DB2 for Linux®, UNIX®, and Windows®, you require the following permissions:
- CREATE BUFFERPOOL
- CREATE TABLESPACE
To run the upgradeTablespaces SQL script for DB2 for z/OS, you require the following permissions:
- CREATE TABLESPACE
To run the upgradeSchema SQL script, you require the following permissions:
- For all database types, you must be able to perform CREATE TABLE, ALTER TABLE, DROP INDEX, CREATE INDEX, CREATE VIEW, and DROP VIEW.
For the Common database scripts:
The following permissions are required:
- CREATE TABLE
- ALTER TABLE
- DROP INDEX
- CREATE INDEX
- CREATE VIEW
- DROP VIEW
- CREATE SEQUENCE
For the Business Space database scripts:
The following permissions are required:
- CREATE TABLE
- GRANT UNLIMITED TABLESPACE
- CONTROL OF USERS TABLESPACE
In addition, the following permissions might be required:
- CREATE SCHEMA
- CREATE INDEX
- DROP TABLE
- DROP SCHEMA

Time requirements and tuning options

Depending on the quantity of data and the power of your database server, the data migration step (excluding the time required to backup the database and upgrade the database schema) can take several hours.

This topic applies only to the Distributed platforms

DB2 for z/OS and OS/390 Version 7

If you use DB2 for z/OS and OS/390 Version 7, and have not yet upgraded the database to DB2 for z/OS version 8 or DB2 9 for z/OS, you will be asked to do that as part of the runtime migration procedure.

Oracle 9i and the Oracle JDBC driver

If you are using Oracle 9i, and have not yet upgraded your database to 10g or 11g, you will be asked to do that as part of the runtime migration procedure.

If you are using the Oracle ojdbc14.jar or the ojdbc5.jar JDBC driver, you will be asked to install and configure the ojdbc6.jar JDBC driver as part of the runtime migration procedure.

After data migration: Retuning your database and re-creating custom views

During data migration, any additional indexes and custom views that you had are lost, and must be re-created.

Creating custom indexes is especially important for the performance of human workflow applications that make complex database queries.