How to increase the table space page size or change the character set for a Process Engine database on DB2 for Linux, Unix, or Windows

Content

Overview
There are instances where you might need to change the page size or database character set for a Process Engine database on DB2. This document discusses how to go about making these changes.

Use the procedures in the techdoc How to determine if your Process Engine DB2 database has the correct table space page size and/or code page for upgrading to Process Engine 5.0 to determine whether page size or code page changes are required before upgrading to Process Engine 5.0.

The procedures in this document show you how to move Process Engine (PE) version 4.5.1 or 5.0 database data from one DB2 for Linux, UNIX and Windows database to another DB2 for Linux, UNIX and Windows database using two different methods. This procedure does not cover making tablespace or character set changes to a PE database configured with DB2 on z/OS. The database administrator should work with the Process Engine administrator to do the migration. With either method, all of the data in the database must be migrated. It is not possible to do a partial migration, such as for selected isolated regions.

The first method uses the IBM Data Movement Tool (IDMT). The IDMT tool is available in IBM developerWorks at: http://www.ibm.com/developerworks/data/library/techarticle/dm-0906datamovement/index.html?ca=drs-
Although the IDMT tool supports additional database migration options, such as from one database vendor to another, the only migration documented and supported with these procedures is the change of page size or character set. Any other configuration changes should be handled with lab services engagements.

The second method documented here uses DB2 EXPORT and LOAD commands.

Summary
The migration procedures consist of three sections.

Preparing four environments to move Process Engine data
In this process there are four environments. These environments need to be set up before starting the migration of the data from one database to another.

1. Process Engine Server: The Process Engine software can be either Process Engine v4.5.1 or 5.0.
2. Source Process Engine DB2 database: This is the Process Engine database that holds the current Process Engine data. This database must be DB2 for Linux, UNIX and Windows, v9.7 FP4.
3. Target Process Engine DB2 database: This is the new DB2 database that is created with the new table spaces with 32 KB pagesizes and supported UTF-8 code page. This database must be DB2 for Linux, UNIX and Windows, v9.7 FP4.
4. Migration work environment: Both migration methods require a work environment to temporarily store the data that is being migrated.
1. IBM Data Movement Tool (IDMT) environment. The IDMT tool must be run on the server where the target DB2 database resides. The tool needs to be able to access both the source and target databases. This location must have enough space to hold both the IDMT software, a copy of Java, the JDBC drivers and all Process Engine data from the source DB2 database. When selecting this location, consider the amount of data you are moving, network speed, and site security. Be sure you have read and understand the documentation and prerequisites for the IDMT tool.
2. Manually running the DB2 export and load commands. This procedure provides an alternate way of migrating the Process Engine data from one DB2 database to another without using the IBM Data Movement Tool.

Migrating the Process Engine data to a new DB2 database
This section covers database backup, extraction of Process Engine data from source database and deployment of that Process Engine data to the new target database.

Reconfiguring the Process Engine Server to use the new database
This section documents reconfiguring the Process Engine to point the Process Engine to the new DB2 database, backing up the target database, and starting up the Process Engine Software.

Note: If after reading this document the reader is not comfortable implementing the steps, it is suggested that Global Business Services (GBS) be engaged to assist and ensure that the procedure is done properly.

Details
Preparing the four environments to move Process Engine data

I. Process Engine Server

1. Identify the Process Engine database user name. In version 4.5.1, this was referred to as the runtime database user name and default was f_sw.
2. Verify that the source database is version 9.7 FP4.
3. Collect information on your current Process Engine environment. Using vwtool, for each isolated region run the following commands with the hardcopy option set ON.
• count #
• config
• queueconfig
• rosterconfig
• logconfig (include system fields)
• views

For version 4.5.1, see the online help for information on running vwtool.For version 5.0, see the online help for information on running vwtool.

4. From the Process Engine Process Task Manager (PTM) utility make a list of:
• The current default and region table spaces
• The regions with custom table spaces. This list should be used as a reference when creating the DB2 table spaces in the new target database and when updating the PTM with the custom region table spaces after the migration.
5. Stop all Process Engine related services and applications, including Process Analyzer. Ensure that all background processes are stopped.

