UDB EEE Architecture

Another competing parallel database that follows the shared-nothing architecture is DB2 UDB Enterprise-Extended Edition (EEE). This product follows the shared-nothing model with each node having its own set of disks. Each instance or node has ownership of a distinct subset of the data, and all access to this data is performed by the owning instance. Thus, it is a partition database. (Fig 3.14) However, the disks are attached to more than one node physically. In case of a node failure, ownership of the disk subsystem moves to another node.

The basic method of UDB (EEE) is to distribute the data and database functions to multiple hosts. It uses a hashing algorithm that enables it to manage the distribution (and redistribution) of data as required. A database partition is a part of the database that has its own portion of the user data, indexes, configuration files, and transaction logs.

Fig 3.14 UDB (EEE) Three Node Cluster

The shared-nothing architecture allows parallel queries to be processed with minimal contention for resources between hosts in the DB2 cluster. Because the number of data partitions has little impact on traffic between hosts, performance scales better almost linearly as more machines are added to the DB2 cluster.

UDB (EEE) uses the concept of function shipping. Function shipping reduces network traffic because functions, such as SQL queries, are shipped instead of data. Function shipping means that relational operators are executed on the node (or processor) containing the data whenever possible. Thus, the operation (or the SQL) is moved to where the data resides. Function shipping is well suited to the shared-nothing architecture model.

In case one node fails, a pre-configured node takes over the disk system and makes the data available through that node. A cluster script starts DB2 UDB EEE database partitions on the takeover node. Once this script completes, all database partitions in the DB2 UDB EEE database are available and processing goes on as usual. As an example, When a RS/6000 SP cluster is implemented with HACMP to support the UDB EEE; nodes are usually configured in three ways:

• Idle Standby - A standby SP node can be provided which will take over the work of a failed SP node. The standby SP node has access to all resources required for the provision of the essential services, e.g., disks, networks, and so on. When the failed SP node is repaired and reintegrated into the cluster, it will reclaim its resources.
• Rotating Standby - A standby SP node is provided to take over the work of a failed SP node, as in the idle standby scenario. However, when the failed SP node is reintroduced, it does not reclaim its resources, but becomes the new standby machine.
• Mutual Takeover - There are no standby SP nodes. All SP nodes are utilized in a normal state. After an SP node failure, the failed SP node’s resources and essential services are taken over by one of the surviving SP nodes in addition to its normal services.

DB2 UDB EEE supports a diverse set of hardware options including SMP, MPP, NUMA, RISC servers, and clustered configurations with a range of interconnect options. DB2 exploits high availability solutions on each platform. DB2 UDB EEE can run on multiple operating systems, including IBM AIX, Linux, HP-UX, Sun Solaris, and Windows NT.