When using multiple resource allocation plans in this fashion, you need to make sure you
don??™t accidentally use the wrong plan at the wrong time. For example, if the database is down
during a scheduled plan change, your job that changes the plan allocation may not execute. How
will that affect your users? If you use multiple resource allocation plans, you need to consider the
impact of using the wrong plan at the wrong time. To avoid such problems, you should try to
minimize the number of resource allocation plans in use.
In addition to the examples and commands shown in this section, you can update existing
resource plans (via the UPDATE_PLAN procedure), delete resource plans (via DELETE_PLAN), and
cascade the deletion of a resource plan plus all its subplans and related resource consumer groups
(DELETE_PLAN_CASCADE). You can update and delete resource consumer groups via
the UPDATE_CONSUMER_GROUP and DELETE_CONSUMER_GROUP procedures, respectively.
Resource plan directives may be updated via UPDATE_PLAN_DIRECTIVE and deleted via
DELETE_PLAN_DIRECTIVE.
When you are modifying resource plans, resource consumer groups, and resource plan
directives, you should test the changes prior to implementing them. To test your changes, create a
pending area for your work. To create a pending area, use the CREATE_PENDING_AREA procedure
of the DBMS_RESOURCE_MANAGER package. When you have completed your changes, use the
VALIDATE_PENDING_AREA procedure to check the validity of the new set of plans, subplans,
and directives.
Pages:
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258