Known issues and limitations for Db2 and Db2 Warehouse

The following known issues apply to the Db2 and Db2 Warehouse services.

Db2 users unable to authenticate to the Db2 OLTP database over JDBC

Applies to: 5.2.0 and later

When users try to access the Db2 OLTP database via JDBC, they face authentication failures even when they have the admin access.

You can see the following error:
[jcc][t4][2013][11249][4.33.31] Connection authorization failure occurred.  Reason: User ID or Password invalid. ERRORCODE=-4214, SQLSTATE=28000
Workaround
  1. Select your deployment by running the following command:
    oc -n ${PROJECT_CPD_INST_OPERANDS} exec -it ${db2_podname} -- bash
  2. Switch to the db2inst1 profile:
    su - db2inst1
  3. Unset the value of environment variable DB2_BEDROCK_ROUTE:
    unset DB2_BEDROCK_ROUTE
  4. Stop wolverine:
    sudo sv stop wolverine
  5. Refresh the db2u security plug-in and restart Db2:
    db2stop force && ipclean -a
/bin/bash -c "source /db2u/scripts/include/db2_functions.sh && refresh_db2_sec_plugin"
db2inst1]$ db2start

    You can now connect to your Db2 database as cpadmin.

Audit records with transaction IDs containing special characters are missing

Applies to: 5.2.0 and later

Some audit records might be missing from the IBM Software Hub audit service because the containerized Db2 Audit service is unable to process some randomly generated transaction IDs that contain special characters.

There is currently no workaround available to resolve this issue.

Workaround

Restart Db2 to fix the issue.

DB2OLTP instance is in a failed state

Applies to: 5.0.0 and later

Fixed in: 5.2.1

On the Instances page, you see the db2oltp instance is in a failed state, but the pods and db2ucluster are healthy.

Workaround

Restart Db2 to fix the issue.

Db2 logs using full disk capacity causes Db2 service to be in unusable state

Applies to: 4.8.4 and later

Even when the cluster is idle, the Db2 disk uses the entire disk capacity, which disrupts all cluster operations such as functional tests, backup and restore, and upgrade.

From within the db2u or etcd pod, running df -k shows that the disk utilization of the archivelogs, activelogs and blumeta0 directories are 100% (or close to it).

Workaround

To bring Db2 deployment to active or healthy state, carry out the following steps:

  1. Delete oldest archive logs in /mnt/logs/archive/db2inst1/BLUDB/NODE0000/LOGSTREAM0000/C0000000 manually.
  2. Delete .dump.bin files in DIAGPATH manually.
  3. Deactivate/activate Db2 db.
  4. Prune transaction logs by following the steps in Managing Db2 transaction logs.

After carrying out the above steps, no directories are at 100%, which allows both the db2u and etcd pods to come up and running.

Unable to authenticate connection to service instance

Applies to: 4.8.0 and later

When reinstalling the Db2 service on IBM® Software Hub, an issue can occur while authenticating a connection. This is due to a mismatch of the issuer ID between certificate secrets used by the db2u pod.

You see an error on the zen-database-core pod that is similar to the following output:

" level=error msg="Service instance 'db2oltp-wkc' database ping check failed" func="zen-databases-core/pkg/impl/operator.(Db2Connection).pingDb" file="/go/src/zen-databases-core/pkg/impl/operator/dbConnection.go:72" error="SQLDriverConnect: {08001} [IBM][CLI Driver] 
SQL30081N A communication error has been detected. Communication protocol being used: "SSL". Communication API being used: "SOCKETS". Location where the error was detected: "SOCKETS". 
Communication function detecting the error: "sqlccSSLSocketSetup". Protocol specific error code(s): "414", "", "*". SQLSTATE=08001\n"

Run the following commands to determine if you get the same issue on both certificates:

  • oc get secret internal-tls -o jsonpath='{.data.ca\.crt}' | base64 -d | openssl x509 -noout -dates -issuer -subject
    Refer to the following example output:
    notBefore=Dec 27 09:31:31 2023 GMT
notAfter=Dec 26 09:31:31 2025 GMT
issuer=CN = cs-ca-certificate
subject=CN = cs-ca-certificate
  • oc get secret <dbtype>-internal-tls -o jsonpath='{.data.ca\.crt}' | base64 -d | openssl x509 -noout -dates -issuer -subject
    Refer to the following example output:
    notBefore=Aug 22 14:20:46 2022 GMT
notAfter=Aug 21 14:25:46 2025 GMT
issuer=CN = zen-ca-certificate
subject=CN = zen-ca-certificate
Before you begin
The following procedure uses the variable <dbtype>. Replace <dbtype> with the type of database in your environment. Correct inputs are:
  • db2oltp
  • db2wh
  • db2aaservice
Workaround
  1. Update your certificate secret.
    1. Run the following command to edit your certificate:
      oc edit certificate <dbtype>-internal-tls-certificate
    2. Add test as a new entry under spec.dnsName. Refer to the following example:
      spec:
  commonName: <dbtype>-internal-tls-certificate
  dnsNames:
    'test'
    '*.zen'
    '*.zen.svc'
    '*.zen.svc.cluster.local'
    zen-ca-cert.zen
    3. Run the following command to verify that a new certificate was created:
      oc get certificaterequest | grep db2
      Refer to the following example output:
      <dbtype>-internal-tls-certificate-1 True True zen-tls-issuer system:serviceaccount:ibm-cert-manager:ibm-cert-manager-controller 127m
  2. Run the following command to verify your changes:
    oc get secret <dbtype>-internal-tls -o jsonpath='{.data.ca\.crt}' | base64 -d | openssl x509 -noout -dates -issuer -subject
  3. Restart your db2u pod to confirm that the connection is successful.

    If you are still experiencing issues, contact IBM Support.

Enabling archiveToDb impacts performance

Applies to: 4.7.0 and later

When you enable audit logging and set archiveToDb to true, Db2 audit stores loaded images after the LOAD task is finished. Keeping these images requires a large amount of disk space in the /mnt/bludata0/db2/copy or /mnt/bludata0/scratch/db2/copy paths. AUDIT.* tables display repetitive logs.

Workaround
To resolve the problem, you must disable the archiveToDb parameter if you are enabling db2u audit
  1. Update the db2ucluster CR.
    1. Find your db2ucluster resource name.
      oc get db2ucluster -n ${PROJECT_CPD_INST_OPERANDS}
    2. Update your db2ucluster resource
      oc edit db2ucluster <db2u_cluster_name> -n ${PROJECT_CPD_INST_OPERANDS} -o yaml
    3. Check archiveToDb is set to false, for example:
      spec:
  addOns:
    audit:
      archiveToDb: false
  2. Update the Audit setups and stored procedure inside the container.
    1. Select your deployment by running the following command.
      oc -n ${PROJECT_CPD_INST_OPERANDS} exec -it ${db2_podname} -- bash
    2. Switch to the db2inst1 profile.
      su - db2inst1
    3. Update Audit setup with --archive-to-db, for example:
      python3 /db2u/script/installaudit.py --archive-to-db false

Issues when creating a Db2 connection with IBM Software Hub 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 IBM Software Hub credentials in the User name and Password fields, and do not check the Cloud Pak for Data authentication box.