Known issues and limitations for Db2 and Db2 Warehouse

The cpadmin user is not recognized as part of ALL USERS group when connecting through terminal

Applies to: 5.3.1 and later

The cpadmin user is part of the ALL USERS group in Cloud Pak for Data. However, when connecting to the database through the terminal using db2 connect to bigsql user cpadmin, the connection is established but cpadmin is not recognized as part of the ALL USERS group in the session.

Workaround

No workaround is currently available.

Db2 restricted deployment fails upgrade on Power (ppc64le) and Z (s390x) hardware due to missing library file libmklidax.so

Applies to: 5.3.0 and later

The Db2 OLTP restricted deployment (deployed via db2aaservice) fails during upgrade from 5.1.x or 5.2.x to 5.3 on Power (ppc64le) and Z (s390x) hardware due to missing library file libmklidax.so.

Symptoms

During upgrade, the upgrade pod terminates with an error indicating that libmklidax.so cannot be found on s390x/ppc64le platforms.

The following error is observed in upgrade pod logs:

Error: library file libmklidax.so not found for current architecture (s390x/ppc64le)
Upgrade aborted.

Cause

The library file libmklidax.so is missing on Power (ppc64le) and Z (s390x) platforms.

Workaround

After obtaining the upgrade pod errors, continue the remaining upgrade steps manually from the db2u pod.

1. Exec into the db2u pod.

   # Example (adjust namespace/pod name as appropriate):
   kubectl exec -it -n <namespace> <db2u-pod-name> -- bash

2. Open a Python shell and run the remaining upgrade steps:

   python3
   from instance.db2oltp import Db2OLTPRestrictedInstance
   inst = Db2OLTPRestrictedInstance()
   inst.apply_license()
   inst._cleanup_db2image_directory()
   inst._delete_temporary_db2inst1_files()

   Exit the Python session after executing the steps successfully.

3. Continue the upgrade in the db2u pod:

   # Update databases as part of the upgrade
   db2_update_upgrade --databases
   
   # Run post-upgrade tasks
   db2_update_upgrade --post-upgrade

Db2 and Db2 Warehouse OLTP instance fails to start after upgrade with SQL0290N error

Applies to: 5.3.0 and later

After upgrading from Cloud Pak for Data 5.1 or 5.2 to 5.3, Db2 Warehouse or Db2 OLTP instances may fail to start and show SQL0290N error.

Symptoms

Db2 pods continuously restart, and the following errors are observed in pod logs or when attempting to connect manually to the database:

ERROR: SQL0290N Table space access is not allowed. SQLSTATE=55039

Cause

The system temporary tablespace TEMPSPACE1 is missing or corrupted after upgrade due to missing container tags in local-backup folder.

Workaround

1. Access the Db2 container environment:

   oc exec -it <pod_name> -- /bin/bash
   su - db2inst1

2. Drop the bad temporary tablespace:

   db2_all "db2 restart db bludb drop pending tablespaces \(TEMPSPACE1\)"

3. Recreate the system temporary tablespace:

   db2 -tf /db2u/scripts/create_sys_temp_tablespace.sql

4. Clean up the existing local-backup directory:

   rm -rf /mnt/blumeta0/local-backup

