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.
Db2 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.
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.
For 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.