Version 1.0.19.0 release notes for M4002-001 model (March 2020)

Learn about new features, fixes, and known issues that apply to IBM® Integrated Analytics System M4002-001 software version 1.0.19.0.

What's new

Security
  • The root user lock-down for IAS appliance can be disabled by raising a PMR request.
    Attention: On disabling root lock-down, the root user has all the privileges to update the operations on the appliance. Improper handling of the appliance by the root user might lead to system instability, downtime, or other incidents. IBM Corporation is not liable for any such incidents.
Migration tools
db_migrate
  • Added support for migration to Db2 tables with hidden columns: hidden columns are automatically skipped and ignored.
  • Restored support for MIXED format.
For more information, see db_migrate command.
db_migrate_iias
  • Improved performance by:
    • Parallel unload of tables to multiple nodes in source machine with -strategy partitions parameter. The -strategy partitions parameter uses all MLNs to unload data, so the number of inserts is high. You can also use -strategy dataslices, which allows you to control the number of inserts with the --max-inserts parameter.
    • Parallel loading to multiple nodes on target IAS. You can now specify multiple hosts (within the same IAS) with the thosts parameter. If a node is not responding, it is skipped and the workload is shared on the remaining nodes. If all nodes are unavailable, migration fails. With this change, the -target option no longer accepts the host parameter. You must always specify the -thosts|-thost option.
    For more information, see db_migrate_iias command.
  • Added support for migration from and to Db2 tables with hidden columns: hidden columns are automatically skipped and ignored
  • Added support for binary data transfer with -binary.
  • Added support for LZ4 compression of migrated data with -compress LZ4 parameter.
Note that both systems, source and target, must support the new formats: binary and LZ4.
dbsql
  • Added support for case sensitive, camel case schema names.
Backup and restore
  • For restoring from a multi-path database backup, added a check to make sure that all the required paths are specified.
  • Any database admin user should now be able to run backups and restores using db_backup and db_restore scripts respectively.
  • db_backup now gives out the following return codes (rc):
    • 0 upon success.
    • 1 upon failure.
    Run echo $? after you run the db_backup command to verify if the command was successful.
  • Added checks for schema/table restore with db_restore to make sure that the backup directories have the right permissions/ownership to read the backup files.
  • db_backup now allows multiple schema backups using -schema or -schemafile options:

    If using -schema option, the schema names must be separated by a space, for example: -schema S1 S2 S3

    If using -schemafile option, specify the absolute path to the file that contains schema names separated by new line. Example: 
    -schemafile /scratch/schema_names.txt
    Example of the schema_names.txt:
    S1
S2
S3
S4
S5

    You can specify any number of schema names using either of these options, but maximum three schemas can run in parallel, while the remaining ones wait in the queue. Each of these schema backups is associated with its own timestamp.

  • db_backup now allows schema backups to multiple paths using -path option. Make sure that the paths do not share the same underlying storage or the filesystem. For example, /scratch/backup1 and /scratch/backup2 cannot be used because they share the same underlying filesystem /scratch.
    You can also use db_restore to restore a schema or tables from multiple paths using -path option:
    • If using the same paths for restore and for backup, you must provide the paths in the same order as at the end of the backup. Run db_backup -history to find out path order.
    • If using different paths for restore, make sure that the backup directory structure, data/metadata files in the backup and their ownership/permissions are not altered or tampered.
  • The backup and restore logs now record the following details:
    • the db_backup and db_restore commands with its arguments
    • the user ID (UID)
    • the effective user ID (EUID)
    • the backup/restore process ID (PID)
  • For schema level backups, db_backup now supports a new option -format binary to back up the table data in the binary format. If -format option is not specified, by default the table data files are generated in text format.

Components

IBM Integrated Analytics System version 1.0.19.0 includes the following components:
Db2 Warehouse v. 3.10
Maintenance release with no new features. See What's New in IBM Db2 Warehouse.
Db2 Engine v. 11.1 (latest update)

