Part 20 was about RAC Services and how to control where workloads run.
Now we move one level deeper:
Once a workload reaches an instance, how do we control how much CPU and other resources it can consume?
This is where Oracle Database Resource Manager becomes essential.
A production RAC should not operate on the assumption that every workload deserves unlimited resources.
Imagine this:
RAC
|
+------------+------------+
| |
RAC1 RAC2
| |
OLTP REPORTING
| |
BATCH ETL
| |
AD-HOC BACKUP
Without resource controls, a reporting query or batch process can consume enough CPU to affect the OLTP workload.
Resource Manager gives you a mechanism to establish priorities and limits.
1. The Problem We’re Solving
Suppose your RAC has:
RAC1 = 32 CPU RAC2 = 32 CPU
And the workloads are:
OLTP REPORTING BATCH AD-HOC
At 09:00:
OLTP 50% REPORTING 20% BATCH 10% AD-HOC 5%
Everything looks fine.
At 14:00 someone launches:
SELECT ... FROM huge_table JOIN huge_table2 ...
and suddenly:
REPORTING → 95% CPU
The OLTP application starts slowing down.
Without Resource Manager, the database scheduler has fewer mechanisms to enforce business priorities.
2. Resource Manager in One Diagram
Think of it like this:
DATABASE
|
Resource Manager
|
+------------+------------+
| | |
OLTP REPORTING BATCH
| | |
HIGH MEDIUM LOW
PRIORITY PRIORITY PRIORITY
The goal is not necessarily to make low-priority workloads slow.
The goal is to make sure that:
Critical workloads remain protected when the system becomes busy.
3. Resource Manager Building Blocks
The main concepts are:
Resource Plan
|
+-- Consumer Groups
|
+-- Resource Directives
|
+-- Mapping Rules
Let’s understand each one.
4. Consumer Group
A consumer group represents a category of workload.
For example:
OLTP_GROUP REPORTING_GROUP BATCH_GROUP ADHOC_GROUP
Think of it as:
“Which type of workload is this session performing?”
5. Resource Plan
The resource plan defines the overall policy.
Example:
PROD_PLAN
It can contain directives such as:
OLTP_GROUP → 60% REPORTING_GROUP → 20% BATCH_GROUP → 15% ADHOC_GROUP → 5%
Conceptually:
PROD_PLAN
|
+-----------+-----------+
| | |
OLTP REPORTING BATCH
60% 20% 15%
|
ADHOC
5%
These percentages are examples—not a universal recommendation.
6. Resource Directive
A directive defines how a particular consumer group behaves within a resource plan.
For example:
OLTP_GROUP CPU allocation = high
while:
ADHOC_GROUP CPU allocation = low
You can also define behavior related to:
- Parallel execution
- Active session pools
- Execution time
- I/O
- Queuing
- Other resource controls depending on your Oracle configuration
7. Why Resource Manager Matters More in RAC
In RAC, you don’t only have:
Database
You have:
RAC | +-- Instance 1 | +-- Instance 2 | +-- Instance N
A resource policy therefore needs to be considered alongside:
Services CPU Cache Fusion Instance load Application architecture
This is why Part 20 and Part 21 are closely connected.
8. Services + Resource Manager
The architecture becomes:
Application
|
SERVICE
|
↓
Consumer Group
|
↓
Resource Manager
|
↓
CPU / Parallelism / I/O
For example:
SALES_APP
↓
OLTP_GROUP
↓
HIGH PRIORITY
and:
REPORTING
↓
REPORTING_GROUP
↓
MEDIUM PRIORITY
9. Check Current Resource Manager Configuration
Start with:
SELECT name,
is_top_plan,
cpu_managed,
status
FROM v$rsrc_plan;
Depending on the Oracle 19c release and configuration, available columns can vary, so verify with:
DESC v$rsrc_plan;
10. Check Consumer Groups
SELECT consumer_group,
status
FROM dba_rsrc_consumer_groups
ORDER BY consumer_group;
You’ll see Oracle’s predefined consumer groups as well as any custom groups.
11. Check Resource Plans
SELECT plan,
status,
comments
FROM dba_rsrc_plans
ORDER BY plan;
Again, expect Oracle-supplied plans in addition to custom plans.
12. Check Resource Directives
SELECT plan,
group_or_subplan,
mgmt_p1,
mgmt_p2,
mgmt_p3
FROM dba_rsrc_plan_directives
ORDER BY plan, group_or_subplan;
This is one of the most useful views when auditing Resource Manager.
13. Important: Don’t Modify SYS Plans Blindly
Before creating anything, inspect the current configuration.
SELECT * FROM dba_rsrc_plans;
and:
SELECT * FROM dba_rsrc_plan_directives ORDER BY plan;
Never assume the database has no existing resource management configuration.
14. Creating a Consumer Group
Let’s build a simple example.
BEGIN
DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP(
consumer_group => 'OLTP_GROUP',
comment => 'Critical OLTP workload'
);
END;
/
Another:
BEGIN
DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP(
consumer_group => 'REPORTING_GROUP',
comment => 'Reporting workload'
);
END;
/
And:
BEGIN
DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP(
consumer_group => 'BATCH_GROUP',
comment => 'Batch processing workload'
);
END;
/
15. Grant Users Access to Consumer Groups
A user needs permission to switch into a consumer group.
For example:
BEGIN
DBMS_RESOURCE_MANAGER_PRIVS.GRANT_SWITCH_CONSUMER_GROUP(
grantee_name => 'APPUSER',
consumer_group => 'OLTP_GROUP',
grant_option => FALSE
);
END;
/
But don’t confuse:
GRANT SWITCH CONSUMER GROUP
with:
Automatically assigning sessions
We’ll handle automatic mapping next.
16. Consumer Group Mapping
This is where Resource Manager becomes really useful.
You can map sessions based on attributes such as:
Username Service Module Action Client program Client OS user
For RAC applications, service-based mapping is particularly interesting.
Conceptually:
SERVICE = SALES_APP
↓
OLTP_GROUP
and:
SERVICE = REPORTING
↓
REPORTING_GROUP
17. Why Service-Based Mapping Is Powerful
Part 20 established:
Application
↓
Service
Now Part 21 extends it:
Application
↓
Service
↓
Consumer Group
↓
Resource Plan
This means the application doesn’t necessarily need to know anything about Resource Manager.
The infrastructure controls it.
18. Mapping Example
For example:
BEGIN
DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING(
DBMS_RESOURCE_MANAGER.SERVICE_NAME,
'SALES_APP',
'OLTP_GROUP'
);
END;
/
And:
BEGIN
DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING(
DBMS_RESOURCE_MANAGER.SERVICE_NAME,
'REPORTING',
'REPORTING_GROUP'
);
END;
/
The exact mapping attributes available should be checked against the Oracle 19c documentation and your environment.
19. Check Mapping Rules
Use:
SELECT attribute,
value,
consumer_group
FROM dba_rsrc_group_mappings
ORDER BY attribute, value;
This lets you verify what Oracle will use when assigning sessions.
20. Create a Resource Plan
Now create:
PROD_RAC_PLAN
Example:
BEGIN
DBMS_RESOURCE_MANAGER.CREATE_PLAN(
plan => 'PROD_RAC_PLAN',
comment => 'Production RAC workload management'
);
END;
/
21. Add OLTP Directive
For example:
BEGIN
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(
plan => 'PROD_RAC_PLAN',
group_or_subplan => 'OLTP_GROUP',
mgmt_p1 => 60,
comment => 'Critical OLTP workload'
);
END;
/
This example assigns 60% of the first-level CPU allocation.
It does not mean:
“OLTP will always consume exactly 60% CPU.”
Resource Manager becomes especially meaningful under resource contention.
22. Add Reporting
BEGIN
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(
plan => 'PROD_RAC_PLAN',
group_or_subplan => 'REPORTING_GROUP',
mgmt_p1 => 25,
comment => 'Reporting workload'
);
END;
/23. Add Batch
BEGIN
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(
plan => 'PROD_RAC_PLAN',
group_or_subplan => 'BATCH_GROUP',
mgmt_p1 => 10,
comment => 'Batch workload'
);
END;
/
24. Add Other Group
You generally want a catch-all category.
For example:
BEGIN
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(
plan => 'PROD_RAC_PLAN',
group_or_subplan => 'OTHER_GROUPS',
mgmt_p1 => 5,
comment => 'Other workloads'
);
END;
/
The exact directives and percentages should be designed from measured workload requirements, not copied blindly.
25. Validate the Plan
Before activating:
BEGIN
DBMS_RESOURCE_MANAGER.VALIDATE_PLAN(
plan => 'PROD_RAC_PLAN'
);
END;
/
This is a very important step.
Don’t activate a resource plan without validation.
26. Enable the Plan
You can set the database parameter:
ALTER SYSTEM SET RESOURCE_MANAGER_PLAN='PROD_RAC_PLAN' SID='*';
In RAC, using:
SID='*'
is commonly used when you want the parameter applied across instances, subject to the database configuration.
Check:
SHOW PARAMETER resource_manager_plan;
or:
SELECT inst_id,
name,
value
FROM gv$parameter
WHERE name = 'resource_manager_plan';
27. Verify on Every RAC Instance
This is essential.
Run:
SELECT inst_id,
value
FROM gv$parameter
WHERE name = 'resource_manager_plan'
ORDER BY inst_id;
You want to verify the intended configuration across:
RAC1 RAC2 ...
28. Instance Caging
Now we reach another important RAC concept:
Instance Caging
The idea is to limit how much CPU an Oracle instance can consume.
For example:
RAC1 32 physical CPUs
You might configure Oracle to operate with:
CPU_COUNT = 24
Conceptually:
Physical CPU
32
|
+-- Oracle instance capacity
24
This creates a boundary around the instance’s CPU consumption.
29. Why Instance Caging?
Imagine:
RAC1 OLTP + Reporting + Batch
A runaway workload can attempt to consume almost all available CPU.
With appropriate CPU management:
OLTP ↓ Protected Reporting ↓ Controlled Batch ↓ Controlled
This can make performance more predictable.
30. CPU_COUNT
Check:
SHOW PARAMETER cpu_count;
or:
SELECT inst_id,
value
FROM gv$parameter
WHERE name = 'cpu_count'
ORDER BY inst_id;
Example:
INST_ID VALUE ------- ----- 1 32 2 32
31. Don’t Change CPU_COUNT Blindly
This is an area where inexperienced DBAs can cause serious problems.
Before changing CPU-related configuration, understand:
Physical CPUs CPU sockets NUMA VM allocation Hypervisor limits Oracle licensing Parallel execution Resource Manager Workload
A CPU count is not simply:
“Number of CPUs shown by
lscpu.”
32. Linux CPU View
Check:
lscpu
and:
nproc
Also inspect:
cat /proc/cpuinfo
For a VM, verify the actual CPU allocation from the virtualization platform.
33. RAC CPU Balance
Suppose:
RAC1 = 32 CPU RAC2 = 32 CPU
but workload is:
RAC1 → 90% RAC2 → 30%
Don’t immediately add CPUs.
Ask:
Why?
Possibilities:
- Service placement
- Connection load balancing
- Batch workload
- Reporting
- SQL inefficiency
- Data locality
- Application behavior
34. Resource Manager Is Not a Replacement for SQL Tuning
Suppose you have:
SELECT * FROM SALES WHERE UPPER(CUSTOMER_NAME) = :1;
and there is no appropriate index.
Resource Manager can limit the workload.
It cannot make the SQL efficient.
The correct hierarchy is:
SQL efficiency
↓
Data model
↓
Indexes
↓
Execution plan
↓
Workload distribution
↓
Resource controls
Resource Manager protects the system.
It doesn’t eliminate the root cause of inefficient SQL.
35. Parallel Execution Control
This is another important area.
Reporting workloads can use parallel execution:
SELECT /*+ parallel(32) */
...
FROM huge_table;
On a 32-CPU system, several users doing this simultaneously can create a serious problem.
For example:
User 1 → PX 32 User 2 → PX 32 User 3 → PX 32
You can quickly oversubscribe the system.
36. Why PX Is Dangerous
Imagine:
32 CPUs Query A → 16 PX Query B → 16 PX Query C → 16 PX Query D → 16 PX
The theoretical requested parallelism is:
64 PX
on:
32 CPUs
Now combine that with:
OLTP LGWR DBWn CKPT Other background processes
and the system can become CPU constrained.
37. Resource Manager and Parallelism
Resource Manager can be used to control parallel execution behavior.
The exact implementation should be designed around your Oracle version and workload.
The principle is:
OLTP ↓ Limited/controlled PX REPORTING ↓ Higher PX allowance BATCH ↓ Controlled PX
Don’t simply allow every user:
PARALLEL 64
38. Detect Parallel Workloads
Find active parallel sessions:
SELECT inst_id,
sid,
serial#,
username,
sql_id,
event,
degree,
req_degree
FROM gv$px_session
ORDER BY inst_id;
Depending on the release, useful columns can differ, so:
DESC gv$px_session;
is worth checking.
39. Detect High CPU Sessions
A quick real-time query:
SELECT inst_id,
sid,
serial#,
username,
sql_id,
module,
service_name,
event
FROM gv$session
WHERE status = 'ACTIVE'
AND type = 'USER'
ORDER BY inst_id, sid;
Then correlate with:
SQL_ID SERVICE_NAME MODULE INSTANCE
40. ASH: Find CPU Consumers
Historical analysis:
SELECT service_name,
instance_number,
sql_id,
COUNT(*) samples
FROM dba_hist_active_sess_history
WHERE sample_time BETWEEN
:start_time AND :end_time
AND session_state = 'ON CPU'
GROUP BY service_name,
instance_number,
sql_id
ORDER BY samples DESC
FETCH FIRST 50 ROWS ONLY;
This gives you a strong starting point for identifying CPU-heavy SQL.
41. Find Top CPU by Service
SELECT service_name,
instance_number,
COUNT(*) cpu_samples
FROM dba_hist_active_sess_history
WHERE sample_time BETWEEN
:start_time AND :end_time
AND session_state = 'ON CPU'
GROUP BY service_name,
instance_number
ORDER BY cpu_samples DESC;
Example:
SERVICE INSTANCE CPU_SAMPLES ----------- -------- ----------- SALES_APP 1 120000 REPORTING 2 95000 BATCH 2 80000
Now you can see where CPU workload is concentrated.
42. Find CPU-Heavy SQL
SELECT sql_id,
COUNT(*) cpu_samples
FROM dba_hist_active_sess_history
WHERE sample_time BETWEEN
:start_time AND :end_time
AND session_state = 'ON CPU'
AND sql_id IS NOT NULL
GROUP BY sql_id
ORDER BY cpu_samples DESC
FETCH FIRST 20 ROWS ONLY;
Then inspect the SQL:
SELECT sql_id,
sql_text
FROM v$sql
WHERE sql_id = :sql_id;
For historical SQL, use the appropriate AWR SQL views if the cursor is no longer in memory.
43. Runaway Session Detection
Suppose a user launches a query that consumes CPU for hours.
Find long-running active sessions:
SELECT inst_id,
sid,
serial#,
username,
sql_id,
module,
service_name,
last_call_et
FROM gv$session
WHERE status = 'ACTIVE'
AND type = 'USER'
ORDER BY last_call_et DESC;
LAST_CALL_ET gives elapsed time in seconds for the current activity in this context.
44. Don’t Kill Sessions Automatically
A common junior DBA response:
ALTER SYSTEM KILL SESSION ...
But first ask:
Who owns it? What SQL is running? Is it business critical? Why is it slow? Is it blocked? Is it consuming CPU or I/O? Is it part of batch processing?
Resource Manager can provide a more controlled approach than manually killing sessions.
45. Resource Manager as a Safety Net
The architecture should be:
SQL Tuning
|
↓
Good execution
|
↓
Workload Design
|
↓
RAC Services
|
↓
Resource Manager
|
↓
Protect critical work
Each layer has a different job.
46. RAC Resource Management
Now combine everything from the last two parts:
APPLICATION
|
SCAN
|
SERVICE
|
+--------+--------+
| |
RAC1 RAC2
| |
Consumer Group Consumer Group
| |
Resource Manager Resource Manager
| |
CPU CPU
| |
+--------+--------+
|
Cache Fusion
This is the architecture you should have in mind.
47. Practical Production Example
Let’s create four consumer groups:
OLTP_GROUP REPORTING_GROUP BATCH_GROUP ADHOC_GROUP
Business priorities:
OLTP → 60 REPORTING → 20 BATCH → 15 ADHOC → 5
Services:
SALES_APP → OLTP_GROUP REPORTING → REPORTING_GROUP BATCH → BATCH_GROUP ADHOC → ADHOC_GROUP
Then:
PROD
|
Resource Plan
|
+-------------+-------------+
| | |
OLTP REPORTING BATCH
60% 20% 15%
|
ADHOC
5%
This is a policy.
Now you need to test whether the policy produces the desired result.
48. Measuring the Result
Before:
OLTP response time = 2 sec REPORTING = 80% CPU
After Resource Manager:
OLTP response time = 0.8 sec REPORTING = slower
That may be a successful result.
Why?
Because the business requirement was:
Protect OLTP.
Resource Manager is not designed to make every workload equally fast.
49. Important Performance Principle
When implementing Resource Manager, ask:
Which workload should suffer first when resources become scarce?
For example:
CPU shortage
|
+-- OLTP → protected
|
+-- Reporting → slowed
|
+-- Batch → slowed further
|
+-- Ad-hoc → lowest priority
That is a business decision translated into database architecture.
50. RAC Instance Caging Scenario
Suppose:
RAC1 = 64 CPUs RAC2 = 64 CPUs
but RAC1 hosts:
OLTP Reporting Batch
while RAC2 hosts:
OLTP
You might decide to control the CPU capacity of the instances to prevent one workload from consuming everything.
But before changing CPU configuration, analyze:
CPU utilization Service placement Resource Manager PX workload VM allocation NUMA topology
Instance Caging should be a deliberate design decision, not a default setting.
51. Check NUMA
On large physical servers:
numactl --hardware
Example:
available: 2 nodes node 0 cpus: ... node 1 cpus: ...
NUMA topology can influence CPU and memory behavior.
For very large RAC systems, you should understand:
CPU Memory NUMA Oracle processes Parallel execution
before making aggressive resource changes.
52. VM Environments
If RAC runs on VMware, KVM, Oracle VM, or another virtualization platform, also investigate:
vCPU allocation CPU ready time CPU contention NUMA exposure CPU overcommit host contention
A database showing:
32 vCPU
doesn’t automatically mean:
32 physical CPUs available at all times.
53. AWR Resource Manager Analysis
AWR can help identify resource manager activity.
Look for:
DB Time DB CPU CPU utilization Wait classes Resource Manager waits
Depending on your configuration, resource manager-related waits can become visible when sessions are deliberately throttled or queued.
The key is to distinguish:
CPU shortage
from:
Resource Manager intentionally limiting CPU
54. Resource Manager Waits
A session may experience Resource Manager-related waits when it is being throttled.
You can investigate:
SELECT inst_id,
event,
COUNT(*) sessions
FROM gv$session
WHERE status = 'ACTIVE'
GROUP BY inst_id, event
ORDER BY sessions DESC;
Look for events associated with resource management and CPU throttling in your workload.
Don’t diagnose solely from the event name; correlate with CPU utilization and the active resource plan.
55. Production Change Procedure
Never implement a new Resource Manager policy like this:
Create plan ↓ Activate ↓ Hope
Use:
Current-state capture
↓
Workload baseline
↓
Design policy
↓
Create test plan
↓
Validate
↓
Test
↓
Controlled production activation
↓
Monitor
↓
Compare
↓
Adjust
56. Capture Current Configuration
Before changes:
SELECT * FROM dba_rsrc_plans; SELECT * FROM dba_rsrc_plan_directives; SELECT * FROM dba_rsrc_consumer_groups; SELECT * FROM dba_rsrc_group_mappings;
Save the output.
Also:
SELECT inst_id,
name,
value
FROM gv$parameter
WHERE name IN (
'resource_manager_plan',
'cpu_count'
)
ORDER BY inst_id, name;
57. Build a Workload Baseline
Capture:
DB CPU DB Time CPU utilization Active sessions Top SQL Top services Parallel SQL GC waits I/O
For example:
SELECT service_name,
instance_number,
COUNT(*) samples
FROM dba_hist_active_sess_history
WHERE sample_time BETWEEN
:start_time AND :end_time
GROUP BY service_name, instance_number
ORDER BY samples DESC;
58. Resource Manager Audit Script
Here’s a useful starting script:
SET LINESIZE 220
SET PAGESIZE 100
PROMPT ========================================
PROMPT RESOURCE MANAGER PLAN
PROMPT ========================================
SELECT plan,
status,
comments
FROM dba_rsrc_plans
ORDER BY plan;
PROMPT ========================================
PROMPT CURRENT PLAN
PROMPT ========================================
SELECT inst_id,
value
FROM gv$parameter
WHERE name = 'resource_manager_plan'
ORDER BY inst_id;
PROMPT ========================================
PROMPT CONSUMER GROUPS
PROMPT ========================================
SELECT consumer_group,
status
FROM dba_rsrc_consumer_groups
ORDER BY consumer_group;
PROMPT ========================================
PROMPT PLAN DIRECTIVES
PROMPT ========================================
SELECT plan,
group_or_subplan,
mgmt_p1,
mgmt_p2,
mgmt_p3
FROM dba_rsrc_plan_directives
ORDER BY plan, group_or_subplan;
PROMPT ========================================
PROMPT GROUP MAPPINGS
PROMPT ========================================
SELECT attribute,
value,
consumer_group
FROM dba_rsrc_group_mappings
ORDER BY attribute, value;
59. Verify Active Consumer Groups
You can investigate session assignments using:
SELECT inst_id,
sid,
serial#,
username,
service_name,
resource_consumer_group,
status
FROM gv$session
WHERE username IS NOT NULL
ORDER BY inst_id, resource_consumer_group;
This is extremely useful.
You can answer:
Is the application actually being assigned to the consumer group I intended?
60. Example
Suppose:
SALES_APP
is supposed to use:
OLTP_GROUP
But the query shows:
SALES_APP → OTHER_GROUPS
Then your policy isn’t working as intended.
Investigate:
Service name Mapping rule Connection pool Session attributes Mapping priority
Don’t assume Resource Manager is active simply because the plan is enabled.
61. The Expert Diagnostic Chain
When an application becomes slow:
Application
↓
Service
↓
Instance
↓
Consumer Group
↓
Resource Plan
↓
CPU / I/O / PX
↓
SQL
↓
Wait Event
This gives you a much more precise diagnostic model.
62. Example Incident
Application team reports:
“The SALES application is slow between 14:00 and 15:00.”
You check:
SELECT inst_id,
service_name,
resource_consumer_group,
COUNT(*)
FROM gv$session
WHERE service_name = 'SALES_APP'
GROUP BY inst_id,
service_name,
resource_consumer_group;
You discover:
RAC1 SALES_APP OLTP_GROUP
Good.
Then ASH:
SALES_APP SQL_ID = abc123 ON CPU
Then you discover:
REPORTING → huge parallel queries → RAC1
Resource Manager shows:
OLTP_GROUP → protected REPORTING_GROUP → limited
But CPU is still saturated.
Now you investigate:
Parallelism SQL efficiency Service placement CPU capacity
This is the correct approach.
63. Don’t Overuse Resource Manager
Resource Manager is powerful.
But if you create:
20 consumer groups 15 resource plans 30 mapping rules
you may create a configuration nobody understands.
A good production design is usually:
Simple enough to operate, detailed enough to protect critical workloads.
64. Recommended Starting Model
For a typical enterprise RAC:
OLTP_GROUP REPORTING_GROUP BATCH_GROUP OTHER_GROUPS
Then expand only when there is a real business or technical requirement.
65. Part 21 — Final Architecture
We’ve now built this:
USERS
|
↓
SCAN
|
↓
SERVICE
|
↓
CONSUMER GROUP
|
↓
RESOURCE PLAN
|
+----------+----------+
| |
RAC1 RAC2
| |
CPU control CPU control
| |
+----------+----------+
|
SQL workload
|
Cache Fusion
|
Interconnect
This is a much more mature RAC design than simply:
RAC1 + RAC2 + shared storage
66. What You Should Know After Part 21
You should now be comfortable explaining:
Resource Manager
- Consumer groups
- Resource plans
- Resource directives
- Consumer group mapping
- CPU allocation
- Workload priorities
RAC
- Service-based resource management
- Instance-level CPU management
- Instance Caging concept
- RAC workload distribution
- Parallel execution risks
Troubleshooting
- CPU saturation
- Runaway workloads
- Resource Manager waits
- Service imbalance
- ASH workload analysis
- Before/after measurement
The Key Lesson
The most important principle from Part 21 is:
RAC availability and performance are not just about adding more CPUs. They are about controlling who gets those CPUs.
A mature architecture looks like:
Business Priority
↓
Application
↓
Service
↓
Consumer Group
↓
Resource Plan
↓
CPU / Parallelism
↓
SQL
↓
Data
And when you combine this with Part 19 and Part 20:
RAC 19c
|
+---------+---------+
| |
Interconnect Services
| |
Cache Fusion Workload routing
| |
+---------+---------+
|
Resource Manager
|
Workload protection
That is the foundation of enterprise RAC workload engineering.
Google+
Facebook
