ADM8000C Backup has been terminated. The SQLCODE returned is SQLCODE.

ADM8001W Incremental backup was not enabled for this database because the TRACKMOD DB configuration parameter was not enabled.

ADM8002W This backup image cannot be used for ROLLFORWARD because the logs associated with this backup has been overwritten on the raw device. Use a more recent backup image.

ADM8003C Restore has been terminated. The SQLCODE returned is SQLCODE.

ADM8004W Incremental backup was not enabled for table space tablespaceName (ID tablespaceID) because the TRACKMOD configuration parameter was not enabled.

ADM8005W Incremental backup was not enabled for table space tablespaceName (ID tablespaceID). A non-incremental backup of this table space is required.

ADM8006W The database manager cannot use the specified restore buffer size of restoreBufferSize 4K pages. A restore buffer size must be multiple of backup buffer size of backupBufferSize 4K pages. The restore operation will continue with the default buffer size.

ADM8007W The database manager cannot perform multiple concurrent incremental restores.

ADM8008W The database manager could not find and/or delete the online reorganization state files for all table spaces during restore. Manual intervention may be needed to remove the file(s).

ADM8009W Could not find and/or delete the online reorganization state files for table space tablespaceName (ID tablespaceID ) during restore. Manual intervention may be needed to remove the file(s).

ADM8010E Backup was unable to copy requested log file logfileName for inclusion in the backup image. The backup has been aborted.

ADM8011W The database backup succeeded. However, the database server was unable to create part of the incremental chain of images during the backup, and will be unable to use the affected images during restore. Specifically, you will not be able to use the backup image with timestamp timestamp for incremental restores involving table space table-space-name.

ADM8012W The database backup succeeded. However, the entry in the recovery history file corresponding to the backup image with timestamp timestamp will not be well-formed, because a write error occurred while updating the recovery history file itself. See the db2diag log file for more information.

ADM8013E The command or operation failed due to an error in the encryption or compression library.

Explanation

Initialization of the encryption or compression library failed causing the command or operation to fail.

User response

Check the admin log and check the associated SQLCA structure. The SQLCA structure contains an associated SQLCODE which provides further explanation on the error and applicable user responses.

ADM8014W The keystore file has changed.

Explanation

DB2 native encryption uses a master key to manage encryption for data in databases. The database manager creates new master keys in two scenarios:

  • A new, encrypted database is created without a manually created master key being specified, so the database manager creates a master key for the new database.
  • The ADMIN_ROTATE_MASTER_KEY built-in stored procedure is invoked to rotate the master key for a database without a manually created master key being specified, so the database manager creates a new master key for the database.

The master keys and corresponding labels are stored in a keystore file. This message is printed to inform you that the database manager has inserted a new master key and master key label into the keystore file.

User response

To maintain data integrity, back up the keystore file.

ADM8500W The database manager has failed to read from the history file because of a possible data corruption. Ensure that the file exists and is intact.

ADM8501W The database manager has failed to write to the history file because the disk is full.

ADM8502W The history file is corrupt. An unrecoverable error has been detected with the file. The existing file has been deleted and a backup has been made. If you would like to determine the root cause of the problem, contact IBM Support. Otherwise, no further action is needed.

ADM8503W The database manager was unable to record a history entry for operation operation.

ADM8504I Successfully deleted the backup image with timestamp timestamp.

ADM8505I Successfully deleted the load copy image with timestamp timestamp.

ADM8506I Successfully deleted the following database logs log-list in log chain log-chain.

ADM8507N Unable to delete the backup image with timestamp timestamp.

Explanation

The database manager attempted to delete the given backup image, but was unsuccessful.

User response

Verify that the database manager has access to the storage manager or directory where the backup images are stored. See the db2diag log file for more information.

ADM8508N Unable to delete the load copy image with timestamp timestamp.

Explanation

The database manager attempted to delete the given load copy image, but was unsuccessful.

User response

Verify that the database manager has access to the storage manager or directory where the load copy images are stored. See the db2diag log file for more information.

ADM8509N Unable to delete the database logs log-list in log chain log-chain.

Explanation

The database manager attempted to delete the given database logs, but was unsuccessful.

User response

Verify that the database manager has access to the storage manager or directory where the log files are stored. See the db2diag log file for more information.

ADM9000W Prefetching was disabled during sort merge; performance may be suboptimal. If this message persists, consider increasing the buffer pool size for temporary table space tablespaceName (ID tablespaceID) or increase the value of the SORTHEAP DB configuration parameter to reduce the extent of sort spilling.

ADM9500W Too many concurrent updates had occurred on table tableName (ID tableID) and table space tablespaceName (ID tablespaceID) during online index create/reorganization. Thus, it will take a longer time to finish online index create/reorganization. You may want to increase your UTIL_HEAP_SZ DB configuration parameter.

ADM9501W Index reorganization has started for table tableName (ID tableID) and table space tablespaceName (ID tablespaceID).

Explanation

The data server is reorganizing the indexes for the specified table. The re-organization is either for nonpartitioned indexes on a partitioned table or for indexes on a nonpartitioned table.

User response

No response is required.

ADM9502W Index reorganization is complete for table tableName (ID tableID) and table space tablespaceName (ID tablespaceID).

Explanation

The data server reorganized the indexes for the specified table. The index reorganization was either for nonpartitioned indexes on a partitioned table or for indexes on a nonpartitioned table.

User response

No response is required.

ADM9503W Reorganizing index IID indexIID (OBJECTID indexObjectID) in table space indexTablespaceName (ID indexTablespaceID) for table tableName (ID tableID) in table space tablespaceName (ID tablespaceID).

Explanation

The data server is reorganizing the specified index. The reorganization is either for nonpartitioned indexes on a partitioned table or for indexes on a nonpartitioned table.

User response

No response is required.

ADM9504W Index reorganization on table tableName (ID tableID) and table space tablespaceName (ID tablespaceID) failed on this database partition with SQLCODE SQLCODE reason code reasonCode.

Explanation

Index reorganization failed on this database partition for the reason described by the SQLCODE. The indexes referred to in this context are either nonpartitioned indexes on a partitioned table or indexes on a nonpartitioned table

User response

Correct the problem that is described by the SQLCODE, and then retry the REORG INDEXES command on the database partition.

ADM9505W Online index reorganization on table tableName (ID tableID) and table space tablespaceName (ID tablespaceID) has been switched to offline mode because the indexes are marked for rebuild. These indexes may have been marked for rebuild during a roll forward through an index creation and/or recreation. If this is the case, consider setting the INDEXREC database manager configuration parameter to RESTART. This will cause indexes that are marked for rebuild during roll forward to be rebuilt during RESTART DATABASE processing.

ADM9506W HADR is enabled, but full logging is disabled for any index creation, recreation, or reorganization on table table-name (table object id: object-id) in tablespace tablespace-name (tablespace id: tablespace-id), since you have explicitly requested to disable it. As a result, any index build operations on this table will not be recovered immediately on the secondary database server using HADR. Indexes on the secondary database server will be recreated implicitly at the end of the HADR takeover process or after the HADR takeover process when the underlying tables are to be accessed. If this is not the desired behavior, enable the full logging on the table before any create, recreate, or reorg index is performed.

ADM9507W When HADR is enabled, it is recommended that the database configuration parameter LOGINDEXBUILD is set to ON, on both the HADR primary database server and the HADR secondary database server. Otherwise, you may not log your index creation, recreation, or reorganization on current or future HADR primary database server. Any non-fully logged index creation, recreation, or reorganization on the primary database server will not be recovered on the secondary database server using HADR. Those indexes which cannot be recovered will be marked as invalid, and will be rebuilt implicitly at the end of the HADR takeover process or after the HADR takeover process when the underlying tables are accessed. If this is not the desired behavior, enable the full logging or use the default setting for this configuration parameter before any index build operations take place.

