Time to Take Another Look at DB2 Data Sharing?

As a member of the DB2 for z/OS National Technical Support Team at the IBM Dallas Systems Center in the 1990s, I had the opportunity to work with some of the first organizations to implement DB2 data sharing on a parallel sysplex. When data sharing was introduced with DB2 for z/OS Version 4, and for some years thereafter, the primary motivation for utilizing the shared-data technology was processing capacity augmentation. IBM had previously shifted from bipolar chip sets to CMOS microprocessors in its mainframe computers, and while this change enabled Big Blue to significantly reduce mainframe TCO, it was some time before the computing power of the CMOS machines matched and then exceeded that of their bipolar predecessors. There were companies in the second half of the 1990s - and even into the 2000s - with DB2-based applications that were pushing the limit of single-system mainframe processing capacity. For these organizations, a shared-disk mainframe cluster (the so-called parallel sysplex) provided the only growth path available. Implementation of DB2 data sharing was an imperative. Some data sharing groups grew to include more than 10 DB2 subsystems.

These days, DB2 data sharing is still of critical importance to many companies, but to a greater and greater extent the key benefit organizations are deriving from the technology is not capacity - it's availability. Oh, sure, data sharing still enables a firm to direct the computing power of multiple mainframe servers at a single DB2 database, but that's not the huge deal it was a few years ago. Because mainframe engines have become so fast (one microprocessor can do today what an entire high-end server did in the 1990s), and because one can get so many engines in one machine (up to 54, whereas 10 used to be considered a lot), numerous companies running parallel sysplexes now could - theoretically, at least - go to from the cluster to a single mainframe and still have room to grow. Would you find many organizations that would seriously consider going from the sysplex to a single-image system? I believe that you wouldn't. People who love their DB2 data sharing groups now do so largely because there's a greater emphasis than ever before on ultra-high availability, and no platform delivers the goods in that department like a parallel sysplex.

DB2 data sharing helps organizations to achieve dial-tone quality by greatly reducing the scope of unplanned outages and very nearly eliminating the need for planned outages. Consider the unplanned outage impact of data sharing. I know of a company that runs a 9-way DB2 data sharing group. Last year, one of the DB2 subsystems in this group abended (in itself, a very rare occurrence). The result? Work continued to flow to the other 8 members of the data sharing group, the failing subsystem was automatically brought back online in less than two minutes, and none of the company's clients noticed an impact from the DB2 failure. In the area of planned outage elimination, data sharing has enabled organizations to apply maintenance to the hardware and software components of a DB2 data sharing group with no need for a maintenance window. How is this done? Simple: a DB2 subsystem is quiesced (in-flight units of work complete, but new requests are routed to other members of the group) and then restarted to activate newly applied software fixes (the same could be done with a z/OS image, or even a mainframe server), and the process is repeated in a round-robin fashion until the maintenance is active on all of the members of the group (DB2 subsystems at a maintenance level "n" can run concurrently with members at an "n + 1" level of maintenance as the round-robin process runs its course). About the only thing requiring a group-wide shutdown (and a relatively brief one, at that) is a switch to a new global locking protocol (I believe that this has happened once since data sharing was introduced) or the running of the CATMAINT job that changes the catalog structure for a new version of DB2 (many companies upgrade their DB2 subsystems to a new version of the code about once every two to three years). DB2 data sharing enables companies to walk the 24x7 walk, versus just talking the talk (I'm originally from Texas, and I actually speak this way sometimes).

Perhaps super-high availability sounds good to you, but you're afraid that data sharing is too expensive for your organization. Think again. It's a good bit less expensive that it was in the early days. For one thing, the advent of internal coupling facilities (CFs provide shared-memory resources which house the global buffer pools and lock structures used by members of the DB2 data sharing group) has taken the hardware cost of data sharing down considerably. On top of that, the CPU cycles spent in the form of data sharing-related overhead has dropped significantly over the years, thanks to faster coupling facility links, faster CF engines, and enhancements in DB2, z/OS, and Coupling Facility Control Code - some organizations drive large data sharing workloads with extensive inter-DB2 read/write concurrent data access, with overhead levels in the high single digits of percent.

So, if you've been thinking that DB2 data sharing is only for companies with gargantuan compute capacity needs and very deep pockets, think again. Data sharing could very well be just the ticket for your organization.