Known issues for Db2 and Db2 Warehouse

The following limitations and known issues apply to database services.

DB2_WORKLOAD is not set when upgrading Db2 Warehouse instance from 3.0.`x` to 3.5.3 or 3.5.4

When you upgrade the Db2® Warehouse from Version 3.0.x to 3.5.3 or 3.5.4, the DB2_WORKLOAD registry variable is not set. This variable configures your database for analytic workloads. This issue occurs during a Helm-to-operator upgrade and is not an issue when performing an operator-to-operator upgrade.

Workaround:

Perform these steps before you do the Helm-to-operator upgrade:

Edit the ConfigMap to add the value ANALYTICS FOR the DBWORKLOAD variable:
```
oc edit cm db2wh-identifier-db2u-config
```
Where identifier is the service identifier for Db2 Warehouse on Cloud Pak for Data.
Change the line DBWORKLOAD "" to DBWORKLOAD "ANALYTICS".
After upgrading the service, verify that DB2_WORKLOAD is set correctly:
```
oc rsh c-db2wh-identifier-db2u-0
    su - db2inst1
    db2set -all | grep DB2_WORKLOAD
```
You should see DB2_WORKLOAD=ANALYTICS.

Issues when creating a Db2 connection with Cloud Pak for Data credentials

When you create a Db2 connection in the web console, an error can occur if you check the Cloud Pak for Data authentication box. To work around this issue, enter your Cloud Pak for Data credentials in the User name and Password fields, and do not check the Cloud Pak for Data authentication box.

Group lookup fails in non-connect scenarios

When you query Db2 to find out which groups a user ID belongs to, the group information is not returned correctly for user IDs that are different than your own. For example, the following query would not return the groups that the ID "WILLIE" belongs to unless the ID "WILLIE" was used to connect to the database and submit the query:

SELECT * FROM TABLE (SYSPROC.AUTH_LIST_GROUPS_FOR_AUTHID('WILLIE')) AS T

Granting of privileges requires specifying the type of the authorization name

When you are granting privileges on Db2, you must specify the type of the user to whom you are granting the privileges, either "user," "role", or "group". The following statement fails:

DB2 GRANT SELECT ON TABLE TEST TO NELSON

If you add the user role, the statement succeeds:

DB2 GRANT SELECT ON TABLE TEST TO USER NELSON

Additional privileges required to enable force application command

A Db2 or Db2 Warehouse user with the DBADM authority that is automatically granted when you create a database cannot run the force application command on Cloud Pak for Data 3.5.0 without manually adding additional privileges.

To run the command, you must add execute privileges on the SYSPROC.ADMIN_CMD stored procedure, and you must have SYSADM, SYSCTRL, or SYSMAINT authority.

Db2 Warehouse MPP pod not redeployed after node shutdown

When you shut down a Red Hat® OpenShift® node on which Db2 Warehouse MPP is deployed and when at least one other node is available in the cluster, the Db2 pod is not redeployed on the available node after 5 minutes. The pod state displays as Unknown. Normally, the pod should be redeployed automatically on an available node in the cluster within 5 minutes.

As a workaround, you can delete the node from your cluster or force delete the pod that is in Unknown state rather than shutting it down and this action should prompt an automatic redeployment.