Known issues and limitations for Data Virtualization

The following known issues and limitations apply to Data Virtualization.

For additional solutions to problems that you might encounter with Data Virtualization, see the troubleshooting topic Troubleshooting the Data Virtualization service.

General issues
The following general issue impacts Data Virtualization users.
Audit issues
The following issues and limitations apply to audit issues in Data Virtualization.
Data source and connection issues and limitations
Installation and upgrade issues
The following issue applies to installing and upgrading Data Virtualization. For more information, see Installing Data Virtualization and Upgrading Data Virtualization.
Data virtualization issues
The following issues and limitations apply to virtualization in Data Virtualization.
User and group management issues
The following issues and limitations apply to user and group management in Data Virtualization. For more information about user and group management, see Virtualizing data.
Data governance issues
The following issues and limitations apply to data governance in Data Virtualization.
Caching issues
The following issues and limitations apply to caching in Data Virtualization.
File issues
The following issues and limitations apply to files in Data Virtualization.

General issues

Users cannot log out from the Data virtualization interface

Applies to: 5.1.0 and later

Users cannot lot out from Data Virtualization by using the Data virtualization UI.

Workaround: Leave the Data virtualization UI and go to another UI page, such as the Home page or the Projects page, and then logout.

Audit issues

Audit log entries might not be forwarded to the zen-audit service

Applies to: 5.1.0

You might lose log entries when the log-streaming pod crashes or the audit log PVC is experiencing issues, resulting in logs not being forwarded to the zen-audit service.
Audit log records might display incomplete information

Applies to: 5.1.0

An audit log record might display only a portion of attributes such as timestamp, action user ID, and etc., when unprintable characters occur in the audit record.

SQL statement text is not logged

Applies to: 5.1.0

SQL statement text is not logged for events that are related to SQL executions within the CONTEXT and EXECUTE categories.

Data source and connection issues

For information about limitations and known issues that apply to data sources and connections, see Limitations and known issues for data sources in Data Virtualization.

Data virtualization issues

The virtualization status might be stuck in the Virtualize data page even after virtualization is complete

Applies to: 5.1.0 and later

When you navigate to the Virtualize page and then virtualize an object in the Files tab, the virtualization status for that object on the Virtualized data page might be stuck in Started even after the process completes.

Workaround: Refresh the Virtualized data page.

Data Virtualization jobs that start at 1PM UTC fail

Applies to: 5.1.2

Data Virtualization jobs that start at 1PM UTC fail because the Db2 database restarts at that time in the Data Virtualization head pod.
To resolve this issue, see Data Virtualization jobs that start at 1PM UTC fail.
Previewing Cloud Object Storage (COS) data might cause a "This flat file is invalid" error

Applies to: 5.1.0

When you navigate to the Virtualize page and then select Files to preview COS data, you might encounter this error: This flat file is invalid. Try refreshing or remove the flat file before continuing. This error occurs when a database connection becomes inactive for an extended time without COS connectivity, which causes the database connection to time out and terminate.

Workaround: Activate the database connection by navigating to the Virtualize page and then virtualizing COS assets.

Some protected objects might intermittently not display a lock icon in the web client

Applies to: 5.1.0

You might intermittently encounter an error message indicating that some protected objects and their columns might not display a lock icon even though they are protected. If you view the details of the error message, you might see an error message similar to the following example:
{"error_message":"Post \"https://<CPD_URL>/v3/enforcement/policies/evaluate/Access/resource?is_atomic_batch=false\": context deadline exceeded (Client.Timeout exceeded while awaiting headers)","method":"POST","url":"https://<CPD_URL>/v3/enforcement/policies/evaluate/Access/resource?is_atomic_batch=false"}
This error is caused by the web client timing out as it performs an evaluation against data protection rules.
Workaround: There is no dedicated workaround, although refreshing the page might help with the display of the icons if the response is received fast enough by the web client. Your data remains protected by the data protection rules.
Recreating virtualized tables after using the DROP NICKNAME SQL statement results in object already exists error

Applies to: 5.1.0

