Blogs

Raising the Availability Bar

Elevating availability in IBM DB2 11 for z/OS is changing the game

Jeff Josten, IBM distinguished engineer and the chief architect of the IBM® DB2® for z/OS® enterprise data server, speaks often of his team’s relentless focus on “raising the bar.” But on what is the bar being raised? Josten means raising it on everything that makes DB2 for z/OS highly well suited as a data server for enterprise-scale deployments. The DB2 11 data server continues an ongoing track record of providing comprehensive capability enhancements for this enterprise-scale database management system (DBMS). Throughout 2014, various features and capabilities of the advanced DB2 for z/OS data server will be examined here, beginning with this installment that looks at DB2 Version 11’s high-availability enhancements.

Uplifting high availability

DB2 for z/OS has a 30-year history as a repository for critical data assets in organizations spanning a wide range of industries around the world. DB2 for z/OS provides a foundational component of many IT infrastructures. It is designed to deliver highly reliable availability that offers around-the-clock access to data, enabling applications to keep factories humming, deliveries on schedule, and salespeople well informed. DB2 Version 11 is in lockstep with its development team’s mantra: it is helping raise the bar for high availability. Several examples demonstrate the ways it achieves this goal.

Online logical database design changes

Beginning with DB2 Version 8, the DB2 development team made it a priority to expand the range of database design changes that a database administrator (DBA) could effect without having to drop and re-create table spaces, tables, and/or indexes. In continuing that work, DB2 Version 11 provides the DROP COLUMN option of the SQL statement, ALTER TABLE. This feature enables a DBA to remove a column in a DB2 table without taking the table offline, if the column is deemed unnecessary. Once a DROP COLUMN statement has been issued, the change is materialized through an online REORG of the table space containing the target table.

Online physical database design changes

One or more partitions of a partitioned table that ends up holding significantly more rows than other partitions of the table is not unusual. Evening out row distribution among partitions for these occurrences—a good approach for optimal performance and availability—used to impact access to a table’s data. DB2 Version 11 addresses this problem in the following two ways:

  • An ALTER TABLE statement to adjust a partition’s key value no longer puts the affected partitions in a restricted state. This operation is now a so-called pending data definition language (DDL) change that is materialized by a subsequent online REORG of the partitions.
  • The REBALANCE option—which is used to allow DB2 to handle partition limit key changes and associated redistribution of table rows—can now be specified for a SHARLEVEL(CHANGE) online REORG. This option enables read/write access to the data during the REORG operation, instead of the read-only access that was offered in previous versions.
Concurrency for DDL, utility, and program bind and rebind operations

For a long time, using DB2 packages bound with RELEASE(DEALLOCATE) in combination with persistent threads—threads that persist through commits—has been a means of boosting execution efficiency for applications accessing DB2. Unfortunately, this combination could block execution of some bind and rebind commands, DDL statements, and utility jobs because it caused packages to remain in a continuous in-use state for relatively long periods.

In a DB2 Version 11 environment, if a bind or rebind command, DDL statement, or utility operation would be blocked by an in-use RELEASE(DEALLOCATE) package, a switch to RELEASE(COMMIT) behavior can be made automatically for any thread associated with the package. RELEASE(COMMIT) mode enables the waiting database administration function to proceed to successful completion. This enhancement also addresses situations in which a package bound with RELEASE(COMMIT) is continually in an in-use state because of the high-volume concurrent execution of related transactions—by effectively and temporarily draining use of the package.

Optimizing uptime

Keen observers may have noticed that these DB2 Version 11 availability enhancements don’t have anything to do with crash prevention. The reason is because DB2 for z/OS—and IBM System z® mainframe computers, in general—already offers a data-serving platform designed to deliver a very high degree of uptime. As a result, increasing DB2 availability means going beyond mere uptime. If a system is up, but data in a table is inaccessible because of a database maintenance operation that must be performed or a database design change that must be made, the value of the system’s up status is diminished. Just having a system up almost all the time is a “been there, done that” proposition for the DB2 for z/OS development team. Therefore, its efforts in recent years have focused steadfastly on helping eliminate data access–compromising effects of database administration activities. When a DB2 system is up, data is always available.

That kind of mind-set for DB2 developers leads to results that raise the bar. In this case, DB2 Version 11 helps raise the availability bar. In the coming months, look for coverage of how DB2 Version 11 can raise the performance bar. Meanwhile, please share any thoughts or questions in the comments.

[followbutton username='IBMdatamag' count='false' lang='en' theme='light']