"What is DB2 data sharing?"

When data sharing was delivered with DB2 for z/OS (OS/390 at the time) Version 4, more than ten years ago, I was part of IBM's DB2 National Technical Support team at the Dallas Systems Center. I was tasked at the time with learning all that I could about data sharing, so that I could help IBM customers (and IBMers) understand, implement, and successfully use the technology. That was a really fun time in my IT career because people had lots of questions about DB2 data sharing, and I very much enjoyed answering those questions (sometimes in-person at locations in Asia, Australia, Europe, and throughout the USA).

Over time, as DB2 data sharing knowledge became more widely diffused, and as people such as my good friend Bryce Krohn shouldered more of the knowledge-transfer load, there were fewer questions for me to answer -- thus my delight in fielding a query a couple of weeks ago. The questioner was the general manager of a company that provides IT training services, and he and I were talking about a request from one of his clients for data sharing education. "So," asked Mr. General Manager, "what is DB2 data sharing?"

[Before I tell you what I told the GM, I'll provide a brief technical response to the question. Data sharing is a shared-disk scale-out solution for DB2 running on an IBM mainframe cluster configuration called a parallel sysplex. In a data sharing group, multiple DB2 subsystems co-own and have concurrent read/write access to a database (there is also a single catalog -- DB2's metadata repository -- that is shared by the DB2 subsystems in the group). Specialized devices called coupling facilities -- existing as standalone boxes and/or as logical partitions within mainframe servers -- provide the shared memory resources in which group buffepools (for data coherency protection) and the global lock structure reside (the latter provides concurrency control and data integrity preservation).]

I thought for a second or two, and told the GM: "DB2 data sharing is the most highly available, highly scalable data-serving platform on the market."

Now, it's been more than eight years since I last worked for IBM, so that wasn't a sales line. It is, I think, a factually correct answer. Consider those two qualities, availability and scalability. The thing about data sharing is, you start with the highest-availability standalone data-serving platform -- an IBM mainframe running the z/OS operating system -- and you make it even MORE highly available by clustering it in a shared-disk configuration. Does anyone dispute my contention that DB2 on a mainframe is the alpha dog when it comes to uptime in a non-clustered environment? Seems to me that fans of competing platforms speak of "mainframe-like" availability. The mainframe is still the gold standard with respect to rock-solid reliability -- the platform against which others are measure d. It's legendary for its ability to stay up under the most extreme loads, able to cruise along for extended periods of time at utilization levels well over 90%, with mixed and widely-varying workloads, keeping a huge number of balls in the air and not dropping a single one. You put several of those babies in a shared-disk cluster, and now you have a system that lets you apply maintenance (hardware or software) without a maintenance window. It also limits the scope of component failures to a remarkable extent, and recovers so quickly from same that a DB2 subsystem or a z/OS image or a mainframe server can crash (and keep in mind that such events are quite rare) and the situation can be resolved (typically in an automated fashion -- the system restores itself in most cases) with users never being aware that a problem occurred (and I'm talking about the real world -- I have first-hand experience in this area).

How about scalability? You might think that the overhead of DB2 data sharing would reach unacceptable levels once you get to four or five servers in a parallel sysplex, but you'd be wrong there. The CPU cost of data sharing is often around 10% or so in a 2-way data sharing group (meaning that an SQL statement running in a DB2 data sharing group might consume 10% more CPU time than the same statement running in a standalone DB2 environment). Add a third DB2 to the group, and you might add another half percentage point of overhead. Add a fourth member, and again overhead is likely to increase by less than one percent. So it goes, with a fifth DB2 member, a sixth, a seventh, an eighth, a ninth -- the increase in overall system capacity is almost linear with respect to the addition of an extra server's cycles. Again, I'm talking about the real world, in which organizations treat a data sharing group like a single-image system and let the parallel sysplex itself distribute work across servers in a load-balancing way, with no attempt made to establish "affinities" between certain servers and certain parts of the shared database in order to reduce overhead. Intense inter-DB2 read/write interest in database objects (tables and indexes) is the norm in data sharing systems I've worked on, and that's so because DB2 (and z/OS and Coupling Facility Control Code) handles that kind of environment very well. DB2 and parallel sysplex architecture allow for the coupling of up to 32 mainframes in one data-sharing cluster, and no one has come close to needing that amount of compute power to handle a data-serving workload (keep in mind that the capacity of individual mainframes continues to grow at an impressive clip).

Hey, there are plenty of good data-serving platforms out there, but when it comes to the ultimate in availability and scalability, the king of the hill is a DB2 for z/OS data sharing group on a parallel sysplex.

Any questions?

"Know the Data"