When you use the DROP NICKNAME SQL statement to drop tables that have a defined nickname, attempting to recreate and virtualize the tables in the Review cart and virtualize tables page results in an Object already exists error.
Workaround: Use the delete API to remove all the data that is associated with the virtualized tables, then attempt to virtualize the table again using the same nickname. The delete API does not indicate whether it ran successfully, and you may encounter an error. Regardless, you should attempt to virtualize the tables again. To use the delete API, you will need to get an authorization token. For more information, see Delete virtualized data and Get authorization token.
Data that is virtualized with double-byte coded character sets and special characters might appear truncated

Applies to: 5.1.0

When you virtualize a table with a double-byte coded character set and special characters, such as Swedish characters, data might appear to be cut off.

Workaround: When virtualizing a table, use the Edit columns menu to extend the field lengths for those columns.

You cannot use special characters such as semicolons in schema names when you virtualize a table in MongoDB on Cloud

Applies to: 5.1.0

When you virtualize a table in a MongoDB on Cloud data source that has a semicolon in the schema name, you will not be able to virtualize the table. The MongoDB on Cloud data source removes the semicolon from the schema name and queries of this virtual table fail with error SQL5105N.

Virtualizing large tables might be slow or might fail

Applies to: 5.1.0

Resolved in: 5.1.2

When you virtualize multiple large tables from data sources, you might see the following messages in the Virtualize objects dialog box. 
Error: CREATE OR REPLACE NICKNAME -- DB2 SQL Error: SQLCODE=-1229, SQLSTATE=40504, SQLERRMC=null, DRIVER=4.29.24
Or
Error: CREATE OR REPLACE NICKNAME -- "<schema>"."<table>" already exists in Server "<server>" (use REPLACE=Y to overwrite)
Or
The table <schema>.<table> already exists. Use REPLACE=Y to overwrite CallStack

This issue occurs even when you do not have tables with the same schema name and table name. The root cause is a timeout and retry sequence that is triggered by HAProxy timeouts. To work around this issue, ensure that your HAProxy settings meet the recommend values. For more information, see Configuring network requirements for Data Virtualization and Changing load balancer timeout settings. If virtualization of large files takes longer than 5 minutes, increase the HAProxy settings and retry the virtualization.

Virtualizing a table with many columns or long column names might fail

Applies to: 5.1.0

Virtualizing some tables in Data Virtualization might fail with a Virtual table creation failed message. Some tables contain columns with large STRING and CLOB data. Virtualizing the table by reducing the column width or even choosing just one of the columns fails with an error message.

Workaround:
  1. Set the remote schema filter to a schema where the large table does not exist so that it does not get cached.
  2. Create the virtual table with a direct CREATE OR REPLACE NICKNAME statement that includes the SOURCELIST definition option as shown in the following example. The SOURCELIST value describes the remote location of the table to be virtualized in the format <CID>:<RemoteSchema>. The CID is the connection ID for the source and can be found in source details of the Data sources page, or in the result of select * from dvsys.listrdbc query.
    /* IBM_DVSYS */ CREATE OR REPLACE NICKNAME "ADMIN"."VERY_LARGE_TABLE" for QPLEX.gaiandb."VERY_LARGE_TABLE"
    ( 
        VERY_LONG_COLUMN_IDENTIFIER1,
        VERY_LONG_COLUMN_IDENTIFIER2,
        VERY_LONG_COLUMN_IDENTIFIER3,
        ...
        VERY_LONG_COLUMN_IDENTIFIER999,
        VERY_LONG_COLUMN_IDENTIFIER1000
) OPTIONS(SOURCELIST 'DB210000:DRV');
    An example of an SQL command to create a large virtual table.
  3. Query individual columns of the large virtual table.

    An example of an SQL statement to query a large table.

  4. Run aggregations and most other queries.
    Note:

    You cannot select all columns for the large table with a SELECT * statement. You see an error message that is similar to the following message.

    SQL5105N  The statement failed because a Big SQL component encountered an 
