FOREWORD

DB2 Universal Database for z/OS has changed a lot over the past few years, with significant growth in the applications and in the size of the data. Some of the growth reflects the increasing volume and complexity of applications. More of the growth has come from new applications, the Web, and vendors. The use of DB2 has changed as well. The initial query, or decision-support, applications began relatively small and simple, but have grown from megabytes to gigabytes to terabytes and continue to grow in size and complexity. There is not much terror in a terabyte any more. Business-intelligence applications have added many options for data mining, online analytical processing, and complex analytics.

We have partnered with many application vendors that have grown rapidly, especially SAP, PeopleSoft, and Siebel. These applications are extremely demanding for a database management system, and they also require a close partnership to provide the best in scalability and availability. We work across the middleware stack of IBM software brands from DB2, Tivoli, WebSphere, Rational, and Lotus. In the past few years, major acquisitions of Informix, Rational, and Candle have enriched our options. We also work with a much larger group of vendors for business intelligence, application development, and database management tools.

Traditional online transaction processing has changed dramatically. Batch work has increased in volume and in the need to be run concurrently. The batch and utility windows have been closing, so that batch has become a sequence of transactions in many situations, and the utilities must run online with other work. The applications have increased in complexity.

In some ways, e-business is very simple. Customers want the best of everything, and they want it now. If yours is not the best or if your site is slow or down, the competition is only a mouse click away. The demands on e-business applications are similar. They must be fast, flexible, scalable, and easy to use. Data management for Web transactions has evolved from simple transactions, accessing a few files in one database management system, to much more complicated, federated access. One Web click can drive a dozen transactions across several machines in different time zones to improve the end user experience.

The Web has also changed the rules for scalability and for availability. As long as employees were providing access, the pattern of use was relatively predictable. Twelve or 18 hours a day were adequate, and the usage peak might be double the average load. The peak load can be a factor of ten and is much less predictable, with billions of potential users in every time zone. Automated search engines, Web devices, and Web appliances can provide trillions of requesters who want your information. Data is retained longer and has more uses. Disk storage continues to grow at an astonishing compound rate of 90 percent per year. At that rate, the current 1-terabyte database will become 24 terabytes in five years.

Improving the business process is important for being competitive. We need to provide fast response to the Web users, but we also need to use the data to find ways to improve our business. Collecting, organizing, and understanding information about how to improve are crucial for a competitive business. I view the process as a cycle, with the e-transaction processing providing information to the business intelligence, and the business intelligence providing process improvements back to the e-transaction processing. Thus, the improvements continue in a cycle. SAP, PeopleSoft, and Siebel have all added business intelligence to their applications to complete the cycle.

DB2 began with a design to handle online transaction processing, batch, and query work. DB2 has grown with the demands for large volumes, higher performance, improved availability, and better concurrency. Over the past decades, that design has been expanded to handle more diverse work even as the volumes and work loads grew. We have added many improvements for optimization and parallel processing. We have found ways to make dynamic SQL more static and static SQL more dynamic. We have new options to index the information. So that's all we need to do in DB2: provide the best of everything; deliver fast; make the information very usable; make the application fun to use; be able to scale, provide concurrent access, and respond immediately; be available 24 hours a day, 365.25 days a year, 100 percent of the time, without increasing costs; and use the information from the click stream to improve the business.

We are not there yet, but DB2 UDB for z/OS version 8 provides a giant step in the right direction. For continuous availability, the options have improved, with more online utilities, improved techniques for backup and recovery, and online schema evolution. The range of options for scalability and performance has improved, allowing much larger volumes of data and logs, using more memory more effectively, and reducing times dramatically with the optimization improvements, materialized query tables, and multirow operations. Programmer productivity has improved with many additions to SQL. It is much easier to port an application from UNIX or Windows with all the improvements. Ease of safe use has improved with a range of security enhancements.

Building a high-performance, high-availability application and database requires a lot of skill, teamwork, knowledge, and experience. Although they have shown that they can build large, high-volume applications, our customers have also learned some hard lessons. It's much easier to learn in a class or from a book than when angry customers and your boss are waiting. Using design and tuning lessons for another product or another version can be part of the problem, not the solution. Susan Lawson is experienced with large, complex DB2 data sharing applications that need both high performance and high availability. She has worked with very large tables and demanding applications. As you read this book, you will see that her experience and judgment show.

Most of the complex and interesting questions do not have a simple answer. The simple answer to the complex problem is generally wrong. Experts know the right answer: It depends.

Perhaps the management would like a simple, certain answer. Sometimes, the pressure is so great that we oversimplify and give a simple answer, even though it's not correct. But although "It depends" is completely correct, that response is also completely useless. We must go on to explain the problem and the issues: State what the response depends on and the range of possibilities. You will find that Susan understands and explains what it depends on.

 Roger Miller
DB2 UDB for z/OS Strategist