Best Practices for Upgrading to DB2 9.7 Are you responsible for upgrading your database to DB2 9.7?

Planning your upgrade is much easier if you know these best practices. Are you looking for details about what will change when you upgrade? Do you know what will not change? What new features will be implemented when you create a new database? Come learn about often overlooked but very important tips and tricks to understand before upgrading. Objectives: !Describe changes to DB2 9.7 packaging and software and operating system requirements. !Understand DB2 9.7 changes to DDL, utilities, tools and monitoring. !Configure a DB2 9.7 database and instance to implement new features. !Analyze DB2 9.7 changes that affect applications and database runtime behavior. !Develop a DB2 9.7 upgrade strategy.

1 !

The objectives of this sessions are stated in the above graphic.

3 !

In order to have a successful migration to a new release, you need to make sure you plan your migration properly. The next set of charts go through the set up steps that you should go through when upgrading DB2.

First, lets look at the activities involved in planning a successful upgrade. The best place to start is to review the Upgrade Guide and Whats New documentation. As you read through this material, you may discover requirements and dependencies that are specific to your environment. For example, you may need to upgrade your servers operating system to a new version or maintenance level. Next you will want to create an inventory of impacted applications. Youll likely need to work with the application owners to determine the impact (if any) of the upgrade. For 3rd party applications, youll want to determine if the product supports DB2 9.7. Often you can easily determine this from the vendors website. Using all this information, you can draft a upgrade plan. The DB2 Upgrade Guide provides step-by-step instructions that you can copy and paste directly into your own upgrade plan. Depending on your needs, youll may want to prepare a plan for both server and client upgrade. The plan should include details on any specific hardware, operating system, and application upgrades that you identified. Before putting the plan in action, youll like want to review the plan with various stakeholders. Depending on the size of the project and organization, the review may need to involve many people. In large organizations, its not uncommon to involve peer DBAs, system, storage, and application administrators, IT architects, project managers, and representatives from impacted lines of business.

In the validation stage, one of the first things you need to do is establish acceptance criteria. You need to determine what conditions must be meet before you can deploy your DB2 upgrade in production. Often there are multiple conditions that make up acceptance criteria. For example, your criteria could consist of the following 3 points ! Condition #1 There must be no regression in application functionality ! Condition #2 There must be no degradation in system performance ! Condition #3 The system must successfully pass a stress test Obviously, youll need to make the criteria specific to your environment and business needs. Once you have established this criteria, the next step is to define a test plan that verifies the criteria. Note that in many cases IT organizations, customers often have well understood acceptance criteria and may have pre-existing test plans and tools in place. Next, you setup a test environment and begin executing the upgrade plan ! First, you perform any prerequisite hardware or operating system upgrades ! Next, you upgrade the DB2 data server and perhaps DB2 clients - depending on your needs ! Finally, if necessary, you upgrade your applications or enable them for new DB2 functionality Once the upgrade complete, its time to execute the test plan. The testing may identify gaps in the original plan. In this case, the gaps should be resolved and re-validated. Of course, the upgrade plan should be updated. Before the upgrade can be deployed, you may need to perform another review of the upgrade plan and seek approval.

Now we arrive at the final stage successful deployment Many production deployments are performed in a short time span. For example, overnight or over a weekend. As a result, it is unlikely youll be able to re-execute your validation tests after the deployment. In this situation, it is common to define a smaller scale sanity test. The sanity test usually consists of a subset of critical user acceptance tests. Follow you validated plan to upgrade your production system. Once the upgrade is complete, execute this sanity test for confirmation.

On the previous slides we showed the 3 key steps for a successful upgrade. On this slide we summarize the best practice items for a successful upgrade. Source: http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/ topic/com.ibm.db2.luw.qb.upgrade.doc/doc/c0007192.html Also: http://www-01.ibm.com/support/docview.wss?

We do not force an upgrade on you via a fixpack ! this really is important as you can be confident that when you apply a fixpack you are not going to get surprises We now provide and support three fixpack streams one for DB2 9, one for DB2 9.5, and lastly for DB2 9.7. Whichever you choose you can be confident that you will be supported for your specific stream If you want to move to DB2 9.7 from DB2 9.1 or DB2 9.5, you cannot do this with a fixpack install. You must install DB2 9.7 separately and go through the simple upgrade procedure we are speaking about in this presentation

"!

"!

Those moving from DB2 UDB V8 will note the difference in how we deploy our fixpacks in the new releases. No longer are fixpacks only applied to GA levels, but now they are completely standalone allowing for multiple full installs of different fixpack levels of DB2 (more on multiple installs later).

Because of the ability for coexistence, it is possible (although not always feasible) to have multiple versions and releases on the same system. Install information changes for you to know !! As of DB2 9, the DB2 install images no longer use operating system formats on Linux and UNIX. All install images are compressed tarballs (.tar.gz) !! On Linux and UNIX, you can use the db2ls command to list information about the DB2 systems and features installed on your system
"!

db2ls replaces platform-specific looks like pkgadd, rpm, SMIT, and swinstall

!! The new db2val tool verifies the core functionality of a DB2 copy by validating the installation, instances, database creation, connections to the database and health of partitioned database environments Regarding co-existence ! In past versions, DB2 used a fixed installation path and that is why multiple release levels could not coexist ! DB2 now allows the user to define the installation path. Therefore DB2 installation can adhere to corporate naming standards, etc.

Instead of doing an in-place upgrade of your pre-DB2 9.7 instance and database, why not consider doing a backup and restore
"! "! "!

Create a full offline backup of the DB2 database you are upgrading from Create a new DB2 9.7 instance Restore the pre-DB2 9.7 backup into the DB2 9.7 instance
"!

Database upgrade occurs automatically

Note: The backup must be a full, offline backup

"!

Rolling forward through the logs from a previous release is not possible

Some details on the Endianness

"!

