This chapter describes some problems you might encounter when using Oracle Database QoS Management and how you can resolve them. This chapter also describes how to locate the trace or log files for Oracle Database QoS Management.
This chapter contains the following sections:
After the initial configuration, Oracle Database Quality of Service Management is an automated system. As a result, most of the problems you might encounter are related to configuring Oracle Database QoS Management. The following sections illustrate the most common problems, and how to resolve them:
Before you can enable Oracle Database QoS Management within a cluster, you must first create a Policy Set. To create a Policy Set, use the Create Policy Set link on the Oracle Enterprise Manager Database Control Cluster Administration page.
A compliant database is an Oracle RAC database that is running Oracle Database release 184.108.40.206 or greater and is configured to run in a Policy-managed deployment.
For a database to be enabled, Oracle Database QoS Management must be able to connect to the database. The connection is configured when you select the Enable Quality of Service Management link in the Oracle Enterprise Manager Database Control Database Availability page. When you select this link, you are prompted for the cluster credentials and the password for the APPQOSSYS account in the database. By default the APPQOSSYS account is expired. When you submit a password, the account is unlocked.
If the password for the APPQOSSYS user is changed through other methods or the account is locked, then Oracle Database QoS Management is disabled for this database until this condition is corrected by selecting the Enable Quality of Service Management link again.
Oracle Database QoS Management installs a special Oracle Database Resource Manager plan whenever a database is enabled for management by Oracle Database QoS Management. Oracle Database QoS Management requires this resource plan to move Performance Classes to different levels of CPU scheduling. No other plan can be active while Oracle Database QoS Management is enabled on this database. If a resource plan is not enabled for the Oracle RAC database, then an error results when trying to enable the database for management by Oracle Database QoS Management. After a resource plan is enabled, then enabling the database for management by Oracle Database QoS Management succeeds.
Caution:By default, any named user may create a server pool. To restrict the operating system users that have this privilege, Oracle strongly recommends that you add specific users to the CRS Administrators list. See Oracle Clusterware Administration and Deployment Guide for more information about adding users to the CRS Administrators list.
Server pools are a new Oracle Clusterware entity beginning in Oracle Grid Infrastructure 11g release 2. Server pools can be managed separately from the database by configuring special operating system groups. By default, the user that installed Oracle Grid Infrastructure for a cluster can perform operations on server pools. If you use a separate operating system for the Oracle Database installation, then execute permissions on a server pool must be granted to the database software owner before a database can be deployed in that server pool. To grant this permission, you must use the CRSCTL utility to modify the server pool ACL attribute. A database administrator can also create server pools using Server Control (SRVCTL) or Oracle Enterprise Manager.
See Also:Oracle Clusterware Administration and Deployment Guide for information about
A server pool is marked as unmanageable if Oracle Database QoS Management is not able to properly measure or predict the performance of Performance Classes deployed in that server pool. A server pool can be considered unmanageable under the following conditions in Oracle Database 11g release 2 (220.127.116.11):
The servers in the server pool have different physical CPU counts.
The CPU count for every database instance could not be retrieved.
The sum of the configured CPU counts for all database instances on a server is greater than its physical CPU count.
Singleton services are deployed in a server pool with a maximum size larger than one.
Oracle Database QoS Management is unable to collect the metrics for all Performance Classes, or the metrics collected do not contain valid data.
The server pool has a database that is not enabled for Oracle Database QoS Management.
If a server is added to a server pool, then Oracle starts up instances and services on the new server for the policy-managed databases in the server pool. When an instance is started on the new server, Oracle checks the SPFILE of the existing instances for the
CPU_COUNT setting, and uses this value for the new instance. By default, if there is no setting for
CPU_COUNT in the SPFILE, then the instances on the new server will be started with
CPU_COUNT set to the number of physical CPUs of the server. This is not a supported configuration and will result in the server pool being marked as unmanageable. Also, if you modify the
CPU_COUNT parameter but do not store the change in the SPFILE, then the
CPU_COUNT parameter might be set to the wrong value on the newly started instance resulting in a configuration violation.
Make sure the databases and database instances that you want to be managed by Oracle Database QoS Management conform to the requirements documented in "Supported Database Configurations".
The database requests (work being done) do not match the classifiers defined for a specific Performance Class and "No demand" is displayed.
A more general classifier of a Performance Class is evaluated first. As a result, the Performance Class with the more specific classifier is shown as having "No demand". For example, if the
sales_pc Performance Class uses the classifier
service=Sales and the
sales_search Performance Class uses the classifier (
ervice=Sales and action=Search), then, if the
sales_pc Performance Class was listed first in the Edit Policy Set Performance Class Order screen, then any work request that uses the
sales service would be placed in the
sales_pc Performance Class, including those that are performing the
Search action. The
sales_search Performance Class does not generate any metrics and "No demand" is displayed for that Performance Class.
The database instance is over-utilized and the metrics query reaches the time out limit and "Incomplete data" is displayed.
The database is not producing mutually consistent data for the Performance Class and "Nonconforming data" is displayed. For example a Performance Class that is classifying database requests that exceed one second will cause this response.
The metrics collected through the query do not pass the sanity verification checks performed by Oracle Database QoS Management and "Nonconforming data" is displayed.
Oracle Database QoS Management is disabled.
An action is in progress implementing a recommendation.
During the first minute of enabling Oracle Database QoS Management, or when submitting a Policy Set or activating a Policy Set.
Servers are moved within a cluster by Oracle Clusterware, or as directed by an administrator. When a new server joins the cluster, Oracle Clusterware places the server in a server pool according to the placement algorithm and the state of the server pool attributes of Min, Max and Importance. See the Oracle Clusterware Administration and Deployment Guide for a complete description of this placement process.
When you install Oracle Grid Infrastructure for a cluster, the default port for the Oracle Application Server Containers for J2EE (OC4J) resource is set to 23792. This can cause a port conflict with Java Remote Method Invocation (RMI). You should set the
OC4J_PORT environment variable in your environment to the number of an available port, then restart the OC4J resource using the following commands:
srvctl modify oc4j -p port srvctl stop oc4j srvctl start oc4j
The Oracle Database QoS Management server operations log file is located at
The Oracle Database QoS Management server trace log file is located at
The OC4J standard out log file and the trace file for the Server Manager (SRVM) component of Oracle Clusterware is located at
The OC4J standard error log file is located at
The start and stop log file for the DBWLM component of Oracle Database QoS Management is located at