IBM Support

IBM Db2 Analytics Accelerator for z/OS Version 7.5.5 Release Notes

Release Notes


Abstract

This document describes enhancements and fixes in IBM Db2 Analytics Accelerator for z/OS Version 7.5.5

Content

 
  • What's new

    Please find information about new functions here .

  • Installation and/or Upgrade Considerations

    • Accelerator on IIAS-specific considerations

      If you plan to install or upgrade IBM Db2 Analytics Accelerator, please contact IBM support by opening a case.
      For an upgrade we would like you to create an Appliance trace and to upload it and the Transfer log to the support case for an offline health check of the system.
      Further, before you begin, please consider the description in APAR PH26946.

      The steps to be performed for an upgrade depend on your current maintenance level of the accelerator:

      Current IDAA V7
      maintenance level
      Upgrade to 7.5.5 - required steps Elapse time needed for applying (*) the software
      (Ballpark estimation)
      7.5.4.x   or
      7.5.3      or
      7.5.2.x   or
      7.5.1
      Perform a full upgrade to maintenance level 7.5.5.
      Note: An "essential" update is possible and may save 1:30 h.
      4 h (when Replication and Accelerators are stopped)
      7.5.0.1
      The upgrade consists of two steps:
      • Step 1: Upgrade from 7.5.0.1 to maintenance level 7.5.3.
      • Step 2: Upgrade to maintenance level 7.5.5 (essential or full).

      Note: Some firmware updates introduced with 7.5.1 require a full upgrade to 7.5.3, when skipping 7.5.1. Therefore an "essential" update is not possible.
      Further, before you begin, please consider the description in APAR PH27055.
      1 day
      7.1.9.x
      The upgrade consists of three steps:
      • Step 1: Upgrade to maintenance level 7.5.0.1.
      • Step 2: Upgrade from 7.5.0.1 to maintenance level 7.5.3.
      • Step 3: Upgrade from 7.5.3 to maintenance level 7.5.5 (essential or full).
       
      We recommend to perform the first two required upgrade steps in the same maintenance window.
      To save some time the first upgrade to 7.5.0.1 can be an “essential” update, skipping firmware updates, followed by the mandatory full upgrade to 7.5.3.
      1.5 days
      Prior to 7.1.9
      A four-step upgrade process is mandatory:
      Day 1
      • Step 1: Upgrade to maintenance level 7.1.9.1.
      • Step 2: Upgrade from 7.1.9.1  to maintenance level 7.5.0.1.
      Day 2
      • Step 3: Upgrade from 7.5.0.1  to maintenance level 7.5.3.
      • Step 4: Upgrade from 7.5.3  to maintenance level 7.5.5 (essential or full).
      While step 2 can be an “essential” update skipping firmware updates, the upgrade to 7.5.3. in step 3 is a mandatory full upgrade.
      2 days
      (*) The time required for downloading the upgrade packages and subsequent transfer to the accelerator is not included.
    • Accelerator on Z-specific considerations

      The steps to be performed for an upgrade depend on your current maintenance level of the accelerator:

      1. Current maintenance level: 7.5.4, 7.5.3, 7.5.2.2, 7.5.2.1, 7.5.2 or 7.5.1
        • We recommend to migrate directly to maintenance level 7.5.5.
        • Important: Compared to previous product releases, the JSON configuration file syntax has changed considerably with product version 7.5.3 and later. Therefore, whenever you want to change the configuration of the accelerator, download the currently active configuration file for the accelerator using the Appliance Installer web user interface for modifications. The downloaded file contains the active configuration with the new JSON syntax.
      2. Current maintenance level: prior to 7.5.1
        • If you plan to install or upgrade IBM Db2 Analytics Accelerator, please contact IBM support by opening a case.
          For an upgrade we would like to know your current maintenance level of the accelerator software and the one you want to upgrade to.
    • New feature-specific considerations: "Excluding suspended tables from accelerated queries"

      The administrator must grant following privileges to the corresponding Db user, which is specified when enabling 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)
  • APARs fixed with 7.5.5

    Click here for the list of APARs having been fixed.

  • Other previously reported issues resolved with 7.5.5
    • Queries

      • Accelerated queries fail with SQL code SQL0955C due to missing statistics.

        Fixed

      • Different query results with date-time expressions that include Feb 29 in a leap year

        Fixed

    • Issues specific to IBM Db2 Analytics Accelerator on Z

      • Cluster initialization fails with large EAV DASD, the Cluster is stuck in 'Initializing'.

        Fixed

    • Integrated Synchronization

      • Integrated Synchronization currently does not support SSL setups with a Db2 certificate signed by a certificate authority (CA) chain, e.g. Root CA -> Intermediate CA -> Db2 certificate.

        Fixed (see also new features of Integrated Synchronization in What's new in 7.5.5)

    • Stored Procedures

      • A stored procedure invocation aborts with message:AQT20111E: Operation RECEIVE, which was supposed to transfer 6 bytes on TCP/IP socket 1 to the remote machine at IP address \ <address> and port 1400 could not be completed within the time allotted (10 seconds).

        Fixed

    • Monitoring

      • The reported table size was not accurate.

        Fixed, the reported table size now includes the size of the synopsis tables.
        Note: You may see slightly increased table sizes beginning with version 7.5.2. This does not necessarily mean that compression in 7.5.2 is worse than before, but could be caused by inclusion of the synopsis tables in the table size.

  • Changed behavior of ACCEL_LOAD_TABLES

    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.
  • Known issues and limitation

    General recommendations

    • Under a high system load, the accelerator might appear slow or run into timeouts.

      Recommendation: Do not run more than 30 load threads in parallel.

    Queries

    • A query running during a partial reload of an incrementally updated table might be unable to access the new partitions.

      Recommendation: Rerun the query after the partial reload has finished.

    • A query referencing a large set of federated objects could result in an SQLCODE -904: 954: Not enough storage is available error

      Recommendation: Contact IBM support for assistance.

    • A query referencing several tables using union all views could run slower than V5.
      Example use cases are when union all views are used for collecting data from multiple branch offices and each branch-office has a schema-identical table that your are all referencing in a single query.

      Recommendation: Contact IBM support for assistance.

    • When executing a query with a large result set, the query could be slow.

      Recommendation: Contact IBM support for assistance.

    • An SQL statement that contains a CAST on a column with the time data type as a character data type may return with colon delimiters instead of dot delimiters once after a table is loaded.

      Example: For the following query "SELECT cast(c_time as char(8)) from T1": On Db2 12 for z/OS the value returned is "13.10.00" as a character string. On the accelerator the value returned is "13:10:00" as a character string. This occurs only once after a table is loaded.

    • When setting DB2_TCG_DEFAULT_OPTIONS="set percentile_cont_spill on", queries containing MEDIAN functions may take longer to run.

      Recommendation: DB2_TCG_DEFAULT_OPTIONS="set percentile_cont_spill on" is crucial to stabilize the performance of MEDIAN functions and avoid out of heap conditions, it is recommended that it be turned on even though queries with MEDIAN may take longer to run.

    Loading tables

    • After running the REORG utility in Db2 12 for z/OS,  reloads might be wrongly recommended for partitions that have already been loaded on the accelerator.

      Recommendation: To receive correct reload recommendations, do not use interactive load recommendations and batch job change detection at the same time.

    Incremental updates

    • CDC-based replication: The time needed to reload a set of incrementally updated tables increases as well as the replication latency.

      Recommendation: Pause after each reload, as this allows the system to come back to normal throughput rates and latency levels.
      As an alternative: use Integrated Synchronization based replication.

    Monitoring

    • The values of the monitoring counter Q8STTMUD are too high, for example 0.18E+20.

      Recommendation: Ignore the high value. It will be corrected during the next collection of statistics.

    • The monitoring values of the Q8STCQL, Q8STCQLS, and Q8STQUEW metrics might be displayed incorrectly.

    • When ACCEL_GET_QUERIES is called while a offloaded query is still on early stage of the execution in IBM DB2 Analytics Accelerator for z/OS, then the result of the stored procedure would contain empty accounting information.

      Recommendation: Retry ACCEL_GET_QUERIES at a later time

    Miscellaneous

    • Under a very high system load caused by the parallel execution of various operations, such as 'Add Tables', 'Remove Tables', and 'Alter Keys', the accelerator might restart unexpectedly, leading to the abortion of running tasks or queries.
      Symptoms are aborted tasks, lock timeout exceptions, or messages with SQL code -911, SQLSTATE=40001, and rc=68.

      Recommendation: Reduce the task diversity of parallel jobs if you process large table sets with more than 100 tables. For example, do not run 'Alter Keys', 'Add Tables', and 'Remove Tables' operations at the same time. Reduce this to 'Alter Keys' and 'Add Tables' jobs or any other combination of just two different tasks.
      If a query failed, rerun the query.

    • When a date literal in a LOCAL date format DD/MM/YYYY or YYYYMMDD is CAST as a CHAR or VARCHAR, the result is not the local date format but rather ISO.
      For example: CAST(DATE('22/11/2018') AS CHAR(10)) will return 2018-11-22 instead of '22/11/2018'.

      Recommendation: None

[{"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Product":{"code":"SS4LQ8","label":"Db2 Analytics Accelerator for z\/OS"},"Component":"","Platform":[{"code":"PF035","label":"z\/OS"}],"Version":"7.5","Edition":"","Line of Business":{"code":"LOB10","label":"Data and AI"}}]

Document Information

Modified date:
06 April 2021

UID

ibm16415581