ADM4000-4999

ADM Message ID Message Explanation User Response

ADM4000W

A catalog cache overflow condition has occurred. There is no error but this indicates that the catalog cache has exceeded the configured maximum size. If this condition persists, you may want to adjust the CATALOGCACHE_SZ DB configuration parameter.

ADM4001I

A failure has occurred while regenerating the view viewName.

ADM4002W

The Event Monitor target table targetTableName (table schema tableSchema ) already exists.

ADM4003E

The UPGRADE DATABASE command failed to upgrade the DB2 Text Search catalogs or indexes due to an error in stored procedure stored-procedure-name.

The database is enabled for DB2 Text Search and has been upgraded successfully. However, an error occurred while upgrading the text search catalogs or indexes.

Call the stored procedures to upgrade the DB2 Text Search catalogs or indexes.

  • If SYSPROC.SYSTS_UPGRADE_INDEX failed to complete successfully, reissue the stored procedure.
  • If SYSPROC.SYSTS_UPGRADE_CATALOG failed to complete successfully, then call these upgrade procedures again in this specific order:
    1. SYSPROC.SYSTS_UPGRADE_CATALOG
    2. SYSPROC.SYSTS_UPGRADE_INDEX

ADM4004W

The db2ckupgrade utility found that the database contains the following types of objects, which are not supported by the version to which upgrading is being considered: XML global variables; or compiled SQL functions that use XML parameters or that return XML types.

You can verify that a given database can successfully be upgraded to a later version using the db2ckupgrade utility.

This message is returned when the db2ckupgrade utility finds database objects which are not supported in the version to which you are upgrading. Specifically, this message is returned when the following database objects are in a database being checked:

  • Global variables of type XML
  • Compiled SQL functions that use parameters of type XML or that return XML types

If you proceed to upgrade the database to the target version, these objects will be invalidated during database upgrade. You will be unable to use these database objects until you upgrade to a version that supports those database objects.

To be able to use the database objects that are invalidated during upgrade, upgrade to a release and fix pack of DB2 database that supports XML global variables and compiled SQL functions that use XML parameters or that return XML types. When you upgrade to a fixpack that supports those database objects, the objects will be automatically revalidated the first time they are referenced after the database has been upgraded.

ADM4005W

The upgrade procedure marked the following types of database objects as "invalidated" because those objects are not supported in the upgraded version: XML global variables; and compiled SQL functions that use XML parameters or that return XML types.

You can upgrade a database to a later version using the UPGRADE DATABASE command.

This message is returned when a database that contains the following database objects is upgraded to a version that does not support those types of database objects:

  • Global variables of type XML
  • Compiled SQL functions that use parameters of type XML or that return XML types

The upgrade operation marked all of these types of database objects as "invalidated". You will be unable to use these database objects until you upgrade to a version that supports those database objects.

To be able to use the database objects that were invalidated during upgrade, upgrade to a release and fix pack of DB2 database that supports XML global variables and compiled SQL functions that use XML parameters or that return XML types. When you upgrade to a fixpack that supports those database objects, the objects will be automatically revalidated the first time they are referenced after the database has been upgraded.

ADM4006E

The db2ckupgrade utility detected a configuration problem that will prevent a successful database upgrade: In the DB2_SQLROUTINE_PREPOPTS registry variable, the EXPLAIN value is set to YES or ALL, but there are no explain tables in the database.

You can customize precompile and bind options for SQL and XQuery procedures and functions by setting the DB2_SQLROUTINE_PREPOPTS registry variable. For example, you can cause access plan information to be stored in explain tables by specifying "EXPLAIN YES" in DB2_SQLROUTINE_PREPOPTS. (Using the DB2_SQLROUTINE_PREPOPTS registry variable is just one of several ways to configure the behavior of the explain feature.)

This message is returned when the db2ckupgrade utility is used to verify whether a specified database can be upgraded, and the DB2_SQLROUTINE_PREPOPTS registry variable contains either "EXPLAIN YES" or "EXPLAIN ALL", but no explain tables exist in the database.

Resolve this upgrade-blocking problem by taking either one of the following actions:

  • Set the EXPLAIN value in the DB2_SQLROUTINE_PREPOPTS registry variable to "EXPLAIN NO".
  • Create explain tables in the database.

After this problem has been resolved, confirm whether there are any other problems that would prevent a successful upgrade operation by issuing the db2ckupgrade command again.

