Before upgrading IBM Db2 Warehouse to version 11.5

Before upgrading to version 11.5, follow this procedure.

1. On the head node, stop the Db2 Warehouse services by issuing the following Docker or Podman command:

   docker exec –it Db2wh stop

   podman exec –it Db2wh stop

2. Issue the following Dokcer or Podman commands to log in to the container shell and to become the user with SYSADM authority:

   docker exec –it Db2wh bash
   su - db2inst1

   podman exec –it Db2wh bash
   su - db2inst1

3. Issue the following Docker command to start Db2 and activate the database:

   db2start 
   db2 activate db bludb

4. If you have distributed transactions that involve Db2 databases, on each node, issue the following commands to connect to the BLUDB database and to list and interactively resolve any indoubt transactions:

   db2 connect to bludb
   db2 list indoubt transactions

   You can automate this by means of a simple shell script, for example:

   N=$(tail -1 ~/sqllib/db2nodes.cfg | cut -d' ' -f1)
   for node in `seq 0 $N`; do
   db2 terminate
   export DB2NODE=$node
   db2 connect to bludb
   db2 list indoubt transactions
   db2 terminate
   done

5. Back up configuration and diagnostic information for all databases that you are going to upgrade by issuing the following commands:
   • To collect information about the database system catalog, database and database manager configuration parameters settings, Db2 registry variables settings, explain table data, and diagnostic information required by IBM Support in case of problems:

     db2support ${SCRATCHDIR} -d bludb -cl 0

     The -cl 0 parameter collects the database system catalog, database and database manager configuration parameters settings, Db2 registry variables settings. The information collected is stored in the db2support.zip compressed file under the output directory. Keep this file until you validate that the upgrade was successful.

   • To retrieve information from the Db2 database system memory sets:

     db2pd -db bludb -member all &> ${SCRATCHDIR}/db2pd.out

   Move the db2support.zip and db2pd.out files from the scratch directory to a location is outside the persistent file system.
6. Verify that the time across all nodes is in sync. To do this, issue the following command and verify that the times on all nodes are within a few minutes of each other:

   rah 'date'

7. Open the SYSCAT.DATATYPES catalog view and check whether your database has any user-defined data types that have names that are the same as the names of any built-in data types. If so, drop those user-defined data types and re-create them using new names that are not restricted. Otherwise, the UPGRADE DATABASE command will fail.
8. Issue the following commands to log out of the SYSADM user and then exit the container shell:

   exit; exit

9. If you are using IBM SpectrumScale (formerly called GPFS) and if you are unsure of your file system device names, retrieve it by issuing the following command:

   mmlsmount all

10. On the head node host, stop the Db2 fault monitoring daemon by issuing the following Docker or Podman command:

    docker exec -it dashDB /mnt/blumeta0/home/db2inst1/sqllib/bin/db2fmcu -d

    podman exec -it dashDB /mnt/blumeta0/home/db2inst1/sqllib/bin/db2fmcu -d

11. Take an offline backup of the BLUDB database as described in Backing up by using the db_backup command.
12. For each file system associated with your Db2W deployment, issue the following command to verify the integrity of the backup image:

    db_ckbkp /imagefile

    where imagefile represents the fully-qualified name of the image file.
13. Run the db2ckupgrade utility prior to upgrading to make sure that the database is ready for the upgrade. The command verifies that a list of conditions is true to succeed at the database upgrade. For more information, see Verifying the database before the upgrade.