I received the other day a very interesting e-mail from Vijay Sitaram, a friend of mine who is a DB2 DBA (or not -- more on this later) at an organization that operates (no pun intended) in the health-care industry. Vijay's note contained some illuminating insights regarding the role of database professionals within a modern, strategically focused enterprise, and via this post I want to share some of these insights with you (my thanks to Vijay for permission to do so).

Recently, Vijay had found that traditional DB2 DBA work was becoming less satisfying for him, for reasons well-known to many DB2 people:

1. DB2 is becoming, more and more, a self-managing DBMS. This is a cross-platform truism. DB2 for z/OS people have for years benefited from advanced file-management features available on that platform (DB2-managed objects are the norm in mainframe environments), and DB2-managed storage capabilities have advanced in a major way via the "Viper" releases of DB2 (Versions 9.1 and 9.5) for Linux, UNIX, and Windows (aka LUW) servers. Similarly, self-tuning memory management -- a technology found now in DB2 9.1 and 9.5 for LUW, providing automated (and dynamic) sizing for things such as the database monitor heap, the agent pool, the package cache, the sort heap, and buffer pools -- is starting to show up in DB2 for z/OS (auto-adjustment of buffer pool sizes is an option available in DB2 9 for z/OS, and I expect to see more developments in this area in future releases).
2. While no vendor is giving server hardware away, the continuing decline in the price of compute power (and server memory) has more and more organizations asking DB2 DBAs to spend proportionally more time on work that is NOT directly related to boosting the CPU- and memory-efficiency of a DB2 workload. Sure, performance tuning is still important, but the value of saving X% of a server's CPU capacity, or reducing DB2's virtual storage footprint by Y megabytes, is not what it was a few years ago.
3. A lot of the DBA work related to DB2 system performance is front-loaded with respect to the life of a system. In other words, once a DB2 system has been effectively tuned and stabilized, over time it tends to require less DBA effort to keep it running well.

So, Vijay was thinking about how he could deliver greater value to his organization as a database professional. His manager provided the opportunity to do just that with this simple directive (paraphrasing a bit here, but this is the gist of what the manager said): "Know the data." What Vijay's manager wanted him to do was deepen his understanding of the data in the DB2 database that he administered (in this case, we're talking about medical billing data). The manager was NOT asking Vijay to know things like the number of rows in a table, or the length of a row in a table, or the cardinality of a column value. That's data about data. The manager was asking Vijay to know the data itself, and to appreciate "the value [that] is in the data." Vijay had already done a lot for his company in looking after an important database. Now he was being told that he could do more for the company if he could answer this question: what is the nature of the data in the database, and why and in what ways is it important to the organization?

