Implementing a common workload management system in a shared-nothing RDBMS
Original Publication Date: 2005-Nov-24
Included in the Prior Art Database: 2005-Nov-24
This invention builds a universal WLM solution within a shared-nothing RDBMS. A common definition of a "service class" is created and used by all database partitions active within a shared-nothing RDBMS. For the purpose of this draft disclosure, a WLM service class is a user defined entity that provides control, statistics and execution limits over a set of requests within a database. As work enters the system, it is assessed at the first database partition (known as the coordinator partition) where it is received by the RDBMS and assigned to a service class. If this request causes work to be done at other database partitions in the RDBMS, that work inherits the parent's service class assignment.
Implementing a common workload management system in a shared -nothing RDBMS A common definition of workload management (WLM) service classes and classifications is created and stored in a central location such as the system catalogs. When the catalog database partition is started, it reads the WLM information from the system catalogs on the disk into memory and begins using those definitions. When each remote database partition is started, it obtains the WLM information from the catalog partition and stores it in its own local memory and begins using it. Therefore, each database partition has its own copy of the WLM information but each partition's copy is the same as all the others. How that information remains consistent when changes are required across database partitions, without having to restart the database, is described in a companion "Efficient Handling of Changes to a Common Workload Management System in a Shared-Nothing RDBMS" Publication.
WLM Info for DB 1
WLM Info for DB 1
DB2 ESE (EE)
Figure1: DB2 ESE (EE) and DPF (EEE)
The resources assigned to a service class may differ from one partition to another even though the initial resource allocation, if any, given in the class definitions from the central location is consistent. So, for example, the number of agents or the amount of temporary table space that can be consumed by a service class may differ from one partition to the next. This is desirable as the actual work performed at each partition may vary, so no one resource definition can fit all. Although all partitions start with the same definition, the local partition's WLM system is allowed to dynamically adjust resource allocation as requir...