What we are alluding to is that if you are restoring a DB2 Linux or UNIX database from a 32-bit platform to a 64-bit platform they must be on the same chip type (i.e., Intel/AMD, RISC, etc.) so the Endian (high/low byte order) is the same. Further information on this can be found at http://en.wikipedia.org/wiki/ Endianness

"!

This is a list of what is and what is not supported. As this changes and in upgraded frequently the best source is the URL listed at the bottom of the slide. Note: There are also minimum recommendations for subsequent Technical Levels as they are tested, so information gets more granular at http://tinyurl.com/r4qcay

To get information on Support changes for 32-bit and 64-bit DB2 servers refer to the appropriate online Information Centres. !! For DB2 9 http://publib.boulder.ibm.com/infocenter/db2luw/v9/index.jsp?topic=/com.ibm.db2.udb.uprun.doc/doc/ c0022266.htm#c0022266 !! For DB2 9.5 http://publib.boulder.ibm.com/infocenter/db2luw/v9r5/topic/com.ibm.db2.luw.qb.migration.doc/doc/c0022266.html !! For DB2 9.7 http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/topic/com.ibm.db2.luw.qb.upgrade.doc/doc/c0022266.html A simple but important step is to remember to apply all necessary OS specific patches prior to installation. Sometimes much grief and time in problem determination can be avoided if this is performed first!
1 2

To verify that it is a CHRP architecture system, issue the command lscfg and look for the following output: Model Architecture: chrp In AIX 6.1 there are two types of Workload Partitions (WPARs): system WPARs and application WPARs. DB2 installation is supported only on a system WPAR. AIX 6.1 also supports the ability to encrypt a JFS2 file system or set of files

This is a list of what is and what is not supported. As this changes and in upgraded frequently the best source is the URL listed at the bottom of the slide. Note: There are also minimum recommendations for subsequent Technical Levels as they are tested, so information gets more granular at http://tinyurl.com/r4qcay To get information on Support changes for 32-bit and 64-bit DB2 servers refer to the appropriate online Information Centres ! For DB2 9 http://publib.boulder.ibm.com/infocenter/db2luw/v9/index.jsp?topic=/ com.ibm.db2.udb.uprun.doc/doc/c0022266.htm#c0022266 ! For DB2 9.5 http://publib.boulder.ibm.com/infocenter/db2luw/v9r5/topic/ com.ibm.db2.luw.qb.migration.doc/doc/c0022266.html ! For DB2 9.7 http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/topic/ com.ibm.db2.luw.qb.upgrade.doc/doc/c0022266.html A simple but important step is to remember to apply all necessary OS specific patches prior to installation. Sometimes much grief and time in problem determination can be avoided if this is performed first! Note: DB2 database products support the hardware-enforced Data Execution Prevention (DEP) feature that is built into some Windows operating systems.

DB2 provides support for 32-bit operating systems on Linux on x86 and Windows operating systems, and 64-bit operating systems on UNIX, Linux and Windows operating systems. You cannot specify the bit size for the instance when you create or upgrade an instance. The bit size for new instances is determined by the operating system where DB2 9.7 is installed. The table on this slide summarizes the DB2 9.7 bit size support that is available for each of the listed operating systems. If you have 32-bit instances and you upgrade to DB2 9.7 on a 64-bit system, you must manage incompatibilities so that your applications and routines can run successfully. Incompatibilities arise because of discontinued functionality or incorrect shared library path specification. The slide on this table also summarizes the details on the available 32-bit and 64-bit support. For example, 32-bit unfenced stored procedures in any supported language except Java are not supported. By dropping and recreating these stored procedures as fenced you can resolve this issue. If you have 32-bit instances and you upgrade to DB2 9.7 on a 64-bit system, you must manage incompatibilities so that your applications and routines can run successfully. Incompatibilities arise because of discontinued functionality or incorrect shared library path specification. For example, 32-bit unfenced stored procedures in any supported language except Java are not supported. By dropping and recreating these stored procedures as fenced you can resolve this issue.

Independent of which release you are upgrading from , we always encourage upgrading to the latest release and fixpack level !! Always upgrade to the latest fixpack to ensure you have all of the available upgrade APAR fixes !! Often difficult (but not impossible) to fix/workaround upgrade specific issues after the fact
"!

Packed descriptors Catalog tables

"!

!! Can upgrade from any DB2 UDB V8 fixpack to DB2 9.7 !! Can upgrade directly from 32-bit to 64-bit !! DB2 9.1/DB2 9.5/DB2 9.7 do not support any of the following products that could have been optionally installed with DB2 UDB V8.x
"!

DB2 Data Warehouse Center / DB2 Data Warehouse Manager DB2 Information Catalog Center DB2 Data Links Manager DB2 DataJoiner

"!

"!

"!

!! No direct upgrade from DataJoiner V2 or from DB2 UDB V6/V7. Upgrade to DB2 UDB V8.x first (DB2 UDB Version 8.2 recommended)
"!

Pre-V8.1 versions must Upgrade to DB2 UDB V8.2.2 first.

"!

Review Technote # 1223978 if pre-DB2 UDB V8.2/V8.1 FP7 DB2 UDB Version 8.2 upgrade considerations http://www.ibm.com/support/docview.wss?uid=swg21223978

"!

The upgrade process is not difficult and we provide you with a number of different ways to go about it. It is important to note that the upgrade process does not touch your data !it is never compromised! Note: !db2iupgrade calls db2ckupgrade and fails if there are any outstanding conditions but will only report errors for the partition you're running from (in DPF). Other partitions may not be consistent - so watch out! ! Restoring the database backups will perform the database upgrade ! Database upgrade does not alter user data. The bulk of the upgrade time is spent updating the catalog information to the new format. The amount of time required to perform a database upgrade is dependent on amount of data in the system catalog (not the amount of user data). The more database objects you have the longer the upgrade time ! Keep in mind that during instance upgrade, we will save your settings in the database manager configuration file. If you restore databases into newly created instances, your database manager configuration settings will be the defaults specific in the new DB2 9.7 instance http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/index.jsp?topic=/ com.ibm.db2.luw.qb.upgrade.doc/doc/c0007191.html