ADM4007W

The db2ckupgrade utility detected a configuration problem that might prevent a successful database upgrade: In the DB2_SQLROUTINE_PREPOPTS registry variable, the EXPLAIN value is set to YES or ALL.

You can customize precompile and bind options for SQL and XQuery procedures and functions by setting the DB2_SQLROUTINE_PREPOPTS registry variable. For example, you can cause access plan information to be stored in explain tables by specifying "EXPLAIN YES" in DB2_SQLROUTINE_PREPOPTS. (Using the DB2_SQLROUTINE_PREPOPTS registry variable is just one of several ways to configure the behavior of the explain feature.)

If you are planning to upgrade a given database, if the DB2_SQLROUTINE_PREPOPTS registry variable contains either "EXPLAIN YES" or "EXPLAIN ALL", and if the database contains no explain tables for your user ID, then if you issue the UPGRADE DATABASE command, the upgrade operation will fail.

When the db2ckupgrade utility detects that the DB2_SQLROUTINE_PREPOPTS registry variable contains either "EXPLAIN YES" or "EXPLAIN ALL", this message is printed to warn you that if there are no explain tables in the database for the ID of the user who issues the UPGRADE DATABASE command, the upgrade operation will fail.

Before upgrading the database, perform one of the following actions:

  • Set the EXPLAIN value in the DB2_SQLROUTINE_PREPOPTS registry variable to "EXPLAIN NO".
  • If there are no explain tables in the database for the user who will be performing the database upgrade operation, create explain tables in the database for that user ID.

ADM4014N

The ALTER TABLE ATTACH operation failed because either there are no indexes on the source table, or the indexes on the source table source-table-name do not match the partitioned index index-name on the target table target-table-name. Reason: reason-code.

See the applicable reason code for more information:

1

The indexes on the source table do not match the unique partitioned index on the target table.

2

The indexes on the source table do not match the partitioned XML pattern values index that was created with the REJECT INVALID VALUES on the target table.

3

The indexes on the source table do not match the partitioned indexes on the target table, and the ALTER TABLE ATTACH statement is defined with the REQUIRE MATCHING INDEXES clause.

Respond according to the reason code, and then rerun the ALTER TABLE ATTACH operation.

1

Create a unique index on the source table that matches the unique partitioned index on the target table.

2

Create an XML pattern values index on the source table (using the REJECT INVALID VALUES clause) to match the index on the target table.

3

Either create an index on the source table that matches the partitioned index on the target table, or remove the REQUIRE MATCHING INDEXES clause from the ALTER TABLE ATTACH statement.

ADM4015I

No index on the source-table source table matches the partitioned index index-name on the target table target-table. ALTER TABLE ATTACH processing continues.

After the ATTACH operation completes successfully, the index partition will be built on the first access to the newly attached table partition. Usually, the first access is from a SET INTEGRITY statement.

To maximize roll-in efficiency, create indexes on the source table that match the partitioned indexes on the target table before attaching the source table to the target table.

No response is required.

ADM4016I

The index indexName on the source table source-table does not match any partitioned indexes on the target table target-table . ALTER TABLE ATTACH processing continues.

A successful ATTACH operation will drop this index on the source table.

To maximize roll-in efficiency, drop the indexes on the source table that do not match the indexes on the target table before attaching the source table to the target table.

No response is required.

ADM4100W

The db2ckupgrade or UPGRADE DATABASE command identified external routines or user-defined wrappers that could have potential incompatibility with the multi-threaded database manager. See the file generated-file that contains the list of routines and wrappers identified, or a set of statements to restore the routine or wrapper definitions altered by the UPGRADE DATABASE command.

The database manager is multi-threaded, as opposed to multi-processed, on Linux and UNIX operating systems. The execution of NOT FENCED and NOT THREADSAFE external routines or user-defined wrappers, which are NOT FENCED in the multi-threaded database manager, could lead to incorrect results, database corruption, or abnormal termination of the database manager. As a result, all NOT FENCED routines and all NOT FENCED user-defined wrappers must be THREADSAFE.

During database upgrade, all external NOT FENCED routines that have no dependency on the database manager library are altered to FENCED and NOT THREADSAFE. Also, the DB2_FENCED option is set to 'Y' for all user-defined wrappers. The UPGRADE DATABASE command generates a script generated-file that contains the statements to restore the routine or wrapper definitions.

