DB2 Version 10.1 for Linux, UNIX, and Windows
DB2 Version 10.1 for Linux, UNIX, and Windows
Changes to DB2® registry variables, configuration parameters, database physical design characteristics, and database authorities and privileges can result in DB2 server behavior changes that might impact your upgrade.
As a general rule, instance profile variables that you set in your DB2 profile registry or your system environment retain their values after an instance upgrade. Some global profile registry variables, such as DB2SYSTEM and DB2PATH, are set by the DB2 installation procedure or instance upgrade. However, the global profile registry variables that you set by running the db2set command with the -g option are not upgraded. Therefore, you must define them after upgrade.
Existing database and database manager configuration parameters also, as a general rule, retain their values after upgrade. However, the default values assigned to new parameters or the new default values assigned to existing parameters could impact the behavior or performance of your applications.
| Name | Upgrade impact |
|---|---|
| DB2_INDEX_PCTFREE_DEFAULT | You can use this registry variable to specify the default percentage of each index page to leave as free space when building the index. If not specified the default is 10. |
| DB2_XSLT_ALLOWED_PATH | You can use this registry variable to controls whether the DB2 instance refers to external entities defined inside of an XSLT stylesheet. By default, this variable is not set so that no access is allowed to external entities. If you are using the document function of XSLT, you must set up this variable to the directories where your XML files can be downloaded. For examples on how to use this variable, see Example: Using the document function of XSLT.. |
| Name | Upgrade impact |
|---|---|
| DB2_EXTENDED_OPTIMIZATION | The ENHANCED_MULTIPLE_DISTINCT setting has been deprecated in Version 10.1. Although the ENHANCED_MULTIPLE_DISTINCT setting is preserved during instance upgrade, if you use multiple distinct queries, you should remove this setting to start using new enhancements for these queries introduced in Version 10.1. |
| DB2BPVARS | The NUMPREFETCHQUEUES and the PREFETCHQUEUESIZE option of this variable have been discontinued as optimization improvements render these options obsolete. The DB2BPVARS registry variable is still deprecated. |
| DB2_NO_FORK_CHECK | This registry variable is no longer deprecated. Continue to use this variable to have the DB2 runtime client minimize checks to determine if the current process is a result of a fork call. |
| DB2NTNOCACHE | This registry variable is no longer deprecated. Continue to use this variable to override the undocumented 192 MB limit for the cache. |
| DB2_PMODEL_SETTINGS | You can now use this variable's new SRVLST_EQUAL_WEIGHT option to override the default behavior in which member weights are computed based on load, and have non-zero member weights in the server list always be identical. |
You should remove the use of registry variables that are deprecated because the functionality associated with the variable is obsolete or has been replaced by new functionality. See Deprecated registry variables to determine the upgrade impact of deprecated registry variables. See Discontinued registry variables to determine the upgrade impact of discontinued registry variables.
If you are upgrading from DB2 Version 9.5 or earlier, consider removing deprecated registry variables in pre-Version 10.1 releases because the functionality associated with the variable is obsolete or has been replaced by new functionality. Also, remove the use of discontinued registry variables in pre-Version 10.1 releases as they do not have the intended effect. See Changes that impact Version 9.5 or earlier releases for details.
The following table describes the upgrade impact of the default values of new database manager configuration parameters:
| Name | Upgrade impact |
|---|---|
| wlm_dispatcher | This parameter enables (YES) or disables (NO) the DB2 workload manager (WLM) dispatcher. By default, an enabled WLM dispatcher controls only CPU limits. |
| wlm_disp_concur | This parameter specifies how the DB2 workload manager (WLM) dispatcher sets the thread concurrency level. You can also manually set the thread concurrency level to a fixed value. |
| wlm_disp_cpu_shares | This parameter enables (YES) or disables (NO) the control of CPU shares by the DB2 workload manager (WLM) dispatcher. By default, an enabled WLM dispatcher controls only CPU limits. |
| wlm_disp_min_util | This parameter specifies the minimum amount of CPU utilization that is necessary for a service class to be included in the DB2 WLM-managed sharing of CPU resources. |
The following table describes the upgrade impact of changes to database manager configuration parameters:
| Name | Upgrade impact |
|---|---|
| alt_diagpath | Alternate diagnostic data directory path configuration parameter has been set from Null to INSTHOME/sqllib/db2adump/ $m for DB2 pureScale® environment, when you upgrade to Version 10.1. If your instance is in a Version 10.1 single partition environment or partitioned database environment then it will remain NULL. |
| cf_diagpath | Diagnostic data directory path configuration parameter for the cluster caching facility (CF) has been set from Null to INSTHOME/sqllib/db2dump/ $m in DB2 pureScale environments. |
| diagpath | The
default value of diagnostic data directory path configuration parameter
is changed
|
No database manager configuration parameters have been deprecated or discontinued in this release. However, if you are upgrading from DB2 Version 9.5 or earlier, consider removing deprecated database manager configuration parameters in pre-Version 10.1 releases because the functionality associated with the parameters is obsolete or has been replaced by new functionality. Also, remove the use of discontinued database manager configuration parameters in pre-Version 10.1 releases as they do not have the intended effect. See Changes that impact Version 9.5 or earlier releases for details.
The following table describes the upgrade impact of the default values of new database configuration parameters:
| Name | Upgrade impact |
|---|---|
| dft_schemas_dcc | This parameter allows the control of default setting for DATA CAPTURE CHANGES on newly created schemas for replication purposes. |
| hadr_replay_delay | This parameter specifies the time that must have passed from when the data is changed on primary before these changes would be reflected on the standby database. The time is specified in number of seconds. |
| hadr_spool_limit | This parameter allows log replay on the HADR standby database to be behind the HADR primary database. If there is a spike in transaction volume or slow replay caused by specific operations and the log receive buffer fills up, the log data is written (or spooled) to disk and then read later. |
| hadr_target_list | This parameter, which is used to enable multiple high availability disaster recovery (HADR) standbys, specifies a list of up to three target host:port pairs that act as HADR standby databases. |
| log_appl_info | This parameter specifies that the application information log record is written at the start of each update transaction. |
| log_ddl_stmts | This parameter specifies that extra information regarding DDL statements will be written to the log. |
| mon_uow_execlist | This parameter enables (ON) or disables (OFF) the collection of execution list information by the unit of work event monitor. By default, execution list information is not collected (OFF). It is a child parameter of the mon_uow_data database configuration parameter. |
| mon_uow_pkglist | This parameter enables (ON) or disables (OFF) the collection of package list information by the unit of work event monitor. By default, package list information is not collected (OFF). It is a child parameter of the mon_uow_data database configuration parameter. |
| systime_period_adj | This database configuration parameter specifies how to handle the situation of a history row for a system-period temporal table potentially being generated with an end timestamp less then the begin timestamp. |
The following table describes the upgrade impact of changes to existing database configuration parameters:
| Name | Upgrade impact |
|---|---|
| auto_reorg | In Version 10.1, automatic reorganization supports reorganizing indexes for volatile tables. After upgrading your databases, if you have automatic reorganization enabled and DB2WORKLOAD is set to SAP, index reorganization will be performed periodically on volatile tables. See Automatic reorganization. |
| auto_stats_views | This parameter enables and disables automatic statistic collection on statistical views. When enabled, the DB2 product will maintain the statistics on statistical views automatically. |
| hadr_local_host | In previous releases, no HADR configuration
parameter could be updated dynamically; the database had to be deactivated
and reactivated for the updates to take effect. Starting in Version 10.1,
updates to these configuration parameters can take effect on the HADR
primary without deactivating the database. Issue a STOP HADR on the
primary, followed by a START HADR AS PRIMARY. As a result, you can
make configuration parameter updates to your HADR primary without
having an impact on the applications that are using the database. Note: The
following new HADR configuration parameters also have this behavior:
|
| mon_uow_data | In Version 10.1, the values that you can specify for mon_uow_data have changed. The default value for mon_uow_data continues to be NONE. It is a parent parameter to mon_uow_execlist and mon_uow_pkglist. For more information, see Collection of package list information has changed. |
| mon_req_metrics | In Version 10.1, the default value for mon_req_metrics is changed from BASE to NONE. |
| mon_act_metrics | The default value for mon_act_metrics is changed from BASE to NONE. |
| mon_obj_metrics | The default value for mon_obj_metrics is changed from BASE to NONE. |
| mon_lw_thresh | The default value for mon_lw_thresh is changed from 5000000 to 4294967295. |
You should remove the use of database configuration parameters that are deprecated because the functionality associated with the variable is obsolete or has been replaced by new functionality. See Some database configuration parameters have been changed to determine the upgrade impact of deprecated database configuration parameters.
If you are upgrading from DB2 Version 9.5 or earlier, consider removing deprecated database configuration parameters in pre-Version 10.1 releases because the functionality associated with the parameter is obsolete or has been replaced by new functionality. Also, remove the use of discontinued database configuration parameters in pre-Version 10.1 releases as they do not have the intended effect. See Changes that impact Version 9.5 or earlier releases for details.
The following table describes the upgrade impact of changes in physical design characteristics of databases:
| Physical characteristic | Upgrade impact |
|---|---|
| CHAR or VARCHAR type | Casting XML data to a CHAR or VARCHAR type that is too small causes the data to be truncated to fit the specified data type and no error is returned. |
| DECIMAL type | Casting XML data to a DECIMAL type that has insufficient space for digits to the right of the decimal separator, the trailing digits are truncated to fit the specified data type and no error is returned. |
| XML data of incompatible types | Comparing XML data of incompatible types, the comparison returns FALSE. |
The following table summarizes the upgrade impact of changes in authorities and privileges:
| Name | Upgrade impact |
|---|---|
| None for this release | None for this release |
See Upgrade impact from DB2 command changes and Upgrade impact from SQL statement changes for a summary of DB2 command and SQL statement changes with upgrade impact. See the Command Reference and SQL Reference for details about all the changes in authorization.