ADM9508W When HADR is enabled, it is recommended that the database or database manager configuration parameter INDEXREC is set to either RESTART or ACCESS in order to enable redo of any index creation, recreation or reorganization. Otherwise, any fully logged index creation, recreation, or reorganization on the primary database server will not be recovered on the secondary database server using HADR. Those indexes which cannot be recovered will be marked as invalid and will be rebuilt implicitly at the end of the HADR takeover process or after the HADR takeover process when the underlying tables are accessed. If this is not the desired behavior, update INDEXREC or use the default setting for this configuration parameter before any index build operations take place.

ADM9509W It is recommended that the database configuration parameter LOGINDEXBUILD is set to ON before HADR is started. Otherwise, any index creation, recreate, or reorganization on the current or future primary database server may not be recovered on the current or future secondary database server using HADR. Those indexes which cannot be recovered will be marked as invalid and will be rebuilt implicitly either at the end of the HADR takeover process or after the HADR takeover process when the underlying tables are to be accessed. If this is not the desired behavior, update the database configuration parameter LOGINDEXBUILD to ON.

ADM9510W An error (sqlcode sqlcode) occurred which prevented the completion of the index rebuild process. Any invalid indexes that have not been rebuilt when the process terminated will be recreated on the first table access. The index rebuild process was invoked either during an explicit or implicit restarting of the database, or at the end of the HADR takeover.

ADM9511W Index reorganization proceeds on index indexname (IID indexIID, OBJECTID indexObjectID) in table space indexTablespaceName (ID indexTablespaceID) for table tableName (ID tableID) in table space ID tablespaceID.

ADM9512W Index reorganization for index indexname (IID indexIID, OBJECTID indexObjectID) in table space indexTablespaceName (ID indexTablespaceID) for table tableName (ID tableID) in table space ID tablespaceID failed on this node with SQLCODE SQLCODE reason code reasonCode. To resolve this problem, re-submit the REORG INDEX command on the failing node(s).

ADM9513W Online index reorganization on table tableName (ID tableID) in table space tablespaceName (ID tablespaceID) found one or more indexes that are marked invalid and cannot proceed until they are rebuilt.

Explanation

The data server will automatically rebuild the indexes on this table. If any nonpartitioned indexes are being rebuilt, the data server will obtain a super exclusive Z table lock for the duration of the rebuild. If only partitioned indexes are being rebuilt, the data server will obtain a super exclusive Z partition lock on each data partition that has invalid indexes for the duration of the rebuild. After the rebuild is complete, the online index reorganization will proceed (using the original lock modes) for any indexes that were specified for reorganization by the current command and have not yet been rebuilt.

User response

No response is required.

ADM9514I BEGIN async index cleanup on table tableName (ID tableID) and table space tablespaceName (ID tablespaceID).

ADM9515I END async index cleanup on table tableName (ID tableID) and table space tablespaceName (ID tablespaceID).

ADM9516W Indexes on the table table_identifier were marked to be rebuilt while upgrading the database.

Explanation

The table_identifier is shown in one of the following forms:

  • TBSPACEID=table_space_id.TABLEID=table_id
  • schema_name.table_name

The indexes on the identified table must be rebuilt because one of the following situations was encountered during a database upgrade:

  • A root page has insufficient space
  • A type-1 index was detected
  • One or more non-severe errors occurred converting the index page.

User response

Indexes will be rebuilt automatically after upgrading the database in one of the following ways:

  • If the indexrec database configuration parameter is set to RESTART or RESTART_NO_REDO, then issuing the RESTART DATABASE command will trigger the rebuild of the indexes.
  • If the indexrec database configuration parameter is set to ACCESS or ACCESS_NO_REDO, then the indexes will be rebuilt on first access to the table on which the indexes are defined. The ADMIN_GET_TAB_INFO function can be used to identify which tables have indexes that require rebuilding.

There will be a one-time performance impact while the indexes are rebuilt.

ADM9517W The index object with ID object-ID in table space table-space-ID for table table-name has been marked invalid during log replay on an HADR standby database. The index will be rebuilt automatically upon subsequent query to this table, if there is a fail over to make this database the HADR primary.

Explanation

The index object can no longer be maintained due to the invalid state. Subsequent log records on this index objects are ignored by database recovery. If no action is taken, in the event of HADR fail over that makes this database the HADR primary, the index will be rebuilt automatically upon subsequent query to this table.

User response

Reinitialize the HADR standby via a new backup of the primary database, to avoid the need of index rebuild in the event of HADR fail over.

ADM9518I Index reorganization has started for the partitioned indexes on data partition dataPartitionID of table tableName (ID tableID) and table space tablespace-Name (ID tablespaceID).

Explanation

The data server is reorganizing the partitioned indexes for the specified data partition.

User response

No response is required.

ADM9519I Index reorganization is complete for partitioned indexes on data partition dataPartitionID of table tableName (ID tableID) and table space tablespaceName (ID tablespaceID).

Explanation

The data server has reorganized the partitioned indexes for the specified data partition.

User response

No response is required.

ADM9520I Reorganizing partitioned index IID indexIID (OBJECTID indexObjectID) in table space indexTablespaceName (ID indexTablespaceID) for data partition dataPartitionID of table tableName (ID tableID) in table space tablespaceName (ID tablespaceID).

Explanation

The data server is reorganizing the index partition on the specified data partition for the specified partitioned index.

User response

No response is required.

ADM9521W Index reorganization for partitioned indexes on data partition dataPartitionID of table tableName (ID tableID) and table space tablespaceName (ID tablespaceID) failed on this database partition with SQLCODE SQLCODE reason code reasonCode.

Explanation

Index reorganization of the partitioned indexes failed on this database partition for the reason described by the SQLCODE.

User response

Correct the problem that is described by the SQLCODE, and then retry the REORG INDEXES command on the database partition.

ADM9522I Index reorganization is complete for partitioned indexes on data partition datapartitionID of table tableName (ID tableID) and table space tablespaceName (ID tablespaceID).

Explanation

The data server has reorganized the partitioned indexes for the specified data partition. Some partitioned indexes on the data partition might still need to be reorganized. This index reorganization will occur later during the reorganization.

User response

No response is required.

ADM9523W An error was encountered on index object with ID object-ID in table space table-space-ID for table table-name during log replay on an HADR standby database. The index object has been marked invalid. The index will be rebuilt automatically upon subsequent query to this table, if there is a fail over to make this database the HADR primary.

Explanation

The index object can no longer be maintained due to the unexpected error. Subsequent log records on this index objects are ignored by database recovery. If no action is taken, in the event of HADR fail over that makes this database the HADR primary, the index will be rebuilt automatically upon subsequent query to this table.

User response

Contact IBM Support to investigate the root cause of the index error. Reinitialize the HADR standby via a new backup of the primary database, to avoid the need of index rebuild in the event of HADR fail over.

ADM9524W An error was encountered on index object with ID object-ID in table space table-space-ID for table table-name during database recovery. The index object has been marked invalid. The index will be rebuilt automatically after the completion of database recovery.

Explanation

The index object can no longer be maintained due to the unexpected error. Subsequent log records on this index objects are ignored by database recovery. The index will be rebuilt automatically, either immediately upon completion of database recovery, or upon subsequent query to this table, depending on the value of indexrec database configuration parameter.

User response

Contact IBM Support to investigate the root cause of the index error.

ADM9525W The index object with ID object-ID in table space table-space-ID for table table-name has been marked invalid. The index will be rebuilt automatically after the completion of database recovery.