error.  Component receiving the error: "DV-FMP".  Component returning the 
error: "Virtualization Connector".  Log entry identifier: "GAI-001-NA".  
Reason: "".  SQLSTATE=58040
Preview of tables to be virtualized might not be correct when the table contains a column that is named id

Applies to: 5.1.0

If you try to virtualize a table that contains a column that is named id, preview shows only the column value of the first row in the table. This issue occurs because the keyword id is reserved for the user interface that displays the table.

In addition, if a table contains a column that is named id and the column contains identical values in the id column, these rows display only the values of the first row for each row that has the same value for the id column.

For example, see the following table.
id a2 a3
1 C1-sjis-ok A0_*&
1 abc 123
This table appears as follows because the second row is replaced with the data from the first row.
id a2 a3
1 C1-sjis-ok A0_*&
1 C1-sjis-ok A0_*&

Workaround: Rename the column of the table to a unique name that is not id. If you cannot rename the column name, you must ensure that values in the column are unique.

Installation and upgrade issues

Pre-backup phase fails when upgrading Data Virtualization from IBM Cloud Pak® for Data 4.8.x to 5.1.2
Applies to: 5.1.2
When you attempt to upgrade your Data Virtualization instance, the liveness probe fails with the error ERROR DV liveness probe failed during the liveness check. After this, the upgrade aborts and the pods restart with the message INFO Pod is still starting. Exit right away with state 0.
Workaround: Your Data Virtualization instance upgrade fails, and the pods restart. Once the pods restart, complete these workaround steps.
  1. Run this command. Replace <DV_instance_namespace> with the Data Virtualization instance namespace that is encountering this issue.
    Note: This workaround can only be applied to one Data Virtualization instance at a time. If you have multiple instances, ensure you switch to the namespace that encounters this issue before you proceed to the next steps.
    oc project <DV_instance_namespace>
  2. Check that the pods fully restarted:
    oc exec c-db2u-dv-db2u-0 -- /bin/sh -c 'ls -l /tmp/.dv_setup_complete'
    If the file doesn't exist, then the pods haven't finished restarting.
  3. Create a SKIP_UPGRADE_HURRICANE_RESTART marker to skip the step that is problematic: 
    oc exec c-db2u-dv-db2u-0 -- db2uctl marker create SKIP_UPGRADE_HURRICANE_RESTART
  4. Run the liveness probe manually: 
    oc exec -it c-db2u-dv-db2u-0 -- su - db2inst1 -c "/opt/dv/current/run_time/liveness.sh"
    Note: Ensure that this command runs successfully before you proceed to the next step.
  5. Create the /tmp/liveness.status files that the Data Virtualization instance upgrade needs during pre-check:
    oc -n zen exec -it c-db2u-dv-db2u-0 -- bash -c "echo 0 > /tmp/liveness.status"
  6. Re-run the Data Virtualization instance upgrade.
Data Virtualization instance is unavailable and the web client is disabled after you upgrade from IBM Cloud Pak for Data 4.8.8 to IBM Software Hub 5.1.1
Applies to: 5.1.1
Diagnosing the problem:
Check that you are experiencing this issue by completing these steps.
  1. Run the following command: 
    oc get bigsql db2u-dv
  2. In the Service instances page, hover over the Data Virtualization instance and you should see this message:
    The service instance is unavailable because of an error.
To check that the web client is disabled, open Data Virtualization and you should see this message: 
No available Data Virtualization instances
Cause:

Upgrading Data Virtualization from IBM Cloud Pak for Data version 4.8.8 to IBM Software Hub 5.1.1 is not supported. For more information, see Upgrading from IBM Cloud Pak for Data Version 4.8 to IBM Software Hub Version 5.1.

