Netezza Performance Server 11.2.0.0 release notes

Deployment options: Netezza Performance Server for Cloud Pak for Data SystemNetezza Performance Server for Cloud Pak for Data

Version 11.2.0.0 introduces a number of new enhancements, improvements, and fixes.

New features, enhancements, and improvements

Netezza Performance Server for Cloud Pak for Data SystemNetezza Performance Server for Cloud Pak for Data
Netezza Performance Server for Cloud Pak for Data
  • You can now install Netezza Performance Server on Microsoft Azure Cloud. For more information, see Installing Netezza on Cloud.
  • Added support for independent compute scaling and storage scaling on IBM Cloud and AWS. For more information, see Scaling.

    Scaling is not yet available on Azure.

Netezza Performance Server for Cloud Pak for Data System
  • Added support for in-field expansion with offline data redistribution, which helps to scale existing on premises systems.
  • Added a connector node feature, which allows to use various storage options for Netezza Performance Server. The connector node is purpose-built to accelerate and improve the performance of your Cloud Pak for Data and Netezza Performance Server engine. The connector node enables the use of more storage arrays such as SAN, NAS, and other lower-cost storage options. Connector node is a Lenovo-based, 2U server platform with integrated storage, processing, and I/O. The chassis comes as a pretested building block loaded with software. The provided Cloud Pak for Data System version is 1.0.7.4 or higher. See Connector node. Contact your IBM Representative to learn more about this feature.
Important:
  1. Upgrading to 11.2.0.0 from a version lower than 11.0.5.0 is not supported. Systems with versions lower than 11.0.5.0 need to be upgraded to 11.0.7.0 first, and then to 11.2.0.0.
  2. Before you can start Uprading to 11.2.X.X, you must disable the logrotate.hourly cron jobs and all other cron jobs that can trigger a postgres session as detailed in Disabling and restoring cron jobs and crontab entries.
  3. If you are upgrading from 11.0.X.X to 11.2.0.0, apply workarounds number 2 and 3 from the Known issues section before you start the upgrade process.
  4. If you are upgrading from 11.0.5.0/1 to 11.2.0.0:
    1. Apply workarounds number 2 and 3 from the Known issues section before you start the upgrade procedure.
    2. Apply workaround number 4 from the Known issues section after step 7 of the upgrade procedure.
  5. Before you upgrade to 11.2.0.0, you must take a DDL of views that are in a database if the views have any non-English characters in their definitions. For example, Korean characters. After you upgrade, you must re-create the views. Follow the steps that are described in the Known issues section, point 7.
  6. Netezza Performance Server host container downgrade from 11.2.0.0 to prior versions is not needed. You need to downgrade only the Netezza Performance Server software. Netezza Performance Server 11.2.0.0 container works with it.

Known issues