Important: Do not start up the Process Engine again until this procedure is complete and you are told to start up the Process Engine.

See Appendix B Shutting down Process Engine server software.

II. Source Process Engine DB2 database server
Do a complete cold database backup of the source Process Engine DB2 database.

III. Target Process Engine DB2 database server

1. Create a target DB2 database to hold the Process Engine data. This must be v9.7 FP4. Use the guidelines in the Process Engine 5.0 installation documentation when creating this database, the database user, and Process Engine required table spaces. See Creating Process Engine database user for DB2 for Linux, UNIX and Windows and Preparing DB2 for Linux, UNIX and Windows servers for database user and database requirements.
2. Ensure that:
   • The operating system user identified as the Process Engine database user was created and has the correct permissions in the target database.
   • The database character set is UTF-8.
   • The data, index, and blob table spaces each were defined with a 32 KB page size. The DB2 table spaces can be named the same as the table spaces in the source DB2 database.
3. For the duration of the migration process, add the Process Engine operating system database user f_sw to the DB2 instance administrative group.

IV. Migration work environments

A. IBM Data Movement Tool (IDMT) environment.

Take the following steps to create the IDMT environment on the target database server.

1. Create a directory to hold the IBM Data Movement Tool (IDMT) software and data.
2. Provide read, write and execute permissions on this directory to the target DB2 instance owner.
3. Download IDMT from the IBM developerWorks web site:

   IBM DeveloperWorks IBM Data Movement Tool page

4. Extract contents of IBMDataMovementTool.zip file into the IDMT directory. Follow the instructions provided with the IDMT regarding prerequisites and setting up the environment.
5. Install the Java and JDBC driver(s).
   • Follow the instructions provided with the IDMT regarding prerequisites and setting up JDBC. The IDMT has specific requirements for the JDBC driver that may differ from any other driver you may already have installed on the target database server.
   • Install the JDBC driver(s) by following the instructions on the download page for DB2 JDBC Driver Versions
   • Make note of which driver(s) were installed and where you install them as this information will be needed later in the Setup IDMT properties and migrate data section

B. Manually running the DB2 export and load commands.

Migrating the Process Engine data to a new DB2 database

A. Migrating using IDMT
On the target database server that holds the IDMT environment - configure the IDMT properties for Process Engine and migrate data.

1. Ensure that the source and target DB2 databases are running.
2. Ensure that the Process Engine software is completely shut down.
3. On the server with the IDMT environment, log on as the target database instance owner.
4. Run the IBMDataMovementTool command/shell file.
1. Check the IBMDataMovementTool.cmd/.sh command file to ensure that the location of the JAVA software is correct. It is on the last line of the script.
2. On windows run the IBMDataMovementTool.cmd; this can be done from either: a browser by clicking on the IBMDataMovementTool.cmd file, or from a command line. The IBMDataMovementTool.cmd will start the IBM Data Movement Tool and open the tool screen.
3. On UNIX run the IBMDataMovement.sh shell script from a shell prompt.
4. Input the source database and target database information:
   • Vendor
   • DB2luw for source database
   • DB2luw for target database
   
   
   
   
   
   
   • Server Name – name assigned to each database server
   • Port Number - port number used by each database instance
   • Database Name – name of each database
   • User ID – Process Engine database user name. Use the same database user name for the source and target databases.
   • Password – password for Process Engine database user.
   • JDBC Drivers - extended file name of each JDBC driver; type in the names or click the ellipses (...) to display a selection list of required driver names, then browse directories to find the installed drivers.
   • Source Schemas will be filled in after the first connection to the source database is made.
   • Migration - specify the following options: DDL , Data, Objects
   • Num Threads – set to 5
   • Num JVM – set to 1
   • # Extract Rows – set to ALL
   • # load Rows – set to ALL

5. Click the Test Connections button under both the source and target database columns to test the JDBC connection to each database.
For the source database, the following message should display at the bottom of the window: Connect to db2luw succeeded and schema information obtained.



For the target DB2 database, the following messages should display in the window:



• The DB2 instance name displays in the box under the Connect to DB2 button of the target database:

Instance Name DB2_01 (9.7)

• The connection status displays in the message box:

Connection to local db2luw server succeeded.

Important: If you try to test the database connection without being a member of a database sysadm operating system group, the following will display in the message box:

Connection to local db2 server succeeded. Warning: User ‘f_sw’ does not seem to be sysadm. You will face problems in deployment.

6. After the database connections are tested and working, select the source schema of the entries provided: Select only the Process Engine database user schema name. For Process Engine the schema name is the same as the Process Engine database user name.
For example: F_SW
7. On the Set Params tab, Save Params. This will save the source and target database information into the IDMTConfig.properties file.




5. Exit IBM Data Movement Tool.
6. In the migr directory, edit the IDMTConfig.properties file, set the following properties and save the file:
   • retainConstraintsName=true
   • useBestPracticeTSNames=false
   • loadException=false
   • exceptSchemaSuffix=
7. Reopen IBM Data Movement Tool
8. Connect to the Source Database
9. Click the Extract DDL/Data button.
10. Click Yes – Are you sure you want to continue?
11. In the migr directory, edit the db2tables.sql file to add the table spaces names to each CREATE TABLE statement.
For example, change from:

--#SET :TABLE:F_SW:VWATTACHED1 


CREATE TABLE "F_SW"."VWATTACHED1" 
( 
"F_WORKCLASSID" INTEGER NOT NULL , 
"F_WOBNUM" CHAR(16) FOR BIT DATA NOT NULL , 
"F_ID" VARCHAR(256) , 
"F_LIBRARYNAME" VARCHAR(64) , 
"F_LIBRARYTYPE" INTEGER NOT NULL , 
"F_TYPE" INTEGER NOT NULL
) 
; 
To the following by adding the table space names:
--#SET :TABLE:F_SW:VWATTACHED1 
CREATE TABLE "F_SW"."VWATTACHED1" 
( 
"F_WORKCLASSID" INTEGER NOT NULL , 
"F_WOBNUM" CHAR(16) FOR BIT DATA NOT NULL , 
"F_ID" VARCHAR(256) , 
"F_LIBRARYNAME" VARCHAR(64) , 
"F_LIBRARYTYPE" INTEGER NOT NULL , 
"F_TYPE" INTEGER NOT NULL
) IN “VWDATA_TS” INDEX IN “VWDATA_TS” LONG IN “VWBLOB_TS” 
; 
Important: Ensure that the table space names are all in upper case when they are within the double quotes.

12. In the migr directory, edit the db2tsbp.sql file. Delete all but the first three lines of the file and save the file. This is done so that IDMT does not try to create new table spaces and buffer pools in the target database. The table spaces that will be used by the Process Engine should already have been created during a prior step of this procedure.
13. In the IDMT, click the Interactive Deploy tab. Click the refresh button.





14. Click on one of the table names in the Select DB2 Objects pane. Check that the table spaces are correct.



15. If the Create statements are correct, from the Extract / Deploy tab connect to the target DB2 database. Click the Deploy DDL/Data button to move the data to the target DB2 database.
16. Click Yes to run db2gen.cmd.



17. The IDMT View File tab will display the progress.
18. Once complete – exit IDMT.

Compare table row count of source and target databases

When the Deploy data completes, compare the number of records in the source database to the target database by running the rowcount shell script that is generated by IDMT. Rowcount is located in the migr directory. Note: both the source and target databases must be running in order for rowcount to connect to each database.

Complete a backup
After verifying that row counts on the source and target databases match, do a backup of the target database. It is best practice to leave the source database in place until system testing and verification confirm the migration was complete and successful.

Next Step:
Continue with the procedures documented in the Reconfiguring the Process Engine Server to use the new database section - to complete the migration process.

B. Migrating using DB2 commands Export and Load

Summary

· Ensure that the Process Engine server software is shut down ( see Appendix B)

· Collect schema from source database (db2look)
· Re-create schema on target database (DB2 script)
· Export Process Engine data from source database to files on disk (EXPORT )
· Load Process Engine data into target database from files (LOAD)

Collecting and copying source database schema to the target database

1. On the source database server, log on to the source database server as the DB2 instance owner.
2. Run db2look at a command prompt to collect the Process Engine schema from the source database. The db2look command will collect the schema from the source database and generate a SQL script to re-create all schema objects including tables, indexes, views and sequences. Run the following at a command prompt:

