IBM Db2 Analytics Accelerator for z/OS Version 8.1 - Release Notes for the GA code level

The following restrictions apply:

• Query result sets
  Queries with LOB columns and expressions larger than 32K in the query result set lead to SQLCODE -904.
  LOB columns and expressions referenced elsewhere in the query can be up to 2GB.
• Locally submitted queries (for example using DSNTEP2, DSNTEP3, DSNTEP4) with LOB columns and expressions in the query result are not supported.
• INSERT from SELECT which contains reference to a LOB column or expression is restricted and leads to SQLCODE -4742.
• LOB columns and expressions are not supported under Db2 DDF native REST services execution environment.
• HPSS archiving of tables with LOB columns and expressions is not supported.
• Data replication of tables with LOB columns and expressions is not supported.
• Only UNICODE tables with LOB columns and expressions re supported.

Additional consideration apply for Accelerator-Only Tables (AOT):

• LOB columns can be specified as part of an AOT.
• INLINE LENGTH will continue to be restricted (SQLCODE - 20016) and LOB_INLINE_LENGTH subsystem parameter will not apply.
• AOTs containing LOB columns must be created under CURRENT RULES = STD (SQLCODE -4742 RC 44).
• DML is not supported for AOTs containing LOB columns (SQLCODE -4742 RC 22).
• The Accelerator loader V3.1 will be required to load data into the AOT.

• The setting of the configuration parameter "temp_working_space=unlimited" in the JSON configuration file is no longer supported. A corresponding setting found in the JSON file during the upgrade to Accelerator version 8.1 will be changed to "temp_working_space=automatic".

• After SMP/E installation of the FMIDs HAQTX10 and JAQTXID, the execution of installation job AQTTIJSP ends with RC 12 as the DBRM library delivered (SAQTDBRM) does not fit to the program code (SAQTMOD). The issue has been documented in APAR PH67172.

  Recommendation: Prior to availability of the PTF for APAR PH67172, either

  • Temporarily use the Stored procedures from Accelerator version 7.5
  • Contact IBM support by opening of a support case to receive the correct DBRM library.

• The Stored Procedure ACCEL_COPY_TABLES does not yet support the attribute "For Bit Data".

  Recommendation: Wait for the fix provided with an upcoming maintenance level of the Accelerator.

Queries

• Query EXPLAIN function is not working due to changed db2wh V12 support that requires new approach

  Recommendation: Capture query performance data, open a support case, and upload the accelerator trace to the support case; the query plan is part of the so-called CDE trace.
  The issue will be fixed with a future maintenance level of the Accelerator.

• Query outliers might impact overall system performance due to increased resource consumption

  Recommendation: Capture query performance data, open a support case, and upload the accelerator trace to the support case

Loading tables

• Load or reload of table sets bigger than 3000 tables might hang.

  Recommendation: Use table sets with max. 3000 tables.

• Load might hang under high stress running 500 parallel loads with 5000 partitions in total.

  Recommendation: Limit the amount of parallel loads.

Federation

• Federation not working due to failing alias/view creation.

  Recommendation: Grant the missing access rights manually.

Tracing

• Backend Database Diagnostics Collection (db2support) is not working properly on DAA-on-Z Multi-node for data nodes. .

  Recommendation: Grant the missing access rights manually.

Setup

• Duplicate IP addresses are not supported for different runtime configurations in the same JSON configuration file, impacting JSON configuration files used for GDPS failover on different CECs. .

  Recommendation: Use different IP addresses for internal cluster network per CEC/ runtime environment.

• Mandatory settings for the setup of Integrated Synchronization (published with Accelerator maintenance level 7.5.6)
  • Excluding suspended tables from accelerated queries

    The administrator must grant the following privileges to the Db2 for z/OS user ID having been specified during enabling of the subsystem for replication using IBM Integrated Synchronization:

    • EXECUTE on the SYSPROC.ACCEL_SET_TABLES_ACCELERATION stored procedure
    • RACF ACCESS(READ) on the data set that contains the AQTENV file in the started task procedure of the Workload Manager (WLM) environment
    • RACF ACCESS(READ) on the data set that contains the AQTDEF6 file in the started task procedure of the Workload Manager (WLM) environment
    • Define an OMVS segment in the Resource Access Control Facility (RACF)

  • Support of schema changes (Add/Alter column)
    • If the schema change affects columns of the type TIMESTAMP, you must also install the PTF UI73158 for Db2 for z/OS (APAR PH31772)
    • The Db2 for z/OS user you specified when you enabled IBM Integrated Synchronization must have the following additional privileges:
      • SELECT privilege on SYSIBM.SYSTABLES, SYSIBM.SYSCOLUMNS
      • SELECT, UPDATE privilege on SYSIBM.SYSACCELERATEDTABLES
• Changed behavior of ACCEL_LOAD_TABLES (published with Accelerator maintenance level 7.1.7)

  The SYSPROC.ACCEL_LOAD_TABLES stored procedure behaves differently if automatic change detection is enabled.
  Before version 7.1.7, a load job with a setting of detectChanges=“DATA” sometimes did not capture the changes in all partitions if the lock mode NONE had been used for the previous load.
  This was fixed with version 7.1.7.

  The new behavior:
  If you use lock mode NONE and detectChanges=“DATA”,

  • it can happen that more changes are detected than are transferred to the accelerator. This is caused by the SKIP LOCKED DATA option, which is used implicitly by the Db2 Unload Utility. If parts of the data were locked by other processes, then this data is ignored and not unloaded to the accelerator.

  • therefore, a partition in an accelerator-shadow table is always fully reloaded to ensure that all changes are finally transferred. A reload is started even if the partition had no further changes since then.

  If you want to use detectChanges="DATA", the recommended lock mode to be used is lock mode "ROW" or higher.