Connecting the master domain manager to a new database when using pools

Connecting the master domain manager to a new database involves reconfiguring the system to recognize and interact with the new database. This process typically includes updating connection strings, ensuring database drivers are compatible, migrating relevant data, and validating connectivity. This ensures the master domain manager can continue to perform its tasks without interruption, leveraging the new database resources and capabilities.

This section applies to IBM Workload Scheduler master domain managers and their backups. It documents how to connect the master domain manager and backup master domain manager to a new database.

Note: This cloning procedure does not clone the following information from the source environment:

The preproduction plan
The history of job runs and job statistics
The audit records
The state of running event rule instances. This means that any complex event rules, where part of the rule has been satisfied prior to cloning of the environment, are generated as new rules after the cloning procedure. Even if the subsequent conditions of the event rule are satisfied, the record that the first part of the rule was satisfied is no longer available, so the rule will never be completely satisfied.

Follow this procedure to export data from your previous database, import it to a new one, and connect the master domain manager and backup master domain manager to the new database. This procedure involves your existing master domain manager, MASTER_1, and a new one, MASTER_TMP, which is installed solely to perform the initial configuration of the new database, ensuring it is properly set up before data import.

Install the new database.
Install a new master domain manager, named MASTER_TMP. This master domain manager is installed only to perform the initial configuration of the new database, ensuring it is properly set up before importing data.
Run the configureDb command to create the new database on the new target RDBMS. For more information, see Database configuration - configureDb script.
On MASTER_1, extract all scheduling object definitions and global options from the previous RDBMS running the dataexport command.
```
dataexport source_dir export_dir
```
where:

source_dir

Is the TWS_HOME directory of IBM Workload Scheduler.

export_dir

Is the directory where the export files are created.

For example:
```
dataexport.cmd F:\IWS1024\twsDBuser F:\IWS1024\export
```
For more information, see dataexport.
Verify that the following files were created in export_dir:
- acls.def
- calendars.def
- erules.def
- folders.def
- globalOpts.def
- jobs.def
  Note: The record length supported by DB2® is 4095 bytes, but it decreases to 4000 bytes with Oracle. When you migrate your job definitions to Oracle, any job with task string (scripts or commands) exceeding 4000 bytes in length are not migrated. In this case, the data import utility replaces the job definition with a dummy job definition and sets the job priority to 0, guaranteeing that successors are not run.
- parms.def
- prompts.def
- rcgroups.def
- resources.def
- scheds.def
- sdoms.def
- srols.def
- topology.def
- users.def (includes encrypted user passwords)
- vartables.def
On MASTER_1, run exportserverdata to export dynamic domain manager data from the database. This command is not documented because it is an internal command. The command is located in /opt/IBM/TWA/TDWB/bin/. For the purpose of this procedure, use the following syntax:
```
./exportserverdata.sh -dbUsr username -dbPwd password 
[-exportFile exportFile] 
```
where:

dbUsr

Is the database user. This parameter is required.

dbPwd

Is the database user password. This parameter is required.

-exportFile

