Scenarios for using DB2
What do the following situations have in common?
An international bank that provides services to its customers 24 hours a day
A multi-campus university system that educates thousands of students and offers hundreds of courses
An electric company that provides electricity to a large geographic region
The common characteristic in each situation is that DB2 is a key ingredient in the data processing environment of the organization.
If you are new to DB2, you might wonder how these and other organizations use the product. You might wonder what types of organizations use DB2. Maybe you wonder if the organizations that use DB2 have all, or only a portion, of their data on the enterprise server. (Sometimes people refer to the enterprise server as the “mainframe.”)
This section helps you imagine some of the possibilities by describing a few scenarios in which organizations depend on DB2 to accomplish their business objectives. 
Providing availability and scalability to large businesses
You might be thinking that the terms enterprise server and mainframe imply that very large businesses use a product like DB2 UDB for z/OS.
This section answers the question, “Why do large businesses choose DB2 UDB for z/OS?” The answer is, “Because these companies need a robust database server that ensures superior availability and scalability.”
Superior availability and scalability in a Parallel Sysplex environment are the key features that distinguish DB2 UDB for z/OS from other database servers. Because of these qualities, DB2 UDB for z/OS is widely deployed in the following types of large industries:
Major credit card companies
Banks
Insurance companies
Brokerage companies
Credit reporting companies
These are companies that process very high volumes of transactions that require millions of concurrent updates every day.
Consider a couple of examples.
The volume of trading that goes on at the major stock exchanges can reach over one billion shares in a single day.
A brokerage company might have a network of thousands of financial advisors and hundreds of thousands of customers who need online access to highly sensitive financial information daily.
You can easily understand why these large-scale businesses need the database system that processes these transactions to be continuously available, scalable, and secure. These enterprise systems must be available to customers who are searching for and relying on their services 24 hours a day.
Systems must provide continuous availability.
If you are waiting for a financial transaction to process and the application that runs that transaction suddenly fails, you might lose the opportunity to make a stock trade at a critical time. The key objective of high availability is to ensure that a system has no single point of failure.
Systems must be scalable.
As businesses grow, their data processing needs also grow. Business ventures, such as mergers, acquisitions, and new services, or new government regulations, can accelerate how quickly the data processing needs of the business grow. As rapid growth occurs, companies need a way to scale their business successfully.
Companies need a large database system that is designed to easily absorb ongoing additions of new types of information and application processes without sacrificing performance or availability. That database system should never impose a constraint on growth. As businesses add more computing capacity, the database system must expand accordingly to ensure that businesses gain the full advantage of the added capacity.
The following scenarios describe how a large international bank benefits from these DB2 UDB for z/OS strengths to provide a high quality of service to its customers.
Scenario 1: Bank mergers occur often. As two banks combine operations, how does the newly formed bank merge unrelated applications?
DB2 UDB for z/OS data sharing in a Parallel Sysplex environment provides the solution that the new bank needs to merge the two banking systems.
Parallel Sysplex clustering technology in DB2 is the answer to availability and scalability. A Parallel Sysplex is a cluster, or complex, of z/OS systems that work together to handle multiple transactions and applications. This technology implements a data sharing design.
The DB2 data sharing design enables businesses to add new DB2 subsystems into a data sharing group, or cluster, as the need arises and without disruption. As applications run on more than one DB2 subsystem, they can concurrently read from and write to the same set of shared data.
The Parallel Sysplex can grow incrementally. Parallel Sysplex architecture integrates up to 32 systems in one cluster. In a shared-disk cluster, each system is a member of the cluster and has access to shared data.
An integral component of a Parallel Sysplex is the coupling facility, a mechanism that coordinates transactions between the different members within a cluster.
When Parallel Sysplex technology is used, the applications from each bank can easily be integrated into a data sharing group and can access shared data.
Scenario 2: The bank runs batch every night and the online workload is running close to 24 hours a day. How can the bank run varied workloads, keep them balanced, and avoid problems at peak times?
DB2 works closely with the z/OS Workload Manager (WLM) component. WLM provides a good way to run mixed workloads concurrently, and data sharing gives the bank a lot of flexibility in how to run the workloads.
Parallel Sysplex technology is designed to handle varied and unpredictable workloads efficiently. The Workload Manager ensures that the bank's workloads are optimally balanced across the systems in the Sysplex.
For example, when the bank adds a new subsystem or the workload becomes unbalanced, data does not need to be redistributed. The new subsystem has the same direct access to the data as all existing subsystems in the data sharing group.
Data sharing works with WLM to give the bank the flexibility it needs to handle peak loads easily. WLM provides the ability to start up servers and subsystems on demand, based on predefined service goals. For example, the bank can start data sharing members to handle peak loads at quarter-end, and stop them when the quarter-end peak finishes.
Scenario 3: The bank creates a Web site to provide online banking to its customers 24 hours a day. Now the DBMS can never be out of service for maintenance activities. How can the bank apply maintenance to its DBMS if it needs to be operational 24 hours a day?
Data sharing and Parallel Sysplex technology give the bank a way to apply software maintenance (a planned outage) while always keeping a subset of its DB2 subsystems up and running.
The Parallel Sysplex environment provides multiple paths to data and builds redundancy into the coupling facility to avoid single points of failure. With Parallel Sysplex technology, the bank can perform maintenance on one member at a time while their systems continue running and remain up-to-date on service. The technology also allows the bank to migrate to a new software release by applying the new release to one member at a time. With this design, the bank avoids outages.
In the event of an application or a system failure on one system (an unplanned outage), the Workload Manager ensures that other systems within the Sysplex will take over the full workload. Once again, the bank avoids outages.
For more information about DB2 data sharing and the Parallel Sysplex environment, see “The Parallel Sysplex environment” on page 77 and “Chapter 12. Data sharing with your DB2 data.”
Providing information to decision makers
Consider a multi-campus university system. A group of educational experts manages the system from day to day. These people make decisions that affect all the university campuses. The decision makers use a data warehouse so that they can “mine” data from the system's many databases and make the best organizational decisions.
Perhaps you've heard the terms data warehousing and data mining. You can think of a data warehouse as a system that provides critical business information to an organization. Data mining is the act of collecting critical business information from that data warehouse, correlating it, and uncovering associations, patterns, and trends. The data warehouse system cleanses the data for accuracy and currency. The data warehouse system also presents the data to the decision makers so that they can interpret and use it effectively and efficiently.
Data warehousing and data mining are related terms that are encompassed by the more global term, business intelligence.
Most organizations use a variety of hardware and software products to store a large amount of data. However, many companies' key decision makers do not have timely access to the information that they need to make critical business decisions. If they had the information, they could make more intelligent decisions for their businesses—thus, the term business intelligence.
The university's data warehouse system, which relies on DB2, transforms the vast amount of data from operational to informational. An example of operational data in a university is the identities of people who enroll in various classes. Clearly, the university needs this information to operate. This operational data becomes informational when, for example, decision makers discover that most students who enroll in Advanced Calculus also enroll in Music Appreciation. The university doesn't require this information to operate, but decision makers can run a more effective institution if they have informational data. As a result of having access to this informational data, university personnel can make better decisions. Individuals who plan class schedules can ensure that these classes do not meet at the same time, thereby enabling students to enroll in both classes.
The university also uses the power of the Internet. Each campus has a Web site, which supplies relevant information to university decision makers, students, parents, and members of the communities that surround each campus.
Using DB2 UDB for z/OS as its enterprise server, along with the DB2 Warehouse Manager, the university can act as follows:
Evaluate the effectiveness of curriculum, expenditures, professors, and professional development
Identify emerging trends early enough for effective action
Complete grant applications more quickly and effectively
Compile a complete summary report on any individual student
Enable authorized end users to use the Web to perform any of these actions, plus others
For more information about DB2 Warehouse Manager, see “The IBM DB2 information management strategy” on page 10 and “DB2 Warehouse Manager”on page 23.
Distributing data and providing Web access
An electric company provides electricity to a large geographic region. Working out of a single office, the company's customer service representatives answer customer calls and submit requests for service. The electric company has hundreds of field representatives who provide service at customer locations. The field representatives work out of many local offices, and they need access to customer service requests that the central office receives.
The customer service representatives document customer requests on their workstations, which have DB2 ConnectTM Personal Edition. This information is uploaded to DB2 UDB for z/OS. The field representatives can then use Java applications to access the customer request information in DB2 from their local offices.
Figure 1.1 illustrates the electric company's distributed environment. This scenario relies on the distributed data facility (DDF), which is part of DB2 UDB for z/OS. DB2 applications can use DDF to access data at other DB2 sites and at remote relational database systems that support Distributed Relational Database Architecture (DRDA). DRDA is a standard for distributed connectivity. An organization called The Open Group developed the standard, with active participation from many companies in the industry, one of which was IBM. All IBM DB2 UDB servers support this DRDA standard.
DDF also enables applications that run in a remote environment that supports DRDA. These applications can use DDF to access data in DB2 UDB servers. Examples of application requesters include IBM DB2 Connect and other DRDA-compliant client products. “Distributed data facility” on page 76 has more information about DDF.