7.5 Creating Oracle Database QoS Management Performance Policies for the Demo System
In this section, the sample implementation of Oracle Database QoS Management is further evolved to include creating and activating Performance Policies and refining them with additional Performance Classes.
Because the default Performance Policy is created by discovering the database services in measure-only mode, the default Performance Policy can initially be activated to test how all of the workloads perform in the cluster. The Dashboard displays both the resource use and wait times that comprise the average response time for each Performance Class during different periods of demand. These numbers can serve to help understand the minimum response times achievable with the allocated resources
If your workloads peak at different times on a regular basis or your service-level agreements (SLAs) are variable based upon time, day of week, and so on, then create additional measure-only Performance Policies that change the size of the server pools to evaluate the minimum resources required for your workloads. In this demonstration, for the Sales application, the workload that uses the online
server pool requires a minimum of two servers. The backoffice
server pool requires only one server to satisfy the workload requests. If both server pools currently contain two servers, then you can enable the online
server pool to take a server from the backoffice
server pool, if needed, by setting the minimum size of the backoffice
server pool to one. You would use a server pool directive override in the "Business Hours" Performance Policy to specify the minimum size of one for the backoffice
server pool.
You could interpret the minimum size of a server pool as the number of servers owned by that server pool. If the sum of the minimum sizes of all the server pools in the cluster is less than the number of servers in the cluster, then the extra servers are referred to as floaters, which are shared by all server pools. For example, if your cluster has 15 servers, three server pools, and a minimum size of four for each server pool, then your system has three floaters.
After the Performance Policies have been run in measure-only mode, Performance Objectives can be added to each Performance Class. The Performance Objectives can be ranked based upon how critical the maintenance of that Performance Objective is to your business. Performance Objectives should be set to maximize headroom above the observed response times but below the response times required to meet SLAs. Maintaining at least 50% headroom is a good starting point to support trading off resources should a Performance Class experience a workload surge. For example, if a Performance Class has an average response time of two milliseconds (ms), then the Performance Objective could be set to three ms— two ms response time and an additional one ms which corresponds to the 50% headroom.
Although service-based classifiers can provide for easy configuration, you might want to define more than one Performance Objective for a service. For example, the sales
service can contain many different workloads, such as Browse Products, Add Customer Account, Sales Cart and Browse Orders. Because the Sales Cart workload generates revenue, you might want this workload to have a shorter response time than the other workloads. You must create a separate Performance Class and associated classifiers to specify specific Performance Objectives for the different workloads.
On the Define Classifier page in the Policy Set wizard, a sales cart performance classifier can be defined by entering sales
as the Service Name and if the application can set MODULE
or ACTION
, enter an appropriate value, otherwise configure a separate USERNAME
from the middle tier. As soon as this new Performance Class is defined, the Performance Class appears automatically in all of the Performance Policies in measure-only mode. The new Performance Class is given the lowest rank by default. Use these values initially to test the performance of your system. After the average performance levels can be determined, a Performance Objective and rank for this Performance Class can be set within each Performance Policy.
Parent topic: Supported Workloads and Strategies