Resolving the problem:
  • If you attempted to upgrade the Data Virtualization service and did not upgrade the instance, then you need to re-enable the Data Virtualization web client. The instances are still working properly.
  • If you attempted to upgrade the Data Virtualization service and the instance, the Db2u operator blocks the upgrade. You must check that the Db2u operator blocked the upgrade, then revert the IBM Cloud Pak for Data instance version back to 4.8.8, and re-enable the Data Virtualization web client.

    Check that the Db2u operator blocked the upgrade
    Complete these steps to check that the Db2u operator blocked the upgrade.
    1. Run this command to check the Db2u operator logs:
      oc logs -n ${CPD_OPERATOR_NAMESPACE} -l control-plane=db2u-operator-manager
    2. In the log, you should see this message confirming that the Db2u operator blocked the upgrade: 
      Upgrading the BigSQL CR from 2.2.8 to 3.1.0 is not supported
    Set the Data Virtualization instance version back to 2.2.8
    To set the version of each Data Virtualization instance back to 2.2.8, run this command: 
    oc patch bigsql db2u-dv --type=merge -p '{"spec":{"version":"2.2.8"}}'
    Re-enable the Data Virtualization web client
    Complete these steps to upgrade the Data Virtualization instance version to match the newly upgraded service version.
    1. Get a list of all the ConfigMaps (one for each Data Virtualization instance) by running these commands:
      oc get cm -n ${CONTROL_PLANE_NAMEPSACE} | grep dv-data-virtualization
      oc get cm -n ${CONTROL_PLANE_NAMEPSACE} | grep dv-watson-query
    2. For each ConfigMap name, complete the steps:
      1. Run this command. Replace <Configmap_name_from_step_1> with the name of each ConfigMap.
        oc edit cm -n ${CONTROL_PLANE_NAMEPSACE} <Configmap_name_from_step_1>
      2. In the metadata fields addon_version and icpdata_addon_version, change 2.2.8 to 3.1.0.
Because Db2 is stuck, unable to complete provisioning a Data Virtualization instance or the instance is not running correctly

Applies to: 5.1.0

Note: This problem applies only to IBM Software Hub installed on an x86_64 cluster that is running on the AMD EPYC processor family 23, 25, or 27.
Diagnosing the problem
Check if the Data Virtualization instance is running on one of the affected AMD EPYC processors by doing the following steps:
  1. Log in to the Data Virtualization head pod:
    oc rsh c-db2u-dv-db2u-0 bash
  2. Switch to the db2inst1 user:
    su - db2inst1
  3. Check if the instance is running on an AMD EPYC processor:
    cat /proc/cpuinfo  | grep "AMD EPYC"

    If no output is returned, then the instance is not running on an AMD EPYC processor.

    Example output if the instance is running on an AMD EPYC processor:
    "model name	: AMD EPYC-Rome Processor"
  4. If the previous step returned output, check the AMD EPYC processor family:
    cat /proc/cpuinfo | grep "cpu family"
    Example output:
    "cpu family	: 23"
Resolving the problem
If the output of the previous command is 23, 25, or 27, then do the following steps in each c-db2u-dv-db2u-n pod:
  1. Log in to the c-db2u-dv-db2u-n pod.

    In the following command, replace n with 0, 1, and so on, depending on the number of worker pods that were created when the instance was provisioned.

    oc rsh c-db2u-dv-db2u-n bash
  2. Switch to the db2inst1 user:
    su - db2inst1
  3. Apply the fix to the GSKIT library.
    echo 'export ICC_SHIFT=3' >> ~/.profile
echo 'ICC_SHIFT=3' >> /opt/ibm/db2/V12.1.0.0/lib64/gskit_db2/C/icc/icclib/ICCSIG.txt
echo 'ICC_SHIFT=3' >> /opt/ibm/db2/V12.1.0.0/lib64/gskit_db2/N/icc/icclib/ICCSIG.txt
  4. Edit the ~/ibm/bigsql/userprofile file:
    vi ~/ibm/bigsql/userprofile
  5. Before the line export DB2ENVLIST, add the following 2 lines:
    export ICC_SHIFT
DB2ENVLIST="${DB2ENVLIST} ICC_SHIFT"
  6. Save and close the file.
  7. Restart Data Virtualization:
    bigsql stop
bigsql start
Upgrading existing Cloud data source connections to Data Virtualization on Cloud Pak for Data version 5.1.0 causes certificate errors

Applies to: 5.1.0