When running db2ckupgrade, external NOT FENCED routines that have no dependency on the database manager library are identified. These routines will be altered to FENCED and NOT THREADSAFE during database upgrade. The file generated-file is generated with a list of all the identified external NOT FENCED routines and user-defined wrappers with the DB2_FENCED option is set to 'N'.

When upgrading the database, verify that all the affected routines and user-defined wrappers can safely be run as NOT FENCED and THREADSAFE. Once verified, they can be altered back to NOT FENCED and THREADSAFE, by running the file generated-file to alter all of the routines and user-defined wrappers to NOT FENCED. Modify this file to contain only the statements that should be executed and run the CLP script after the database has been upgraded.

After running db2ckupgrade and before upgrading your database, alter the identified routines, listed in the generated file generated-file, to FENCED and NOT THREADSAFE and set the DB2_FENCED option to 'Y' for user-defined wrappers.

ADM4101W

The UPGRADE DATABASE command failed to automatically collect statistics on the table-name system catalog table. The following RUNSTATS command returned SQLCODE sqlcode with tokens tokens : command.

After successfully completing the database upgrade, the UPGRADE DATABASE command was unable to collect the statistics on the table-name system catalog table. The RUNSTATS command returned SQLCODE sqlcode with tokens tokens.
  1. Determine the appropriate user response based on the SQLCODE sqlcode returned.
  2. Correct the problem and re-issue the RUNSTATS command on the table-name system catalog table to collect statistics.

ADM4102W

The database contains one or more identifiers called NULL. To avoid conflict with the NULL keyword, you should qualify or delimit with double quotes any identifiers called NULL in SQL statements.

An untyped NULL specification can occur anywhere in an expression. If an identifier called NULL is used in an SQL statement without being fully qualified or delimited, the identifier specification might resolve to the NULL keyword instead of the identifier reference. This would result in a change in behavior from previous releases.

Determine if you have identifiers called NULL in the database by issuing the following statements:

  • SELECT TABSCHEMA, TABNAME, COLNAME FROM SYSCAT.COLUMNS WHERE COLNAME = 'NULL';
  • SELECT ROUTINESCHEMA, ROUTINENAME, PARMNAME FROM SYSCAT.ROUTINEPARMS WHERE PARMNAME = 'NULL';
  • For Version 9.5 databases or later, SELECT VARSCHEMA, VARNAME FROM SYSCAT.VARIABLES WHERE VARNAME = 'NULL'.

To avoid conflict with the NULL keyword, qualify or delimit with double quotes the identifiers called NULL in SQL statements.

ADM4103W

The connection attribute attributename contains asterisks (*) in the workload workloadname. A single asterisk (*) will be replaced with two asterisks (**) during database upgrade. Reason code = reason-code.

Starting with DB2 Version 9.7, you can use a single asterisk (*) as a wildcard character and two asterisks (**) to represent one literal asterisk (*) in some workload attributes.

The db2ckupgrade command identifies asterisks (*) in the connection attribute and the UPGRADE DATABASE command replaces the single asterisk (*) with two asterisks (**) if the type of connection attribute is one of the following values: 1 ( APPLNAME ) 6 ( CURRENT CLIENT_USERID ) 7 ( CURRENT CLIENT_APPLNAME ) 8 ( CURRENT CLIENT_WRKSTNNAME ) 9 ( CURRENT CLIENT_ACCTNG )

Reason codes are as follows:

1

The connection attribute was truncated because it reached the maximum length when a single asterisk (*) is replaced with two asterisks (**) during database upgrade.

2

The connection attribute was not truncated when a single asterisk (*) is replaced with two asterisks (**) during database upgrade.

Replace asterisks (*) in the connection attribute with another character if possible.

ADM4104E

One or more databases are enabled for XML Extender. You must remove the XML Extender functionality from the instance and databases before upgrading.

Starting with DB2 Version 9.7, XML Extender is discontinued. Possible reasons for this error are:

  • The instance that you specified for upgrade has XML Extender functionality enabled, and the implicit call to db2ckupgrade fails because one or more databases are enabled for XML Extender.
  • The database that you are checking for upgrade is enabled for XML Extender.

Remove the XML Extender functionality from the instance and disable databases for XML Extender. Then re-issue the db2iupgrade or db2ckupgrade command.

ADM4105W

