Installing a Db2 instance for Data Gate on Cloud Pak for Data

You must install, provision, and configure a Db2 or Db2 Warehouse instance on Cloud Pak for Data for each Data Gate instance.

About this task

A Data Gate instance requires either a Db2 or Db2 Warehouse instance depending on the type of target database that you select when creating a Data Gate instance.

If you plan on using Data Gate for transactional workloads, install and configure Db2 as described in Installing Db2.
Important: After installing the basic Db2 service (Community Edition license), you must upgrade to Db2 Advanced Enterprise Server Edition.
1. Follow the instructions in:
  1. Upgrading the Db2 license after installing
  2. Upgrading the license for a deployed Db2 service
2. Scale up CPU and memory by following the steps in Scale up Db2.
If you plan on using Data Gate for analytical workloads, install and configure Db2 Warehouse as described in Installing Db2 Warehouse.

In either case, the following requirements and recommendations should be followed during Db2 installation and configuration to ensure correct operation and optimal performance of Data Gate:

Procedure

Recommended: For the best Data Gate performance, create a Db2 or Db2 Warehouse service instance on a dedicated node with its own dedicated storage.
Always aim for a low synchronization latency and a high load throughput.
For more information, see:
Recommended: For the best Data Gate performance, after the Db2 or Db2 Warehouse instance is created, consider increasing the total size of the Db2 or Db2 Warehouse log file. Otherwise, the loading of tables might fail because the log file is too small.
- For test and development systems, consider increasing the total size to about 3 GB by setting the value of the logfilsiz parameter to 50000 and the value of the logprimary parameter to 15.
- For production systems, your Db2 administrator should adjust the settings based on the system capacity.
- Change the persistent logfilsiz and logprimary settings by modifying the configuration values in the Db2uCluster or Db2uInstance custom resource (CR) that controls the settings of the Db2 or Db2 Warehouse target database instance.
  Important: The Db2uCluster custom resource is deprecated and will be removed in a future release. The following example illustrates the configuration flow for the Db2uInstance CR. For further information about changing Db2 target database configurations, see Deploying Db2 using a custom resource for Db2 and Changing Db2 Warehouse configuration settings for Db2 Warehouse.
  1. Determine the Db2uInstance CR name of your target database instance and edit it. Replace ${PROJECT_CPD_INST_OPERANDS} with your project name in the following sample command. Run the command:
```
oc get db2uinstance -n ${PROJECT_CPD_INST_OPERANDS}
DB2UINSTANCE_ID=<db2uinstance_cr_name>
oc edit db2uinstance ${DB2UINSTANCE_ID} -n ${PROJECT_CPD_INST_OPERANDS}
```
  2. The database configuration (YAML file) is now in edit mode. Database configuration parameters are added under spec.environment.databases[].dbConfig. Navigate to this section and add or change the logfilsiz and logprimary values as shown in the following example:
```
spec:
  environment:
    databases:
      - name: BLUDB
        dbConfig:
          LOGPRIMARY: "15"    
          LOGFILSIZ: "50000"
```
  3. Save and exit the YAML file. Changing the configuration values in the Db2uCluster or Db2uInstance CR can avoid losing your logfilsiz and logprimary settings after an upgrade.
  4. The dbConfig changes of the Db2ucluster or Db2uInstance CR will be detected and applied automatically. You can monitor pod logs to verify that the configurations are applied successfully. Run the command:
```
oc logs c-${DB2UINSTANCE_ID}-db2u-0 -n ${PROJECT_CPD_INST_OPERANDS}
```
For more information, see:
- Db2 logfilsiz - Size of log files configuration parameter
- Db2 logprimary - Number of primary log files configuration parameter
Recommended: To further optimize the performance after the creation of the Db2 instance, consider increasing the values of the locklist and maxlock parameters. This is to avoid that too many row locks are replaced with a lock of the entire table while tables are being synchronized (a process called lock escalation).
- For test and development systems, keep the default value Automatic.
- For production systems, change the value of the locklist parameter to 500000 and the value of the maxlocks parameter to 13.
For more information, see:
- locklist - Maximum storage for lock list configuration parameter
- maxlocks - Maximum percent of lock list before escalation configuration parameter
Recommended: To minimize the impact of operational disruptions caused by upgrades, consider a high-availability setup. Such a setup requires an additional Db2 or Db2 Warehouse instance.
For more information, see:
- High availability
- High Availability and Disaster Recovery with IBM Data Gate for z/OS