When you upgrade an existing Cloud data source connection to Data Virtualization on Cloud Pak for Data version 5.1.0, you might encounter this error stating that the certificate cannot be found:
... Reason: /opt/ibm/db2/V11.5.0.0/java/jdk64/jre/lib/security/cacerts (No such file or directory)
In releases prior to version 5.1.0, certificates that were required to connect to an external data source were stored in the default Java trust store. In version 5.1.0, additional security requirements (including FIPS support) require certificates to be stored in trust stores specific to each data source connection. As a result, when you upgrade to version 5.1.0, existing connections might continue to point to the old Java trust store instead of the required trust store for each data source.

Workaround: To workaround this issue, complete these steps.
  1. Run this stored procedure to recreate all the connections using the newly updated connection information.
    call DVSYS.RESTORECONFIG('',?,?)
    Ensure that all the connections (CID) are listed as AVAILABLE on the web client. If this does not fix the problem, or there remains UNAVAILABLE connections, then proceed to the next step.
  2. Conditional step: If the previous step did not fix the problem, then complete this conditional step in the RunSQL console.
    1. Run this query to retrieve the CID of all UNAVAILABLE connections.
      select CID from DVSYS.listrdbc where cstatus='UNAVAILABLE';
      Take a note of the CID for the next step.
    2. Run this query to retrieve the CCID, USR and PWD. Replace <CID> with the CID from the previous step.
      Note: You must repeat these steps for each UNAVAILABLE connection.
      select * from  dvsys.connection_details where cid='<CID>'"
      For example: 
      select * from  dvsys.connection_details where cid='DB210000'"
      If the connection uses vaulted credentials, the output displays the user and password masked using the string {SECRET_REF}.
    3. Run the following setRdbcX stored procedure. Ensure you replace <SRC_TYPE>, <HOST_NAME>, <DATABASE_PORT>,<DATABASE_NAME>, <USR>, <PWD>, <USE_SSL> and <CCID> values from the connection_details table, and the associated <NODE_NAME> and <CID> values from the first step.

      You must also add additional options including EDITCID and CCID in <ADDITIONAL_OPTIONS>. See the following example.

      Note: If the connection does not use vaulted credentials, then you must explicitly replace <USR> and <PWD> with the correct user and password. This requires a user with the Data Virtualization Admin role. 
      call DVSYS.setRdbcX('<SRC_TYPE>','<HOST_NAME>','<DATABASE_PORT>','<DATABASE_NAME>','','<USR>','<PWD>','<USE_SSL>','<VALIDATE_CERT>','','','<NODE_NAME>','<ADDITIONAL_OPTIONS>',?,?,?);
      For example:
      call DVSYS.setRdbcX('DB2','924186d3-ec79-4daf-aa77-3297081a929b.zu9tc4nd0urletsa6ufg.ds.app.cloud','31101','bludb','','{SECRET_REF}','{SECRET_REF}', '1', '0', '', '', 'qpendpoint_3:6417', 'EDITCID=DB210000,CCID=85b3d676-f627-4f57-a8fd-aad00782c2de',?,?,?)
      The connection is recreated successfully.
Upgrading remote connectors to IBM Cloud Pak for Data version 5.1.0 results in an Unable to initialise GaianNode data (aborting) error

Applies to: 5.1.0

When you upgrade remote connectors to IBM Cloud Pak for Data version 5.1.0 using the stored procedure DVSYS.UPDATEREMOTECONNECTOR, the remote connectors do not start and are not displayed in the output select node_name from dvsys.listnodes. An error message similar to the following example can be found in <Remote_Connector_Install_Path>/sysroot/data/gaiandb-stdout.log.

Example error message:

Unable to initialise GaianNode data (aborting): Another GaianNode or Derby instance may be attached to db folder 'gaiandb'? Otherwise, authentication may have failed or the database may be corrupted (delete it & restart to recycle it). Also check optional messages below.
java.sql.SQLException: java.sql.SQLException: Failed to start database 'gaiandb6556' with class loader jdk.internal.loader.ClassLoaders$AppClassLoader@f1fd8dc9, see the next exception for details. SQL: CREATE FUNCTION maintainConnection2 (nodeid VARCHAR(100), usr VARCHAR(10), pwd VARCHAR(10), extraInfo VARCHAR(32672)) RETURNS VARCHAR(32672) PARAMETER STYLE JAVA LANGUAGE JAVA NO SQL EXTERNAL NAME 'com.ibm.gaiandb.GaianDBConfigProcedures.maintainConnection2'