Netezza Performance Server for Cloud Pak for Data System
  1. Fixed-format data files that contain numeric fields might be loaded incorrectly into the database. For more information, see https://www.ibm.com/support/pages/node/6583457.

  2. If you are upgrading from 11.0.X.X to 11.2.0.0, the system is prone to a postgres crash if the database objects have default values that are defined for their columns. For example, tables, external tables, global temp tables, views based on these tables.
    TESTDB.ADMIN(ADMIN)=> \d test_table
                           Table "TEST_TABLE"
     Attribute |         Type          | Modifier |  Default Value
    -----------+-----------------------+----------+------------------
     COL1      | INTEGER               |          |
     COL2      | CHARACTER VARYING(40) | NOT NULL | '0'::"NVARCHAR"
     COL3      | CHARACTER(10)         | NOT NULL | 'NA'::"NVARCHAR"
    Distributed on hash: "COL1"
    Note: You must apply the workaround before you can start the upgrade process.
    WORKAROUND:
    1. Download a new script here and copy the .tar file on the Netezza Performance Server host.
    2. Unpack the .tar file, copy the nz_update_column_defaults.sh script to a wanted location (location/tmp), and set the permissions:
      tar zxf nz_update_column_defaults.tgz
      chmod 775 nz_update_column_defaults.sh
    3. Run the nz_update_column_defaults.sh script:
      $ ./nz_update_column_defaults.sh
      Example:
      $ ./nz_update_column_defaults.sh
      Processing database: SYSTEM
      Processing database: TEST_DB
      
      ================================================================================
      
      The following file has been created for you
           /tmp/update_column_defaults.2021_02_22_120331.sql
      The script creates an SQL file.
    4. Run the SQL file that was generated:
      $ nzsql -f /tmp/update_column_defaults.2021_02_22_120331.sql
      Example:
      $ nzsql -f /tmp/update_column_defaults.2021_02_22_120331.sql
      You are now connected to database "SYSTEM".
      UPDATE 0
      You are now connected to database "TEST_DB".
      UPDATE 10

      The entries in the catalog table are updated.

  3. If you are upgrading from 11.0.X.X to 11.2.0.0, you must set password policy to none before you start the upgrade procedure.
    1. Verify whether password policy is set on the system:
      nzsql -c "show system default passwordpolicy;"
      If password policy is (null), skip steps b and c.

      If password policy is set on the system, note its information from the output of the command.

    2. Set the password policy to none:
      nzsql -c "set system default passwordpolicy to none;"
    3. After you complete the upgrade procedure, restore the password policy by using the information from step a.
      Example:
      nzsql  -c "set system default passwordpolicy to 'minlen=10, lcredit=0 ucredit=-1 dcredit=-1 ocredit=1';"
  4. If you are upgrading from 11.0.5.0/1 to 11.2.0.0, you must apply a workaround before performing the upgrade steps (before step 7 of Upgrading the software).

    WORKAROUND:

    1. After you unpack the kit, go to the kit.11.2.0.0 folder and make a copy of the CopyPostgres.pm file:
      cd /nz/kit.11.2.0.0/share/upgrade/plugins/nz/Plugin/
      cp CopyPostgres.pm CopyPostgres.pm.original
    2. Remove below lines from the CopyPostgres.pm file and save the file:
      # This plugin should come into picture when transition from/to 11.0.5.0 or 11.0.5.1 only
      if ((nz::Rev::revcmp($originver, '11.0.5.0') != 0) || (nz::Rev::revcmp($originver, '11.0.5.1') != 0) ||
          (nz::Rev::revcmp($targetver, '11.0.5.0') != 0) || (nz::Rev::revcmp($targetver, '11.0.5.1') != 0) ) {
      return 1;
      } 
      You can run step 8 from Upgrading the software now.
  5. Software upgrade to 11.2.0 fails and the system is in the Stopped state.

    If the software upgrade to 11.2.0.0 fails out or errors after you upgrade the container to 11.2.0.0 from 11.0.X.X, the system is in the Stopped state on the previous version.

    The nzstart command might fail with the following error in sysmgr due to sysmgr stopping unexpectedly:
    Error: NZ-01571: Spu AEK 'key-unlock' operation failed.
    Error: ' Action not supported.'.

    WORKAROUND:

    To get the system back Online, follow the steps:
    1. Make sure that Netezza Performance Server is on version 11.0.X.X:
      nzrev
    2. Make a copy of the hpfinfo file:
      cp /nzlocal/scripts/hpfinfo /nzlocal/scripts/hpfinfo.original
    3. Open the file:
      vi /nzlocal/scripts/hpfinfo
    4. Remove the following two entries that appear before the EOF statement. Do not remove EOF.
      SYS_AEK_ENABLED="YES"
      SYS_KEY_STORE_SHARED="YES"
    5. Save the file.
    6. Start the system:
      nzstart
    Now, you can resolve any issues that are related to the software upgrade and attempt upgrade again.
  6. During upgrade, a postgres crash might happen if FIPS and QUERY/AUDIT history are enabled on the system. To prevent the postgres crash, you must apply the following workaround before you upgrade Netezza Performance Server.
    To check whether QUERY/AUDIT history is enabled on the system, run:
    SHOW HISTORY CONFIGURATION;
    If the CONFIG_DBTYPE column shows 1 or 2, QUERY/AUDIT history is enabled on the system.

    WORKAROUND:

    You must disable QUERY/AUDIT history if it is enabled on the system.
    1. Run the following queries from the nzsql prompt:
      CREATE HISTORY CONFIGURATION MY_NONE HISTTYPE NONE;
      SET HISTORY CONFIGURATION MY_NONE;
    2. Stop and restart the system:
      nzstop
      nzstart
    3. Verify whether query history is unavailable:
      SHOW HISTORY CONFIGURATION;
      If the CONFIG_DBTYPE column shows 3, QUERY/AUDIT history is unavailable on the system.
  7. Before you upgrade to 11.2.0.0, you must take a DDL of views that are in a database if the views have any non-English characters in their definitions. For example, Korean characters. After you upgrade, you must re-create the views.

    To take a DDL of views and to re-create the views for a specific database, follow the steps:

    1. Before the upgrade, run the command:
      /nz/support/bin/nz_ddl_view DBNAME -schemas all > views_DBNAME.out
      Where
      DBNAME
      Specifies the name of the database.
    2. After the upgrade, run the command to re-create the views. Use the file that was taken before upgrade (views_DBNAME.out).
      nzsql -db DBNAME -f views_DBNAME.out
      Where
      DBNAME
      Specifies the name of the database.
    3. If you have multiple databases with views that have non-English characters, repeat step 6 a before upgrade and 6 b after upgrade for all databases.

  8. nzrestore fails if backup is taken with BUCKET_URL having slashes.
    Whenever the nzrestore failure happens with following error:
    [Restore Server] : Starting the restore process
    [Restore Server] : Operation aborted 
    Error: Connector exited with error: 'The specified key does not exist. with address : xx.xxx.xx.xxx'.
    Check the backup command and verify whether BUCKET_URL is having slashes as shown in the following example:
    BUCKET_URL=bakcupbucket/subdir/
    UNIQUE_ID=2024-01-12
    WORKAROUND:
    Modify BUCKET_URL and UNIQUE_ID as shown:
    BUCKET_URL=bakcupbucket 
    UNIQUE_ID=subdir/2024-01-12
    Note: UNIQUE_ID is a combination of string that is taken from BUCKET_URL after the first slash and actual UNIQUE_ID. Pass these two arguments to the nzrestore command.

Resolved issues

Netezza Performance Server for Cloud Pak for Data System Netezza Performance Server for Cloud Pak for Data

Introduced a number of critical fixes to improve Netezza Performance Server stability.