Resolved issues

  • Defects addressed in Db2 Warehouse:
    • LDAP should have TLS 1.2 as minimum allowed version
    • After ap upgrade to 1.0.16.0, DB2 services are not coming up, causing HA management and Db2 to go down.
  • Web console component includes fixes for the following issues:
    • Backup and restore could not be launched from console
    • Console configuration files might be corrupted sometimes
    • User provided certificate is lost after console is upgraded
    • Large sort memory and tablespace consumption in console utility event monitor query
  • Granular backup and restore object ownership fixes.
  • Fixed the issue with incremental database backup: updated db_backup to estimate the increase in database size since the last full online backup and then compare if the given backup path has enough space to accommodate the backup, instead of comparing it with the entire database size.
  • Fixed a bug in db_restore, to allow database restore from multiple paths specified with a space ( ), or a comma (,), or both, a comma and a space (, ) as separators. Examples:
    • -path p1,p2
    • -path p1 p2
    • -path p1, p2
  • Fixed a bug in db_backup, to avoid creating multiple database backups under the same directory. Now, every database backup has its own unique directory backup_<type>_<number>.
  • Updated db_backup script to create backup directories as db2inst1 or database admin user, to allow users to delete schema backups without root access.

    During schema backup, if the db2inst1 or the database admin user doesn't have the right permissions to create backup directories in the given path, then the directories are created with a root user and a warning is displayed. Note that root access is required to remove them.

  • Fixed db_backup -history command not to throw a Traceback error when run during an offline backup or any restore operation. However, this command cannot return history results when the database is down during any offline operation.

Known issues

db_backup fails on un-encrypted database
The error is caused by the fact that the database encryption is set to NO.

Workaround:

Modify the values of the ENCRLIB and ENCROPTS parameters to null:
[bluadmin@node0101-fab - Db2wh ~]$ db2 get database config for bludb | grep Encryption
 Encryption Library for Backup                 (ENCRLIB) = /opt/ibm/db2/V11.1.0.0/lib64/libdb2encr.so.1
 Encryption Options for Backup                (ENCROPTS) =
GPFS upgrade fails with Could not upgrade rpms on all nodes

Workaround:

Rerun apupgrade.

db_backup -history reports failure to connect to database when the database is online

Workaround:

The Db2 parameter DB2COMM needs to have TCPIP set. If set to ssl, db_backup -history is not able to connect and reports that the database is offline when in fact the database is active. The problem is resolved when DB2COMM is set to tcpip.

Upgrade fails on preinstall with the following error: ERROR: OSError: [Errno 2] No such file or directory: '/opt/ibm/appliance/platform/etc/device_info/'

Workaround:

Create the missing directory manually and restart the upgrade.

After schema level restore permissions of objects are changed
A PUBLIC create privilege is added in schema ownership after schema level restore. Workaround:
REVOKE CREATEIN ON SCHEMA SchemaName FROM PUBLIC BY ALL
Misleading Backup failed message on the web console
When running backup from the web console, a Backup failed message is displayed even when the backup finished successfully. You can check the backup history in the console, or run db_backup -history to verify if the backup actually failed.
Guardium configuration fails at apinit
When configuring IBM Guardium, apstop might fail but the process continues with apinit, resulting in error.
Problems with static routing
  • While adding a static route with apsetup, most nodes lose their fbond/mbond network interfaces. You must bring up bonded interfaces manually.
  • Deleting a static route with apsetup only deletes it on the current node.
The About window in the web console displays HTTP Error 400 message instead of system information.
Log in to the web console and select the user icon from the top bar, then select About. The error message is displayed.
The db_backup -history command cannot return history results when the database is down during any offline operation.
IBM Spectrum Protect backups fail with Kernel issues

When using the IBM Spectrum Protect client for backup and restore, the Kernel issues might occur, which cause the backups to fail.

Workaround:
  1. Edit all dsm.sys files in /opt/ibm/appliance/storage/head/tsm/api/node010X-fab, where X is a node number. Add the following lines to all these dsm.sys files:
    tcpbuffsize 512
tcpwindowsize 1024
tcpnodelay no
  2. Start the backup again.
EMC NetWorker backup/restore fails
EMC NetWorker backup/restore fails with SQL2062N. An error occurred while accessing the /usr/lib/libnsrdb2.so media. Reason code is 0. This is occurring due to two parameters that are added in the nmda_db2.cfg file on each node.
WORKAROUND:
  1. As the root user, edit the /nsr/apps/config/nmda_db2.cfg file and comment out the NSR_LIBNSRDB2_DEBUG_LEVEL=9 and NSR_DEBUG_LEVEL=9 parameters. This must be done on every node in the container.
  2. Rerun backup/restore.
Backup and restore
The -compress lz4 option is not supported for backup and restore.