For more information on DVSYS.UPDATEREMOTECONNECTOR, see Upgrading remote connectors.

Workaround:
  1. Change the following properties in the files gaiandb_config.properties and derby.properties. Both of the files are located in the directory <Remote_Connector_Install_Path>/sysroot/data.
    • In the gaiandb_config.properties file, replace EXTENDER_CLASS_NAME=com.ibm.gaiandb.confluence.ConfluenceExtender with this property:
      EXTENDER_CLASS_NAME=com.ibm.gaiandb.queryplex.ConfluenceExtender
    • In the derby.properties file, replace derby.authentication.provider=com.ibm.gaiandb.confluence.DVAuthenticator with this property:
      derby.authentication.provider=com.ibm.gaiandb.queryplex.DVAuthenticator
  2. Restart the Remote connector by completing one of the following options.
    • Linux
      For Linux systems, run this command to start the Remote connector from the directory <Remote_Connector_Install_Path>/sysroot: 
      nohup ./datavirtualization_start.sh &
    • Windows
      For Windows systems, open the Microsoft Windows Services console (or services.msc), and then restart the Remote connector. Your Remote connector is named DataVirtualizationService<port> .

      For example, the Remote connector is named DataVirtualizationService6414, and you would restart this service in the Microsoft Windows Services console.

Db2REST pod in CrashLoopBackOff state

Applies to: 5.1.0

You can't connect to the Db2REST server. After enabling REST, the REST pod enters CrashLoopBackOff state and repeatedly restarts and never reaches completion.
You see the following log:
chmod: cannot access '/db2u/tmp/os_envar_configmap': No such file or directory
/db2u/scripts/include/common_functions.sh: line 23: /db2u/tmp/os_envar_configmap: No such file or directory
ls: cannot access '/opt/ibm/dbrest/auth': No such file or directory
......+.+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++*....+......+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++*............+..+.+.....+.......+...........+....+..+....+..............+...+...+.......+...+............+...+....................+.+...+..+.........+....+.......................+............+...+....+........+.+.....+.+.....+....+...............+.....+.+.....+......+....+..................+......+..+....+...+..+....+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
...........+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++*..........+.........+.....+......+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++*.+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
-----
Starting up IBM Db2 REST container...
Starting the Db2 REST server...
Starting server with https
/opt/ibm/dbrest/scripts/../bin/db2rest-server: error while loading shared libraries: libcrypt.so.1: cannot open shared object file: No such file or directory
SERVER STATUS: INACTIVE
#############################################################
###  IBM Db2 REST container was started successfully   ###
#############################################################
* If you used docker/oc/kubectl logs to monitor progress, detach from the
console by pressing Ctrl+C.
* To get a command line prompt, issue the following command from the host:
    [ docker | oc | kubectl -n <NS> ] exec -it <rest container name> bash
#############################################################
Workaround: Complete the following steps to resolve this issue:
  1. Find your affected db2ucluster resource by running the following command:
    oc get db2ucluster
    Refer to the following example output:
    NAME      STATE      AGE