Explanation

The index object can no longer be maintained due to the invalid state. Subsequent log records on this index objects are ignored by database recovery. The index will be rebuilt automatically, either immediately upon completion of database recovery, or upon subsequent query to this table, depending on the value of indexrec database configuration parameter.

User response

No response is required.

ADM10000W A Java exception has been caught. The Java stack traceback has been written to the db2diag log file.

ADM10500E Health indicator Health-Indicator-Short-Description (Health-Indicator-Short-Name) breached the Threshold-Bound-Name alarm threshold of Threshold-Bound-Value with value Health-Indicator-Value on Monitored-Object-Type Monitored-Object-Name. Calculation: Formula-String = Formula-with-Values = Health-Indicator-Value. History (Timestamp, Value, Formula): Health-Indicator-History-List

Explanation

The health monitor generated an alert because the alarm threshold for this health indicator was breached. This situation should be addressed immediately as it can lead to a degradation in database performance or an interruption in operation.

User response

You can use CLP commands to obtain recommendations, and in some cases take actions, to resolve this alert.

From the CLP, you can obtain the Health indicator description and recommended actions by executing the following commands:

  • GET RECOMMENDATIONS FOR HEALTH INDICATOR Health-Indicator-Short-Name
  • GET DESCRIPTION FOR HEALTH INDICATOR Health-Indicator-Short-Name

ADM10501W Health indicator Health-Indicator-Short-Description (Health-Indicator-Short-Name) breached the Threshold-Bound-Name warning threshold of Threshold-Bound-Value with value Health-Indicator-Value on Monitored-Object-Type Monitored-Object-Name. Calculation: Formula-String = Formula-with-Values = Health-Indicator-Value. History (Timestamp, Value, Formula): Health-Indicator-History-List

Explanation

The health monitor generated an alert because the warning threshold for this health indicator was breached. This condition does not necessarily require immediate attention, but rather it may lead to a degradation in database performance or an interruption in operation if the condition worsens over time.

User response

You can use CLP commands to obtain recommendations, and in some cases take actions, to resolve this alert.

From the CLP, you can obtain the Health indicator description and recommended actions by executing the following commands:

  • GET RECOMMENDATIONS FOR HEALTH INDICATOR Health-Indicator-Short-Name
  • GET DESCRIPTION FOR HEALTH INDICATOR Health-Indicator-Short-Name

ADM10502W Health indicator Health-Indicator-Short-Description (Health-Indicator-Short-Name) is in state Health-Indicator-Value on Monitored-Object-Type Monitored-Object-Name.

Explanation

The health monitor generated an alert because the state value of this health indicator was non-normal. This condition does not necessarily require immediate attention, but rather it will depend on the expected state of the database given operations being performed on it at the time, and the prevailing workload.

User response

You can use CLP commands to obtain recommendations, and in some cases take actions, to resolve this alert.

From the CLP, you can obtain the Health indicator description and recommended actions by executing the following commands:

  • GET RECOMMENDATIONS FOR HEALTH INDICATOR Health-Indicator-Short-Name
  • GET DESCRIPTION FOR HEALTH INDICATOR Health-Indicator-Short-Name

ADM10503I The health monitor has initiated an alert action, running Alert-Action-Type Alert-Action-Name on system System-Name, because the Health Indicator Health-Indicator-Short-Description (Health-Indicator-Short-Name) is in the Alert-State alert state on Monitored-Object-Type Monitored-Object-Name.

Explanation

The health monitor was configured to initiate the action when the health indicator is in this alert state. This message is an indication that the action was indeed initiated.

User response

No action is required.

ADM10504E The health monitor failed, with sqlcode SQLCODE, to initiate an alert action, running Alert-Action-Type Alert-Action-Name on system System-Name, when the Health Indicator Health-Indicator-Short-Description (Health-Indicator-Short-Name) went into the Alert-State alert state on Monitored-Object-Type Monitored-Object-Name.

Explanation

The health monitor was configured to initiate the action when the health indicator is in this alert state, but received this SQLCODE when it called the API to execute the action. The alert action was not initiated.

User response

Check the First Failure Service log (db2diag log file) for a record detailing the failure.

ADM10505E The DB2 Service does not have the necessary authority to run the Health Monitor. The Health Monitor has been shut down. If the service is configured to log on using the Local System account (SYSTEM), then it must be changed to log on with a particular user account. If it is configured to log on with a particular user account, then you must ensure that the user account is valid and has the necessary access rights to run the DB2 service. Once the log on configuration has been corrected, it is necessary to restart the DB2 service to start the Health Monitor.

ADM10506E The health monitor is unable to send an alert notification because the SMTP Server (smtp_server) DB2 Administration Server configuration parameter is not set. Update the smtp_server configuration parameter with the name of a valid SMTP server.

Explanation

The health monitor was configured to send notifications upon alert occurrence, but was unable to send the notification because no SMTP server name was specified for the SMTP Server DAS configuration parameter.

User response

Update the smtp_server configuration parameter with the name of a valid SMTP server.

ADM10507E The health monitor was unable to send an alert notification because the server SMTP-Server-Name, specified in the SMTP Server DB2 Administration Server configuration parameter (smtp_server), does not appear to be an SMTP server. Ensure that a valid SMTP server name is specified in the DB2 Administration Server configuration.

Explanation

The health monitor was configured to send notifications upon alert occurrence, but was unable to send the notification because the server specified in the DB2 Administration Server configuration does not have SMTP server functionality.

User response

Ensure that a valid SMTP server name is specified in the DB2 Administration Server configuration for the smtp_server parameter.

ADM10508E The health monitor was unable to send an alert notification because invalid recipient(s) were specified in the health notification list which contains Notification-List. Update the Contact record with the invalid address.

Explanation

The health monitor was configured to send notifications upon alert occurrence, but was unable to send the notification because one or more addresses for the contacts specified on the health notification list are invalid.

User response

Check the Contact record for the contacts specified for health notification and update the invalid recipient address.

ADM10509E The health monitor was unable to send an alert notification because the notification was sent by an invalid Sender with the address Sender-Address. Look at the SMTP server configuration. If all the settings are correct, contact DB2 Support.

Explanation

The health monitor was configured to send notifications upon alert occurrence, but was unable to send the notification because the Sender address was rejected as unacceptable by the SMTP server. The Sender address has the format <instance name>@<host>, where 'instance' is running on 'host'.

User response

Look at the SMTP server configuration. If all the settings are correct, contact DB2 Support.

ADM10510E The health monitor was unable to send an alert notification because the SMTP server issued the following error: SMTP_ERROR. Check the SMTP server documentation for information on the error code that was returned. If the problem cannot be remedied, contact DB2 Support.

Explanation

The health monitor was configured to send notifications upon alert occurrence, but was unable to send the notification because the SMTP server encountered an error.

User response

Check the SMTP server documentation for information on the error code that was returned. If the problem cannot be remedied, contact DB2 Support.

ADM10511E The health monitor was unable to send an alert notification because there was a communication error with the SMTP server. Check the First Failure Service log (db2diag log file) for a record detailing the failure.

Explanation

The health monitor was configured to send notifications upon alert occurrence, but was unable to send the notification because there was a communication error when trying to reach the SMTP server.

User response

Check the First Failure Service log (db2diag log file) for a record detailing the failure.

ADM10512W Health indicator Health-Indicator-Short-Description (Health-Indicator-Short-Name) is in state Health-Indicator-Value on Monitored-Object-Type Monitored-Object-Name. Collection (Object Name, Timestamp, Value, Detail): Collection.

Explanation

