Introduction

When you design or manage an Oracle RAC environment, one of the most important architectural decisions you will make is choosing between:

Policy-Managed vs Administrator-Managed

This choice directly affects how your database services are deployed, how workloads are balanced, and how easily your environment scales in the future.

In Oracle RAC 19c and beyond, understanding Policy-Managed vs Administrator-Managed databases is essential for DBAs who want to build flexible, scalable, and highly available systems.

In this guide, we’ll break everything down in a simple, practical way so you can clearly decide which model is best for your environment.

---

What is Administrator-Managed RAC?

In an Administrator-Managed RAC database, the DBA explicitly defines:

• Which instance runs on which node
• Where each service runs
• Preferred and available nodes

👉 Everything is manually controlled

Key idea:

DBA directly maps database instances to specific cluster nodes

---

How Administrator-Managed Works

Example cluster:

Node1 → Instance DB1_1  
Node2 → Instance DB1_2  
Node3 → Instance DB1_3

Services are defined like:

• Preferred nodes → Node1, Node2
• Available nodes → Node3

If Node1 fails → service moves to Node3

👉 DBA defines all this manually

---

Advantages of Administrator-Managed

✔ Simple to understand
✔ Predictable behavior
✔ Good for small clusters
✔ Easier for legacy applications

---

Limitations

❌ Hard to scale
❌ Manual reconfiguration needed
❌ Not flexible for dynamic workloads
❌ Less automation

---

What is Policy-Managed RAC?

A Policy-Managed RAC database removes node-specific mapping and uses server pools instead.

👉 Instead of assigning instances to nodes, you assign them to server pools

🧠 Key idea:

Oracle decides where instances run based on policies

---

How Policy-Managed Works

Example cluster with 6 nodes:

You create a server pool:

Server Pool: OLTP_POOL
Cardinality: 3

This means:

👉 3 nodes from the cluster will run the database instances

But you do not specify which nodes

Oracle Clusterware automatically chooses nodes based on availability and load.

---

Services in Policy-Managed RAC

Services are defined using:

• Server pools
• Cardinality
• Service role

Example:

srvctl add service -db CDB1 -service SALES \
-serverpool OLTP_POOL -cardinality UNIFORM

👉 The service will run across all instances in the server pool

---

Policy-Managed vs Administrator-Managed – Key Differences

Feature	Administrator-Managed	Policy-Managed
Instance placement	Fixed to nodes	Dynamic via server pools
Service placement	Node-based	Server pool-based
Scalability	Limited	Highly scalable
Automation	Low	High
Best for	Small / static environments	Cloud / large dynamic environments
Workload balancing	Manual	Automatic

---

When Should You Use Administrator-Managed?

Choose Administrator-Managed when:

• You have a small cluster
• You want full manual control
• Your workload is stable
• You are supporting legacy systems
• You want predictable node-specific behavior

👉 Example: Banking system with strict node allocation

---

When Should You Use Policy-Managed?

Choose Policy-Managed when:

• You have large RAC clusters
• You need elastic scaling
• You want automatic workload distribution
• You are using Oracle QoS Management
• You run cloud or modern applications

👉 Example: SaaS application with dynamic load

---

How Failover Works in Both Models

Administrator-Managed

• Service fails over to predefined available node

Policy-Managed

• Oracle automatically chooses best node in server pool

👉 More intelligent and flexible

---

Integration with QoS (Quality of Service)

One major advantage of Policy-Managed RAC is its integration with QoS Management.

QoS can:

• Move servers between pools
• Adjust workload dynamically
• Improve response times

👉 This is not possible in Administrator-Managed RAC

---

Real-World Scenario

Let’s say you have:

• 8-node cluster
• Mixed workloads (OLTP + Reporting)

With Administrator-Managed:

• You must manually assign nodes
• Hard to rebalance load

With Policy-Managed:

• Create two server pools:

OLTP_POOL → 5 nodes  
REPORT_POOL → 3 nodes

👉 Oracle automatically distributes workload

---

Migration from Administrator to Policy-Managed

Oracle allows you to convert an existing RAC database:

srvctl modify database -db mydb -policy MANAGED

But it requires:

• Proper server pools
• Service reconfiguration
• Testing

---

Performance Considerations

Administrator-Managed

✔ Good for fixed workloads
❌ Risk of node overload

Policy-Managed

✔ Better load balancing
✔ Better scalability
✔ Better resource utilization

---

Monitoring Both Models

DBAs can monitor using:

srvctl config database
srvctl status database
crsctl stat res -t

And views like:

• GV$ACTIVE_SERVICES
• GV$INSTANCE
• DBA_SERVICES

---

Easy Way to Remember

Here’s a simple trick:

Administrator-Managed → DBA decides
Policy-Managed → Oracle decides

---

Conclusion

Choosing between Policy-Managed vs Administrator-Managed RAC is a key architectural decision.

Both models have their place:

✔ Administrator-Managed → simple, stable, predictable
✔ Policy-Managed → flexible, scalable, automated

For modern environments, Policy-Managed RAC is the recommended approach because it supports:

• Dynamic scaling
• QoS integration
• Cloud-ready deployments

Understanding Policy-Managed vs Administrator-Managed will help you:

• Design better RAC architectures
• Improve performance
• Simplify cluster management
• Build future-ready systems