Not being one to drop a ball, Vijay took this one and ran with it. He immersed himself in learning about the data elements in the database and the relationships between these elements. He built up his knowledge of how medical billing works (no easy task that -- I've worked with medical billing data, and it is very complex stuff), getting a lot of help from the senior programmer who developed the company's medical billing application. Vijay found that his deeper understanding of the data had some immediate payoffs, in that he was able to improve the performance of the ETL (extract/transform/load) processes used to update the database. He also found that his data knowledge made it much easier for him to successfully address database design issues.

Now, Vijay is helping his company with the implementation and deployment of data integration and data cleansing tools, and he's about to get into advanced data analysis software in a big way, focusing on cubing capabilities that will enable data users to drill into data structures to uncover actionable intelligence. In short, knowing how his organization values the data he administers, Vijay is working to grow that value by making it easier for users to access and analyze the data to improve decision making. In doing that, Vijay is increasing his value to his company. A side benefit: he's having more fun on the job.

Is Vijay still a DBA? He's not so sure that the "DBA" title reflects the kind of work he's doing now (and it's not as though he no longer does traditional DBA work -- it's more like "DBA-plus" these days). Vijay has asked that his job title be changed to Architect. If that decision were mine to make, I'd give it a thumbs-up. Drive on, Vijay.

When Things Old Are New Again

Due to my having been very busy with a client engagement, I've let more time than usual go by since the last post to my blog. The aforementioned client job provided me with an interesting experience in the form of a Q&A session between one of the organization's DB2 DBAs and a group of database-focused developers. Executives at this company had decided not long ago that DB2 would be the data-serving platform of choice going forward, and the developers in the room had long worked with a different DBMS used by the firm. Among the questions asked were some aimed at understanding the reasons for the company's strategic shift with regard to database technology. Why DB2 versus the other DBMS that they knew so well? The DB2 DBA did a great job in responding to these questions, and I found his answers to be quite interesting.

Often, when those of us who've worked with DB2 for a long time think about the product and what makes it particularly attractive in today's market, we call to mind recently announced features that score well in terms of the "cool" factor. How would the DBA reply to the "Why DB2?" question? Would he talk about the pureXML technology that makes DB2 the best-of-breed product for managing both XML documents and traditional relational data? Would he point to the Deep Compression feature that can slash disk space requirements for a database at a surprisingly low CPU cost? Maybe multi-dimensional clustering, a capability that can deliver breakthrough performance results for data that aligns naturally with several different dimensions (e.g., geography, time period, and product category)? Or online, in-place REORG, which gets data order back right with no need for "shadow" tables? No, no, no, and nope (the last of these a nod to my Texas roots).

With all that way cool DB2 stuff available to jazz up his response, the DBA chose instead to emphasize a few of DB2's bedrock qualities that some of us take for granted: a fantastic SQL statement optimizer, tremendous vertical scalability, and manageability. In speaking of these key advantages, the DBA made a compelling case for DB2. Hereinafter, I'll summarize his message to his application development colleagues.

First, the optimizer. Pity the IBM teams in Toronto and San Jose who develop this key component of DB2. They are probably accustomed to hearing from DB2 users who are upset over one of those rare occasions when the optimizer actually chooses a demonstrably suboptimal data access path (and quite often THAT ends up being due to inaccurate or incomplete database statistics in the DB2 catalog). People don't talk about the DB2 optimizer when it works as it's supposed to, so they end up hardly talking about it at all because it just about always does the right thing. To the question-answering DBA, however, DB2's world-class optimizer meant that he and his colleagues could spend lots more time with matters such as database design and deployment, and lots less time trying to tweak queries to get good performance. That the SQL optimizer would be touted as one of DB2's greatest strengths should come as no surprise to those who know the history product. Dr. Pat Selinger and her team at IBM's Almaden Research Center pioneered the cost-based optimization of SQL statements back in the late 1970s, when few people in the larger IT community had even heard the term "relational database." With a lead like that, it shouldn't be too hard to remain the front-runner, but IBM of course never relaxes when it comes to making the DB2 optimizer better and better. The DBA in the Q&A session actually did spend some time talking about one of the more recent optimizer-related features to have come out of DB2 development: materialized query tables, aka MQTs. MQTs can be used to hold the precomputed results of complex queries, and the DB2 optimizer can choose to use one - sometimes with order-of-magnitude query runtime improvement - without a query-submitting end user even having to know of the MQT's existence. As disc jockeys used to say in days of yore, the hits just keep on coming.

On now to vertical scalability. DB2 certainly has - in the form of DB2 for z/OS data sharing and the data partitioning feature of DB2 for Linux, UNIX, and Windows (LUW) - multi-server clustering solutions that offer unmatched horizontal scalability, and that's great, but often what an organization wants for a particular database deployment is a solution that can drive higher and higher levels of throughput as the resources of a single server are boosted through the addition of CPUs and/or server memory. Does this sound simple to you, delivering greater throughput as a server's compute power is increased? It's not. In particular, as microprocessor speed and capacity (multi-core, anyone?) continue to break through already amazing levels, the software engineering challenges associated with preventing data processing bottlenecks from hobbling system performance become more and more daunting. Overcoming these challenges has long been a major focus of the DB2 development organization, and it shows. Data server capacity planning becomes much less of a guessing game when you can count on a DBMS to scale with the servers on which it runs.

Finally, manageability. That may not be a scintillating topic of conversation, but it's hugely important with respect to another kind of DB2 scalability that I call human scalability. This term refers to the ability of an IT organization to expand the deployment of a data-serving platform WITHOUT having to boost the ranks of technology support personnel in a proportional manner. To the organization for which my highlighted DBA works, this is huge. They have a few hundred DB2 databases deployed now, with more to come. Some of these databases contain multiple terabytes of data, and lots of others are sized in the hundreds of gigabytes. A solution that can be set up, maintained, and managed in a people-efficient way is a must under these circumstances, and DB2 flat-out delivers the goods. It's always been very strong from a monitoring perspective, delivering rich performance and availability data via CPU-efficient traces. It continues to allow for more and more database changes and maintenance operations to be accomplished online, with no need for a "window" of inaccessibility from the user perspective. And it is becoming, more and more, a self-managing solution, with the self-tuning memory management (STMM) feature of the DB2 "Viper" release being a particularly noteworthy innovation (STMM was made possible by the extension of the threaded model of internal operation - already there for DB2 on Windows servers - to the UNIX and Linux platforms).

The late, great, Johnny Cash once sang of an encounter from which he "come away [sic] with a different point of view." Thus I came away from listening to a DBA - someone focused on helping his employing organization accomplish necessary work efficiently and effectively - explain to a group of developers why the organization had hitched its data-serving wagon to a horse called DB2. Sometimes the things that make DB2 a winner in the marketplace are the strengths that have been their all along (and which get better all the time). So, keep up with all the new and cool stuff, but don't forget about the solid rock on which that cool stuff stands.