Limitations and known issues in Db2 Data Management Console

The Database availability widget in the Summary page might not display the correct value for availability percentage. The availability percentage is calculated based on historical data. When the repository database is not available for a certain period, the historical data for that period is lost causing the availability percentage value to deviate. As a workaround, view the database availability alert to understand whether the database is available or not.

Applies to: 4.0.0 and later

unable to find valid certification path to requested

To resolve this issue, upgrade the database instance version 3.5.x to 4.0.1.

Applies to: Upgrading Db2 Data Management Console from the version 3.5.x to 4.0.1 release.

Run SQL statements from the Db2 Data Management Console SQL editor, does not support the Run method option CLP WITH SSH.

Applies to: 4.0.0 and later

Administrators cannot apply Cancel Activities operation against the application that is generated by a db2inst1 user.

Applies to: 4.0.0 and later

User cannot apply a Force Application operation from the console page.

Applies to: 4.0.0 and later

JDBC connection fails when you use the JDBC connect URL in the connection information page.

As a workaround, use JDBC connect URL in the database instance detail page.

Applies to: 4.0.0 and later

RUNSQL does not support a function or an operator as input parameters in the stored procedure.

Applies to: 4.0.3 and later

An error message might be displayed when a user attempts to change the timestamp (Last 'N' hour) for the Responsiveness and Throughput widgets in the Monitor > Summary page. This issue applies to Data Virtualization and Big SQL database connections. As a workaround, refresh the page in a stable network environment.

Applies to: 4.0.0

Fixed in: 4.0.1

After an upgrade, the Db2 Data Management Console load log directory is cleared and cannot be retrieved. To know more about the workaround, see Load logs are cleared after upgrade.

Applies to: 4.0.0 and later

Redis might not start, when all the redis sentinel and server pods are started at the same time. To know more about the workaround, see Redis fails to start.

Applies to: 4.0.0

Fixed in: 4.0.1

Could not get a resource from the pool: ##Could not get a resource from the pool ##

1. Check whether the redis pods are started:

   oc get pods |grep ibm-dmc |grep redis -n {PROJECT}

   For example,

   # oc get pods |grep redis
   
   c-ibm-dmc-1655857923892692-redis-m-0 4/4 Running 0 30m
   
   c-ibm-dmc-1655857923892692-redis-m-1 4/4 Running 0 30m
   
   c-ibm-dmc-1655857923892692-redis-m-2 4/4 Running 0 30m
   
   c-ibm-dmc-1655857923892692-redis-s-0 4/4 Running 0 30m
   
   c-ibm-dmc-1655857923892692-redis-s-1 4/4 Running 0 30m
   
   c-ibm-dmc-1655857923892692-redis-s-2 4/4 Running 0 30m

2. If a redis pod does not exist, run the following command:

   oc patch namespacescope common-service --type='json' -p='[{"op":"replace", "path": "/spec/csvInjector/enable", "value":true}]' -n ibm-common-services

3. Wait for 10 minutes and check whether the redis pods are started.

Applies to: 4.0.0 and later

After reinstalling or reprovisioning Db2 Data Management Console, the event monitors might fail to work correctly as defined in the event monitor profile. To know more about the workaround, see Event monitors might not work correctly after reinstalling the console.

Applies to: 4.0.0

Fixed in: 4.0.1

cloudctl case launch --args "--recursive --inputDir ./" --action installCatalog --case {DMC}.tgz --inventory dmcOperatorSetup --namespace openshift-marketplace --tolerance 1

cloudctl case launch --action installCatalog --case  {DMC}.tgz --inventory dmcOperatorSetup --namespace openshift-marketplace --tolerance 1

Applies to: 4.0.0

Fixed in: 4.0.1

HWCADM0047E: The ddl can not be gotten because binding or precompilation did not complete successfully. For detailed info, please check the error code SQL0001N.tivol

db2 connect to BLUDB
db2 "bind db2look.bnd BLOCKING ALL GRANT PUBLIC sqlerror continue"
db2 "bind db2lkfun.bnd BLOCKING ALL GRANT PUBLIC sqlerror continue"

Applies to: 4.0.0 and 4.0.1

Fixed in: 4.0.2

The ibm-dmc-addon-ui pod cannot be ready because the cluster fails to pull ibm-dmc-addon-ui image. This issue occurs in the following scenarios:

Scenario 1 - Db2 Data Management Console version 4.0.1 is installed but addon CR version 4.0.0 is created.

Scenario 2 - Db2 Data Management Console version 4.0.0 is upgraded to version 4.0.1 but the addon CR still uses version 4.0.0.

Workaround: Update the Db2 Data Management Console addon CR and instance CR to version 4.0.1.

Applies to: 4.0.1

Fixed in: 4.0.2

oc patch -n ibm-common-services sub ibm-dmc-operator --type=merge --patch='{"spec": {"source": "ibm-operator-catalog"}}'

Applies to: 4.0.1

Fixed in: 4.0.2

As a workaround to provision the Db2 Data Management Console service instance (version 4.0.2), download and use the CASE package for Db2 Data Management Console (version 4.0.2).