db2look –d source_database_name -e –z source_PE_database_schema_name -o output_file_name    



The output will go to the local directory unless you indicate a full path for the output file name and location.
The following is an example of the output returned to the screen.
-- No userid was specified, db2look tries to use Environment variable USER 
-- USER is: DB2INST3 
-- Specified SCHEMA is: F_SW 
-- Creating DDL for table(s) 
-- Schema name is ignored for the Federated Section 
-- Output is sent to file: crtestdb.sql 

3. Edit the db2look output file, in this example: crtestdb.sql.

   Modify the CONNECT TO database command as follows:

change:


CONNECT TO source_database_name
to
 CONNECT TO target_database_name USER PE_DB_user_name USING PE_DB_USER_password
For example:
 CONNECT TO PEDB USER F_SW USING MYPASSWORD 
4. Edit the table space names to add target table space names to the end of the create table statements. Your system might not have separate table spaces for data, indexes and BLOBs but you must provide tables space names for all three in the CREATE TABLE statements. The table space names specified here must exist in the target database before you move the data to the target database. If, for example, your indexes are stored in the data table space

For example, change:



CREATE TABLE "F_SW "."VWRDBOBJECT" (
 "F_OBJECTROOT" VARCHAR(128) NOT NULL , 
 "F_REGIONNUM" INTEGER , 
 "F_SUBNAME1" VARCHAR(128) , 
 "F_SUBNAME2" VARCHAR(128) , 
 "F_SUBNAME3" VARCHAR(128) , 
 "F_LOCATION" VARCHAR(128) NOT NULL , 
 "F_MARKEDASDELETED" DECIMAL(3,0) ) 
 IN "VWDATA_TS" ; 

to:

CREATE TABLE "F_SW "."VWRDBOBJECT" (
 "F_OBJECTROOT" VARCHAR(128) NOT NULL , 
 "F_REGIONNUM" INTEGER , 
 "F_SUBNAME1" VARCHAR(128) , 
 "F_SUBNAME2" VARCHAR(128) , 
 "F_SUBNAME3" VARCHAR(128) , 
 "F_LOCATION" VARCHAR(128) NOT NULL , 
 "F_MARKEDASDELETED" DECIMAL(3,0) ) 
 IN "VWDATA_TS" INDEX IN "VWINDEX_TS" LONG IN "VWBLOB_TS" ; 

where:
VWDATA_TS is the data table space
VWINDEX_TS is the index table space
VWBLOB_TS is the BLOB table space

Optionally, if you only want to use two table spaces and want your indexes to be stored in the data table space, the table space information would look like this:

 IN "VWDATA_TS" INDEX IN "VWDATA_TS" LONG IN "VWBLOB_TS" ; 

Important: Table space names that are surrounded by quotation marks must be in upper case.
5. Save your changes.
6. Copy edited crtestdb.sql script to the target DB2 server.
7. Run the script file on the target database server to create the Process Engine schema on the target database.

On UNIX:
db2 -tvf /DB2db2Manual/crtestdb.sql -z /DB2db2Manual/crtestdb.output 

On Windows:
db2 -tvf C:\DB2db2Manual\crtestdb.sql -z c:\DB2db2Manual\crtestdb.output 

8. Check the crtestdb.output file for errors and messages.

Exporting Process Engine data from the source DB2 database into systems files on the target database server.

Create file system directories on the target database server to hold the Process Engine data, then run the DB2 export command to copy the Process Engine data from the source database to files in the new directories.

1. On the target DB2 database server, create the new directories to hold all the Process Engine data. The base directories that need to be created are: main directory, within that main directory: a directory for each table to hold blob column data, a msg directory and a a dump directory. Create the main directory, the msg and the dump directories ( adjust path names if on Windows) :

Type of directory	Directory Name	Create command	Directory permissions for instance owner
Main	PEtableData	mkdir PEtableData	Read/write/execute
Message	msg	mkdir PEtableData/msg	Read/write/execute
Dump	dump	mkdir PEtableData/dump	Read/write/execute
Table (for blob data)	PE Table name	See command in next step	Read/write/execute