The health monitor generated an alert because the state value of this health indicator was non-normal. This condition does not necessarily require immediate attention but indicates that a non-optimal situation prevails with respect to the health of one or many object collected under this health indicator. The situation may get resolved automatically if the corresponding automatic maintenance utility was turned on and the state is automated .

User response

You can use CLP commands to obtain recommendations, and in some cases take actions, to resolve this alert.

From the CLP, you can obtain the Health indicator description and recommended actions by executing the following commands:

  • GET RECOMMENDATIONS FOR HEALTH INDICATOR Health-Indicator-Short-Name
  • GET DESCRIPTION FOR HEALTH INDICATOR Health-Indicator-Short-Name

ADM10513I Automatic Utility-Name has completed on table Table-Name in database Database-Name with a return code of SQL-Return-Code. The utility started at Start-Timestamp and completed at End-Timestamp.

ADM10514I Automatic BACKUP has completed on database Database-Name with a return code of SQL-Return-Code. The utility started at Start-Timestamp and completed at End-Timestamp. The timestamp for the backup image is Backup-Image-Timestamp.

ADM10515I The automatic maintenance policy Policy-Name has been updated in database Database-Name. The policy options have been updated from Original-Policy-Options-List to New-Policy-Options-List.

ADM10516I The automatic maintenance policy Policy-Name has been updated in database Database-Name. The options now being used for this policy are: Policy-Options-List.

ADM11000E The database manager is unable to create or attach to the memory segment used for fenced routine communications. Decrease the amount of database shared memory used by your instance, and retry.

ADM11001E DB2 did not create a memory segment for running fenced routines. This was specified by the use of DB2_FMP_COMM_HEAPSZ registry variable.

ADM11002E Insufficient shared memory available for communication with the db2fmp process. Use the DB2_FMP_COMM_HEAPSZ registry variable to increase the amount of shared memory available for fenced routines.

ADM11003E DB2 failed to create the memory segment used for communication with fenced routines. If restarting DB2, ensure that no db2fmp processes are active on the instance prior to start. Otherwise, you can adjust the value through the DB2_FMP_COMM_HEAPSZ registry variable, or you can decrease the value of ASLHEAPSZ in the database manager configuration.

ADM11500W MQListener generated a message. Message code = MQL-msgcode. Refer to the documentation for information about the message.

ADM12000C DB2START processing failed; a valid product license was not found. If you have licensed this product, ensure the license key is properly installed. You can install the license using the db2licm command. The license file can be obtained from your licensed product CD.

User response

ADM12001C DB2 connect processing failed; a valid product license was not found. If you have licensed this product, ensure the license key is properly installed. You can install the license using the db2licm command. The license file can be obtained from your licensed product CD.

User response

ADM12002C Connect processing failed; a valid product license was not found. If you are accessing host or iSeries database server, make sure you have a licensed DB2 Connect product or DB2 Connect server support component installed. DB2 Connect server support component is included in DB2 Enterprise edition.

User response

ADM12006E The product product-name does not have a valid license key registered. If you have licensed this product, ensure the license key is properly registered. You can register the license using the db2licm command. The license key can be obtained from your licensed product CD. If a license key is not registered, this product will be enabled for a num-days day evaluation period. Use of the product for the evaluation period constitutes acceptance of the terms of the IBM license agreement located in the installation path of this product in the license directory.

User response

ADM12007E There are num-days day(s) left in the evaluation period for the product product-name. For evaluation license terms and conditions, refer to the IBM License Acceptance and License Information document located in the license directory in the installation path of this product. If you have licensed this product, ensure the license key is properly registered. You can register the license using the db2licm command line utility. The license file can be obtained from your licensed product CD.

User response

ADM12008C The product product-name does not have a valid license key installed and the evaluation period has expired. Functions specific to this product are not enabled. If you have licensed this product, ensure the license key is properly installed. You can install the license using the db2licm command. The license file can be obtained from your licensed product CD.

User response

ADM12009E The number of concurrent users of the DB2 Workgroup product has exceeded the defined entitlement of entitlement. Concurrent user count is user-count. You should purchase additional user based entitlements from your IBM representative or authorized dealer and update your license using the db2licm command.

User response

ADM12010E The number of concurrent users of the DB2 Connect product has exceeded the defined entitlement of entitlement. Concurrent user count is user-count. You should purchase additional user based entitlements from your IBM representative or authorized dealer and update your license using the db2licm command.

User response

ADM12011C One or more database partitions does not have a valid DB2 license key installed for the product-name product. Install a valid license key on each physical partition using the db2licm command.

User response

ADM12012E The number of concurrent users of the DB2 Enterprise product has exceeded the defined entitlement of entitlement. Concurrent user count is user-count. You should purchase additional user based entitlements from your IBM representative or authorized dealer and update your license using the db2licm command.

User response

ADM12013E The number of concurrent database connections to the DB2 Connect product has exceeded the defined entitlement of entitlement. Database connection count is num-connections.

ADM12014C The version of the DB2 Connect product you are using is not licensed for use with TCP/IP protocol. Upgrade to a full function DB2 Connect product to use TCP/IP.

ADM12015C The version of the DB2 Connect product you are using is not licensed for updating multiple databases in the same transaction. Upgrade to a full function DB2 Connect product to update multiple databases in the same transaction.

ADM12017E The number of processors on this machine exceeds the defined entitlement of entitlement for the product product-name. The number of processors on this machine is num-cpu.

Explanation

You can purchase DB2 Connect and database products either per processor (priced by Processor Value Unit (PVU)) or per user.

If you purchase your database product license per processor, you will see License Type: "CPU Option" in the License Center or in the output from the command "db2licm -l".

Prior to DB2 V9.5 Fix Pack 4, this message is returned by DB2 Connect and database products when it is determined that there are more processors on the current machine than are entitled to be used with the named product. The database product will continue to function even when this message is returned. However, using the database product with more processors than the defined entitlement allows will cause problems with business audit processes and will complicate support processes, if you need to access IBM support.

This message is not returned by DB2 Connect and database products starting with DB2 V9.5 Fix Pack 4 and later because the database product will only use the machine resources for which it is licensed to use.

User response

  1. Purchase additional processor-based entitlements from your IBM representative or authorized dealer.
  2. Update your license using the db2licm command.

ADM12018E The number of concurrent users for this product has exceeded the defined entitlement of entitlement. Concurrent user count is user-count. You should purchase additional user based entitlements from your IBM representative or authorized dealer and update your license using the db2licm command.

User response

ADM12020E The number of connectors has exceeded the defined entitlement of entitlement. Current number of connectors is num-connectors. You should purchase additional connector entitlements from your IBM representative or authorized dealer and update your license using the db2licm command.

User response

ADM12022E The database manager has detected that database partitioning feature is being used without database partitioning license. Purchase database partitioning entitlements from your IBM representative or authorized dealer and update your license using the db2licm command.

User response

ADM12023E The number of concurrent users of product-name product has exceeded the defined entitlement of entitlement. Concurrent user count is user-count. You should purchase additional user based entitlements from your IBM representative or authorized dealer and update your license using the db2licm command.

User response

ADM12024E A valid license key was not found for the requested function. The current license key for product_name product does not allow the requested functionality. Purchase the license key for this function from your IBM representative or authorized dealer and update your license using the db2licm command.

User response

ADM12025E The amount of memory on this machine exceeds the defined limit of limit (MB) for the product product-name. The amount of memory on this machine is memory (MB).

Explanation

This product has a defined memory limit that has been exceeded. The memory limit cannot be changed via DB2 licensing tools.

User response

Contact your IBM representative or authorized dealer to obtain a product that can be licensed to run on this system.