db2u-dv   Ready      34m
  2. Disable REST for your db2ucluster.
    1. Run the following command to edit your db2ucluster:
      oc edit db2ucluster deployment_ID
    2. Set rest to false in your CR. Refer to the following example:
      spec:
  ...
  addOns:
    rest:
      enabled: false
  3. Save your db2u-release Config Map:
    oc get cm db2u-release -n ${PROJECT_CPD_INST_OPERATORS} -o yaml > db2u-release.yaml
  4. Extract, then replace your REST images.
    1. Extract your Db2 11.5.9.0 REST image:
      REST_IMAGE_1159=$(oc get cm db2u-release -n ${PROJECT_CPD_INST_OPERATORS} -o=jsonpath='{.data.json}' | jq '.databases.db2u["11.5.9.0"].images.rest')
    2. Extract your Db2 12.1.0.0 REST image:
      REST_IMAGE_CN1=$(oc get cm db2u-release -n ${PROJECT_CPD_INST_OPERATORS} -o=jsonpath='{.data.json}' | jq '.databases.db2u["12.1.0.0"].images.rest')
    3. Replace your Db2 12.1.0.0 REST image with your 11.5.9.0 REST image:
      sed -i.bak "s|\"rest\": $REST_IMAGE_CN1|\"rest\": $REST_IMAGE_1159|g" db2u-release.yaml
  5. Apply your changes to your ConfigMap:
    oc apply -f db2u-release.yaml -n ${PROJECT_CPD_INST_OPERATORS}
  6. Delete your ConfigMap YAML file:
    rm db2u-release.yaml
  7. Enable REST for your db2ucluster.
    1. Run the following command to edit your db2ucluster:
      oc edit db2ucluster deployment_ID
    2. Set rest to true in your CR. Refer to the following example:
      spec:
  ...
  addOns:
    rest:
      enabled: true

User and group management issues

Privileges and authorities that are granted to user groups are not considered when you create views

Applies to: 5.1.0

Privileges and authorities that are granted to user groups are not considered when you create views. This limitation is a result of a Db2 limitation on groups.

Workaround: Instead of granting access to specific groups from the Manage access page, you should grant access to the public by selecting All data virtualization users. Then create a new data protection rule to define Allow or Deny rules based on groups.

Data governance issues

Limited governance support for object or schema names that contain the slash (/), backslash (\) or both characters
Applies to: 5.1.0
Publishing an object or schema to a catalog or project fails if the object or schema name contains the backslash (\).
Note: Data protection rules do not apply to the objects with the backslash (\) character in their object or schema name.
The failed publish action displays this error: 
The assets request failed: CDICO2034E: The path (/CPADMIN/D/EMO] contains more path elements than defined for the connection [2).
Additionally, if a transformation data protection rule (masking or row filtering rule) applies to an object with the slash (/) character in its object or schema name, then the query of the object fails with this error: 
The statement failed because a Big SQL component encountered an error. Component receiving the error: "External authorizer". Component returning the error: "WKC Authorizer". Log entry identifier: "[SCL-0-31cabb638]". Reason: "RCAC-0".. SQLCODE=-5105, SQLSTATE=58040, DRIVER=4.32.28

Workaround: Avoid using the slash (/), backslash (\) or both characters when you name a Data Virtualization schema or object.
The List view on the Virtualize page does not consistently display tables or views
Applies to: 5.1.0
The List view does not accurately display the tables or views the user has access to for data sources that have personal credentials enabled. For data sources with personal credentials enabled, this issue occurs because the list view displays tables or views that are relevant to CCDEFINER user.
Workaround: Use the Explore view to view the tables and views that you have access to.
Partial redaction and length-preserving full redaction of empty strings returns a string of “X” characters
Applies to: 5.1.0
When you are masking empty strings using partial redaction or length-preserving full redaction data protection rules, Data Virtualization returns a string of "X"s (or another character depending on the rule definition) instead of returning an empty string.
RCAC data protection rules are not applied to a view if both Deny access and masking IBM Knowledge Catalog rules are applied to the table referenced by the view
Applies to: 5.1.0

If a table has both the Deny access rule and external RCAC (column and row filters) IBM Knowledge Catalog data protection rules applied to it, then the RCAC rules are not applied to any views that reference that table, leaving the view unmasked.

Workaround:

Use Data Virtualization Db2 authorizations to deny access and define IBM Knowledge Catalog data protection rules to mask data and filter rows instead of doing both through IBM Knowledge Catalog data protection rules. For more information, see Managing access to virtual objects in Data Virtualization.

You cannot apply business terms when you virtualize files in data sources on the Files tab

Applies to: 5.1.0

When you virtualize files in Data > Data virtualization > Virtualize, the Business terms column is not available for data sources on the Files tab. These data sources do not support business terms.