5. Create the backup_tempspace script and save it.

   backup_tempspace.sh script:

   #!/bin/sh
   
   # --- Simple Logging Functions ---
   logger_debug() { echo "[DEBUG] $*"; }
   logger_info()  { echo "[INFO]  $*"; }
   logger_error() { echo "[ERROR] $*"; }
   
   # boolean for either smp or mpp
   is_smp=false  # or true depending on your environment
   
   backup_tempspace() {
       local data_dir="/mnt/bludata0/db2/databases/db2inst1"
       logger_debug "Backing up Tempspace..."
       if [[ $(${GLOBAL_SUDO_CMD} ls ${TEMPTSDIR}/${FORMATION_ID}/db2inst1 | grep NODE | wc -l) -eq 0 ]]; then
           logger_debug "Backing up Tempspace skipped: node directory not found in ${TEMPTSDIR}/${FORMATION_ID}/db2inst1"
           return 0
       fi
       tempspace_dirs=$(rah "ls ${TEMPTSDIR}/${FORMATION_ID}/db2inst1" | grep NODE)
       echo -e "Tempspace directories are:\n${tempspace_dirs}"
   
       data_dirs=$(rah "ls ${data_dir}" | grep NODE)
       [[ "$is_smp" == true ]] && data_dirs="NODE0000"
       if [[ "$data_dirs" == "" ]]; then
           logger_error "Backing up Tempspace skipped: failed to list data node dirs"
           return 0
       fi
       echo -e "Node directories are:\n${data_dirs}"
   
       mkdir -p ${LOCAL_BACKUP_DIR}
       ${GLOBAL_SUDO_CMD} chown ${DB2INSTANCE?}:${INST_GROUP?} ${LOCAL_BACKUP_DIR}
   
       # Backup local temp space from all dashdb nodes -- only need directories and small SQLTAG.NAM files.
       # Preserve directory/file ownership and permission.
       local backup_rc=0
       logger_info "Creating checksums for system tempspace"
       ${GLOBAL_SUDO_CMD} find "${TEMPTSDIR}/${FORMATION_ID}/${DB2INSTANCE?}" -type f -exec md5sum {} \+ |logger_info
       logger_info "Backing up Tempspace"
       ${GLOBAL_SUDO_CMD} rsync -rdgop --numeric-ids --checksum --exclude '*TLB' --exclude '*TDA' --exclude '*TBA' ${TEMPTSDIR}/${FORMATION_ID}/db2inst1/NODE* ${LOCAL_BACKUP_DIR} 2>&1 | logger_debug
       backup_rc=${PIPESTATUS[0]}
       ${GLOBAL_SUDO_CMD} chown -R ${DB2INSTANCE?}:${INST_GROUP?} ${LOCAL_BACKUP_DIR}/NODE*
       echo -e "The dir contents of ${LOCAL_BACKUP_DIR} after backup are:\n$(${GLOBAL_SUDO_CMD} find "${LOCAL_BACKUP_DIR}" -type f -exec ls -l {} +)"
       if [[ $backup_rc -eq 0 ]]; then
           logger_info "Backing up Tempspace succeeded"
       else
           logger_error "Backing up Tempspace failed with rc=$backup_rc"
       fi
       return $backup_rc
   }
   
   # --- Run the Function ---
   backup_tempspace

6. Run the tempspace backup script:

   ./backup_tempspace.sh

7. Verify that the backup was successful and that the node directories were created:

   ls -la /mnt/blumeta0/local-backup

8. Exit from the pod and patch the Db2 StatefulSet entrypoint:

   Copy the entrypoint script db2u_root_entrypoint.sh from the pod to your local machine:

   oc cp <pod_name>:/db2u/db2u_root_entrypoint.sh ./db2u_root_entrypoint.sh

9. Edit the script and comment out lines 188–208:

   vi db2u_root_entrypoint.sh

10. Create a configmap using the updated script:

    oc create configmap db2u-root-entrypoint --from-file=db2u_root_entrypoint.sh

11. Find the name of the StatefulSet (for example):

    oc get sts | grep db2wh

12. Patch the StatefulSet to mount the modified script:

    oc patch sts <db2wh-statefulset-name> --type=json -p='[
      {
        "op": "add",
        "path": "/spec/template/spec/volumes/-",
        "value": {
          "name": "db2u-root-entrypoint",
          "configMap": {
            "name": "db2u-root-entrypoint",
            "defaultMode": 509
          }
        }
      },
      {
        "op": "add",
        "path": "/spec/template/spec/containers/0/volumeMounts/-",
        "value": {
          "name": "db2u-root-entrypoint",
          "mountPath": "/db2u/db2u_root_entrypoint.sh",
          "subPath": "db2u_root_entrypoint.sh"
        }
      }
    ]'

    Wait for the Db2 pod to restart automatically.
13. Verify the update and Db2 functionality:
    1. After the pod is ready, verify that the updated entrypoint is applied:

       oc exec -it <pod_name> -- /bin/bash
       cat /db2u/db2u_root_entrypoint.sh

    2. Test the Db2 connection and check the tablespace details:

       db2 connect to bludb
       db2 list db directory
       db2 "list tablespaces show detail"

    The Db2 instance should now start successfully, with TEMPSPACE1 restored and the service status showing as RUNNING.

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 preceding 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.

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.