{ "date": "2016-03-10T15:15:40", "slug": "resource-manager-plan-from-oem-vs-command-line", "link": "https://www.dbi-services.com/blog/resource-manager-plan-from-oem-vs-command-line/", "title": { "rendered": "Resource Manager plan from OEM vs. command line" }, "content": { "rendered": "

By Franck Pachot

\n

.
\nYou are rather GUI or command line? Let’s compare what you can do with them when you want to create a Resource Manager plan, and what is missing in the GUI.
\n
\nI’m using EM13c here on a 12c database. Doc for command line API is here.

\n

I’ll explain what you can set in the GUI and the matching arguments generated by OEM:

\n

\"Screenshot

\n

Here we have the name and description (comment):

\n
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE (\n   plan                      IN VARCHAR2, \n   comment                   IN VARCHAR2 DEFAULT NULL,
\n

When the ‘Activate this plan’ is checked, it calls the dbms_resource_manager.switch_plan, with the allow_scheduler_plan_switches=>false if you uncheck ‘Automatic Plan Switching Enabled’

\n

The CREATE_PLAN_DIRECTIVE is called for each group or sub plan:

\n
   group_or_subplan          IN VARCHAR2, \n
\n

The ‘Utilization limit %’ defines the max_utilization_limit wich is now utilization_limit:

\n
   max_utilization_limit        IN NUMBER   DEFAULT NULL,  -- deprecated\n   utilization_limit            IN NUMBER   DEFAULT NULL,
\n

The number or shares that we set are converted to percentage of total shares in order to define the cpu_p1 which is now mgmt_p1.

\n
\n   cpu_p1                    IN NUMBER   DEFAULT NULL, -- deprecated\n   mgmt_p1                   IN NUMBER   DEFAULT NULL,
\n

Actually, OEM put the share number and not the percentage when generating the SQL, but that’s ok.

\n

Parallel Query DOP and queuing

\n

\"Screenshot

\n

Here are the parallel settings. ‘bypass queue’ sets parallel_stmt_critical to ‘bypass_queue’ to avoid statement queuing for this consumer group.

\n
   parallel_stmt_critical       IN VARCHAR2 DEFAULT NULL);\n
\n

and the settings (using the deprecated parallel_target_percentage instead of parallel_sever_limit )

\n
   parallel_degree_limit_p1  IN NUMBER   DEFAULT NULL,\n   parallel_target_percentage   IN NUMBER   DEFAULT NULL,  -- deprecated \n   parallel_queue_timeout       IN NUMBER   DEFAULT NULL,
\n

The timeout is the number of seconds the statement can remain queued.

\n

Per session or per-call limits

\n

\"Screenshot

\n

The limits set the following arguments (in respective order):

\n
   switch_elapsed_time          IN NUMBER   DEFAULT NULL,\n   switch_time                  IN NUMBER   DEFAULT NULL,\n   switch_io_megabytes          IN NUMBER   DEFAULT NULL,\n   switch_io_logical            IN NUMBER   DEFAULT NULL,\n   switch_io_reqs               IN NUMBER   DEFAULT NULL,
\n

The actions sets a consumer group to switch to, or KILL_SESSION or CANCEL_SQL:

\n
   switch_group              IN VARCHAR2 DEFAULT NULL,\n
\n

The ‘track by statement’ sets to true the switch_for_call (it switches to group only until the end of the call) and the ‘use estimate’ sets switch_estimate to true:

\n
   switch_for_call           IN BOOLEAN  DEFAULT NULL,\n   switch_estimate           IN BOOLEAN  DEFAULT FALSE,
\n

Idle time limits

\n

\"Screenshot

\n

This sets the following time in seconds:

\n
   max_idle_time                IN NUMBER   DEFAULT NULL,\n   max_idle_blocker_time        IN NUMBER   DEFAULT NULL,
\n

What is missing?

\n

It seems that we cannot set here the limit based on CBO estimation:

\n
   max_est_exec_time         IN NUMBER   DEFAULT NULL,
\n

Same for the maximum number of active sessions limit

\n
   active_sess_pool_p1       IN NUMBER   DEFAULT NULL,\n
\n

And the transaction undo size limit:

\n
   undo_pool                 IN NUMBER   DEFAULT NULL,\n
\n", "protected": false } }