| OS/2 | WIN | UNIX | DB2 PE |
In DB2 Version 5, ADSM_PASSWORD is a database configuration parameter. In DB2 Version 2, it was a database manager configuration parameter.
| Note: | In DB2 PE Version 1, this parameter was spelled ADSM_PASWD. |
Any attempt to update or retrieve the DATABASE MANAGER CONFIGURATION value for ADSM_PASSWORD will be a no-op; that is, no error or value will be returned.
You will have to set the ADSM_PASSWORD for any databases for which you want to use the parameter.
| OS/2 | WIN | UNIX | DB2 PE |
In DB2 Version 5, NUM_POOLAGENTS is used as a guideline for how large you want the agent pool to grow. It replaces the MAX_IDLEAGENTS parameter used in DB2 Version 2. The agent pool contains subagents and idle agents. Idle agents can be used as parallel subagents or as coordinating agents.
You will need to replace the MAX_IDLEAGENTS parameter with this new parameter.
| OS/2 | WIN | UNIX | DB2 PE |
In Version 2, the value of the MAXDARI and MAXCAGENTS parameters were limited by the value of the MAXAGENTS configuration parameter. The default value of -1 means "equal to MAXAGENTS".
Beginning in DB2 Version 5, the value of these two parameters are limited by the value of the MAX_COORDAGENTS configuration parameter. The default value of -1 means "equal to MAX_COORDAGENTS".
| Note: | On non-Partitioned (non-MPP) configurations, the configuration parameter MAX_COORDAGENTS can only have a value of -1, meaning "equal to MAXAGENTS". |
Updates to MAXDARI and MAXCAGENTS to values greater than -1 may fail if the value specified is greater than MAX_COORDAGENTS.
Be aware of how MAX_COORDAGENTS is set. MAXDARI and MAXCAGENTS cannot be greater than MAX_COORDAGENTS.
| OS/2 | WIN | UNIX | DB2 PE |
The data type of this database configuration parameter has changed from being an unsigned 2-byte integer to an unsigned 4-byte integer. A new token has been added for the configuration APIs indicating a 4-byte integer.
The configuration API will still recognize the Version 2 token, but the full range of values of this parameter is greater than what is supported by a 2-byte integer.
Existing applications will continue to work using the configuration API or via REXX, but the results might be unpredictable because of the larger range in DB2 Version 5.
Recode the application or REXX script to use the new token. For users of the Command Line Processor or the Control Center, this change in the token would not affect your applications.
| OS/2 | WIN | UNIX | DB2 PE |
The data type of this database configuration parameter has changed from being an unsigned 2-byte integer to an unsigned 4-byte integer. A new token has been added for the configuration APIs indicating a 4-byte integer.
In Version 2, the value of this parameter was limited by the size of the APPLHEAPSZ configuration parameter and indicated the size of a per-agent parameter. In DB2 Version 5, this parameter limits the size of a global per-database cache. Therefore, its value is no longer limited by the size of the APPLHEAPSZ configuration parameter.
In DB2 PE Version 1.2, the value of this parameter was limited by 7/8 of the value of the DPHEAP configuration parameter, since the cache was allocated from DBHEAP. In DB2 Version 5, the value of the cache is allocated out of its own heap. Therefore, the value of the PCKCACHESZ configuration parameter is no longer limited by the size of the DBHEAP configuration parameter.
The following might occur:
Depending on the symptoms, do one of the following:
| OS/2 | WIN | UNIX | DB2 PE |
Beginning in DB2 Version 5, the use of these parameters has changed significantly.
Applications might receive an SQL0973 indicating that the APPLHEAP heap or APP_CTL_HEAP has been exhausted.
You will have to reconfigure these parameters for optimum performance. Refer to the Administration Guide and the online help for the Control Center for recommendations on tuning these parameters.
| UNIX | OS/2 | WIN | DB2 PE |
In previous versions of DB2, each database had one buffer pool, which was created when the database was created. You could change the size of the buffer pool using the buffpage parameter. In DB2 Version 5, each database can have multiple buffer pools. You can create additional buffer pools or change the size of a buffer pool through the CREATE BUFFERPOOL or ALTER BUFFERPOOL statements or through the Control Center using the appropriate command.
If the buffer pool size is specified to be -1, then the value of the database configuration parameter is used as the size of the buffer pool.
| Note: | When the BUFFPAGE database configuration parameter is updated, you will receive an SQLCODE SQL1482W warning. |
In DB2 Version 5, a new or migrated database has a default buffer pool. For a new database created in DB2 Version 5, the size of the default buffer pool is determined by the operating system. For a migrated database, the size of the buffer pool is set to -1, which then refers to the buffpage configuration parameter.
To resolve this problem, you will need to do the following:
| OS/2 | WIN | UNIX | DB2 PE |
In DB2 Version 5, in a partitioned database, the node number is appended to the path in the form path_name \NODExxxx (path_name /NODExxxx on UNIX-based systems), where xxxx is the 4 digit node number. This maintains the uniqueness of the path across the database partitions.
When updating the NEWLOGPATH configuration parameter, the node number is automatically appended to the path name. This may result in path names that are too long (greater than 242 characters), and the configuration parameter update may fail.
Be aware that the log files will reside in the path that includes the node numbering designation. If the configuration parameter update failed, ensure that the path length, including the node number designation, is less than or equal to 242 characters.
|
|
|
| DB2 PE |
In DB2 PE Version 1.2, this database configuration parameter was known as MULTIPGAL and the data type of this database configuration parameter was an unsigned 1-byte integer. In DB2 Version 5, the data type of this parameter is an unsigned 2-byte integer, using a new token.
Existing applications will continue to work using either the SQLF_DBTN_MULTIPGAL or the SQLF_DBNR_MULTIPAGE_ALLOC tokens.
While the configuration APIs support both tokens, applications should be updated to use the new tokens.
| UNIX |
Beginning in Version 2, new dft_extent_sz configuration parameter serves as the default EXTENTSIZE setting for table spaces where this is not specified.
It is modifiable.
If an application attempts to specify the SEGPAGES parameter in the CREATE DATABASE command, the command will still work; however, the parameter will be ignored. The EXTENTSIZE will be set to the default.
Update the command to specify the new EXTENTSIZE parameter when creating a table space.
| UNIX | OS/2 |
In DB2 Version 5, the size of a lock request block has been changed to 36 bytes. As a result, fewer lock request blocks will fit in the configured amount of space allocated for the lock list.
This may result in more frequent lock escalations.
You should increase the setting of the LOCKLIST configuration parameter accordingly.
| UNIX | OS/2 |
The tokens for database configuration parameters buffpage and sortheap have changed.
The names of the parameters as identified in command line processor or in the Control Center remain the same (buffpage and sortheap). The old tokens are maintained for backlevel binary compatibility.
On AIX, the configuration APIs treat the new token and the old token as indicating a 32 byte unsigned integer. On OS/2 however, the configuration APIs will treat the old token as indicating a 16 byte unsigned integer. This is consistent with Version 1 behavior. The new tokens will be treated as indicating an unsigned 32 byte integer.
Version 1 applications which specify the old token names will not work against a Version 2 or later database.
In order to migrate old application code the token names need to be changed. Additionally, on OS/2, the data type of the variable being passed to the configuration APIs will have to be changed to an unsigned 32 byte integer.
| UNIX |
In DB2 for AIX Version 1, the numerical values for the database manager configuration parameter tokens SQLF_KTN_MAXDARI and SQLF_KTN_KEEPDARI were 22 and 23 respectively. Beginning in Version 2, they are 80 and 81 respectively. Binaries from Version 1 will be supported despite this discrepancy.
Applications which perform a DATABASE MANAGER CONFIGURATION operation and specify the changed parameters by explicitly stating their numeric values will no longer work as desired.
If code is being migrated and the token name is used, nothing needs to be changed. If however, the token values were coded explicitly in the application, the application will have to be changed to reflect the new values.
To protect the application from future changes of this type, it is recommended that the token is coded, rather than the actual value.
| OS/2 |
In DB2 for OS/2 Version 1.2, the numerical values for the database manager configuration parameter tokens SQLF_KTN_FILESERVER and SQLF_KTN_OBJECTNAME were 22 and 23 respectively. Beginning in Version 2, they are 47 and 48 respectively. Binaries from Version 1 will be supported despite this discrepancy.
Applications which perform a DATABASE MANAGER CONFIGURATION operation and specify the changed parameters by explicitly stating their numeric values will no longer work as desired.
If code is being migrated and the token name is used, nothing need be changed. If however, the token values were coded explicitly in the application, the application will have to be changed to reflect the new values.
To protect the application from future changes of this type, it is recommended that the token is coded, rather than the actual value.
| UNIX | OS/2 | WIN |
Many return codes indicating an attempt to set a specific parameter outside of its valid range were replaced with generic out-of-range return codes.
The following return codes have been replaced with a return code of -5130 (SQLF_RC_INV_RANGE as defined in sqlutil.h):
and SQLF_RC_INV_DBMENT (-5126) is returned, beginning in Version 2, instead of SQLF_RC_INVK3 (-5105) which is no longer returned.
If an application is looking for a specific error code which has been replaced by a new one, then this will cause the application to function incorrectly.
Update the application to look for valid return codes.
| OS/2 |
All configuration parameters in OS/2 that were expressed in segments in Version 1 are now expressed in 4KB pages.
Beginning in Version 2, when you specify a configuration parameter which used to be a measure of segments, it is treated as a measure of 4KB pages. This will result in a different total amount of space in most cases.
Migration takes care of this incompatibility by allocating the same amount of storage that was allocated before the migration. Existing applications that specify parameter values should be converted to specify the proper number of 4KB page units.
| OS/2 |
The following database configuration parameters are obsolete:
Version 1 binary applications attempting to update or get the value of these parameters will result in a no-operation with a return code of 0.
Applications should be updated to not reference these parameters.
If you are updating or viewing the value for MAXTOTFILOP, then you can now use Database Manager Configuration commands.
| UNIX | OS/2 |
The following database manager configuration parameters are obsolete:
Version 1 binary applications attempting to update or get the value of these parameters will result in a no-operation with a return code of 0.
Applications should be updated to not reference these parameters.
|
|
|
| DB2 PE |
After you migrate to DB2 UDB from DB2 Parallel Edition Version 1.x, you may, in some situations, notice a performance degradation compared to DB2 Parallel Edition. This is caused by a change in the default value of the DB2_MMAP_READ and DB2_MMAP_WRITE profile registry values. (These were know as environment variables in DB2 Parallel Edition.) The default value of these registry variables in DB2 Parallel Edition was "OFF". This allowed AIX to cache DB2 data that was read from JFS filesystems into memory (that is, the data was outside the buffer pool). In DB2 UDB, as in the case of DB2 Version 2, the default value of these registry values is "ON" which prevents the AIX caching.
In DB2 UDB, the problem occurs when accessing DB2 data that was previously referenced but is no longer in the DB2 buffer pool. Because the DB2 buffer pool is relatively small, in DB2 UDB such access may require disk I/O. In DB2 Parallel Edition, the request to access the data may have been satisfied by the AIX cache which is much faster.
In situations like the one mentioned above, setting DB2_MMAP_READ and DB2_MMAP_WRITE to "OFF" in DB2 UDB may result in queries running up to three times faster. However, you should devote a large amount of system memory to the DB2 buffer pool. If you do this, AIX caching provides no additional benefit.