Data Recovery and High Availability

Backup overview

Note the following restrictions:

|
• The starting of an online backup operation of a DMS table space is allowed |when a table within the same table space is being reorganized online. There |may be lock waits of the reorganization operation during the truncate phase.
|
• The starting of an online backup operation of an SMS table space is not |allowed when a table within the same table space is being reorganized online. |Both operations require an exclusive lock.

Using backup

The following restrictions apply to the backup utility:

|
• A table space backup operation and a table space restore operation cannot |be run at the same time, even if different table spaces are involved.
|
• If you want to be able to do rollforward recovery in a partitioned database |environment, you must regularly back up the database on the list of nodes, |and you must have at least one backup image of the rest of the nodes in the |system (even those that do not contain user data for that database). Two |situations require the backed-up image of a database partition at a database |partition server that does not contain user data for the database: |
  |
  • You added a database partition server to the database system after taking |the last backup, and you need to do forward recovery on this database partition |server.
  |
  • Point-in-time recovery is used, which requires that all database partitions |in the system are in rollforward pending state.
  |
  • Online backup operations for DMS table spaces are incompatible with the |following operations: |
    |
    • load
    |
    • Reorganization (offline only); (online reorganization of a table in the |table space being backed up can be used, although there may be lock waits |during the truncate phase of the reorganization operation).
    |
    • drop table space
    |
    • table truncation
    |
    • index creation
    |
    • not logged initially (used with the CREATE TABLE and ALTER TABLE statements)

High availability disaster recovery overview

When performing the START HADR, STOP HADR, or TAKEOVER HADR commands, the corresponding error codes might be generated: SQL01767N, SQL01769N, or SQL01770N with a reason code of 98. The reason code indicates that there is no installed license for HADR on the server where the command was run. To correct the problem, install a valid HADR license using db2licm or install a version of the server that contains a valid HADR license as part of its distribution.

Cross-platform backup and restore support

DB2 Universal Database^(TM) (UDB) supports cross-platform backup and restore operations.

You can restore databases created on a DB2^(R) UDB Version 8 32-bit Windows^(R) platform to a DB2 UDB Version 8 64-bit Windows platform, or the reverse.

You can restore databases created on a DB2 UDB Version 8 32-bit Linux^(TM) x86 platform to a DB2 UDB Version 8 64-bit Linux x86-64 or IA64 platform, or the reverse.

You can restore databases created on DB2 UDB Version 8 AIX^(R), HP-UX, Linux PPC, Linux zSeries^(R), or the Solaris Operating Environment platforms, in 32-bit or 64-bit, to DB2 UDB Version 8 AIX, HP-UX, Linux PPC, Linux zSeries, or Solaris Operating Environment platforms (32-bit or 64-bit).

Backing up to tape (Linux)

The maximum block size limit for 3480 and 3490 tape devices on Linux is 61 440 bytes

Tivoli Storage Manager

When calling the BACKUP DATABASE or RESTORE DATABASE commands, you can specify that you want to use the Tivoli^(R) Storage Manager (TSM) product to manage database or table space backup or restore operation. The minimum required level of TSM client API is Version 4.2.0, except on the following:

• 64-bit Solaris systems which require TSM client API Version 4.2.1.
• 64-bit Windows NT^(R) operating systems which require TSM client API Version 5.1.
• 32-bit Linux for iSeries^(TM) and pSeries^(R) which requires at minimum TSM client API Version 5.1.5
• |64-bit Linux for iSeries and pSeries which requires at minimum TSM client |API Version 5.3
• 64-bit Linux on AMD Opteron systems which require a minimum TSM client API Version 5.2.0.
• Linux for zSeries 64-bit which requires a minimum TSM client API Version 5.2.2.

Value restrictions for the HADR local host and local service parameters

When specifying values for the high availability disaster recovery (HADR) local host and local service parameters (HADR_LOCAL_SVC and HADR_REMOTE_SVC) while preparing an update database configuration command , the values must be ports that are not in use for any other service. If the parameters are being configured using the Linux or UNIX^(R) command line, the values should be also set in the /etc/services file.

Additional system requirements for high availability disaster recovery

If you create a table space on the primary database and log replay fails on the standby database because the containers are not available, the primary database does not receive an error message stating that the log replay failed.

To check for log replay errors, you must monitor the db2diag.log and the administration log on the standby database when you are creating new table spaces.

If a takeover operation occurs, the new table space that you created is not available on the new primary database. To recover from this situation, restore the table space on the new primary database from a backup image.

In the following example, table space MY_TABLESPACE is restored on database MY_DATABASE before it is used as the new primary database:

1. db2 connect to my_database
2. db2 list tablespaces show detail
   Note:
   Run the db2 list tablespaces show detail command to show the status of all table spaces and to obtain the table space ID number required for Step 5.
3. db2 stop hadr on database my_database
4. db2 "restore database my_database tablespace (my_tablespace) online redirect"
5. db2 "set tablespace containers for my_tablespace_ID_# ignore rollforward container operations using (path '/my_new_container_path/')"
6. db2 "restore database my_database continue"
7. db2 rollforward database my_database to end of logs and stop tablespace "(my_tablespace)"
8. db2 start hadr on database my_database as primary

Non-replicated operations for high availability disaster recovery

Version 8.2 documentation states:

BLOBs and CLOBs are not replicated; however, the space for them will be allocated on the standby database.

The statement should read as follows:

Non-logged BLOBs and CLOBs are not replicated; however, the space for them will be allocated on the standby database.

HADR does not support raw logs

High availability disaster recovery (HADR) does not support the use of raw I/O (direct disk access) for database log files. If HADR is started with the START HADR command, or if the database is restarted with HADR configured, and raw logs are detected, the associated command will fail with SQL1768N reason code "9".