This slide just summarizes some of the things you cannot do and what is not supported. http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/index.jsp?topic=/ com.ibm.db2.luw.qb.upgrade.doc/doc/c0007191.html

We repeat many times in this presentation that preparation is key. This slide shows you the steps you should consider for you preparation tasks prior to actually doing the upgrade. Source: http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/index.jsp? topic=/com.ibm.db2.luw.qb.upgrade.doc/doc/t0050541.html Details on db2ckupgrade: http://publib.boulder.ibm.com/infocenter/db2luw/ v9r7/topic/com.ibm.db2.luw.qb.upgrade.doc/doc/t0007187.html

Details on db2ckupgrade: http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/topic/com.ibm.db2.luw.qb.upgrade.doc/doc/t0007187.html Details on side-by-side upgrade steps http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/index.jsp?topic=/com.ibm.db2.luw.qb.upgrade.doc/doc/t0011368.html Windows Specific http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/topic/com.ibm.db2.luw.qb.upgrade.doc/doc/t0007199.html The upgrade process is not difficult and we provide you with a number of different ways to go about it. You should always perform a full offline database backup of your existing databases and any other pre-upgrade tasksthat apply. If you perform a full offline database backup recently and you cannot perform another one before upgrade, you can perform an incremental offline database backup instead. However, if you perform an incremental offline database backup before upgrade, you must have access to the most recent full offline database backup and the incremental offline database backup and use an automatic incremental restore to upgrade the database. A manual incremental restore will fail because each RESTORE DATABASE command tries to upgrade the database before thedatabase is completely recovered. Note: ! Database upgrade does not alter user data. The bulk of the upgrade time is spent updating the catalog information to the new format. The amount of time required to perform a database upgrade is dependent on amount of data in the system catalog (not the amount of user data). The more database objects you have the longer the upgrade time ! ! Keep in mind that during instance upgrade, we will save your settings in the database manager configuration file. If you restore databases into newly created instances, your database manager configuration settings will be the defaults specific in the new DB2 9.5 instance Upgrading your DB2 Administration Server (DAS) is only necessary to keep your existing DAS configuration. If your DAS is running on DB2 UDB Version 8, upgrading your DAS is necessary to use the Control Center for administrating instances running on DB2 9.1 or later, task management, and task scheduling. Otherwise, you can drop your existing DAS and create a new DAS in DB2 9.7. On Windows operating systems, if you choose to automatically upgrade your preDB2 9.7 copy and you have a DAS running under this copy, the DAS is also upgraded along with your instances ! The DB2 administration tools and the DAS have been deprecated in DB2 9.7 and might be discontinued in a future release. If you plan to use the Data Source Explorer in IBM Optim Database Administrator for DB2 LUW to perform database administration tasks, you do not have to upgrade the DAS. Also, you can drop the DAS and the tools catalog database. You can now use the Control Center for remote administration of DB2 9.7 instances, as well as pre-DB2 9.7 instances ! Optional: Upgrade your DAS if you want to keep your existing DAS configuration and use new functionality available in DB2 9.7. If your DAS is running on DB2 UDB

On this slide we remind you that we do not touch the data during an upgrade. However we do upgrade a number of database constructs.

After a database upgrade you may have to recreate some of your packages or rebind those marked as invalid by the upgrade process. If you choose not to rebind manually, they will be rebound at first access. Source: http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/index.jsp?

The actions you can and cannot take do to an upgrade vary based on the operating system platform. This slide lists some of those differences. Upgrading a Windows Server details
http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/index.jsp?topic=/ com.ibm.db2.luw.qb.upgrade.doc/doc/t0007199.html

Just a couple of things to be aware of that others have hit are listed on this slide. !! One upgrade issue that has affected a few customers APAR IY85495 Configuration files are out of sync with actual table space information. Reported by db2ckupgrade
"!

If affected, apply FP14 and upgrade again

Details on the 2nd issue follow. Question !! When using DB2 9.x on AIX 5L, DB2 commands such as db2icrt, db2start and db2stop appear to hang Cause !! DB2 9.x now supports IPv6. When DB2 calls AIX with getaddrinfo(), it will ask for both an IPv4 and an IPv6 address. The AIX resolver will return an IPv4 and an IPv6 address if the /etc/netsvc.conf file is configured as follows hosts=bind,local

AIX will first get the address locally, then if that fails, it will go to the DNS server. For server that does not have IPv6 configured, it is time consuming for AIX to attempt to get an IPv6 address before it fails. Since DB2 relies on AIX for getting address information, this cause DB2 commands to appear to be hanging. Note that any program which calls one of several AIX name resolution APIs that includes resolving IPv6 protocol will suffer the same long delays. Answer !! For servers that do not have IPv6 configured, you should configure the /etc/netsvc.conf file as follows
"!

hosts=bind4,local4

!! AIX will then only return IPv4 address for all name resolution APIs()

This slide simply states and reinforces the ability to have a hard-stop enforcement of DB2 product features and the fact that DB2 pureXML is now free.

