Migrating Successfully to IBM DB2 10 for z/OS

IBM® DB2® for z/OS® holds, protects, and makes available one of your organization’s most valuable assets: its data. It’s no surprise, then, that when you are planning to migrate to a new version of DB2, you are involved in a critical project.

Ideally, the migration steps will be transparent to the applications, and you provide them with a new, more powerful, more reliable database management system.

But how do you define success for a migration project? Most simply, success is a measure of how well you achieved your objectives through the execution of a project. What are your expectations when migrating to DB2 10? It is a particularly feature-rich release capable of filling expectations in many diverse fields. Some of the early adopters of DB2 10 were interested in the new security options. Many were looking forward to CPU reduction and other performance improvements. For others, availability and throughput were more important.

Defining clear and measurable objectives is the first step toward a successful migration.

The importance of planning and preparation

Getting your environment ready for DB2 10 includes considering new system requirements and unsupported functions. Consequently, adapting your environment may take some planning and preparation, which may involve a lot of time.

For example, DB2 10 introduces significant changes in the DB2 Catalog that require z/OS System Managed Storage (SMS) for the catalog objects before you can migrate. This is not a difficult change to apply, but it could concern some organizations. This change often involves DBAs and storage administrators, and it might require some effort to implement.

Another example: DB2 10 does not support Private Protocol for distributed access to DB2 for z/OS, so you have to migrate some of your applications to Distributed Relational Database Architecture (DRDA). However, this is good news because DRDA is a more efficient and powerful protocol than Private Protocol—so making this change could help some of your applications work better.

To fully exploit the improved characteristics of the distributed access to DB2 for z/OS, you might need to upgrade the DB2 Client and DB2 Connect servers in your organization. You can perform these changes well in advance—perhaps even in the early stages of your migration strategy.

You can migrate to DB2 10 from DB2 8 and skip DB2 9 in the process. This is a nice option that allows users to get the DB2 10 code in a potentially shorter migration path. Nevertheless, planning is more important if you plan to skip a release. Part of the planning is defining how you will measure the effects of DB2 10. Which metric will you use to determine if you have, for example, a CPU improvement or a CPU regression? How will you report on whether your system has a higher throughput after the migration?

Success stories

After more than two years of DB2 10 general availability (GA was in October 2010), success stories of stability and improved performance abound. Many users have shared their migration experiences in user groups, forums, and conferences. Of course, some of them also experienced problems along the way. Many initial adopters played a very important role in detecting issues in the early days. Their significant contributions helped to achieve the code maturity that DB2 10 has acquired today, providing a more comfortable level of stability for all users.

There is no doubt that there is a special interest in the potential DB2 10 CPU savings. User experiences are confirming these expectations, especially for online transaction processing (OLTP) and distributed access to DB2 workloads. The reports of users involved in skip-release migrations (from DB2 8 to DB2 10) are especially important when you consider that you are getting the DB2 code of version 9 and version 10 in a single step, with zero CPU regression.

DB2 10 introduces the concept of CPU savings out of the box—that is, improvements without application changes. But for non-dynamic SQL applications, you have to REBIND packages to get these improvements. To help you plan a “safe” REBIND strategy, consider using REBIND with APREUSE and APCOMPARE. With the proper use of these new DB2 10 options, you can get the DB2 10 runtime improvements while avoiding changes in access paths. (Remember, the potential CPU savings are workload-dependent, so your results might be different.)

After a REBIND, packages get the real storage benefit of DB2 10: a dramatic reduction in memory below the 2 GB bar required for thread. Storage of less than 2 GB is a common limitation on the scalability of DB2 subsystems, especially on large DB2 installations. A single instance of DB2 10 can accommodate up to 20 times more concurrent threads than previous versions of DB2, providing an unprecedented step forward on concurrency and enabling potential additional savings through consolidation and simplification.

Thanks to the catalog changes in DB2 10, you get a higher level of concurrency for operations that access the DB2 Catalog. This allows for concurrent data definition language (DDL) processing and concurrent BIND and REBIND operations, providing the basis for reviewing your current maintenance windows and reducing total maintenance time. You can reduce maintenance requirements by replacing catalog links with indexes, but the advantages are visible only when you migrate to DB2 10 New Function Mode (NFM). In Conversion Mode (CM), DB2 has to maintain both catalog indexes and links because you are allowed to fall back your DB2 subsystem in this mode. For this reason, you should plan to move out of CM and toward NFM soon after a business-cycle validation. And of course, being in NFM allows you to take advantage of the many new features that are only available with it—such as the caching of dynamic SQL statements with literals, SQL Procedure Language performance improvements, and the Index Include Columns feature.

Your migration: A success story?

DB2 10 is a feature-rich, innovative release. There are many reasons why you and your organization should be planning to migrate soon. And the migration steps are not particularly difficult.

But to make your migration a success story, you have to plan ahead carefully. You must plan the preparation process to get your environment ready. You must plan the migration itself in anticipation of DB2 10 NFM. And most importantly, you must plan how to get the best out of the new DB2 features.

Happy planning, happy migration, and happy DB2 10!

Are you planning a migration to DB2 10? Have you already done it? Please share your experience in the comments.