ADM12026W The database server has detected that a valid license for the product product-name has not been registered.

Explanation

Registration of a valid license key is required in order to comply with the terms and conditions of your License Agreement. The license keys for this product are located on this product's activation CD in the 'license' directory.

User response

Use the db2licm command (Run db2licm -a license-file-name from sqllib\bin on Windows or sqllib/adm on Unix and Linux) to register the appropriate licenses that you have purchased. The License Agreement text is located in the 'license' directory in the installation directory of this product.

ADM12027E The amount of memory on this server now exceeds the defined limit of limit (GB) for the product product-name. The amount of memory on this server is memory (GB).

Explanation

The database manager instance is attempting to use more memory allocated for DB2 than specified in your product license. DB2 limits itself to the licensed amount of memory.

User response

To take full advantage of your server's memory capacity, contact your IBM representative or authorized dealer to obtain an edition of DB2 with a higher licensed memory limit.

ADM12500E The HADR standby database cannot be made consistent with the primary database. The log stream of the standby database is incompatible with that of the primary database. To use this database as a standby, it must be recreated from a backup image or split mirror of the primary database.

ADM12501E Unable to establish HADR primary-standby connection because the operating systems do not match the primary and standby databases. Move the primary or standby databases to a different host or upgrade the operating system of one host to match the other host.

ADM12502E Unable to establish HADR primary-standby connection because the DB2 versions do not match the primary and standby databases. Upgrade the DB2 software to the same release and FixPak on either the HADR primary or HADR standby database to match the other.

ADM12503E Unable to establish HADR primary-standby connection because the DB2 bit level (32-bit vs. 64-bit) do not match the primary and standby databases. Change the bit level of the primary or standby database to match each other.

ADM12504E Unable to establish HADR primary-standby connection because the value of HADR_REMOTE_INST at one of the instances does not match the actual instance name of the other instance. This is a sanity check to ensure that only the intended database pairing occurs. If any of the HADR_REMOTE_INST configuration parameters or instance names is set incorrectly, you may correct it and try again to start HADR.

ADM12505E Unable to establish HADR primary-standby connection because the database names do not match. Correct the database name so it matches on the HADR primary and HADR standby.

ADM12506E Unable to establish HADR primary-standby connection because the primary and standby databases did not originate from the same database. Recreate the standby from a backup image or split mirror of the primary database.

ADM12507E Unable to establish HADR primary-standby connection because the HADR configuration parameters do not match. Change the configuration parameters HADR_TIMEOUT and HADR_SYNCMODE on either the HADR primary or standby so that they match the other system's values, and ensure that HADR_LOCAL_HOST and HADR_REMOTE_HOST match the host name of the local and remote machines.

ADM12508W Log receiving has been suspended on the HADR standby database because of a disk full condition. If the primary and standby databases are in peer state and in SYNC, NEARSYNC, or ASYNC HADR synchronization mode, transactions on the primary might be blocked.

Explanation

The standby database is unable to receive any more log data from the primary database because of a disk full condition on the standby.The standby frees disk space automatically after it finishes replaying logs, as long as the logs are archived on the primary and there are no uncommitted transactions started in or before the given log file.

User response

One of the following:

  • Wait for the standby to catch up with the primary. Log receiving will resume on the standby as old logs are released after they have been replayed on the standby and archived on the primary.
  • Provide more disk space on the standby for logs. Do not delete any logs because DB2 handles that automatically.

If the primary was blocked because of a disk full situation on the standby, consider using the SUPERASNYC HADR synchronization mode to avoid encountering this error in the future.

ADM12509E HADR encountered an abnormal condition. Reason code: reason-code

Explanation

The explanation corresponding to the reason code is:

1

The HADR primary database cannot find a log file that was requested by the standby. HADR will attempt to recover from the condition by disconnecting and then reconnecting the primary and the standby. Each reconnection will attempt to access the file. These retry attempts will help avoid transient errors such as a conflict with other log file usage.

2

The HADR standby received a bad log page. HADR will attempt to recover from the condition by disconnecting and then reconnecting the primary and standby. These retry attempts will help avoid transient errors.

3

The HADR primary has broken its connection to the standby because the primary reach its peer limit. This condition indicates that the standby or network cannot keep up with the primary's workload. The primary has disconnected from the standby to unblock itself. After the standby has replayed the logs it received, it will reconnect to the primary and the pair will start from remote catchup state, which does not block primary log writing.

4

The HADR standby is shutting down because its log writing disk is full and it cannot reclaim any space.The standby log device is not large enough to hold the logs produced by the primary.

5

The HADR standby was unable to access the needed log file or log files. Possible causes of the access failure include user removal of log files, or I/O errors on the log device. The HADR standby automatically manages log files, so always ensure that they are not manually removed or altered. The HADR standby will attempt to recover from the condition by starting remote catch up from the missing log file.

6

Detected another primary database.

7

The standby database is shutting down after repeated failures to start the replay member in DB2 pureScale environment.

8

In a DB2 pureScale environment, an address listed in hadr_target_list does not actually belong to the remote cluster.

10

A previous takeover by force was performed on this standby database but it did not complete.

99

Fatal error encountered. The database is shutting down.

User response

Either re-create the standby using a newer backup image from the primary, or follow the user response corresponding to the reason code:

1

If the attempts to access the log file keep failing, check the db2diag.log file for the file number and determine why the file cannot be found. This can occur if the file is very old and has been removed from the archive, or if there has been a media failure. Depending on the cause, possible responses are:

  • Put the file back in the log path or archive.
  • Repair the media that failed.
2

If the error condition persists, determine the root cause, make the appropriate corrections, and attempt to start HADR on the database.

3

One of the following actions:

  • Increase the setting for the DB2_HADR_PEER_WAIT_LIMIT registry variable.
  • Reduce the workload on the primary.
  • Tune or upgrade the network.
  • Tune or upgrade the standby.
4

Increase the log device capacity and restart the standby.

5

The standby should be able to recover by requesting the files from the primary. If the error condition persists, determine the root cause, and make the appropriate corrections.

6

Determine which database should be the primary. Drop the other primary database or try converting it to a standby. If both should be primary, they should be removed from each other's hadr_target_list, so that they are independent.

7

Determine the cause of the failures, correct the problem, then restart the standby database. If the problem is limited to a particular member, you can designate another member as the preferred replay member by running the START HADR command with the AS STANDBY option on another member.

8

This is not a fatal error. HADR remains functional. Remove the bad address from the hadr_target_list at the earliest convenient moment.

10

Do one of the following:

  • Reissue takeover by force to complete the takeover.
  • Deactivate the database, stop HADR, and then roll forward the database to convert it into a standard database.
  • Deactivate, then drop the database. Re-create it as a standby if needed.
99

Determine the root cause, make the appropriate corrections, and attempt to start the database.

ADM12510E Unable to establish HADR primary-standby connection with host: remote-host. Reason code: reason-code

Explanation

If the unreachable host is listed as "hadr_target_list", it means there are multiple addresses listed in the hadr_target_list database configuration parameter, but this database cannot form a connection with any of them.

The explanation corresponding to the reason code is:

9

The HADR primary was unable to reach the standby host. Possible causes are:

  • A standby host name or IP address in the hadr_target_list or hadr_remote_host database configuration parameter on the primary is incorrect.
  • A standby host that is specified in the hadr_target_list or hadr_remote_host database configuration parameter on the primary was offline.
  • For DB2 pureScale installations, the host and service for the standby replay member does not appear in the hadr_target_list database configuration parameter on the primary.
  • There is a network failure preventing connectivity with the standby host or hosts.
10