This slide shows some of the administration changes in DB2 9.7. Partitioned indexes are created by default for partitioned tables Starting in DB2 9.7, if you do not specify the PARTITIONED or the NOT PARTITIONED clause on the CREATE INDEX statement when creating indexes on partitioned tables, a partitioned index is created by default Some database manager configuration parameters have been changed DB2 9.7 contains a number of new and changed database manager configuration parameters NO FILE SYSTEM CACHING for table space containers is the default for General Parallel File System (GPFS) Starting in DB2 9.7, when the underlying file system is GPFS, NO FILE SYSTEM CACHING is the default behavior for table space definition on a subset of platforms if you do not specify the FILE SYSTEM CACHING option on the CREATE TABLESPACE statement and on some of the table space definition parameters of the CREATE DATABASE command Some registry and environment variables have changed In DB2 9.7, there are a number of changes to registry and environment variables. Primary and secondary log files use non-buffered I/O by default In DB2 9.7, primary and secondary recovery log files use non-buffered I/O automatically, eliminating the overhead incurred by the operating system when caching these log files The CONCURRENTDBCOORDACTIVITIES threshold has been changed To reduce the chance of creating inadvertent deadlock scenarios, the behavior of the CONCURRENTDBCOORDACTIVITIES threshold has been changed. DESCRIBE command lists information about additional index types By default, the DESCRIBE command with the INDEXES FOR TABLE parameter now lists information about the system-generated XML regions index and XML path indexes, and DB2 Text Search indexes, in addition to information about relational indexes and indexes over XML data. Control Centre and Database Administration Server (DAS) have been deprecated For details please see http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/topic/com.ibm.db2.luw.wn.doc/doc/ i0054250.html

Just a small item on a change in the physical location of the registry files for DB2.

Details on registry variable changes are found here http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/ topic/com.ibm.db2.luw.wn.doc/doc/i0052034.html DB2_ATS_ENABLE This registry variable enables or disables the administrative task scheduler DB2_DDL_SOFT_INVAL This registry variable enables soft invalidation of applicable database objects when they are dropped or altered, meaning that active access to an object that is being invalidated can continue DB2_FCM_SETTINGS On Linux operating systems, you can set this registry variable with the FCM_MAXIMIZE_SET_SIZE token to pre-allocate a default 2 GB of space for the fast communication manager (FCM) buffer. The token must have a value of either YES or TRUE to enable this feature DB2_FORCE_OFFLINE_ADD_PARTITION This environment variable allows you to specify whether add partition operations are to be performed offline or online. The default setting of FALSE indicates that DB2 partitions can be added without taking the database offline. After instance upgrade, if you need to enforce the same behavior as in previous releases, set this registry variable to TRUE. This setting allows you to add partitions only in offline mode when you start the instance DB2_DEFERRED_PREPARE_SEMANTICS This registry variable allows dynamic statements containing untyped parameter markers to use deferred prepare semantics. By default, this variable is set to YES so that any untyped parameter markers derive their data types and length attributes based on the input descriptor from subsequent OPEN or EXECUTE statements. In previous releases, compilation of such dynamic statements would have failed DB2_PMAP_COMPATIBILITY This variable allows users to continue using the sqlugtpi and sqlugrpn APIs to return, respectively, the distribution information for a table, and the distribution map offset and database partition for a row. The default is ON (maintaining a size of 4,096 entries). When this variable is set to OFF, the distribution map size for new or upgraded databases is increased to 32 768 entries and you have to use the new db2GetDistMap and db2GetRowPartNum API DB2RESILIENCE This environment variable controls whether DB2 data page read errors are tolerated, and activates extended trap recovery. It is set to ON by default. To revert to the behavior of previous releases and force the database manager to shutdown the instance, set the registry variable to OFF DB2_LIMIT_FENCED_GROUP By default, this registry variable is set to OFF to maintain the same behavior as in previous releases so that there is no upgrade impact. However, you should consider setting this registry variable to ON after the upgrade to improve the security for external routines

Details on registry variable changes are found here http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/ topic/com.ibm.db2.luw.wn.doc/doc/i0052034.html DB2_LOGGER_NON_ BUFFERED_IO Previous default - OFF Starting with DB2 9.7, the default value for this variable is AUTOMATIC, which means that log files in the active log path might be accessed using non-buffered I/O. The database manager determines which log files benefit from using non-buffered I/O. In DB2 9.5 fixpack 1 or later, the default was OFF and log files were accessed using only buffered I/O DB2_EVMON_STMT_FILTER This variable has new options that allow users to determine which rules to apply to which event monitors. Each option represents an integer value mapping to a specific SQL operation. These new options are also available starting in DB2 9.5 fixpack 1 DB2_SQLROUTINE_PREPOPTS This variable has two new options: APREUSE, which indicates whether the query compiler will attempt to reuse access plans. CONCURRENTACCESSRESOLUTION, which specifies the concurrent access resolution to use for statements in the package DB2_WORKLOAD This variable has two new values: CM and WC. These settings allow you to configure a set of registry variables in your database for applications provided by IBM Content Manager and IBM Websphere Commerce. The CM and WC values are also available starting in DB2 9.5 fixpack 3 and fixpack 4, respectively DB2_EVALUNCOMMITTED and DB2_SKIPDELETED For statements operating under cursor stability isolation level with currently committed behavior enabled using the cur_commit database configuration parameter, these registry variables are in effect only when currently committed cannot be applied to a scan. Otherwise, the evaluation of predicates is performed on data retrieved by currently committed scans. If currently committed behavior was enabled using the BIND command or the PREPARE statement, these registry variables have no effect. For more information, see the cur_commit configuration parameter DB2_SERVER_ENCALG The DB2_SERVER_ENCALG registry variable is deprecated. If the alternate_auth_enc database manager configuration parameter is set, its value has precedence over the DB2_SERVER_ENCALG value DB2_SKIPINSERTED For statements operating under cursor stability isolation level with currently committed behavior enabled, this registry variable has no effect. For more information, see the cur_commit configuration parameter DB2_GRP_LOOKUP The setting for DB2_GRP_LOOKUP is not modified by instance upgrade. Due to the changes to the security model in DB2 9.7, if this registry variable is not set, ensure that domain users are granted the database authorities and privileges that they required after the upgrade.

