IBM Db2 FAQS

What are the best practices for taking a backup?

The following best practices can help improve backup and restore performance:

1. Compression should be enabled

2. The following parameters should be optimally configured:

   • Utility Heap Size (UTIL_HEAP_SZ) 

   • No. of CPUs

   • No. of Table Spaces

   • Extent Size

   • Page Size

3. Parallelism & Buffer configuration may be used to improve backup performance. Parameters that should be configured are:

   • Parallelism

   • Buffer Size

   • No. of Buffers

More information about backup best practices is available in IBM Knowledge Center.

How to take a full online backup of a db2 database?

For the examples below we are using the database name as TEST and location as ‘/backup_dir’. If no path is provided backups will be generated in the current directory.

Non-DPF backups

db2 backup db TEST  online to  /backup_dir compress include logs

DPF, SSV backups

db2 backup db TEST ON ALL DBPARTITIONNUMS online to /backup_dir compress include logs

DPF, NONSSV backups

db2_all "db2 backup db TEST online to /backup_dir compress include logs"

Multi-part backup

b2 backup db TEST  online to  /backup_dir1,/backup_dir2,/backup_dir3 compress include logs

What is the user-side validation prior to the snapshot?

User-side validation prior to a snapshot operation:

• The user must validate the backup files using db2ckbkp utility on the staging host.

• The user must validate the archive logs using db2cklog utility on the staging host.

• The authenticity of archive logs would be managed by the user.

• The user has to provide the first active log at the staging database log directory location after applying the logs.

• If there is a scenario where a user performed some load copy (non-logged transactions) operations on the source side then it’s the responsibility of the user to make those non-logged transactions available on the staging database.

How to use the Delphix Continuous Data Engine key pair?

Perform the following steps to use the Delphix Continuous Data Engine key pair:

1. Select Public Key for the Login Type.

2. Click View Public Key.

3. Copy the public key that is displayed, and append it to the end of your ~/.ssh/authorized_keys file. If this file does not exist, you must create it. 

   1. Run chmod 600 ~/.ssh/authorized_keys to allow only the file's owner to read and write to it (make sure the file is owned by you).

   2. Run chmod 755 ~ to restrict access to your home directory so that no other may write to it.

   3. Run chmod 700 ~/.ssh so that others cannot write to it. The ~/.ssh directory is not writable by group or others. Otherwise, authentication will fail.

How to update the Db2 version level?

This is applicable only when the target environment is using a different Db2 fix pack level than the source. Consider the following scenarios for the optional prerequisite mentioned above:

1. if your source environment uses Db2 version 11.5.5 and your target environment uses Db2 11.5.8 or a later fix pack, you need to update the databases in the target environment.

2. If your databases were created or upgraded to Db2 Version 11.1 GA and you applied Db2 Version 11.1 Fix Pack 1 or later, then running the above command will automatically apply all updates required from Version 11.1 GA up to and including the fix pack level that you are installing.

3. To know how to update databases, see db2updv115 - Update database to Version 11.5 mod pack command

4. Certain database or instance operations are restricted while an online fix pack update is in progress.

5. See db2updv111 - Update database to Version 11.1 fix pack command, which mentions it is mandatory to run db2updv111 on the database if one is coming from a higher version of fix pack to Lower OR vice versa.

6. For more information, you can also refer: Update the databases for a Db2 11.1.x fix pack

If your source environment uses version 11.1.x and your target is to be upgraded to 11.5.x, following are the steps to perform for an in-place upgrade of dsource and VDB.

How to match the DB2 common directory when the target host is added in multiple Delphix Continuous Data Engines?

The connector path directory structure is as follows in the target host  <toolkit path>/<Delphix_COMMON>/DB2_18f4ff11-b758-4bf2-9a37-719a22f5a4b8/logs/<instance name>. However, if there are multiple Delphix Continuous Data Engines using this target, then multiple common directories are created on the target host like this (three engines access the same target and plugin code):

delphix@support-tools:/nas/support/truist/69459$ ls -lart
total 875888
drwxrwxr-x  8 delphix delphix      8192 Oct 20 11:54 Delphix_COMMON_17b1429568c0_290c7f251296_28_host/
drwxrwxr-x  8 delphix delphix      8192 Oct 20 11:59 Delphix_COMMON_ce55f7389c2d_7e296fa53e07_24_host/
drwxrwxr-x  8 delphix delphix      8192 Oct 20 12:04 Delphix_COMMON_cd1f039b057f_63d00dbd3271_22_host/
drwxrwx---  5 delphix delphix       152 Oct 27 11:59 Delphix_cd1f039b057f_63d00dbd3271_23_host/

To identify the common directory corresponding to the Delphix Continuous Data Engine:

• Collect the Engine UUID (You can get "Server ID" from the GUI "About" menu). In this case Engine UUID is:

  CODE

  421de915-558f-68a1-fac8-cd1f039b057f

• Take the last group of numbers:

  CODE

  cd1f039b057f

• Match this group with the FIRST group of numbers following the "COMMON_" characters in the directory name, and in this case it is:

  CODE

  Delphix_COMMON_cd1f039b057f_63d00dbd3271_22_host