The HADR primary was not able to form a TCP connection with the standby. Possible causes are:

  • The standby database was offline.
  • The standby database was online but HADR was not started.
  • The standby's hadr_local_svc database configuration parameter does not match the TCP service listed in the hadr_target_list database configuration parameter on the primary.
  • For DB2 pureScale installations, the host and service for the standby replay member does not appear in the hadr_target_list database configuration parameter on the primary.
11

The HADR primary was unable to form a connection with the standby database within the time specified by the hadr_timeout database configuration parameter. The network between the primary and the standby is slow or unreliable.

12

The HADR primary was unable to form a connection with the standby database within the time specified by the hadr_timeout database configuration parameter.

13

The HADR_SSL_LABEL configuration parameter is not valid or has expired on the primary database or the standby database.

User response

The user response corresponding to the reason code is:

9
  • Validate the configuration listed in the primary's hadr_target_list or hadr_remote_host database configuration parameter.
  • Verify that the standby host is online.
  • For DB2 pureScale installations, verify that the standby replay members hadr_local_host and hadr_local_svc appear in the hadr_target_list database configuration parameter on the primary.
  • Verify that the standby host can be pinged from the primary host and the network connectivity is reliable with adequate response time.
10
  • Verify that the standby database is online. If not then issue the following command: ACTIVATE DATABASE dbname.
  • Verify that the role on the standby database is STANDBY by checking the HADR_ROLE value in the db2pd -hadr command output. If not then issue the following command: START HADR ON DATABASE dbname AS STANDBY.
  • Verify that the standby's hadr_local_svc database configuration parameter matches the TCP service listed in the primary's hadr_target_list database configuration parameter for that standby host. If they do not match then update the appropriate database configuration parameter.
  • For DB2 pureScale installations, verify that the standby replay members hadr_local_host and hadr_local_svc appear in the hadr_target_list database configuration parameter on the primary.
11

Verify that the standby host can be pinged from the primary host and the network connectivity is reliable with adequate response time.

12

Increase the value of the hadr_timeout database configuration parameter.

13

To enable SSL communication between the HADR primary database and the standby database, set the configuration parameter HADR_SSL_LABEL to a valid certificate name on the primary database and the standby database.

ADM12511W The HADR standby database was not able to access the log archive when attempting to retrieve log file log-file-name.

Explanation

An error occurred when the standby database attempted to retrieve a log file from the log archive. This error is not fatal. The standby database will attempt to acquire the file from the primary database by entering remote catchup state.

User response

Investigate why the standby database is not able to access the log archive:

  • Make sure that LOGARCHMETH1 and LOGARCHMETH2 are configured correctly.
  • Make sure that the standby machine and instance owner can access the log archive device.
  • Make sure that the archive contains log files on the correct log chain.

It is important to resolve this issue, especially if this database might have to perform takeover to become a primary database in the future. After it is a primary database, it must be able to access the archive device to avoid running out of disk space in the active log path.

ADM12512W Log replay on the HADR standby has stopped on table space tablespace_name (ID tablespace_id) because it has been put into tablespace_state state.

Explanation

The standby database can no longer replay log records on this table space due to error. Data in this table space will not be available if this database takes over the primary role. The standby database will continue replaying logs shipped from primary on other table spaces.

User response

Investigate and resolve the possible causes, such as:

  • File system is not mounted.
  • The standby is unable to access some containers, or the container is not big enough.
  • The standby is unable to locate or access a load copy image.

ADM12513E Unable to establish HADR primary-standby connection because the primary and standby databases are incompatible. Reason code: reason-code

Explanation

The explanation corresponding to the reason code is:

1

The settings for the hadr_local_host and hadr_local_svc configuration parameters on the local database must match the settings for the hadr_remote_host and hadr_remote_svc configuration parameters on the remote database.

2

The settings for the hadr_local_host and hadr_local_svc configuration parameters on the remote database must match the settings for the hadr_remote_host and hadr_remote_svc configuration parameters on the local database.

3

At least one of the HADR databases does not have its hadr_target_list configuration parameter set. With the hadr_target_list parameter, all of the participating databases must have it set or unset.

4

The hadr_target_list configuration parameter on the local database does not include entries that correspond to the hadr_local_host and hadr_local_svc configuration parameter settings for the remote database members.

5

The local log stream ID does not match the remote log stream ID.

6

The local database member ID does not match the remote database member ID ID.

7

The setting for the hadr_timeout configuration parameter on the local database must match the hadr_timeout setting on the remote database.

8

If the hadr_target_list configuration parameter is not configured on your HADR databases, the setting for the hadr_sycnmode configuration parameter on the local database must match the hadr_syncmode setting on the remote database.

9

The hadr_replay_delay configuration parameter is set to a non-zero value on the standby, but the effective synchronization mode (which derived from the setting on the primary) is not SUPERASYNC.

10

The setting for the hadr_peer_window configuration parameter on the local database must match the hadr_peer_window setting on the remote database.

11

The primary and standby database types are incompatible; for example, if one of the databases uses the DB2 pureScale feature, the other must as well.

12

The primary and standby database topologies are incompatible. The two databases must have same number of members and each pair of primary-standby matching members must have same member id and log stream id. HADR cannot be set up if the two databases do not meet this requirement.

13

The two databases are incompatible because they do not have the same replay type (physical replay).

99

Other incompatibility errors.

User response

Refer to the explanation of the error message that follows this message and take any needed corrective action.

1

Configure the hadr_local_host and hadr_local_svc configuration parameters on the local database to match the settings for the hadr_remote_host and hadr_remote_svc configuration parameters on the remote database.

2

Configure the hadr_local_host and hadr_local_svc configuration parameters on the remote database to match the settings for the hadr_remote_host and hadr_remote_svc configuration parameters on the local database.

3

Either configure the hadr_target_list configuration parameter on all of the databases or on none of the databases.

4

Add at least one value from the hadr_local_host and hadr_local_svc configuration parameter settings for a remote database member to the hadr_target_list configuration parameter on the local database.

5

Because the two databases are incompatible with each other, HADR cannot be set up. Reinitialize the standby with a backup or split mirror image from the primary.

6

Because the two databases are incompatible with each other, HADR cannot be set up. Reinitialize the standby with a backup or split mirror image from the primary.

7

Configure the hadr_timeout configuration parameter to the same value on the primary and standby databases.

8

Configure the hadr_syncmode configuration parameter to the same value on the primary and standby databases.

9

Set the hadr_replay_delay configuration parameter to 0, or change the effective syncmode to SUPERASYNC by setting the hadr_syncmode configuration parameter on the primary database.

10

Configure the hadr_peer_window configuration parameter to the same value on the primary and standby databases.

11

Use the same database type for both the HADR primary and the HADR standby.

12

Reinitialize the standby with a backup or split mirror image from the primary so that standby has the same topology as the primary.

13

Use the physical replay type.

99

Generic incompatibility error. See the db2diag.log for more information.

ADM12514E Log replay on the HADR standby database has stopped because member member-id was added on the HADR primary but has not been added on the standby. The standby database has been deactivated due to this error.

Explanation

When a member is added to the HADR primary, it must also be added to the standby or the standby will be deactivated.

User response

Add the new member on the standby, then reactivate the database on the standby to restart log replay. You should also ensure that the hadr_local_host and hadr_local_svc configuration parameters have been set on the new member.

ADM12515E The HADR primary and standby databases are no longer compatible because the primary database has fewer members than the standby.

Explanation

This can occur in the following scenarios:

  • A member was dropped on the primary.
  • A member was added on the primary; then a forced takeover happened before the add member event was replicated to the standby; then the old primary attempted to reintegrate as a new standby, but it has more members than the new primary.