This slide highlights some of the registry variable changes you should be aware of. Details on registry variable changes are found here http://publib.boulder.ibm.com/infocenter/db2luw/ v9r7/topic/com.ibm.db2.luw.wn.doc/doc/i0052033.html and http://publib.boulder.ibm.com/ infocenter/db2luw/v9r7/topic/com.ibm.db2.luw.wn.doc/doc/i0052379.html DB2_CAPTURE_LOCKTIMEOUT The registry variable is being deprecated and might be removed in a future release because there are new methods to collect lock timeout events using the CREATE EVENT MONITOR FOR LOCKING statement DB2_SERVER_ENCALG The registry variable is being deprecated and might be removed in a future release because you should use the alternate_auth_enc configuration parameter instead DB2_THREAD_SUSPENSION This variable has been replaced with the DB2RESILIENCE variable which activates extended trap recovery by default. It also controls whether DB2 data page read errors are tolerated 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. If you are upgrading from DB2 9.1 or earlier, consider removing deprecated registry variables in pre-DB2 9.7 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-DB2 9.7 releases as they do not have the intended effect.

This slide shows some of the instance (database manager) configuration changes in DB2 9.7. New and changed instance configuration parameters are listed here in detail: http://publib.boulder.ibm.com/infocenter/db2luw/ v9r7/topic/com.ibm.db2.luw.wn.doc/doc/i0052553.html alternate_auth_enc This parameter enables AES 256-bit encryption of user IDs and passwords. By default, this parameter is not set which means that the server accepts the encryption algorithm the client proposes so that there is no upgrade impact. During instance upgrade, if the DB2_SERVER_ENCALG registry variable is set, the alternate_auth_enc configuration parameter is set to AES_ONLY or AES_CMP depending on the setting of DB2_SERVER_ENCALG so that your pre-upgrade setting is preserved. After the upgrade, if you want to change how AES 256-bit encryption is used, update the setting of the alternate_auth_enc configuration parameter because the setting of DB2_SERVER_ENCALG is ignored. diagsize This parameter enables the DB2 diagnostic rotating logs functionality. During instance upgrade, the diagsize is set to 0 to maintain the same behavior as in previous releases. With this setting, one single diagnostic log file (db2diag.log) and one administration notification log (instance_name.nfy) are used for error and notification logging and these two files grow indefinitely ssl_cipherspecs Supported cipher specifications at the server. Specifies the cipher suites that the server allows for incoming connection requests when using SSL protocol ssl_clnt_keydb, ssl_clnt_stash To configure Secure Sockets Layer (SSL) support in a client in previous releases, you used to set values for SSL parameters in the SSLClientconfig.ini file. If this file exists when you upgrade your instances, these new database manager parameters are set to the corresponding SSL parameter value in SSLClientconfig.ini. If this file does not exist, these database manager parameters are set to null value (default). You must set these database manager parameters to enable SSL protocol support in a client ssl_svr_keydb, ssl_svr_label, ssl_svr_stash, ssl_svcename To configure SSL support in a DB2 instance in previous releases, you set values for SSL parameters in the SSLconfig.ini file. If this file exists when you upgrade your instances, these new database manager parameters are set to the corresponding SSL parameter value in SSLconfig.ini. If this file does not exist, these database manager parameters are set to null value (default) which means that the instance is started without SSL protocol support ssl_versions Supported SSL versions at the server. Specifies SSL and TLS versions that the server supports for incoming connection requests authentication, srvcon_auth If you enabled 256-bit AES encryption for user IDs and passwords, check the alternate_auth_enc parameter which allows you to specify an alternate encryption algorithm for user names and passwords

New, changed, and deprecated database configuration parameters are listed here in detail: http://publib.boulder.ibm.com/infocenter/ db2luw/v9r7/topic/com.ibm.db2.luw.wn.doc/doc/i0052508.html and here http://publib.boulder.ibm.com/infocenter/ db2luw/v9r7/topic/com.ibm.db2.luw.qb.upgrade.doc/doc/r0022380.html#r0022380__cdbm auto_reval Automatic revalidation and invalidation. During database upgrade, this configuration parameter is set to DISABLED to maintain the same invalidation and revalidation behavior for database objects as in previous releases so that there is no upgrade impact. If you create new databases in DB2 9.7, the auto_reval configuration parameter is set to DEFERRED by default so that revalidation deferred semantics are enabled. This setting impacts certain DDL statements and allows you to create views, functions, stored procedures, triggers, and global variables even if they reference objects that do not exist or are invalid. Blocknonlogged Block non-logged activity. This configuration parameter prevents the creation of tables that allow non-logged activity. By default, blocknonlogged is set to NO. cur_commit Currently committed. During database upgrade, this configuration parameter is set to DISABLED to maintain the same behavior as in previous releases so that there is no upgrade impact. If you want to enable currently committed behavior on cursor stability scans, you need to set the cur_commit configuration parameter to ON after the upgrade. For new databases created in DB2 9.7, the cur_commit configuration parameter is set to ON so that currently committed behavior is enabled on cursor stability scans. date_compat Date compatibility. This parameter indicates whether the DATE compatibility semantics associated with the TIMESTAMP(0) data type are applied to the connected database. The value is determined at database creation time, and is based on the setting of the DB2_COMPATIBILITY_VECTOR registry variable for DATE support. The value cannot be changed. dec_to_char_fmt This configuration parameter controls the character string returned by the CHAR(decimal-expresion) scalar function and the CAST specification from decimal to character. If dec_to_char_fmt is set to NEW, the CHAR function returns a fixed-length character string representation of a decimal number without leading zeros and without a decimal separator when the decimal part is zero. If dec_to_char_fmt is set to V95, the character string included leading zeros and a decimal separator when the decimal part was zero. During database upgrade, this configuration parameter is set to V95 so that the function returns the same character string format as in previous releases. For new databases created in DB2 9.7, dec_to_char_fmt is set to NEW. You need to set this parameter to V95 for compatibility with existing applications. mon_act_metrics, mon_deadlock, mon_locktimeout, mon_lockwait, mon_lw_thresh, mon_obj_metrics, mon_req_metrics, mon_uow_data These parameters control the collection of metrics and event monitor data at the database level including the new lock event monitor. During database upgrade, these parameters are set to NONE, except for mon_deadlock which is set to WITHOUT_HIST and mon_lw_thresh which is set to 5,000,000, so that there is no change in behavior from previous releases. stmt_conc Statement concentrator. This configuration parameter enables statement concentration for dynamic statements. The setting in the database configuration is used only when the client does not explicitly enable or disable statement concentrator. Default is OFF.

