Best Practices - DB2 MultiNode iDataAgent

Updated

Creating Subclients

As a best practice, it is recommended that you create separate subclients to backup data that undergo frequent changes.

For example, if the EXAMPLE and USERS dbspaces undergo frequent changes, you can create a separate subclient for each tablespace.

Example:

User-defined subclient: Test1

Content: EXAMPLE

User-defined subclient: Test2

Content: USERS

Best Practice: Create a separate user-defined subclient for the log files on the client.

Distributing the client data using subclients as recommended above, can help improve backup performance by organizing the workload on the client into logical groupings.

Reconfiguring the Default Subclient Content

We recommend that you do not re-configure the content of a default subclient because this would disable its capability to serve as a catch-all entity for client data. As a result, some data will not get backed up or scanned.

Restarting Jobs Only on Failed Nodes

By default, if a backup/restore job for the DB2 MultiNode iDataAgent goes to a pending state, and if the job has completed on some of the nodes, the restart option will start the job on all the nodes. To start the job only on the nodes where the job has failed, a certain timeout period can be set to elapse before a job can be restarted on a successful node.

Use the following steps to specify the timeout period in seconds, on all the nodes:

  1. From the CommCell Browser, navigate to Client Computers.

  2. Right-click the <DB2 MultiNode Client> in which you want to add the additional setting, and then click Properties.

  3. Click the additional setting Settings tab.

  4. Click Add.

  5. In the Name box, type sBKPRESTARTFAILEDNODESTimeOut.

  6. The Category, Type and Value will be automatically displayed.

  7. Click OK.

Several options are available for enhancing backup performance and reduce the network bandwidth used for performing backups. These options include:

  • Specifying the buffer size, and the number of buffers for the backups. When you back up the database to multiple locations, provide a sufficient buffer value to improve performance.

  • Setting the parallelism for backup and restore operations: If the DB2 database contains a large number of tablespaces and indexes, set the maximum number of concurrent parallelism queries to take advantage of the available input and output bandwidth, and the DB2 server processor power. This targets the input and output intensive queries (for example, tablespace scans, or large index scans) and CPU intensive queries (for example, joins, sorts, or complex expressions). If the number is not set, an optimal value is automatically chosen.

    Note: The DB2 Agent runs the backups by using a system-generated script that is performed from the command line. The CommCell Console serves as a front-end user interface for specifying various backup arguments and parameters that are passed to the backup script.

Disabling Optimization for Restores from a Tape Library

When you restore from a tape library, or you run a multi stream third party command line backup, disable optimization. For more information, see Disabling Optimization for Database Restores.

Run a Full CommCell Console GUI Backup after Changing a Database's Table Spaces

If you add, update, or delete a database's table space, run a full backup from the CommCell Console as soon as possible. In this situation, a full backup of the source database is mandatory if you want to run a redirect restore. Only a full CommCell Console GUI backup syncs all the table space information so that the backup can be used for a redirect restore. Conversely, third-party command line full backups don't update the necessary Commvault database metadata. Consequently, the correct list of table spaces is not displayed on the Browse and Restore dialog box when running a redirect restore.