Scalable growth

As you move more data processing into a DB2® environment, your processing needs can exceed the capacity of a single system. Data sharing might relieve that constraint.

Start of changeDB2 for z/OS® is optimized to use your existing hardware more efficiently and manage a larger workload. DB2 now has more 64 bit storage, and supports more concurrent threads than previous versions. These improvements greatly increase the capabilities of a single system, which reduces the cost of new hardware, software, and maintenance. However, there are several ways to scale the capabilities of your system to meet your business needs.End of change

Without data sharing

Without DB2 data sharing, you have the following options:

  • Copy the data, or split the data into separate DB2 subsystems.

    This approach requires that you maintain separate copies of the data. No communication takes place among DB2 subsystems, and the DB2 catalog is not shared.

  • Install another DB2 subsystem, and rewrite applications to access the original data as distributed data.

    This approach might relieve the workload on the original DB2 subsystem, but it requires changes to your applications and has performance overhead of its own. Nevertheless, for DB2 subsystems that are separated by great distance or for a DB2 subsystem that needs to share data with a system that outside the data sharing group, the distributed data facility is still your only option.

  • Install a larger processor and move data and applications to that machine.

    This option can be expensive. In addition, this approach requires your system to come down while you move to the new, larger machine.

With data sharing

With DB2 data sharing, you can take advantage of the following benefits:

Incremental growth
The Parallel Sysplex® cluster can grow incrementally. You can add a new DB2 subsystem onto another central processor complex and access the same data through the new DB2 subsystem. You no longer need to manage copies or distribute data. All DB2 subsystems in the data sharing group have concurrent read-write access, and all DB2 subsystems use a single DB2 catalog.
Workload balancing
DB2 data sharing provides flexibility for growth and workload balancing. With the partitioned data approach to parallelism (sometimes called the shared-nothing architecture), a one-to-one relationship exists between a particular DBMS and a segment of data. By contrast, data in a DB2 data sharing environment does not need to be redistributed when you add a new subsystem or when the workload becomes unbalanced. The new DB2 member has the same direct access to the data as all other existing members of the data sharing group.
DB2 works closely with the z/OS Workload Manager (WLM) to ensure that incoming work is optimally balanced across the systems in the cluster. WLM manages workloads that share system resources and have different priorities and resource-use characteristics.
Example: Assume that large queries with a low priority are running on the same system as online transactions with a higher priority. WLM can ensure that the queries do not monopolize resources and do not prevent the online transactions from achieving acceptable response times. WLM works in both a single-system and a multisystem (data sharing) environment.
Capacity when you need it
A data sharing configuration can handle your peak loads. You can start data sharing members to handle peak loads, such as end-of-quarter processing, and then stop them when the peak passes.

You can take advantage of all these benefits, whether your workloads are for online transaction processing (OLTP), or a mixture of OLTP, batch, and queries.

Higher transaction rates

Data sharing gives you opportunities to put more work through the system. As the following figure illustrates, you can run the same application on more than one DB2 subsystem to achieve transaction rates that are higher than are possible on a single subsystem.

Figure 1. How data sharing enables growth
. You can move some of your existing DB2 workload onto another central processor complex (CPC).
Begin figure description. Forming a data sharing group of even just two members can relieve an already-saturated DB2 subsystem and support many more application instances. End figure description.

More capacity to process complex queries

Sysplex query parallelism enables DB2 to use all the processing power of the data sharing group to process a single query. For users who do complex data analysis or decision support, Sysplex query parallelism is a scalable solution. Because the data sharing group can grow, you can put more power behind those queries even as those queries become more complex and run on larger and larger sets of data.

The following figure shows that all members of a data sharing group can participate in processing a single query. In this example, the ACCOUNT table has ten partitions. One member processes partitions 1 and 2; another member processes partitions 3, 4, and 5; a third member processes partitions 6 and 7; and the fourth member processes partitions 8, 9, and 10.

Figure 2. Query processed in parallel by members of a data sharing group
. Different DB2 members process different partitions of the data.
Begin figure description. A SELECT statement is processed against the ACCOUNT table by all four members of a data sharing group, in parallel. End figure description.

This is a simplification of the concept—several DB2 subsystems can access the same physical partition. To take full advantage of parallelism, use partitioned table spaces.