New, changed, and deprecated database configuration parameters are listed here in detail: http://publib.boulder.ibm.com/infocenter/ db2luw/v9r7/topic/com.ibm.db2.luw.wn.doc/doc/i0052508.html logbufsz Log buffer size. DB2 9.5 default - 8 pages (each 4KB); DB2 9.7 default - 256 pages ( each 4KB) applheapsz Application heap size.. In databases upgraded from DB2 9.1 or DB2 UDB V8, the applheapsz configuration parameter is set to AUTOMATIC to account for changes to the DB2 memory model. In releases prior to DB2 9.5, this parameter indicated the amount of memory for each database agent. Starting with DB2 9.5, this parameter indicates the total amount of memory for an application. Due to optimization enhancements to match MQTs, the requirement for application heap has increased. If this parameter is set to AUTOMATIC, this setting accounts for the new requirements. If you cannot set this parameter to AUTOMATIC or increase its value, reduce the number of MQTs considered for a given query by using optimization profiles dbheap Database heap. The database manager can now determine when to apply row compression to temporary tables that meet certain criteria to improve query performance. Memory allocated for database heap is used to create the compression dictionary and released once the dictionary is created. If you are using row compression and temporary tables eligible for compression, ensure that you have enough space to create the dictionary by setting the dbheap parameter to AUTOMATIC locklist Maximum storage for lock list. The limit for this parameter is now 134,217,728 pages (4 KB). Increase the locklist parameter to twice the pre-upgrade value. Due to the increase of the lock request block size to twice the size required in previous releases, active locks in the database require twice the amount of memory. logbufsz , logfilsiz, logprimary A log sequence number (LSN) uses now 8 bytes. In previous releases, LSN was 6 bytes in length. You might need to increase the value of this parameter according to your database logging activity. The maximum limit for logbufsz has been changed to 131,070. The maximum limit for logfilsiz has been changed to 1,048,572. The default value for the logbufsz parameter is now 256 pages (4KB). In previous releases it was 8 pages (4KB). After database upgrade, if you set the cur_commit configuration parameter to ON so that currently committed behavior is enabled on cursor stability scans, ensure that this parameter has a value of 256 or higher. pckcachesz Package cache size. To support the new access plan reuse, section diagnostic facilities, and XML explain, package cache memory requirements can increase 25 to 40 percent. For certain types of complex queries, the package cache memory requirements have doubled. The impact from the database upgrade should be minimal because of the small size of this cache relative to overall memory requirements. By setting this parameter to AUTOMATIC, the new requirements are taken into account. Storing LOB data as inlined might require that you increase the pckcachesz database configuration parameter. By setting this parameter to AUTOMATIC, the new requirements are taken into account. The maximum limit for pckcachesz on 64-bit operating systems has been changed to 2,147,483,646. dyn_query_mgmt Dynamic SQL and XQuery query management. This configuration parameter is deprecated because it is Query Patroller specific.

You should be aware of functionality that is deprecated or discontinued in DB2 9.7 that can affect the upgrade of your DB2 server. Also, you should be aware of the DB2 products that are no longer supported because upgrade from these products to DB2 9.7 is unsupported. To deal with these functionality changes, you must perform additional tasks before or after upgrade. The majority of these tasks are pre-upgrade or post-upgrade tasks for DB2 servers. The following list describes changes that are not included in the pre-upgrade and post-upgrade tasks for DB2 servers. Control Center tools have been deprecated The Control Center tools have been deprecated in DB2 9.7 and might be discontinued in a future release. Start using the Data Source Explorer in IBM Optim Database Administrator for DB2 LUW to perform database administration tasks. Netscape support has been discontinued Netscape is no longer a supported Web browser for First Steps and the installation launch pad. If Netscape is set up as your default Web browser, running First Steps will return the DBI1435E error message. Health Monitor has been deprecated The Health Monitor has been deprecated in DB2 9.7 and might be discontinued in a future release. Start using IBM Optim Database Administrator for DB2 LUW to monitor the health of your instances and databases. Type-1 indexes have been discontinued Type-1 indexes have been discontinued in DB2 9.7 and are marked invalid during database upgrade. Partitioned databases are no longer supported on Windows 32-bit operating systems Partitioned databases are no longer supported on Windows 32-bit operating systems in DB2 9.7. Some commands have been deprecated or discontinued. Raw logs - The use of raw devices for database logging has been deprecated since DB2 9.1 and will be removed in a future release. You should use a file system instead of a raw device Some DB2 Products have been deprecated or discontinued

This side notes some of the changes in DB2 9.7 which could affect database design.

This side notes some of the changes in DB2 9.7 which could affect database design. Of specific note is the new XML storage architecture. The architecture for how we store the XML documents internally has improved in DB2 9.7 to be more efficient. Any existing (pre-DB2 9.7) XML documents stored in DB2 are not converted to the new architecture upon upgrade. To take advantage of the new architecture you must move the XML documents to a new DB2 9.7 created table; online table move is useful here.

