DB2 pureScale Feature is an extension of the existing IBM DB2 product for Linux, UNIX, and Windows that allows you to scale your database solution. Multiple database servers, known as DB2 members, process incoming database requests; these members operate in a clustered system and share data. The primary focus of DB2 pureScale is scalability and high availability.

Each member of a pureScale cluster runs its own DB2 instance using DB2 server software and has access to the entire database. The cluster caching facility (CF) in DB2 pureScale coordinates data sharing among members and ensures concurrency control and cache coherence.
DB2 pureScale uses IBM Tivoli System Automation for Multi Platforms (SA MP) as a built-in cluster manager to detect component failures and automatically perform all necessary actions to minimize the impact on the overall system. For example, if the primary CF fails, the cluster manager automatically assigns the primary function to the secondary CF and redirects all requests to it.
The benefits of DB2 pureScale Feature include:
- Database distribution across multiple servers (active/active scenario)
- Scaling through multiple servers
- The ability to add more members to scale horizontally and meet your business needs.
- Continuous availability of the database.
- The IBM DB2 pureScale feature is designed to continue processing incoming database requests without interruption, even during planned system maintenance or extreme circumstances, such as when multiple components fail simultaneously.
- Stealth maintenance of operating system and hardware.
- Using DB2 pureScale Feature requires an additional license that can be purchased from SAP or IBM
What is it used for?
Db2 pureScale can help reduce the risk and cost associated with the growth of your distributed database solution by providing extreme capacity and application transparency. The Db2 pureScale environment is designed for continuous availability and is capable of exceeding even the industry's strictest standards.
When workloads increase, does your distributed database system require you to change your applications or alter how data is distributed? If so, your system does not scale transparently. Even simple application changes incur time and cost penalties and may pose risks to system availability. There is always much at stake: every second lost in system availability can directly impact customer retention, meeting service level agreements, and your bottom line.
With Db2 pureScale Feature, scaling your database solution is straightforward. Multiple database servers, known as members, process incoming database requests; these members operate in a clustered system and share data. You can transparently add more members to scale horizontally and meet even the most demanding business needs. No changes to the application, data redistribution, or performance tuning are required.
To deliver a design capable of exceptional levels of database availability, Db2 pureScale Feature relies on known and proven design characteristics of the Db2 for z/OS® database software. By also integrating various advanced hardware and software technologies, Db2 pureScale Feature meets the most stringent requirements for high fault tolerance and can support database request processing even in extreme circumstances.
What are the components of DB2 pureScale?
Db2 pureScale Feature combines several closely integrated software components into a high availability database solution. These software components are automatically installed and configured when you implement the Db2 pureScale Feature.
Caching
The Db2 pureScale feature includes a cluster caching facility, also known as the CF component in a Db2 pureScale environment. This function is used to coordinate locking through a global lock manager to prevent conflicting access to the same table data by different members. The cluster caching function is also used to maintain page cache coherence among all members through a shared buffer pool. The shared buffer pool coordinates the copies of pages that may exist in the local buffer pools of the members.
The cluster caching function also provides a Shared Communication Area (SCA). Members can use this shared communication area to emulate shared memory across the entire cluster.
At least one cluster caching facility must be online for a database to be available while Db2 members are online. To leverage the design of a continuous availability environment, use multiple cluster caching facility instances. Duplicating the database metadata and data in a secondary cluster caching facility ensures that while it is active, it remains in the same state as the primary CF. If the primary CF fails, a secondary one can take over to maintain database availability.
CFs can run on their own machines or may share hosts with members running on their own logical partitions (LPARs). The hosts of the cluster caching facility should not be used for anything other than Db2 pureScale Feature. If you must run other software on the cluster caching facility hosts, additional manual configuration adjustments for your database may be required.
Db2 Cluster Services
Db2 cluster services is software that provides automatic heartbeat failure detection and automatically initiates the necessary recovery operations after a failure is detected. It also provides the cluster file system that grants each host in a Db2 pureScale instance access to a common file system.
Db2 cluster services includes technology from IBM Tivoli® System Automation for Multiplatforms (Tivoli SA MP), IBM Reliable Scalable Clustering Technology (RSCT), and IBM Spectrum Scale software. This technology is packaged as an integral part of the Db2 pureScale Feature.
If a component of your Db2 pureScale environment does not respond to the heartbeat detection protocol, Db2 cluster services alert the members and the cluster caching facilities, isolate the failed component from shared storage (if necessary), and initiate a restart of the component. This restart process is designed to be automatic and requires no intervention from you.
While the recovery of the failed component is underway, the rest of the instance remains available and can continue processing incoming database requests. Applications connected to a failing member will automatically be redirected to other members through Db2's client automatic redirection support.
The installation process for Db2 pureScale Feature uses IBM Spectrum Scale software to create the Db2 cluster file system on shared disk.
Shared Disk Storage
The disk storage you use to set up the instance is shared among all components of the Db2 pureScale environment. The disk storage is used for the following purposes:
- To store the database data itself.
- To store the instance configuration and other database information, such as logs, metadata, log files, and backups.
- To store troubleshooting information for the members and cluster caching facilities, such as db2diag log files and first occurrence data capture (FODC) information.
- To assist Db2 cluster services in arbitrating which members and cluster caching facility resources will remain operational in the event of a severe communication failure preventing one half of the hosts from communicating with the other half. This arbitration process prevents groups of hosts from processing database requests independently of one another. In the case of a severe communication failure where one group of hosts cannot communicate with another, Db2 cluster services will automatically allow the larger group to remain operational. If the groups are equal, a shared tie-break disk is used to arbitrate which group remains operational.