User response

  1. Cause the the instance of the primary database to have the same number of members as the instance of the standby database by performing one of the following actions:
    • Add another member to the instance of the primary database.
    • Drop a member from the instance of the standby database.
  2. Reinitialize the standby database by performing the following steps:
    1. Create a backup image of the primary database.
    2. Restore the image of the primary database to the standby database.

ADM12516W The HADR database dbname at address is encrypted but at address is not encrypted.

Explanation

This warning is logged when one database of a high availability disaster recover (HADR) primary-standby database pair is configured to use DB2 native encryption but the other database is not.

User response

To prevent this warning, take the following actions:

  1. Review encryption settings of the HADR primary database and standby database by using one of the following methods:
    • Issue the db2pd command specifying the -encryptioninfo parameter.
    • Invoke the SYSPROC.ADMIN_GET_ENCRYPTION_INFO table function.
  2. Configure the HADR primary database and standby database with matching encryption settings.

ADM12517E A master key rotation to label label failed on the HADR standby with zrc zrc.

Explanation

When a high availability disaster recovery (HADR) primary-standby database pair is configured to use DB2 native encryption, the master key on the primary database and the master key on the standby database must match. To maintain this, the standby database will rotate the master key there whenever the master key is rotated on the primary database. This requires that when you rotate the master key on the primary database, you must specify the label of a master key that is available on both the primary database and the standby database.

This message is printed when the master key on an HADR primary database has been successfully rotated, but rotating the master key on the corresponding standby database failed.

After this message is printed, the HADR standby database will disconnect from the primary database and continue to attempt to rotate the master key locally for 30 minutes:

  • If the standby database successfully rotates the master key locally within that time, the standby database will reconnect to the primary database.
  • If the standby database is unable to rotate the master key locally within that time, the standby database will shut down.

User response

Monitor the status of the master key rotation on the standby database by using one of the following methods:

  • Issue the db2pd command with the -hadr parameter.
  • Invoke the MON_GET_HADR table function on the standby database, and review the STANDBY_KEY_ROTATION_ERROR flag of the HADR_FLAGS column.

If the standby database shuts down, manually synchronize the master key on the standby database with the master key on the primary database, and then restart the standby database.

ADM12518W The connection between the HADR primary and standby databases could not be established because the HADR_SSL_LABEL database configuration parameter is not set to a valid, compatible value on the primary and standby databases. Reason Code: reason_code. Remote Address: remote_address. Remote port: remote_port.

Explanation

You can configure your HADR primary and standby databases to use SSL connections by setting the HADR_SSL_LABEL to a valid label name. To use TCPIP connections, you can leave HADR_SSL_LABEL unset.

This message is returned when the value of HADR_SSL_LABEL on the primary database and on the standby databases are not compatible. The reason code indicates more specifically what is wrong:

1

The local database (on the server where this log containing this message is located) is configured to use TCP and the remote database is configured to use SSL.

2

The local database (on the server where this log containing this message is located) is configured to use SSL and the remote database is configured to use TCP.

User response

Respond to reason code 1 and reason code 2 in the same way.

Update the HADR_SSL_LABEL on either the primary or standby database:

  • To use SSL, set the HADR_SSL_LABEL on both databases to a valid label.
  • To use TCP, set the HADR_SSL_LABEL on both databases to an empty string. For example to use TCP, run following command: 
    db2 update db cfg for <dbname> using HADR_SSL_LABEL ""

ADM12519E This HADR standby database has been rejected by the HADR primary database.

Explanation

The primary has rejected the connect request made by this standby database. The standby database will be terminated.

User response

Investigate the administration notification log and db2dig.log for the primary database and search for ADM12510E for the reason of rejection.

ADM12520E The HADR Primary database encountered an error while initiating the Remote Catchup phase.

Explanation

An error occurred when attempting to initiate the Remote Catchup phase on the HADR Primary database. The HADR Primary database will close its connection to the Standby database and the shipment of log records will halt. When the HADR Standby database performs its automatic reconnection to the Primary database, this error condition may repeat itself.

User response

The diagnostic log file (db2diag.log) should be examined to determine the cause of the error. Once the error is resolved, a subsequent automatic reconnection from the HADR Standby database will proceed and the shipment of log records will resume.

ADM13001E Plug-in plugin-name received error code error-code from the DB2 security plug-in API GSS-API-name with the error message error-message.

ADM13002E Unable to unload plug-in plugin-name. No further action is required.

ADM13003E The principal name principal-name used for plugin-name is invalid. Ensure that the principal name is valid and that it is in a format that is recognized by the security plug-in.

ADM13004E The plug-in name plugin-name is invalid. Ensure that a valid plug-in name is specified.

ADM13005E Unable to load plug-in plugin-name. Verify that the plug-in exists and that the directory location and file permissions are valid.

ADM13006E Plug-in plugin-name encountered an unexpected error. Contact IBM Support for assistance.

ADM13500E An agent executing an asynchronous background task processor encountered an unrecoverable error. The task processor has been suspended and diagnostic information was written to the db2diag log file. Contact IBM Support for assistance. The task processor context is address. The task processor description is description.

ADM14000E The database manager is unable to open diagnostic log file filename. Run the command "db2diag -rc rcList" to find out more.

ADM14001C An unexpected and critical error has occurred: error-type. The instance may have been shutdown as a result. capture-type FODC (First Occurrence Data Capture) has been invoked and diagnostic information has been recorded in directory directory-name. Please look in this directory for detailed evidence about what happened and contact IBM support if necessary to diagnose the problem.

ADM14002C capture-type FODC has been invoked for symptom error-type and diagnostic information has been recorded in directory directory-name. Please look in this directory for detailed evidence about what happened and contact IBM support if necessary to diagnose the problem.

ADM14003W FODC has been invoked by the user from db2fodc tool for symptom symptom and diagnostic information has been recorded in directory directory. Please look in this directory for detailed evidence about what happened and contact IBM support if necessary to diagnose the problem.

ADM14004C EDU Database database-name marked bad. capture-type FODC has been invoked and diagnostic information has been recorded in directory parameter. Please look in this directory for detailed evidence about what happened and contact IBM support if necessary to diagnose the problem.

ADM14005E The following error occurred: symptom. First Occurrence Data Capture (FODC) has been invoked in the following mode: capture-mode. Diagnostic information has been recorded in the directory named directory-name.

Explanation

First occurrence data capture (FODC) is a general term applied to the set of diagnostic information the DB2 administration server captures automatically when errors occur.

User response

Review the diagnostic information, such as log files, dump files, or trap files, in the named directory.

ADM14010C An unexpected and critical error has occurred: error-type. capture-type First Occurrence Data Capture has been invoked and diagnostic information has been recorded in directory directory-name.

Explanation

One or more DB2 threads associated with this instance have been suspended, but the instance process is still running. The database manager instance might become unstable and must be stopped and restarted.

User response

To restore the stability of the database manager instance, stop and restart the instance by running the following commands at a command prompt:

db2_kill

db2start

If at all possible, wait until the instance is no longer accessed by any applications before issuing the db2_kill command. db2_kill may result in crash recovery processing upon subsequent db2start.

Look in the named directory for detailed evidence about what happened and, if required, contact IBM Software Support to diagnose the problem.

ADM14011C A critical failure has caused the following type of error: error-type. The database manager cannot recover from the failure. First Occurrence Data Capture (FODC) was invoked in the following mode: capture-type. FODC diagnostic information is located in the following directory: directory-name.

Explanation

First occurrence data capture (FODC) is a general term applied to the set of diagnostic information the database server captures automatically when errors occur.

The database manager on all supported platforms has trap resilience capabilities that enable it to respond to certain code traps or segmentation violations in order to keep the database manager instance running.