DBADM authority In DB2 9.7, there are new authorities for access control and data access. For each authorization ID holding DBADM authority, including the SYSADM group, the UPGRADE DATABASE command explicitly grants ACCESSCTRL and DATAACCESS authorities so that existing database administrators maintain the same authority access and privileges as in previous releases. The UPGRADE DATABASE command also grants EXECUTE privilege on all system-defined routines by explicitly granting the SYSROLE_AUTH_DBADM system role to any authorization ID holding DBADM authority. Revoking DBADM authority now implicitly revokes all these authorities SECADM authority In DB2 9.7, SECADM authority is required for security administration and it is the only authority that provides the ability to grant and revoke all authorities and privileges. If the database does not have a user with SECADM authority, the UPGRADE DATABASE command explicitly grants SECADM authority to the user performing this command. If any users in the SYSADM group need SECADM authority, you must explicitly grant it to them. Also, the UPGRADE DATABASE command revokes the EXECUTE privilege from PUBLIC on the audit routines, AUDIT_LIST_LOGS, AUDIT_DELIM_EXTRACT, and AUDIT_ARCHIVE. For each authorization ID holding SECADM authority, the UPGRADE DATABASE command explicitly grants the EXECUTE privilege on the audit routines by granting the SYSROLE_AUTH_SECADM system role SYSADM authority In DB2 9.7, DBADM authority is required for database administration and SECADM authority is required for security administration. If users in the SYSADM group need either authority, you have to explicitly grant it. Also, a user who holds SYSADM authority is no longer able to grant any authorities or privileges, except to grant table space privileges. The UPGRADE DATABASE command explicitly grants DBADM authority to the SYSADM group. Therefore, there should be no upgrade impact but you should review all of the changes in authorities and make any necessary changes SYSMON authority In DB2 9.7, the SYSMON authority now enables a user to also run several LIST commands EXECUTE privilege In DB2 9.7, the UPGRADE DATABASE command revokes the EXECUTE privilege from PUBLIC on the audit routines, AUDIT_LIST_LOGS, AUDIT_DELIM_EXTRACT, and AUDIT_ARCHIVE. For each authorization ID holding SECADM authority, the UPGRADE DATABASE command explicitly grants the EXECUTE privilege on the audit routines by granting the SYSROLE_AUTH_SECADM system role When the database upgrade is called implicitly using the RESTORE DATABASE command from a pre-DB2 9.7 database backup, the changes described above are also applied to the database that you are restoring.

This slide wraps up some other changes to SECADM and for extenders.

There are numerous items of interest for both DB2 CLP and SQL statements after an upgrade to DB2 9.7. While too numerous to mention here, we provide a highlight of what may affect and provide links to the online pages with details for this.

This slide gives you a tabular view of what options you have for upgrading your clients. Source http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/topic/ com.ibm.db2.luw.qb.upgrade.doc/doc/t0023857.html Source for Runtime client on Windows http://publib.boulder.ibm.com/ infocenter/db2luw/v9r7/index.jsp?topic=/ com.ibm.db2.luw.qb.upgrade.doc/doc/t0023854.html Source for Windows Client http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/ index.jsp?topic=/com.ibm.db2.luw.qb.upgrade.doc/doc/ t0023857.html

Taking the proper preparatory steps will help you have a successful upgrade. This slide shows the key steps for your clients. Source http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/ topic/com.ibm.db2.luw.qb.upgrade.doc/doc/t0023857.html Verifying your client upgrade http://publib.boulder.ibm.com/ infocenter/db2luw/v9r7/index.jsp?topic=/

As of DB2 9, the set of supported protocols was trimmed down to reflect what customers were really using in the marketplace. This slide simply gives you some of the basic information of the new DB2 9.7 Data Server clients that you will deploy in your environment.

In DB2 9.7, the support for connectivity between clients and DB2 servers is shown in this slide. Connections to DB2 9.7 servers from a client release prior to version 8.2 are not supported. Besides connectivity support, if you issue DB2 commands or SQL statements from a client to a DB2 server with a different version, you must be aware of incompatibilities between releases that can arise from changes in default behavior or restrictions lifted for these commands or SQL statements. For example, if you issue the DESCRIBE statement with the INDEXES FOR TABLE parameter from a DB2 9.7 client, a pre-DB2 9.7 DB2 server lists only relational indexes while a DB2 9.7 server lists indexes over XML data and text search indexes in addition to relational indexes. Refer to Upgrade impact from DB2 command changes and Upgrade impact from SQL statement changes for details. Details: http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/index.jsp?topic=/ com.ibm.db2.luw.qb.upgrade.doc/doc/c0023412.html

This slide reiterates the fact that you can upgrade your client before your server and use your DB2 9.7 client to connect to your current DB2 server. Note, however, that the level of function will be limited by the level of the DB2 server being connected to.

The IBM Data Server Driver for JDBC and SQLJ includes the db2jcc.jar class file for applications that use JDBC 3.0 methods or earlier and the db2jcc4.jar class file for applications that use JDBC 4.0 methods or earlier. The JDBC 4.0 java.sql.DatabaseMetaData.getDriverName method returns the IBM Data Server Driver for JDBC and SQLJ name instead of the IBM DB2 JDBC Universal Driver Architecture name. To manage the behavioral differences between the IBM Data Server Driver for JDBC and SQLJ Version 4.7 and previous releases of this driver, upgrade Java applications that use IBM Data Server Driver for JDBC and SQLJ. The DB2 JDBC Type 2 driver has been deprecated since DB2 9.1. You should modify your Java applications and external routines to use the IBM Data Server Driver for JDBC and SQLJ with type 2 connections. To manage the behavioral differences between the IBM Data Server Driver for JDBC and SQLJ Version 3.57 and the DB2 JDBC Type 2 driver, upgrade your Java applications that use DB2 JDBC Type 2 driver. DB2 CLI applications, DB2 CLP interface, and .Net Data Provider clients support Secure Sockets Layer (SSL). The IBM Global Security Kit (GSKit) provides encryption services for the Secure Sockets Layer (SSL) support. Refer to Configuring Secure Sockets Layer (SSL) support in non-Java DB2 clients for details about how to enable SSL in a client including how to download and install the GSKit

This slide summarizes some items of note for SQL procedures.

On this slide we note some of the key items for unfenced external routes and provide a link for how to manage issues.