Applies to: 4.0.3

Fixed in: 4.0.5

Applies to: 4.0.3

Fixed in: 4.0.5

Applies to: 4.0.3 and later

You cannot backup and restore Redis on a different cluster. The Redis pods remain in the crash loop back-off state even after you restore them remotely. As a workaround to successfully back up and restore Redis, delete the Db2 Data Management Console instance and provision it again.

When a resource quota is present in the cluster, Redis fails to start and displays the following error message:

~$ oc get sts -A |grep redis
test-cdo-cedp-repository             c-ibm-dmc-1646304902648951-redis-m   0/2  

c-ibm-dmc-1646304902648951-redis-m sts events:

create Pod c-ibm-dmc-1646304902648951-redis-m-0 in StatefulSet c-ibm-dmc-1646304902648951-redis-m failed error: pods "c-ibm-dmc-1646304902648951-redis-m-0" is forbidden: failed quota: default: must specify limits.memory,requests.memory

1. Get the Redis Statefulset.

   oc get sts |grep redis
   c-ibm-dmc-1646806131101880-redis-m   3/3     45h
   c-ibm-dmc-1646806131101880-redis-s   3/3     45h

2. Edit Redis pods.

   oc edit sts c-ibm-dmc-1646806131101880-redis-m

3. 1. Search for the following code:

      name: init
      resources: {}

   2. Remove the following code:

      resources: {}

   3. Add the following code:

      resources:
        limits:
          cpu: 51m
          memory: 130Mi
        requests:
          cpu: 50m
          memory: 128Mi
      

4. Repeat step 2 and step 3 for the c-ibm-dmc-1646806131101880-redis-s statefulsets.

The CPU and memory of Redis pods do not increase or decrease according to the resource changes in Redis CR.

Fixed in: 4.0.7

When the Db2 Data Management Console is updated to a newer version and if Redis pods are upgraded to the supported version, the upgraded Redis pods continue to use the old Redis images.

oc get redissentinels [YOUR_REDISSENTINELS] -n [YOUR_NAMESPACE] -o yaml |grep updateStrategy
  updateStrategy: RollingUpdate

# oc get pods |grep dmc |grep redis
c-ibm-dmc-1653363006896520-redis-m-0                         4/4     Running     0             21h
c-ibm-dmc-1653363006896520-redis-m-1                         4/4     Running     0             21h
c-ibm-dmc-1653363006896520-redis-m-2                         4/4     Running     0             21h
c-ibm-dmc-1653363006896520-redis-s-0                         4/4     Running     0             20h
c-ibm-dmc-1653363006896520-redis-s-1                         4/4     Running     0             20h
c-ibm-dmc-1653363006896520-redis-s-2                         4/4     Running     0             21h

1. Get the CR name.

   oc get redissentinel

2. Run the following command:

   oc get redissentinels <CR_name> -o yaml > redissentinels.yaml

3. Delete the Redis pods.

   oc delete redissentinels <CR_name>

4. After the Redis pods (sentinel and member pods) are successfully deleted, run the following command:

   oc create -f redissentinels.yaml

Applies to : 4.0.6 and earlier

Fixed in: 4.0.7

1. Enable maintain mode.
   1. Get the CR name.

      oc get dmc -n <namespace>

   2. Edit CR.

      oc edit dmc <dmc cr name>

   3. Append the following code under spec.

      ignoreForMaintenance: true

2. Edit deployments.
   1. Run the following command to get deployments.

      oc get deployment -n <namespace> | grep dmc
      ibm-dmc-****-admin              
      ibm-dmc-****-dbapi             
      ibm-dmc-****-explain            
      ibm-dmc-****-job-scheduler      
      ibm-dmc-****-runsql     

   2. Edit admin, dbapi, explain, job-scheduler, and runsql.
      1. Run the following command:

         oc edit deployment ibm-dmc-****-**** -o yaml -n <namespace>

      2. Search for the following code:

         - mountPath: /opt/ibm-datasrvrmgr/Config/cpd-internal-tls
                     name: cpd-internal-tls

      3. Change the name: cpd-internal-tls to name: <db2type>-internal-tls where <db2type> can be db2oltp, db2wh, dv, or bigsql.
      4. Save and exit.
   3. Wait for the pods to restart.
3. Edit sts.
   1. Run the following command to get sts.

      oc get sts -n <namespace> |grep dmc             
      ibm-dmc-****-monitor                 

   2. Edit monitor.
      1. Run the following command:

         oc edit sts ibm-dmc-****-monitor -o yaml -n <namespace>

      2. Search for the following code in volumeMounts: block.

          - mountPath: /opt/ibm-datasrvrmgr/Config/cpd-internal-tls
                     name: cpd-internal-tls

      3. Change the name: cpd-internal-tls to name: <db2type>-internal-tls where <db2type> can be db2oltp, db2wh, dv, or bigsql.
      4. Save and exit.
   3. Wait for the monitor pods to restart.

Applies to: 4.0.8 and later