This message is returned when a trap is caused by a critical error from which the database manager cannot recover, despite trap resilience being enabled.

The database manager will stop the instance.

User response

  1. Collect the FODC diagnostic information from the named directory.
  2. Contact IBM Software Support to diagnose the problem.

ADM14012C A critical failure has caused the following type of error: error-type. The database manager will attempt to recover from the failure. First Occurrence Data Capture (FODC) was invoked in the following mode: capture-type. FODC diagnostic information is located in the following directory: directory-name.

Explanation

First occurrence data capture (FODC) is a general term applied to the set of diagnostic information the database server captures automatically when errors occur.

The database manager on all supported platforms has trap resilience capabilities that enable it to survive certain code traps or segmentation violations in order to keep the database manager instance running.

This message is returned when a trap is caused by a critical error, and the database manager will attempt to recover from the failure because trap resilience is enabled.

The database manager will stop the instance.

User response

Although the database manager will attempt to recover from the failure, it is important to diagnose why the failure happened by performing the following steps:

  1. Collect the FODC diagnostic information from the named directory.
  2. Contact IBM Software Support to diagnose the problem.

ADM14013C The following type of critical error occurred: error-type. This error occurred because one or more threads that are associated with the current database manager instance have been suspended, but the instance process is still running. First Occurrence Data Capture (FODC) was invoked in the following mode: capture-type. FODC diagnostic information is located in the following directory: directory-name.

Explanation

First occurrence data capture (FODC) is a general term applied to the set of diagnostic information the DB2 administration server captures automatically when errors occur.

User response

  1. To terminate all active applications which issue a COMMIT or ROLLBACK within the timeout period, which minimizes the recovery window for crash recovery when the db2start command is run, issue the following command: 
    db2 quiesce instance <instance_name>
   user <user_name>
   defer with timeout <minutes>
  2. [Optional] To terminate any applications that did not COMMIT or ROLLBACK during the timeout period in Step 1 and any new applications which accessed the database after the timeout period completed, issue the following command: 
    db2 quiesce instance <instance_name>
   user <user_name>
   immediate
  3. Forcefully shut down the instance and suspended EDUs by executing the following command: 
    db2_kill

    Note: Issuing the db2stop command will not complete when an instance has sustained a trap.

  4. Restart the database manager instance using either one of the following commands: 
    db2start

    or

    START DATABASE MANAGER

ADM14014C An unexpected and critical error has occurred: error-type. This error might affect the availability of the resource-or-service-name resource or service on member member-id.

Explanation

One or more DB2 threads encountered an unexpected error, but the DB2 member is still running. The error might affect the availability of the specified resource or service for the affected database. The database is still available; however, it might not provide optimal service, especially if applications have a dependency on the specified resource or service.

User response

To restore the stability of the database, stop all applications on this member and force a restart of the database manager instance on this member with the following commands:

  1. db2stop member <member-id>
        quiesce <timeout_minutes>

    Existing applications have up to <timeout_minutes> to reach the next commit or rollback point before being forced off. After the specified <timeout_minutes>, all remaining applications are terminated.

  2. db2start member <member-id>

Look in the DIAGPATH for the affected DB2 member for any additional evidence about what has occurred and, if required, contact IBM Software Support to diagnose the problem.

ADM14500E Unable to allocate memory required for deferred index cleanup on table schema.table. If you wish to use immediate cleanup rollout for the statement, either set the DB2_MDC_ROLLOUT registry variable to ON, or use the CURRENT ROLLOUT MODE special register, and rerun the statement.

ADM15000E The file logfileName is not accessible for reading. Verify the access permissions for this file and its associated device.

ADM15001E An error was returned trying to access file logfileName. Make sure that the file exists and that the device or file is accessible.

ADM15500E An index data inconsistency is detected on table schema-name. table-name during INSPECT command. Please contact DB2 support team to report the problem.

ADM15501W The administrative task scheduler encountered a temporary resource constraint that prevented the execution of task task-id. The scheduler will retry every retry-interval seconds.

ADM15502W The administrative task scheduler could not execute task task-id because the database is inactive.

ADM15503E The administrative task scheduler detected a security error on database database-name. No scheduled tasks will be executed on this database. To resume task execution, drop the SYSTOOLS.ADMINTASKS and SYSTOOLS.ADMINTASKSTATUS table, and recreate all the scheduled tasks on this database using the SYSPROC.ADMIN_TASK_ADD stored procedure.

ADM15510E The INSPECT command found inconsistent row contents in a block in the multidimensional clustering (MDC) table named schema-name.table-name.

Explanation

In the context of MDC tables, a block is a set of contiguous pages on disk. In MDC tables, rows of table data that contain the same indexes are clustered together on disk, in these blocks, to facilitate faster searching and improved performance.

The INSPECT command was verifying the block indexes of the named table, and discovered rows in one or more blocks that are not valid according to the block index entries. This can happen for several reasons, including disk error or data corruption.

User response

Refer to the db2diag log file for more information about this error.

Contact IBM software support for assistance.

ADM16000W Following an attach operation, a SET INTEGRITY...ALL IMMEDIATE UNCHECKED statement running against a partitioned table that has a nonpartitioned index defined on it executes as though it were a SET INTEGRITY...ALLOW WRITE ACCESS IMMEDIATE CHECKED statement. The SET INTEGRITY operation updates the index to include data for the newly attached partition. It also performs constraints checking, range validation, and maintenance of any other nonpartitioned indexes that are defined on the table.

ADM16500E The specified member subset references a member that does not exist in the instance. Member subset: subset_name. Member: member_id.

Explanation

A member subset references a member that does not exist in the instance. The member subset definition was adjusted in-memory to exclude the specified member. The member subset definition in the system catalogs was not modified.

User response

Either remove the member from the member subset, or drop the member subset. To remove the member from the member subset definition, use system routine SYSPROC.WLM_ALTER_MEMBER_SUBSET. To drop the member subset, use system routine SYSPROC.WLM_DROP_MEMBER_SUBSET.

ADM16501E The specified exclusive member subset does not include any members that exist in member subset member-subset-token.

Explanation

The in-memory definition of exclusive member subset does not contain any members that exist in the instance. The in-memory definition of the subset was adjusted; the subset was disabled. Connections assigned to this member subset are rejected with SQLCODE SQL1717N. The system catalog definition of the subset is not modified.

User response

To add members which exist in the instance to the member subset definition, use the SYSPROC.WLM_ALTER_MEMBER_SUBSET system routine. Alternatively, to drop the member subset, use the SYSPROC.WLM_DROP_MEMBER_SUBSET system routine.

ADM16502I The specified database alias used by the member subset is not cataloged in the system database directory. The database manager will catalog the database alias. Database alias: database_alias. Member subset: member_subset.

Explanation

The database alias is managed by a member subset but is not currently cataloged in the system database directory. The database manager will automatically catalog this database alias. Applications can connect to the database alias and be assigned to the member subset. The definition of a member subset can be viewed by querying the system catalog view SYSCAT.MEMBERSUBSETS.

User response

No action required.

ADM16503E An attempt to automatically catalog the specified database alias by the database manager has failed. Database alias: database_alias. Member subset: member_subset. SQLCODE: sqlcode.

Explanation

An attempt was made by the database manager to catalog a database alias that is managed by a member subset. The attempt failed. Connections to the database alias will fail to resolve the database.

User response

Explicitly catalog the database alias using the CATALOG DATABASE DATABASE_NAME AS DATABASE_ALIAS command. Alternatively, to drop the member subset, use system routine SYSPROC.WLM_DROP_MEMBER_SUBSET.