Part 1  |  Part 2  |  Part 3

Part 2, from a conversation between DBAzine and several of the leading experts working with DB2 today. This group of DB2 professionals has a wide range of different experiences with DB2 and unique perspectives on the ever-changing DB2 technical environment. Our conversation was directed by several questions — questions about DB2's past, present, and future (view Part 1).

This distinguished group was made up of the following experts:

Roger Miller — Roger is the lead DB2 for z/OS strategist, but he started in DB2 as a programmer. He can be reached at millerrl@us.ibm.com.

Betty Gray — Betty is an independent DB2 educator and consultant. She can be reached at wolf_gray@msn.com.

Alex Robb — Alex is the Director of DB2 Curriculum for Themis Inc. He can be reached at k_arobb@mindspring.com.

Linda Ball — Linda was the Corporate Architect for DB2 for OS/390 and z/OS Product Development at BMC Software.

Randy Ebersole — Randy is a Senior IT Specialist for DB2 UDB for z/OS at IBM. He can be reached at ebersole@us.ibm.com.

Craig S. Mullins — Craig is Director of Technology Planning and a data management strategist with BMC Software. He can be reached at www.CraigSMullins.com.

DBAzine: How viable is DB2 as an Internet database platform? Just how easy (or difficult) is it to use technologies like DB2 connect, JDBC, and SQLJ to create Web-based applications? Do you know of any organization that has done it successfully and what steps did they take to succeed?

Roger Miller: Of course I believe DB2 is an extremely viable Internet database platform. The majority of the customers I deal with serve up some piece of their application to the Web. At a minimum, they are downloading the data to serve it via the Web.

Alex Robb: I believe it's the best server on the market today. DB2 Connect is very easy to use. With SQLJ you get static SQL in Java, and that can enhance performance above JDBC Java access. Personally, I really like pre-compile.

Randy Ebersole: DB2 is "the" Internet database platform. The first reason is ease of use. What I mean is, there are many options available to developers. An example of this would be the many enhancements surrounding the use of Java. Obviously, the data is in DB2. So taking advantage of Java and also technology such as DB2 stored procedures, the development groups have what they need to provide the applications. With all the expertise they have with DB2, my customers have seen great benefit from DB2, instead of switching to different development environments.

From the database side of things, the customers I work with are all using DB2 as their Internet database platform for the same reasons-it is fast, reliable, scalable, and has high-availability. Did that sound too much like a marketing brochure? In making the decision on which platform to use, most customers ask this question, "Where is my data?" When the answer is in DB2 databases, they overwhelmingly stay with DB2 on z/OS.

Betty Gray: I have not had the same response from my DB2 clients. Not many shops are using it as an Internet database platform. The reason — mainframe apps people are not the same people who do Web apps.

Linda Ball: Many of the customers I talk to are using the data in DB2 for z/OS on the Web. IBM has made great strides by allowing ASCII and UNICODE data and supporting Java. Some companies I talk to are actually moving data from Oracle or UNIX or Windows DB2 to the mainframe and standardizing on the platform. I think there is a huge demand for more ease-of-use and ease-of-development with the connections, however. In spite of the bumps, though, customers are doing it and doing it in production. It has, in fact, created a tremendous pressure for 24x7x365 operations. Someone is accessing the data all the time.

Craig S. Mullins: The Web is the current driving force for database implementation across all DBMS platforms… DB2 included. And IBM has done a stellar job of enabling DB2 for the Web.

DBAzine: It seems that big ERP and CRM application vendors get priority in terms of the new features and functions implemented in new DB2 versions. Do you think this will be problematic to the majority of DB2 users who do not use these purchased applications? Why or why not?

Roger Miller: Most of the ERP/CRM vendor needs are the same as other customers — only more of it. Ebusiness applications are very hard to distinguish from ERP or CRM. The ERP/CRM vendors helped grow the DB2 customer base. The vendors typically run dynamic SQL and they need to run very fast, with a wide spectrum of uses. Personally, I think it's nice to have the application vendor companies go out in front of what our customers are doing. For example, the vendors needed 5,000 concurrent open data sets — and they were the only ones. Now, this is common and it's no problem for everyone else. Meanwhile one ERP vendor is going to need about 60,000 data sets for each instance.

Alex Robb: I disagree. I think it's a problem. For example, a "certain company's" word processing package has 2 million features, none of which I use as an end-user. They were added to make some larger vendor companies happy. Now they just muck up the word processing package with so many options, that I can't find what I need to use regularly. There's also the issue of how much harder it makes things when you try to upgrade to a new release. IBM must come up with some way to allow its customers to pick and choose features and not install the whole upgrade package every time.

Randy Ebersole: Actually, I think all DB2 users take advantage of the additional feature/functions that are developed. IBM's approach is to help the DB2 community utilize and exploit the technology. If there had to be a Feature/Function added for a vendor, it could be used by other customers as well.

Betty Gray: The vendors do get priority. I find myself cringing every time I go into a Peoplesoft shop. The shop has tons of Peoplesoft enhancements from IBM. It can be a mess to sort through.

Even though all the enhancements are messy for the client to sort through, I don't think it is problematic that IBM is giving the vendors priority. Typically, these are huge customers that IBM should spend time on. But, when they help these vendors with their customers, time is being taken away from some place.