The Database is enabled for DB2 WebSphere MQ functions. The set of functions defined for XML Extender will be dropped during database upgrade.

Starting with DB2 Version 9.7, XML Extender is discontinued. The set of DB2 WebSphere MQ functions that are defined for XML Extender will be dropped during database upgrade. These functions declare parameters using XML Extender user-defined data types.

After the database upgrade, if you want to use DB2 WebSphere MQ functions with xml data type parameters, run the enable_MQFunctions command with the -force and -xml parameters to create new MQ functions for XML data type and re-create the existing MQ functions.

ADM4106W

The upgraded database was enabled for XML Extender. XML Extender functionality was not disabled during database upgrade. However, this functionality will fail to run.

Starting with DB2 Version 9.7, XML Extender has been discontinued. The database that you restored from a backup image created in a previous release is enabled for XML Extender.

The database was upgraded successfully. However, the XML Extender functionality such as routines will fail to run.

Restore the database to a DB2 copy running a database product version that supports XML Extender, then upgrade from XML Extender.

ADM4110I

Updating the database level.

The data server is updating the database to the latest level supported by the current mod pack.

No connections are allowed against the database until this process completes.

No user response is required.

ADM4111I

The database level has been updated successfully.

The data server has successfully updated the database to the latest level supported by the current mod pack.

No user response is required.

ADM4112W

Update to the latest database level supported by the current mod pack has been skipped. Reason code: reason-code.

The data server could not update the database to the latest level supported by the current mod pack.

Possible reason code values are:

1

The database is not activating via an ordinary connect or explicit ACTIVATE DATABASE command after a clean database shutdown.

2

The database level cannot be updated, while the database is in an active HADR relationship.

Take the appropriate action indicated for the reason code value given:

1

Deactivate the database and then reactivate it using an ordinary connect or an explicit ACTIVATE DATABASE command.

2

Stop HADR and request the database update operation using the ADMIN_UPDATE_DB_LEVEL stored procedure. Deactivate and reactivate the database. Then, reinitialize the standby with a full backup from the primary.

ADM4113E

The operation-name operation could not be completed because an incomplete database update was detected.

The data server could not complete the requested operation because an incomplete database update was detected.

Restart the database to resolve the incomplete database update and then retry the operation.

ADM4114W

An incomplete database update operation was rolled back by crash recovery and is no longer pending.

The data server rolled back an incomplete database update operation while performing crash recovery and the update is no longer pending.

Rerequest the database update operation using the ADMIN_UPDATE_DB_LEVEL stored procedure.

ADM4115E

The database can not be updated to the latest level because an error was detected in the catalogs. The details are located in the result file file-name that needs to be formatted with the db2inspf utility. The file can be found in the diagnostic data directory path.

A request was made to update the database to the latest level supported by the current mod pack. However, that request failed because an error was detected in the catalogs. As a precaution, the database will not be updated to the latest level.

Conact IBM support for assistance.

ADM4200N

The data type of the column could not be changed because of the data in the row with row identifier rowid.

You can change the data type of a table column by using the ALTER TABLE statement with the ALTER COLUMN clause and the SET DATA TYPE clause.

This message is returned when an attempt to change the data type of a column fails because of an incompatibility between data in one of the rows of the table and the data type to which the column is being changed.
  1. Review the db2diag logs for more detailed information about why the data in the named row prevented the data type of the column from being changed.
  2. Resolve the incompatibility by doing one of the following:
    • Modify the data in the row so that the data type of the column can be changed.
    • Change the data type of the column to one that is compatible with the existing data.

ADM4201N

The data type of the column could not be changed because of the default values for the column named column-name in the table named table-name.

You can change the data type of a table column by using the ALTER TABLE statement with the ALTER COLUMN clause and the SET DATA TYPE clause.

This message is returned when an attempt to change the data type of a column fails because of an incompatibility with the default values for the column being altered.
  1. Review the db2diag logs for more detailed information about why the default values for the column prevented the data type of the column from being changed.
  2. Resolve the incompatibility by doing one of the following:
    • Modify or drop the default values for the column so that the data type of the column can be changed.
    • Change the data type of the column to one that is compatible with the existing data.

ADM4500W

A package cache overflow condition has occurred. There is no error but this indicates that the package cache has exceeded the configured maximum size. If this condition persists, you should perform additional monitoring to determine if you need to change the PCKCACHESZ DB configuration parameter. You could also set it to AUTOMATIC.