Migrating from DB2 Governor to DB2 workload manager

Migrating from DB2® Governor to DB2 workload manager (WLM) requires that you set up your database for coexistence of DB2 Governor and DB2 WLM, re-examine your goals, and implement a workload management solution.

To migrate from DB2 Governor to DB2 WLM:

1. Upgrade the data server where the Governor is installed to DB2 Version 9.7 so that you have an environment where DB2 WLM and the Governor can coexist. Use one of the following tasks:
   • Upgrading DB2 servers (Windows)
   • Upgrading DB2 servers (Linux and UNIX)

   After the upgrade, there is a default workload created to identify all the user database activities and the workload is mapped to the default user service class which defines an execution environment. The Governor action nice rule clause is managed in only the default user service class. You cannot use the Governor to alter the priority of agents in user-defined service superclasses and subclasses. However, all other governor rules are enforced for all user-defined service classes.

2. Limit the use of DB2 WLM to control work in the default user service class to avoid potential conflicts between the Governor and DB2 WLM.
3. Re-examine your workload management goals. Understanding them is critical to implement a workload management solution.
4. Identify the work that runs on the data server and maps to your goals. Take advantage of the additional identification options at your disposal in DB2 WLM.
5. Manage the work that you identified by assigning resources and imposing controls to meet your goal metrics. Using any of the following approaches might result in a more simple and effective implementation:
   • Use DB2 service classes to separate and isolate competing workloads from each other or group database activities. Then change the agent, buffer pool, and prefetch priority options each service class receives to affect their individual response times. Try this approach first instead of creating concurrency thresholds.
   • Take note of the AUTHID and APPLNAME parameter values in the Governor control file and create a workload specifying the SESSION_USER and APPLNAME connection attributes using the AUTHID and APPLNAME parameter values.
   • If you cannot separate work by its source using workloads, map all incoming work to a common service super class and use a DB2 work action set to separate work by different characteristics and assign it to different service sub classes. At this point, manipulate the resources available to each service class to achieve your goals.
   • If you do not achieve the desired results by setting the priority options each service class receives alone, selectively apply other features of DB2 WLM as needed until you achieve your goals, such as the application of DB2 thresholds.
   • When you use DB2 thresholds, ensure that the threshold violations event monitor is created and activated; otherwise, you will not know when and what thresholds are being violated.
   • If you create thresholds to map to the same workloads the Governor was watching, consider all the thresholds available in DB2 WLM. Some of the DB2 Governor reactive rules will find a direct functional equivalent in DB2 workload management thresholds, like those controlling maximum execution time, the maximum number of rows returned, or the maximum connection idle time. Others are unique to workload management or to the DB2 Governor and require you to rethink your approach to controlling work in current workload management terms. Note that DB2 Governor rules can apply to already running queries, whereas changes to DB2 WLM thresholds apply only to new queries.

     Consider all the different threshold actions available in DB2 WLM. You can choose a more forgiving action when a resource threshold is exceeded than ending the activity, such as letting the threshold continue execution or remapping it to a service subclass with different resource controls, and you can use the information logged in the threshold violations event monitor to further investigate the activity.

   • For the rowssel limit, you can create a threshold using the SQLROWSRETURNED condition to indicate what action should be taken when the limit of number of data rows returned to the application is exceeded.
   • For the rowsread limit, you can create a threshold using the SQLROWSREAD or SQLROWSREADINSC condition to indicate what action should be taken when the limit of number of data rows read during query evaluation is exceeded.
   • For the cpu limit, you can create a threshold using the CPUTIME or CPUTIMEINSC condition to indicate what action should be taken when the limit for the amount of combined user and system CPU time consumed by an activity is exceeded.
   • For the idle limit, you can create a threshold using the CONNECTIONIDLETIME condition to indicate what action should be taken when the maximum connection idle time is exceeded.
   • For the uowtime limit, you can create a threshold using the UOWTOTALTIME condition to indicate the length of time a unit of work is allowed to run.
   • If you are using connection pooling, DB2 WLM has the client attributes available for proper identification and management of queries. The application at the middle tier could either call the sqleseti API or WLM_SET_CLIENT_INFO procedure to set one of the client attributes before it issues the SQL.
   • If your data server runs on the AIX® operating system, consider using AIX WLM for a more granular control of processor resource.
6. Monitor options to ensure that you are meeting your goals.