That said, the more mature DB2 becomes, enhancements are becoming more and more specific anyway. Many shops I go to have not gone to V7 yet. When asked why, they often say they 'would gain little from the V7 enhancements.

Craig S. Mullins: Well, I can understand the point of view that other users can benefit from the features that IBM is implementing for the big ERP vendors. And in most cases that is probably true. But there are a few examples that do not conform. For example, prior to DB2 V6, the maximum length of a string literal that could be inserted using SQL INSERTs was limited to 254 characters. But, because a big ERP vendor sometimes needed to insert 255 characters IBM changed this limit from 254 to 255 in V6. Now, really, did anyone else breathe a sigh of relief and say "Thank God I have that extra character"? I doubt it! Did this hurt anyone? Probably not, other than the development time it took to support that one extra byte which could have been used to support something that more members of the DB2 community would find useful. Even so, I don't fault IBM for sometimes favoring the big application vendors. When those vendors support DB2 it helps to validate DB2 in the marketplace and makes DB2 a stronger platform for all of us.

DBAzine: DB2 is a phenomenal DBMS with world class support and leading edge functionality, but what single feature that DB2 does not yet support would have the biggest impact? On whom would this impact be felt (developers, DBAs, ISVs, consultants, etc.) and why?

Roger Miller: Online Schema Evolution — Performance, Scalability, and Availability. What customers would like is the ability to alter, so that there is no need to drop and recreate. There are hundreds of attributes that we'd like to change, such as the number of partitions or the data type of a column. We have been working on this change for a long time, and the work effort is large enough that it will be staged over three or four versions.

Alex Robb: Personally, I think it has to be what I call the "Maximum Lock Flaw." Once someone has a lock, they can keep it forever. In my ideal shop, I'd like to be able to say, "If someone has a lock for over 30 seconds, I can shut him down."

Betty Gray: I think someday that it would be great to be able to do a join across servers. Who would benefit-anyone who wanted it. This feature would allow true Web-enablement. You would be able to see all your data, anywhere it's located in the world.

Linda Ball: IBM is talking a lot about self-healing and self-managing code. Having a DBMS that never needed to have customers decide when to run utilities, that automatically knew where waste was occurring (updating indexes that are never used), that collected and reacted to statistics without intervention would change everything for DBAs and would greatly impact what the ISVs bring to the table. The steps to include these functions in the base DBMS will take many, many years to implement. In the interim, DBAs will have more alternatives for managing data and nimble ISVs will be providing a lot of the intelligence outside the database engine. I would point to the Real Time Statistics as an example of this. This rudimentary capability to capture statistics inside the engine is to be applauded. However, providing some sample stored procedures to react to the statistics is not really lights out, hands free management. It is just a new way to get the data that drives intelligence. So DBAs shouldn't expect to be able to let the DBMS manage itself for many, many years.

However, this type of change in the base DBMS will drive many products, from IBM and ISVs, to 'raise the access point' for DBAs. At BMC Software we are focusing on providing the DBA with advice (intelligence from data) and when the base DBMS supports more data gathering that speeds up that process.

Craig S. Mullins: I am going to stray a bit from the answers given by my colleagues and promote the concept of making DB2 more relational. With that in mind I would like to see DB2 support domains. By adding domains to the DBMS we can promote stronger data integrity. One of the biggest problems in the world of data management is assuring clean data in the database. Supporting domains would help.

DBAzine: Automated management is a hot topic these days. Look into the future 5 years and tell me how you envision the DB2 environment. What is automated? Is DB2 self-healing? How?

Roger Miller: We have been working to automate for many years. One of the early attempts at automation was the DB2 optimizer, and we're still not done yet. Many of the problems for automation are difficult to manage. We have added many resources to improve this area, and are calling it autonomic computing. To keep up in this area, I suggest that you watch the Web at http://www.ibm.com/autonomic or http://www.ibm.com/autonomic/index.shtml.

Alex Robb: I really have no true comment. If I was taking a wild guess, I think recovery and reorganization will be automated, but who really knows.

Randy Ebersole: There is an IBM-wide initiative (and a IT community challenge) called autonomic computing. Within the DB2 world it is called SMART=Self-Managing and Resource Tuning. Many DB2 features-past, present and future-will be able to be categorized as self-healing, and also as self-configuring, self-optimizing or self-protecting. Automation has been a hot topic at IBM for a long time and will continue to be a high priority.

Betty Gray: I have no idea. My only guess is that it will involve data sharing in some way.

Linda Ball: In five years, a lot of DBAs (and developers) will use tools that do more than just respond to commands (REORG this, CREATE that). However, DB2 will not be completely self-healing. The version after V8 might do some things automatically, letting us forget about what was once a painful intervention. For example, several versions down-the-line DB2 could have a feature that optionally collected information when rows were updated and had to be overflowed and then automatically adjusted the indexes and the pointer/overflow records using 'maintenance transactions' triggered on some schedule. People might have one less reason to have to actually REORG data. But I'm betting there will still be DBAs helping figure out when to REORG data. They may mostly use triggering or advisory intelligence (from IBM or ISVs) but they will spend time on it. [Disclaimer: I have no idea whether IBM is considering such a feature as mentioned. I was just using one of the 'reasons for REORG' as an example of possible self-healing behavior!]

Interviews conducted by Elizabeth A. Mullins.

Part 3: the panel of experts discusses enforce logging of database changes, the advantages and limitations of advances in storage hardware, and more.