2. Create a directory for each Process Engine table using the following sub-steps. You will connect to the target database to generate a shell / command script. You will edit that script file, and then use it to create a directory for each table.
   1. Still logged on as the DB2 instance owner, enter the following at a command prompt:

   db2 connect to target_database

   2. Run the following SQL statement from a command prompt:

   On UNIX:

   db2 "select tabname from syscat.tables where type = 'T' and tabschema='F_SW' " |sed -e "s?^?mkdir PEtableData/?" > crDataDirs.txt

   On Windows:

   db2 "select tabname from syscat.tables where type = 'T' and tabschema='F_SW' " > crDataDirs.txt

   3. Edit the crDataDirs.txt file.
      • On Windows and UNIX -delete any lines that do not have a PE table name
      • On Windows only edit the crDataDirs.txt file - add “mkdir PEtableData\” to the beginning of each line.
   4. On UNIX change the text file to be executable:

   chmod 775 crDataDirs.txt

   5. Run the modified crDataDirs.txt script at the command or shell prompt.

      $ crDataDirs.txt

   6. On UNIX change access right of all directories:

   $ chmod -R 775 PEtableData

3. Get a list of all Process Engine tables to be used to create the DB2 export commands.
1. From the target database server connect to the source database as the instance owner.
2. Using the following command create a list of Process Engine tables.

db2 "select tabname from syscat.tables where type='T' and tabschema='F_SW'" > doPEexports.txt

3. Using the list of tables in the doPEexports.txt file, create the DB2 export commands. The export commands can be run individually or in a script. Create a DB2 export line for every table listed in the doPEexports.txt file. export line to use:

db2 "export to PEtableData/.txt of del lobs to PEtableData/ modified by lobsinfile coldel~ select * from f_sw.tabName"

  For example: for the table VWSYSNUMS:

db2 "export to PEtableData/vwsysnums.txt of del lobs to PEtableData/vwsysnums modified by lobsinfile coldel~ select * from f_sw.vwsysnums"

4. Export the Process Engine tables by running the script or entering the export commands manually. Redirect the output of the export to a text file.

Load the Process Engine data from files to the target database
For every table that was EXPORTED from the source database (based on the prior steps) run the DB2 LOAD command.

1. Log on to the target database as the instance owner and connect to the database.
2. Compose a LOAD command for each EXPORTED table. Replace each set of < > with the appropriate data for that table. Use the following LOAD command syntax

db2 LOAD table_name 

LOAD FROM
"<full path name of the .txt file of the EXPORTED table data>" 
OF DEL
LOBS FROM "<full path name of the blob directory for the EXPORTED table>" 
MODIFIED BY LOBSINFILE CODEPAGE=1208 COLDEL~ ANYORDER USEDEFAULTS CHARDEL"" DELPRIORITYCHAR DUMPFILE="<full path name of dump directory plus table name>"
METHOD P (<list of columns by number>) 
MESSAGES "<full path name of msg directory plus table name >" 
REPLACE INTO "<schema name>"."<table name>" 
( 
<list of each column name, if using double quotes column names must be in upper case, the list must be In the same order as the data columns were exported > 
) 
; 
  
Windows:
Example LOAD command for table VWSYSNUMS: 
--LOAD F_SW:VWSYSNUMS 
LOAD FROM
"C:\PEtableData\vwsysnums.txt" 
OF DEL
LOBS FROM "C:\PEtableData\vwsysnums\" 
MODIFIED BY LOBSINFILE CODEPAGE=1208 COLDEL~ ANYORDER USEDEFAULTS CHARDEL"" DELPRIORITYCHAR DUMPFILE="C:\PEtableData\dump\f_sw_vwsysnums.txt"
METHOD P (1,2,3,4,5,6,7,8) 
MESSAGES "C:\PEtableData\msg\vwsysnums.txt" 
REPLACE INTO "F_SW"."VWSYSNUMS" 
( 
"F_SERVERCONFIG", 
"F_RECNUM", 
"F_NEXTVIEWID", 
"F_NEXTINDEXID", 
"F_DBVERSION", 
"F_STATCONINTERVAL", 
"F_STATSNAPINTERVAL", 
"F_SESSIONTIMEOUT" 
) 
; 
 
