One of the (ok, many) interesting things that I have personally learned over the years of discussing workload management and monitoring issues with DB2 customers is that they don't all approach the task of identifying incoming work in the same manner and some think about it in radically different ways (at least it seemed that way to me when I learned about it :).
I thought a summary of these different approaches would be interesting as a way of opening our minds a bit to perhaps view old problems from new, alternate perspectives. It never hurts to think new thoughts (at least not after the first little bit), it might help crack a problem for you some day, and it helps to keep one's brain from calcifying! ;)
An important part of workload management is being able to assign business priority to specific subsets of work in a database system and then ensuring that system priorities align with the specified business priorities for those different subsets. Experience has shown me that customers approach the discussion on how to identify different subsets of work from one of three different perspectives:
- Who is submitting the work
- What type of work is being submitted
- Where is the work impacting the database
The Who customers identify incoming work based on connection attributes such as the session authorization ID or the application name.Business priority is assigned based on the identity of the external entity that is submitting the work.
The What customers look at the type of work being submitted and distinguish large analytical queries from small GUI dialog queries, etc.Business priority is assigned based on the type of work being submitted.
The majority of customers that I have worked with use one of these two approaches (or a hybrid of them) as this is how most of us naturally think about the incoming work but there is actually a small minority who prefer to work from the data outwards.
The Where customers actually use the identify of the different data objects being accessed by the work as the way to assign business priority to the work. In such cases, there may be either a basic organizational preference or past experience using this approach with another product, or it just may be asier for them to identify and prioritize the target of work rather than the sources and types of work itself. In such cases, they assign business priority to work touching a specific object (or objects) based on either an inherent attribute of the data, such as the object contains test data or the object contains production data, or based on an access characteristic of the data within the organization, such as how frequently the object is accessed or the age of the data. This latter aspect is also referred to as the “temperature” of the data and shows up in discussions in managing data within a system based on a multi-temperature approach.
I try to show the different options below in a picture....
From a DB2 implementation pespective, we provide different mechanisms to try and support all three approaches (and any hybrid of them).
The customer preferring the Who approach would use DB2 Workloads to formally identify, monitor, and control the source of work.
The customer following the What approach would leverage DB2 Work Class Sets to identify the type of incoming work and then use DB2 Work Action Sets to monitor and control the different types of work appropriately.
Finally, the customer using the Where approach would look to use the data tag capability introduced in DB2 LUW 10.1 along with DB2 Work Class Sets and DB2 Work Action Sets to identify, monitor, and control the work based on the storage being accessed.