You cannot see business term assignments or grouped tables in the Explore view

Applies to: 5.1.0

On the Virtualize page, you cannot see business term assignments and you cannot see grouped tables.

Workaround: Switch to the List view to see business term assignments and grouped tables.

Cannot see list of available tables in the strict virtualization mode

Applies to: 5.1.0

In the strict virtualization mode (where you can see tables only if they have at least one column with business term assignment), when you navigate to the Virtualize page, the console appears to be loading the table list for a while without showing any tables. The loading can be much slower compared to the default virtualization mode while the console evaluates the list of eligible tables that can be virtualized, depending on term assignments to data source table and column names.

A virtualized object cannot be used in Cognos Dashboards without credentials and an appropriate role

Applies to: 5.1.0

Using a virtualized object in Data Virtualization displays an error message if you do not enter credentials for the Data Virtualization connection or you do not have the correct role.

If you did not enter a username and password when you created the connection to the Data Virtualization data source, you see the following error: Missing personal credentials. If you are not assigned the Admin or Steward role for this object, you see the following error: Unable to access this asset.

To work around this issue, see .

Caching issues

Online backup of Data Virtualization can affect cache refreshes

Applies to: 5.1.0

If you schedule an online backup in Data Virtualization and if at the same time a cache refresh operation runs, the cache write operation can fail.

Online backup in Data Virtualization works by quiescing database write and update operations. Cache refresh is a write operation that updates Data Virtualization caches with fresh data from remote data sources. Both online backup and cache refresh operations can be scheduled to run periodically. These schedules can conflict and every time the cache tries to refresh, an online backup might be in progress or it might start while the cache refresh is in progress. In these scenarios, cache refresh operations can fail with an error similar to the following message. The cache is active but it contains stale data.

The statement failed because a Big SQL component encountered an error. 
Component receiving the error: "BigSQL IO". Component returning the error: "UNKNOWN". 
Log entry identifier: "[BSL-1-b1bf428f]". Reason: "Cannot add block to /warehouse".. 
SQLCODE=-5105, SQLSTATE=58040, DRIVER=4.27.25

Cache auto-refresh might also fail and you can either manually refresh or wait for the next auto-refresh. However, if the online backup is scheduled such that it conflicts with any cache's refresh schedule, then every auto-refresh of those caches will fail.

Workaround: Reschedule the cache's refresh or the online backup schedule to avoid conflicts. You can also refresh the cache manually at any time.

File issues

You cannot preview long string values in headings in CSV, TSV, or Excel files

Applies to: 5.1.0

When you use the first row as column headings, the string values in that row must not exceed the maximum Db2 identifier length of 128 characters and cannot be duplicated. If your file has string names in the header row with values that are too long or are duplicated, an error message is displayed when you try to preview your file in Data Virtualization.
400: Missing ResultSet:java.sql.SQLSyntaxErrorException: Long column type column or parameter 'COLUMN2' not permitted in declared global temporary tables or procedure definitions.

Column heading names are case-insensitive and converted to uppercase in the API response, which is exposed by the console. Therefore, a column that is named ABC is considered the same as a column that is named abc. However, the columns can be renamed to mixed case when you virtualize your data source.

Workaround: Review the first row in the data file that contains the intended column heading names and make the necessary changes to avoid this limitation.
You might encounter errors when you virtualize large Excel files

Applies to: 5.1.0

You might experience an error when you preview or virtualize large files with Excel format (XLS):
ERROR 400 'Your InputStream was neither an OLE2 stream nor an OOXML stream' was thrown while evaluating an expression.
Workaround: You can follow these steps:
  1. Load the file data into a table on a supported data source.
  2. Virtualize the table.
  3. Optionally, you can change the format of the file; for example, to CSV format before you virtualize it again.
Encoding detection override for files data with Japanese characters

Applies to: 5.1.0

For text files exposed by remote connectors, Cloud Pak for Data automatically detects the encoding scheme of flat data files, such as CSV and TSV files. However, to avoid decoding issues, it is recommended that you set the encoding scheme manually for flat data files.