Implicit LOB data inlining For upgraded databases, the INLINE LENGTH default value is the maximum size of the LOB descriptor for the corresponding LOB column. LOB data is inlined when the length of the LOB data plus the overhead is less than the INLINE LENGTH value. Therefore, if the LOB data length plus the overhead is less than the LOB descriptor size for the LOB column, the LOB data is implicitly inlined in a table row after the database upgrade. If you make extensive use of LOBs in your database applications, you can increase performance for SQL statements that access the LOB data by increasing INLINE LENGTH to an adequate value because no additional I/O is required to access the LOB data when it is inlined in a table row. Refer to Adopting new DB2 Version 9.7 functionality in database applications and routines for details. XQuery expressions and XML data types After upgrading to DB2 9.7, the XQuery string data type is used for values of elements or attributes that are not cast in an XQuery expression. Type annotations in existing XML documents that you validated are no longer used to do implicit casting. If you validate new XML documents to insert them in an XML data type column, these XML documents are stored without type annotations. For XQuery expressions that depend on data types based on type annotations from validated XML documents, you need to explicitly cast elements and attributes in all XQuery expressions from validated XML documents. Without explicit type casting, XQuery expressions that used implicit casting or casting to other types will fail after the upgrade.

On this slide you see more details on LOB locators and the upgrade process.

This slide provides some details for Java external routines and the upgrade process.

System catalog views and system-defined administrative routines and views After database upgrade to DB2 9.7, the system catalog views under the SYSCAT schema remain compatible with catalog views that you defined in DB2 9.1. However, there are new columns, increases in column length, or columns with changed data types in some of the system catalog views. SQL administrative routines include changes such as new parameters and new columns returned. Also, some routines are replaced with system-defined administrative routines and views. In addition, all of the system-defined table functions with names that start with SNAPSHOT_ have been deprecated since DB2 9.1. Review the following topics to determine if you have applications and scripts that are impacted by changes to system catalog views and system-defined administrative routines and views System catalog Deprecated system-defined administrative routines and their replacement routines or views

"! "!

For new databases created in DB2 9.7, the cur_commit configuration parameter is set to ON so that currently committed semantics is enabled on cursor stability scans. Under the new currently committed semantics, only committed data is returned, as was the case previously with the cursor isolation level, but now a read operation does not wait for a write operation to release row locks. A returned result set operating under cursor stability isolation level might be different than in previous releases. Refer to Adopting new Version 9.7 functionality in upgraded databases for details on enabling currently committed behavior.

The MQT matching process now considers additional situations that can result in the optimizer choosing a different execution plan for queries that match an MQT. In upgraded databases, you could experience improvements in queries matching GROUP BY MQTs that use the DISTINCT clause and queries that use DATE predicates right after the upgrade without any actions on your part. However, exploiting these features further and exploiting other improvements such as use of view MQTs or optimization guidelines to force the optimizer to choose a specific MQT, require implementation after the upgrade. Refer to Adopting new DB2 Version 9.7 functionality in database applications and routines for details on how to use these new features.

The optimizer now pushes down relational predicates (for filters and XPath extractions) into XQuery query blocks. Therefore, enabling early data filtering and better potential index usage. In partitioned database environments, early data filtering potentially reduces the amount of data transfer between partitions. Consequently, you will notice new query access paths, improved performance, and reduced memory usage for combined SQL/XQuery queries. See Compiler rewrite example: Predicate pushdown for combined SQL/XQuery statements

Scan sharing is introduced in DB2 9.7 to allow a scan to read the buffer pool pages of another scan. This behavior increases concurrency, reduces query response times, and increases system throughput without requiring hardware upgrades. The SQL compiler determines eligibility for scan sharing automatically. At run time, an eligible scan may or may not participate in sharing, based on considerations in effect that were not known at compile time. See Scan sharing Rebind any statically bound packages after upgrade to take advantage of optimizer improvements.

This slide summarizes some of the items you should be aware of with respect to database packages after upgrading to DB2 9.7. For rebinding, see http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/
topic/com.ibm.db2.luw.qb.upgrade.doc/doc/t0022384.html For optimizer enhancements, see http://publib.boulder.ibm.com/infocenter/ db2luw/v9r7/topic/com.ibm.db2.luw.qb.upgrade.doc/doc/ c0023412.html#c0023412__optimizer

This slide summarizes key points for ADO.NET applications. Source: http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/ topic/com.ibm.db2.luw.qb.upgrade.doc/doc/t0023417.html

This slide summarizes key points for .NET CLR applications. Source: http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/ topic/com.ibm.db2.luw.qb.upgrade.doc/doc/t0023428.html

This slide simply provides a high level list of best practices for your application upgrade when moving to DB2 9.7. Source: http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/ topic/com.ibm.db2.luw.qb.upgrade.doc/doc/t0023449.html

This slide provides some thoughts on enabling new function in DB2 9.7 in your applications.

Here you see a few items which are very useful for you for your planning purposes before, during, and even after your upgrade. These are resources that will help you feel confident in this process and help you succeed. !! DB2 Upgrade Portal
"!

Portal contains a list of all the available upgrade roadmaps, upgrade guides, and information and resources related to upgrade to a new release of DB2 products and upgrade of software that uses DB2 database products such as IBM InfoSphere Warehouse, DB2 Content Manager, and SAP systems From the portal, users can find the version specifics roadmaps that they need. As a result, if a a customer bookmarks the Portal, the link is future-proof for this and future upgrades
"! "!

One-stop-shop for the latest information Provides detailed upgrade roadmaps for different DB2 versions

!! DB2 Upgrade Guide is a comprehensive resource for all upgrade informatio !! DB2 9.7 Upgrade Roadmap - This upgrade roadmap will help you navigate through the available information and resources related to upgrading from DB2 UDB Version 8, DB2 9.1, or DB2 9.5 to DB2 9.7

This page continues with additional resources to make you successful and prepared for your upgrade.

59 !