Note the following restrictions:
The following restrictions apply to the backup utility:
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.
DB2 Universal Database (UDB) supports cross-platform backup and restore operations.
You can restore databases created on a DB2 UDB Version 8 32-bit Windows 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 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, HP-UX, Linux PPC, Linux zSeries, 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).
The maximum block size limit for 3480 and 3490 tape devices on Linux is 61 440 bytes
Device | Attachment | Block Size Limit | DB2 buffer size limit (in 4-KB pages) |
---|---|---|---|
3480 | s370 | 61 440 | 15 |
3490 | s370 | 61 440 | 15 |
When calling the BACKUP DATABASE or RESTORE DATABASE commands, you can specify that you want to use the Tivoli 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:
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 command line, the values should be also set in the /etc/services file.
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:
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.
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".
| | |The health monitor and the fault monitor are tools that work on a single |database instance. The health monitor uses health indicators to evaluate the health of specific aspects of database manager performance |or database performance. A health indicator measures the health of some aspect |of a specific class of database objects, such as a table space. Health indicators |can be evaluated against specific criteria to determine the health of that |class of database object. In addition, health indicators can generate alerts |to notify you when an indicator exceeds a threshold or indicates a database |object is in a non-normal state
|By comparison, the fault monitor is solely responsible for keeping the |instance it is monitoring up and running. If the DB2 UDB instance it is monitoring |terminates unexpectedly, the fault monitor restarts the instance. The fault |monitor is not available on Windows.
| | |To turn off fault monitoring for the database instance DB2INST1, type the |following command from a DB2 UDB command window:
|db2fm -i db2inst1 -f no| |
To confirm that fault monitor is no longer running for DB2INST1, type the |following command on UNIX systems:
|ps -ef|grep -i fm|
On Linux systems, type the following command:
|ps auxw|grep -i fm|
An entry that shows db2fmd and DB2INST1 indicates that the fault monitor |is still running on that instance. To turn off the fault monitor, type the |following command as the instance owner:
|db2fm -i db2inst1 -D[ Top of page |Previous page | Next page | Contents ]