Is the file name to which the server data is to be exported from the database. This parameter is required if you use a file different from the default server.properties file, located in the same path as the exportserverdata command. If you use a file other than server.properties, specify the name and path of the file.
On MASTER_1, relocate the definitions of the specified components from file topology.def to a newly created file named topology_env.def, placing it in a different folder.
- MASTER_1 (modify type from MANAGER to FTA)
- MASTER_1_1
- MASTER_2
- MASTER_2_1
- SERVER_XA
Agent definitions remain in the original topology.def file.
On MASTER_TMP, run the addserverdata command. The command is located in /opt/IBM/TWA/TDWB/bin/. This command is not documented because it is an internal command. For the purpose of this procedure, use the following syntax:
```
./addserverdata.sh -dbUsr <ORACLE_user> -dbPwd <ORACLE_password> 
-importFile <file_created_by_exportserverdata>
```
On MASTER_TMP, import the master domain manager definition, using the following command:
```
composer replace topology_env.def
```
Modify the definitions of MASTER_1 to MANAGER and MASTER_TMP to FTA.
On MASTER_1, set the fence to HIGH, by running the following command:
```
conman fence @ HI noask
```
Stop WebSphere Application Server Liberty on both MASTER_1 and MASTER_2 (MASTER_2 is the backup master domain manager).
Reconfigure the master domain manager and backup master domain manager by performing the following changes:
1. Edit the WebSphere Application Server Liberty datasource.xml file, so that it points to the new RDBMS. For more information, see Changing the properties for the database.
2. In the TWA_DATA_DIR/usr/servers/engineServer/resources/properties/TWSConfig.properties file, uncomment the com.ibm.tws.dao.rdbms.rdbmsName line and specify the name of your RDBMS. For more information, see Changing the properties for the database.
3. In the TWA_DATA_DIR/broker/config/DAOCommon.properties file, change the com.ibm.tdwb.dao.rdbms.rdbmsName line to specify the name of your RDBMS.
4. In the TWA_DATA_DIR/broker/config/CLIConfig.properties file, change the following strings:
  
  com.ibm.tdwb.dao.rdbms.rdbmsName
  
  to specify the name of your RDBMS.
  
  com.ibm.tdwb.dao.rdbms.jdbcPath
  
  to specify the path to your JDBC connection string.
  
  com.ibm.tdwb.dao.rdbms.jdbcDriver
  
  to specify the name of the class implementing your JDBC driver.
5. In the TWA_DATA_DIR/usr/servers/engineServer/jvm.options file, specify the path to the database drivers.
6. In the TWA_home/TDWB/bin/tdwb_env.sh file, specify the path to the database drivers.
On On MASTER_2, run addserverdata to add dynamic domain manager data in the database. The command is located in /opt/IBM/TWA/TDWB/bin/. This command is not documented because it is an internal command. For the purpose of this procedure, use the following syntax:
```
./addserverdata.sh -dbUsr username -dbPwd password 
-importFile importFile {[-MDM true]}
```
where:

dbUsr

Is the database user. This parameter is required.

dbPwd

Is the database user password. This parameter is required.

-importFile

Is the file name from which the server data is to be imported into the database. This parameter is required if you use a file different from the default server.properties file, located in the same path as the addserverdata command. If you use a file other than server.properties, specify the name and path of the file.

MDM

Specifies whether the workstation where you run the command is the master domain manager. This parameter is required on the master domain manager and is optional on the dynamic domain manager.
On MASTER_1 restart WebSphere Application Server Liberty on the master domain manager.
On MASTER_1, reload the shell session for the changes to take effect and check that the environment is working correctly by running the following commands:
```
optman ls
composer display cpu=MDM_name
```
Remove the workstation definitions for SERVER_TMP and SERVER_TMP_1.
On MASTER_1, run the dataimport command to import data from your previous RBDMS.
```
dataimport.cmd F:\IWS1024\twsDBuser F:\IWS1024\export
```
where:

source_dir

is the TWS_HOME directory of the source environment instance of IBM® Workload Scheduler, which corresponds to installation_dir/TWS.

export_dir

is the directory where you copied the object definitions and the global options retrieved from the source environment.

For more information, see dataimport.
Restart MASTER_2.
On MASTER_1, set the fence to 0, as follows:
```
conman fence @ 0 noask
```
Run the following command to align the plan with the information inserted in the database:
```
Jnextplan -for 0000 -noremove 
```
Run the following command to extend the plan by 24 hours:
```
JnextPlan -to startOfDay tz your_timezone -noremove
```
For more information about Jnextplan, see JnextPlan.
The master domain manager and backup master domain manager are now configured to connect to the new database and your environment is up and running. Your pools are migrated to the new database.
If you need to connect the Dynamic Workload Console to a new database, see Connecting the Dynamic Workload Console to a new node or database.