UNIX: 
Example LOAD command for table VWSYSNUMS: 
--LOAD F_SW:VWSYSNUMS 
LOAD FROM
"/PEtableData/vwsysnums.txt" 
OF DEL
LOBS FROM "/PEtableData/vwsysnums/" 
MODIFIED BY LOBSINFILE CODEPAGE=1208 COLDEL~ ANYORDER USEDEFAULTS CHARDEL"" DELPRIORITYCHAR DUMPFILE="/PEtableData/dump/f_sw_vwsysnums.txt"
METHOD P (1,2,3,4,5,6,7,8) 
MESSAGES "/PEtableData/msg/vwsysnums.txt" 
REPLACE INTO "F_SW"."VWSYSNUMS" 
( 
"F_SERVERCONFIG", 
"F_RECNUM", 
"F_NEXTVIEWID", 
"F_NEXTINDEXID", 
"F_DBVERSION", 
"F_STATCONINTERVAL", 
"F_STATSNAPINTERVAL", 
"F_SESSIONTIMEOUT" 
) 
; 

 

Compare source and target database tables
Count the number of records in both the source and target database using the following steps on each database.

1. Log on to the database server as the instance owner and connect to the database.
2. Run the following SELECT statement for every table:

db2 “SELECT COUNT(*) FROM SCHEMA_NAME.TABLE_NAME”

where the SCHEMA_NAME.TABLE_NAME parameter is replaced by each SCHEMA_NAME.TABLE_NAME from the doPEexports.txt file.

3. Compare the number of records in the source and target databases for every table and verify they are the same.

Next Step:
Continue with the procedures documented in the Reconfiguring the Process Engine Server to use the new database section - to complete the migration process.

Reconfiguring the Process Engine Server to use the new database
Reconfigure the Process Engine to use the new DB2 database. Use the steps applicable to the version of Process Engine software on the Process Engine server.

Process Engine 4.5.1

1. If not already done, update the DB2 software on the Process Engine server to DB2 v9.7 Fix Pack 4.
2. On the Process Engine server, log on as the target database instance owner
3. Catalog the DB2 target database on the Process Engine server:
1. Catalog a node:

db2 catalog tcpip node nodename remote dbserver server port

2. Catalog the database:

db2 catalog db dbname as unique-db alias at node nodename

where:

nodename is any name you can set for the host that contains the database you want to catalog

dbserver is the hostname or the IP address of the node where the target database resides

port is the port number of the server database manager instance

dbname is the name of the database that will be used by the Process Engine, if an alias is not specified
unique-db alias (optional) is the database alias that can be specified, and will be used by the Process Engine
4. Test the connection.

db2 connect to dbname user db_user_name using password

or

db2 connect to unique-db alias user db_user_name using password

5. Run fn_edit to change the DB2 database alias name to the new target name.
6. On the new Process Engine DB2 target database, drop the VWRDBObject table. It will be recreated with the new information when the Process Engine starts again.

Process Engine 5.0
Reconfigure an existing Process Engine virtual server or create a new Process Engine virtual server that points to the new DB2 database location. At a command prompt:

1. Change to the Process Engine directory.
2. Configuring the Process Engine server with the new database information.
1. Backup the existing ProcessEngineDirectory\data\virtual_server_name\vwserver.ini
2. Copy the ProcessEngineDirectory\data\PEInitV.properties.sample to ProcessEngineDirectory\data\PEInitV.properties if it does not already exist
3. Edit the ProcessEngineDirectory\data\PEInitV.properties with the new database information as shown below:

DBType=DB2 


DBHost=database_host_name 
DBVersion=DB2LUW 
DBPort=database_port 
DBName=new_target_database_name 
DBUserName=database_user_name 
DBpw=database_user_password
4. Run the following command to save the database information in the virtual server directory.

ProcessEngineDirectory\peinit virtual_server_name –V ProcessEngineDirectory\data\peinitV.properties

