Enabling adaptive workload manager

In some scenarios you may want to migrate your database to an adaptive workload manager environment.

Prerequisites

The adaptive workload manager uses a different set of system workload manager objects (built-in service classes, thresholds, work actions, etc) than the legacy workload manager. Before the adaptive workload manager can be enabled on a database, you must migrate the system workload manager objects. This migration step only needs to be performed once per database and requires deactivation/activation.

Migration of the system workload manager objects is only supported if the database configuration parameters SHEAPTHRES_SHR and SORTHEAP are not set to automatic .

To migrate the system workload manager objects:
  1. Using a connection that has DBADM or WLMADM authority or was granted the ability to execute the stored procedure, invoke the adaptive workload manager migration stored procedure as follows:
    CALL WLM_ENABLE_ADMISSION_CTRL('yes')

    This prepares the database for migration to an adaptive workload manager environment; however, no changes are made to the active database at this time.

  2. Deactivate and then reactivate the database. Upon reactivation, the database has new objects created, some old objects deleted and the database configuration parameter wlm_admission_ctrl set to YES putting the database into the adaptive workload manager default environment. In a pureScale environment, the database must be inactive on all members before database reactivation will allow migration to proceed.

If any workload objects were pointing to SYSDEFAULTMANAGEDSUBCLASS under SYSDEFAULTUSERCLASS before migration then those will be changed to point at SYSDEFAULTUSERCLASS during the migration. Also, if any user created thresholds were defined on SYSDEFAULTMANAGEDSUBCLASS under SYSDEFAULTUSERCLASS before the migration then those will be dropped during migration and messages will be generated in the db2diag.log.

Enabling the adaptive workload manager

After the system workload manager objects have been migrated, the adaptive workload manager can be enabled and disabled dynamically by updating the wlm_admission_ctrl database configuration parameter.
Note:
  • Migration to and from an adaptive workload manager environment is fully supported in an HADR environment.
  • In order to return to the legacy system workload manager environment, follow the procedure shown in Restoring the legacy system workload manager objects.
Important: Fix pack fallback is not supported after migration because the enablement of admission control done during migration is not supported on the previous level. You should ensure that if you migrated to adaptive workload manager and need to fallback to the previous fix pack, the legacy workload manager is restored using the process detailed in Restoring the Legacy System Workload Manager Objects, before fallback. If migration is completed and fix pack fallback is also completed, errors will be received from database configuration because admission control is not allowed to be turned on in that environment. At that time, the issue can be resolved by reapplying the new level, executing the disable procedure and then redoing fix pack fallback. Alternately, the database configuration parameter wlm_admission_ctrl can be set to no. However, the WLM objects created during adaptive workload migration will no longer protect the database from resource over usage because they are no longer properly enabled.