ADM10000-19999

ADM10000W

ADM10500E

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.

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

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

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

ADM10501W

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.

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

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

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

ADM10502W

The health monitor generated an alert because the state value of this health indicator was nonnormal. 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.

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

From the CLP, you can obtain the Health indicator description and recommended actions by running 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 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.

No action is required.

ADM10504E

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.

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

ADM10505E

ADM10506E

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.

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

ADM10507E

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

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 configured to send notifications upon alert occurrence, but was unable to send the notification because one or more addresses for the contacts that are specified on the health notification list are invalid.

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

ADM10509E

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'.

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

ADM10510E

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.

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 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.

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

ADM10512W

The health monitor generated an alert because the state value of this health indicator was nonnormal. This condition does not necessarily require immediate attention but indicates that a nonoptimal situation prevails regarding the health of one or many objects collected under this health indicator. The situation might get resolved automatically if the corresponding automatic maintenance utility was turned on and the state is automated.

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

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

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

ADM10513I

ADM10514I

ADM10515I

ADM10516I

ADM11000E

ADM11001E

ADM11002E

ADM11003E

ADM11500W

ADM12000C

ADM12001C

ADM12002C

ADM12006E

ADM12007E

ADM12008C

ADM12009E

ADM12010E

ADM12011C

ADM12012E

ADM12013E

ADM12014C

ADM12015C

ADM12017E

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".

DB2 Connect and database products return this message when they detect that the current machine uses more processors than the product is entitled to use. The database product continues to function even when this message is displayed. However, using more processors than the defined entitlement can cause issues with business audits and complicates support if you need help from IBM.

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

ADM12018E

ADM12020E

ADM12022E

ADM12023E

ADM12024E

ADM12025E

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

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

ADM12026W

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.

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 database manager instance is attempting to use more memory that is allocated for Db2 than specified in your product license. Db2 limits itself to the licensed amount of memory.

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

ADM12501E

ADM12502E

ADM12503E

ADM12504E

ADM12505E

ADM12506E

ADM12507E

ADM12508W

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.

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

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 attempts to recover from the condition by disconnecting and then reconnecting the primary and the standby. Each reconnection attempts to access the file. These retry attempts help avoid transient errors such as a conflict with other log file usage.

2

The HADR standby received a bad log page. HADR attempts to recover from the condition by disconnecting and then reconnecting the primary and standby. These retry attempts 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 that 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 shuts 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 attempts 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 shut down after repeated failures to start the replay member in the Db2 pureScale environment.

8

In a Db2 pureScale environment, an address that is 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.

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 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

If the unreachable host is listed as "hadr_target_list", it means that there are multiple addresses that are 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 hostname 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 primary was not able to form a connection with the standby database when HADR_SSL_LABEL database configuration is set. Possible causes are:

• The HADR_SSL_LABEL configuration parameter is not valid or has expired on the primary database or the standby database.
• Network errors, such as the partner closed the socket before the protocol completed.

14

Hostname validation is enabled for SSL communication between the primary and standby hosts and it failed because the specified hostname does not match any of the hostname fields in the certificate returned by this host. Details about this certificate have been logged to the db2diag.log file.

The user response corresponding to the reason code is:

9

• Validate the configuration that is 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 that is 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.
• Verify that the network connectivity is reliable with adequate response time.

14

In db2diag.log, examine the common name and Subject Alternate Name (SAN) fields of the certificate that is returned by the specified host. These fields contain the hostnames or IP addresses that the certificate is issued for. Ensure that a correct certificate is being issued for the intended host. Consult the Hostname Validation documentation for more information about how to create correct certificates when using hostname validation for primary-standby SSL communication in an HADR configuration.

If all the hosts in the HADR environment are using correct certificates, this error would suggest that there is a security risk. The communication might have been intercepted by a malicious host.

ADM12511W

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 attempts to acquire the file from the primary database by entering a remote catchup state.

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

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 continues replaying logs that are shipped from primary on other table spaces.

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 large enough.
• The standby is unable to locate or access a load copy image.

ADM12513E

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 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.

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 nonzero 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 the same number of members and each pair of primary-standby matching members must have the 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.

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 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 the 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

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

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

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.

1. Cause 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

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

To prevent this warning, take the following actions:

1. Review the 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

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 rotates 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 reconnects to the primary database.
• If the standby database is unable to rotate the master key locally within that time, the standby database shuts down.

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

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.

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

The primary has rejected the connect request that is made by this standby database. The standby database is terminated.

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

ADM12520E

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.

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 proceeds and the shipment of log records resume.

ADM13000E

ADM13001E

ADM13002E

ADM13003E

ADM13004E

ADM13005E

ADM13006E

ADM13500E

ADM14000E

ADM14001C

ADM14002C

ADM14003W

ADM14004C

ADM14005E

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.

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

ADM14010C

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.

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

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.

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

ADM14012C

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.

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

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

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 by using either one of the following commands:

    db2start 

   Or

    START DATABASE MANAGER 

ADM14014C

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 an optimal service, especially if applications have a dependency on the specified resource or service.

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

ADM15000E

ADM15001E

ADM15500E

ADM15501W

ADM15502W

ADM15503E

ADM15510E

In the context of MDC tables, a block is a set of contiguous pages on disk. In MDC tables, rows of table data that contains 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.

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

Contact IBM software support for assistance.

ADM16000W

ADM16500E

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.

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 in-memory definition of an 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.

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 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.

No action required.

ADM16503E

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.

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

ADM16504E

An attempt to kill a process during a CLEANUP failed because the process is stuck in kernel mode ( EXITING state ). Cluster automation will retry the operation. However, if you see this message repeated several times, without being followed by 'ADM7513W Database manager has started' admin log, then the member process cannot be killed. In that case, the host must be manually rebooted.

Manually reboot the host.

ADM16505E

An attempt to kill a process during a CLEANUP failed because the process is stuck in kernel mode (EXITING state). Db2 automatically reboots the host.

Collect 'snap -ac' after the host comes back up and engage AIX support to diagnose the root cause of abnormal process state for a prolonged period of time.