3. If the default tablespace_names are different in the target database from the source database, these additional steps will have to be run.
1. Copy the ProcessEngineDirectory\data\PEInitD.properties.sample to ProcessEngineDirectory\data\PEInitD.properties if it does not already exist
2. Obtain the CE security information on the target server by running the following command. This command will also implicitly check the connection to the target database. Enter the PEAdministrator username and password when prompted.

ProcessEngineDirectory\peinit virtual_server_name -sc


User name: pwtestadmin
Password:
PEServerMainPort = 32777
PEServerNamingServicePort = 32776
ServiceUser = PEAdmin
CEURL =http://CEServer:9080/wsi/FNCEWS40MTOM/
SysAdminGroup =PEAdminGroup
SysConfigGroup = PEConfigGroup
PEInit finished successfully
3. Edit the ProcessEngineDirectory\data\PEInitD.properties with the new table space information as in the sample shown below

PEServerMainPort=32777 


PEServerNamingServicePort=32776
CEURL =http://CEServer:9080/wsi/FNCEWS40MTOM/ 
ServiceUser=PEAdmin 
ServicePW=password 
SysAdminGroup=PEAdminGroup 
SysConfigGroup=PEConfigGroup 
 
pe_data=VWDATA_TS 
pe_index=VWINDEX_TS 
pe_blob=VWBLOB_TS
4. Set the new tablespace information in the database by running

   ProcessEngineDirectory\peinit virtual_server_name –D ProcessEngineDirectory\data\peinitD.properties –o 

   When prompted enter pe_service_username and pe_service_user_password

4. On the Process Engine collect the same information from the new DB2 database that you did at the beginning of this procedure.
1. From vwtool for each isolated region run the following commands with the hardcopy option set ON – 1) count #, 2) config, 3) queueconfig, rosterconfig and logconfig (include system fields), 4) views.
   
   
2. Compare this new information with the prior information.
   
3. If using the IDMT method - it will be necessary to re-create the PE database views. Follow instructions in Appendix C. Recreate Process Engine database views.
5. Shutdown the Process Engine server.
6. Update the Process Analyzer with the new target PE database. (see Appendix A. )
7. Make a complete cold DB2 database backup of the new PE DB2 database.
8. Remove the Process Engine operating system database user f_sw from the DB2 instance administrative group.
9. Backup new Process Engine configuration files.

Appendix A. Update Process Analyzer
On the Process Analyzer (PA) update PA with the new Process Engine database name and location.
1. Install the DB2 JDBC driver
2. Run the PA Process Task Manager (PTM) tool to update the PA configuration with the new Process Engine DB2 database information.




Appendix B. Shutting down Process Engine server software

1. Stop all Process Engine related services and applications, including Process Analyzer. Ensure that all background processes are stopped.

Important: Do not start up the Process Engine again until this procedure is complete and you are told to start up the Process Engine.

For version 4.5.1, see Stopping all Process Engine-related services and applications (Windows) or Stopping all Process Engine-related services and applications (UNIX)

For version 5.0, see Starting and stopping IBM FileNet P8 Platform components

2. Disable automatic startup of the software. This will ensure that the Process Engine does not start up if the Process Engine server gets rebooted during this procedure.

Process Engine 4.5.1
On Windows:
Set the IMSService service to manual startup
On UNIX:
Follow the instructions in the link:
http://publib.boulder.ibm.com/infocenter/p8docs/v4r5m1/index.jsp


Process Engine 5.0
On Windows:
Set the Process Engine Manager service to manual startup.
On UNIX:
Edit the /etc/inittab file to comment out the following line:
PEMR:2345:wait:/opt/IBM/FileNet/ProcessEngine/runstartpemgr

Appendix C. Recreate Process Engine database views

On the Process Engine server while the Process Engine is started run the vwtool utility to recreate the PE database views. IDMT will not recreate the PE DB views.

From vwtool for each isolated region run either or both of the create database views commands: createDBviews ( used for PA ) or createDBviewsCI ( case insensitive views normally used by a site with BPF). Each command has site specific requirements for the PE DB views. The site DBA and/or PE administrator would know how the PE views are used at each site.

The createDBviews and createDBviewsCI commands have two possible options:
· Choose option ‘v’ of that command to create the views directly in the database.
· Choose option ‘s’ of that command if the site needs to modify the CREATE VIEW statements.