How Does Throttling Work?
To control throttling, there is an algorithm that is busy ensuring that DB2 UDB is aware of the utility's load on the system and adjusts its consumption accordingly. A simplified representation of this algorithm is shown below:
The DBA ellipse represents the setting of the UTIL_IMPACT_LIM parameter that is determined by the DBA and the business policy. The DB2 ellipse encapsulates the utilities that are running. During utility operations, a sensor interacts with the Adaptive Controller box (which is actually inside DB2 UDB), and it runs algorithms that determine a metric for computing degradation. It compares that returned value with a baseline estimation for the workload and the "impact allowances," as defined by the DBA. If there is a problem, a separate process will cause the utility to "sleep" until it is in compliance with the set policy.
The graph on the right plots a sample of the output for the aforementioned OLTP workload with the BACKUP utility running. In this test, the UTIL_IMPACT_LIM parameter was set to 50 (represented by the red line). The actual performance numbers are plotted in blue. You can see that DB2 UDB was able to keep the workload constant by throttling the utility after it exceeded the target threshold and the throttling algorithm took effect.
More representative of the real world would be a scenario involving multiple concurrent workloads on the system.
The following test had a dual workload with the BACKUP utility running concurrently. On the left side of the diagram, you can see the workload distribution between the two applications, with the total system resource shown in blue. On the right side of the diagram, the BACKUP utility has been invoked, again with the UTIL_IMPACT_LIM = 50. If you look at the right side of the diagram, you can see that the "meat" of the workloads' impact on the system is now at 900 seconds, compared to 600 seconds on the left - this implies that the workloads were impacted by roughly 50%. Note that the distribution of the workloads in both diagrams has a similar shape.
Using DB2 UDB Throttling
In DB2 UDB V8.1.2, throttling is mainly confined to the BACKUP utility; throttling the REBALANCE utility requires special handling.
Utilities can be run in either throttled or unthrottled mode. In unthrottled mode, the utility would not be under the throttling system and does not obey the UTIL_IMPACT_LIM parameter. In throttled mode, you can actually assign different priorities.
In most cases, DBAs will just run a utility in throttled mode without any special priority. Although the ability to specify a priority is not very important when there are not a lot of utilities that can be throttled, this method created an infrastructure that is scalable and extensible to support other utilities in future releases (see the DB2 UDB Throttling in "Stinger" section later in this article).
For example, the following syntax was added to the BACKUP DATABASE command:
On the BACKUP DATABASE command, priority is an optional flag that represents a number in the range of 1 to 100, with 100 representing the highest priority, and 1 representing the lowest priority. The priority specifies the amount of throttling to which the utility is subjected. All utilities at the same priority undergo the same amount of throttling, and utilities at lower priorities are throttled more than those at higher priorities. If you do not specify this option, the default priority is 50. If you invoke the BACKUP utility without specifying the UTIL_IMPACT_PRIORITY keyword, the utility will execute in unthrottled mode (of course, if the UTIL_IMPACT_PRIORITY keyword is specified, but UTIL_IMPACT_LIM is set to 100, the utility will run unthrottled).
The REBALANCE utility is invoked indirectly from an ALTER TABLESPACE operation. By default, the REBALANCE utility is started in unthrottled mode, and a mechanism is provided whereby a DBA can throttle this utility after it has been started.
The ability to use the command line processor (CLP) to enable or disable throttling, as well as reprioritize a running utility, is also provided through the set command, as follows:
set UTIL_IMPACT_PRIORITY for <utility_id> to <priority>
For the set command, the priority flag performs the same function as detailed above; however, if you set it to 0, it will force a throttled utility to continue unthrottled.
In the DB2 UDB V8.1.2 implementation, running multiple throttled utilities at the same time is not supported.
DB2 UDB "Stinger" has a number of enhancements to the throttling capabilities of DB2 UDB (check out www.ibm.com/db2/stinger for more information):
- Some of the utilities and policy settings have been encapsulated in the Control Center and Wizards.
- There is an active utilities monitor to track the status of utilities.
- Snapshots and SQL support for monitoring the progress of executing utilities have been added.
- Multiple concurrently running utilities can be throttled.
- The UTIL_IMPACT_PRIORITY clause has been added to the RUNSTATS utility.
About the Authors
Paul C. Zikopoulos, BA, MBA, is with IBM Canada Ltd. Paul has written numerous magazine articles and books about DB2. Paul has co-authored the books: DB2 Version 8: The Official Guide, DB2: The Complete Reference, DB2 Fundamentals Certification for Dummies, DB2 for Dummies, and A DBA's Guide to Databases on Linux. Paul is a DB2 Certified Advanced Technical Expert (DRDA and Cluster/EEE) and a DB2 Certified Solutions Expert (Business Intelligence and Database Administration). You can reach him at: paulz_ibm at msn.com.
Roman B. Melnyk, PhD, is with IBM Canada Ltd., specializing in database administration, DB2 utilities, and SQL. Roman has written numerous DB2 books, articles, and other related materials. Roman co-authored DB2 Version 8: The Official Guide, DB2: The Complete Reference, DB2 Fundamentals Certification for Dummies, and DB2 for Dummies. You can reach him at roman_b_melnyk at hotmail.com.
IBM reserves the right to include or exclude any features advertised as part of the DB2 UDB "Stinger" release in the final version of this product.