Monitors and changes the behavior of applications that run against a database. By default, a daemon is started on every logical node, but the front-end utility can be used to start a single daemon at a specific node to monitor the activity against the database partition at that node.
Each governor daemon collects statistics about the applications running against a database. It then checks these statistics against the rules that were specified in the governor configuration file that applies to that specific database. The governor then acts according to these rules. For example, a rule may indicate that an application is using too much resource. In this situation, the governor may change the application's priority or force it off the database, according to instructions specified in the governor configuration file.
Authorization
sysctrl
Required Connection
Instance. This command establishes an implicit instance attachment.
Command Syntax
>>-db2gov------------------------------------------------------->
>--+-start--database--+--------------------+--config-file--log-file--+><
| +-nodenum--node-num--+ |
+-stop--database--+--------------------+--------------------------+
+-nodenum--node-num--+
|
Command Parameters
Usage Notes
Governor Configuration File
The first task in the governor daemon's execution loop is to check whether its configuration file has changed or has not yet been read. If either condition is true, the daemon reads the file; this permits an administator to change the behavior of the governor daemon while it is running.
The configuration file must reside in a directory that is mounted across all the database nodes, because the governor daemon on each node must be able to read the same configuration file.
The file consists of rules and comments. Most entries can be specified in uppercase, lowercase, or mixed case characters. The exception is applname, which is case sensitive. Each rule in the file must be followed by a semicolon (;). Comments are enclosed by braces ({}).
The following rules are specified only once in a configuration file:
| Note: | This option is not available on Windows NT or OS/2. |
If a short connect session occurs entirely within the account interval, no log record is written. When log records are written, they contain CPU statistics that reflect CPU usage since the previous log record for the connection. If the governor is stopped and then restarted, CPU usage may be reflected in two log records; these can be identified through the application IDs in the log records. For more information about governor log files, see ***).
The following rule clauses are combined to form a rule. The rule, not the clause, is followed by a semicolon. Clauses can be specified only once in a rule, but can be specified in more than one rule. Clauses must be specified in the order shown. In the description that follows, [ ] indicates an optional clause.
The time period must be specified in the form hh:mm hh:mm. For example: time 8:00 18:00. If this clause does not appear in a rule, the rule is valid 24 hours a day.
Multiple application names must be separated by a comma. For example: applname db2bp, batch, geneprog. If this clause does not appear in a rule, the rule applies to all application names.
Notes:
| Note: | This option is not available on Windows NT or OS/2. |
For this parameter to be effective, the agentpri database manager parameter must be set to the default value; otherwise, it overrides the priority clause.
An application that is holding up many other applications through locking will be given a high priority.
To ensure fairness, an application that has been in the system for a long time will be given a high priority.
To improve response time, an application that is estimated to be close to finishing will be given a high priority.
| Note: | Applications that are not covered by any schedule rule will run at the highest priority. |
The schedule action can:
For instance, if 12 applications (three short, five medium, and six long) are running at the same time, they may all have poor response times because they are splitting the CPU. The database administrator can set up two groups, medium-length applications and long-length applications. Using priorities, the governor permits all the short applications to run, and ensures that at most three medium and three long applications run simultaneously. To achieve this, the governor configuration file contains one rule for medium-length applications, and another rule for long applications. The following example shows a portion of a governor configuration file that illustrates this point:
desc "Group together medium applications in 1 schedule class" applname medq1, medq2, medq3, medq4, medq5 setlimit cpu -1 action schedule class; desc "Group together long applications in 1 schedule class" applname longq1, longq2, longq3, longq4, longq5, longq6 setlimit cpu -1 action schedule class;
If one group is running a large number of applications, the administrator can ensure that other groups are still able to obtain reasonable response times for their applications. For instance, in a case involving three departments (Finance, Inventory, and Planning), all the Finance users could be put into one group, all the Inventory users could be put into a second, and all the Planning users could be put into a third group. The processing power would be split more or less evenly among the three departments. The following example shows a portion of a governor configuration file that illustrates this point:
desc "Group together Finance department users" authid tom, dick, harry, mo, larry, curly setlimit cpu -1 action schedule class; desc "Group together Inventory department users" authid pat, chris, jack, jill setlimit cpu -1 action schedule class; desc "Group together Planning department users" authid tara, dianne, henrietta, maureen, linda, candy setlimit cpu -1 action schedule class;
If the class option is not included with the action, the governor creates its own classes based on how many applications fall under the schedule action, and puts applications into different classes based on the DB2 query compiler's cost estimate for the query the application is running. The administrator can choose to have all applications scheduled by not qualifying which applications are chosen. That is, no applname or authid clauses are supplied, and the setlimit clause causes no restrictions.
| Note: | If a limit is exceeded, and the action clause is not specified, the governor reduces the priority of agents working for the application by 10. |
Following is an example of a governor configuration file:
{ Wake up once a second, the database name is ibmsampl }
interval 1; dbname ibmsampl;
desc "CPU restrictions apply 24 hours a day to everyone"
setlimit cpu 600 rowssel 1000000;
desc 'Allow no UOW to run for more than an hour'
setlimit uowtime 3600;
desc "Slow down a subset of applications"
applname jointA, jointB, jointC, quryA
setlimit cpu 3 locks 1000 rowssel 500;
desc "Have governor prioritize these 6 long apps in 1 class"
applname longq1, longq2, longq3, longq4, longq5, longq6
setlimit cpu -1
action schedule class;
desc "Schedule all applications run by the planning dept"
authid planid1, planid2, planid3, planid4, planid5
setlimit cpu -1
action schedule;
desc "Schedule all CPU hogs in one class which will control consumption"
setlimit cpu 3600
action schedule class;
desc 'Slow down the use of db2 CLP by the novice user'
authid novice
applname db2bp
setlimit cpu 5 locks 100 rowssel 250;
desc "During day hours do not let anyone run for more than 10 seconds"
time 8:30 17:00 setlimit cpu 10 action force;
desc 'Allow users doing performance tuning to run some of
their applications during lunch hour'
time 12:00 13:00 authid ming, geoffrey, john, bill
applname tpcc1, tpcc2, tpcA, tpvG setlimit cpu 600 rowssel 120000 action force;
desc "Some people should not be limited -- database administrator
and a few others. As this is the last specification in the
file, it will override what came before."
authid gene, hershel, janet setlimit cpu -1 locks -1 rowssel -1;
desc 'Increase the priority of an important application so it always
completes quickly'
applname V1app setlimit cpu 1 locks 1 rowssel 1 priority -20;
A separate log file exists for each governor daemon. This prevents file-locking bottlenecks that would result from many governor daemons writing to the same file at the same time.
The log files are stored in the $HOME/sqllib/log directory. The base name for the log files is provided when the db2gov command is issued. Ensure that the log file name contains the database name, because there will be a log file for each node of each database that is being governed. The number of the node on which the governor is running is automatically appended to the log file name to ensure that the file name for each governor is unique.
Each record in the log file has the following format:
Date Time NodeNum RecType Message
The Date and Time fields are in the form yyyy-mm-dd-hh.mm.ss, so that the log files for each node can be merged by sorting on the combination of these two fields.
The NodeNum field indicates the number of the node on which the governor is running.
The RecType field contains different values, depending on the type of log record being written. The values that can be recorded are:
Because standard values are written, the log files can be queried for different types of actions. The Message field provides other nonstandard information that varies according to the value in the Rectype field. For instance, a FORCE or a NICE record indicates that application information exists in the Message field, while an ERROR record includes an error message.
Following is an example of a governor log file:
1996-12-11 14.54.52 0 START Database = TQTEST 1996-12-11 14.54.52 0 READCFG Config = /u/db2instance/sqllib/tqtest.cfg 1996-12-11 14.54.53 0 ERROR SQLMON Error: SQLCode = -1032 1996-12-11 14.54.54 0 ERROR SQLMONSZ Error: SQLCode = -1032
To query a governor log file, use db2govlg - DB2 Governor Log Query.
See Also
db2govlg - DB2 Governor Log Query.