Oracle RAC Interview Questions: 25 Scenarios With Answers

Published Aug 2026 · 11 min read

RAC is where Oracle DBA interviews get decided. Single-instance questions separate the prepared from the unprepared; RAC questions separate people who have actually run a cluster from people who have read about one. Panels know this, so they push until you either show real operational detail or run out.

Below are 25 questions that come up again and again, grouped the way an interview actually flows — architecture first, then the interconnect, then failure handling, then day-2 operations. Each answer is written the way you should say it out loud: the short version first, then the detail that proves you have done it. Commands shown were verified against Oracle 19c Grid Infrastructure.

Architecture: the opening five

1. What actually makes RAC different from a single-instance database?

One database, many instances. The datafiles, control files and redo threads sit on shared storage, and two or more instances on separate servers mount that same database concurrently. Everything else follows from that: you need a cluster layer to decide who is a member, shared storage every node can write to, and a coordination mechanism so two instances never hand out conflicting versions of the same block. Say the last part — most candidates stop at "multiple instances" and never mention consistency.

2. What is Grid Infrastructure, and how is it different from the database home?

Grid Infrastructure is a separate Oracle home containing Oracle Clusterware (node membership, resource management, failover) and Oracle ASM (volume management). It starts before the database and owns the cluster resources — VIPs, SCAN listeners, ASM instances, database and service resources. The database home is just the RDBMS binaries. They patch on separate schedules, and in most shops Grid Infrastructure runs at an equal or higher patch level than the database.

3. What is a SCAN and why does it exist?

The Single Client Access Name is one hostname that resolves to three IP addresses in round-robin. It exists so clients never need to know node names. Add or remove a node and the client connect string does not change — that is the whole point. Three addresses is the recommendation regardless of cluster size; it gives redundancy without tying clients to specific hardware.

4. Walk me through how a client connection actually reaches an instance.

The client resolves the SCAN name and gets one of the three SCAN IPs. It contacts that SCAN listener. The SCAN listener knows which instances offer the requested service and how loaded each one is, because every instance registers with it — LREG does this in 12c and later, PMON in older releases. The SCAN listener then redirects the client to the local listener on the chosen node, and the client makes a second connection there. Interviewers listen for the redirect: the SCAN listener does not proxy the session, it hands it off.

5. SCAN listener versus local listener — what is the real difference?

The SCAN listener is a routing tier. It runs on up to three nodes, accepts the initial connection and redirects. The local listener runs on every node, listens on that node's VIP, and is what actually hands the session to an instance. If your local listener is down, the SCAN listener will simply route elsewhere; if all local listeners are down, connections fail even though SCAN answers. We covered this in more depth in SCAN listener vs local listener.

Cache Fusion and the interconnect

6. Explain Cache Fusion in your own words.

When an instance needs a block that another instance already has in its buffer cache, it does not read it from disk — the holding instance ships it across the private interconnect. Global Cache Service tracks which instance masters each block and grants access modes. The practical consequence: a healthy RAC does far more memory-to-memory transfer than disk I/O, and interconnect latency becomes a first-class performance factor.

7. What is a gc wait, and when is it a problem?

Any wait event beginning gc is a session waiting on a global cache operation. They are normal — you will never see zero. They become a problem when they dominate your top waits or when the average wait climbs. A block transfer over a healthy interconnect should complete in well under a millisecond; consistent multi-millisecond averages point at the network, not the database.

8. Difference between gc cr block and gc current block?

A CR (consistent read) block is a read-consistent version built for a query at a specific SCN. A current block is the live block, requested because the session intends to modify it. Heavy gc current block traffic usually means the same blocks are being updated from multiple nodes — classic hot-block contention that you fix with partitioning, sequence caching, or by routing that workload to one node via services.

9. How do you check what the interconnect is actually using?

Do not trust the documentation of the server build; ask the database. If it reports a public interface, someone has misconfigured the cluster and you are pushing cache traffic over the public network.

-- what interface is Cache Fusion really using?
SELECT name, ip_address, is_public FROM v$cluster_interconnects;

-- where is global cache time actually going?
SELECT event, total_waits, ROUND(time_waited_micro/1e6,1) AS sec_waited
FROM   v$system_event
WHERE  event LIKE 'gc %'
ORDER  BY time_waited_micro DESC
FETCH  FIRST 10 ROWS ONLY;

10. What happens when the interconnect saturates?

Block transfers queue, gc waits climb, and sessions across every node slow down together — that "everything is slow but no single query is slow" symptom. Left long enough, heartbeat traffic itself is delayed and you move from a performance problem to an availability problem, because delayed heartbeats are exactly what triggers eviction. Mentioning that link between interconnect health and eviction is a strong signal in an interview.

Node eviction: the question that separates seniors

11. What causes a node eviction?

Broadly three things: the node stops answering the network heartbeat across the interconnect, it stops writing its disk heartbeat to the voting files, or a critical clusterware process fails. Resource starvation is the usual root cause behind all three — a node paging heavily or with a hung storage path cannot heartbeat on time even though it looks "up" from the outside.

12. Which timeouts govern that?

Two you should know by name. misscount is how long a node can miss the network heartbeat before it is evicted — 30 seconds in a standard RAC install. disktimeout governs the voting disk heartbeat and defaults to 200 seconds. Interviewers like candidates who add the warning: do not change these to mask a storage or network problem, because you are extending the window in which split brain could occur.

13. What is split brain, and how does RAC prevent it?

Split brain is two sets of nodes each believing they are the surviving cluster, both writing to the same datafiles — guaranteed corruption. RAC prevents it with quorum on the voting files. When the cluster fragments, the group that can see a majority of voting disks survives; the minority evicts itself. That is why voting files come in odd numbers.

14. How many voting disks should you have, and where do they live?

They live in an ASM diskgroup, and the count follows that diskgroup's redundancy: external gives you one, normal gives three, high gives five. You want an odd number so a majority always exists. Put the voting diskgroup on storage that fails independently of your data — a shared array that takes everything down with it defeats the purpose.

15. A node just evicted. Where do you look, in order?

Start with the clusterware alert log, then the CSS daemon trace, then the operating system log — in that order, because each one narrows the window. Note that the path moved: 12c and later use the ADR-style location under $ORACLE_BASE, while 11g kept logs under the Grid home.

# 12c and later
$ORACLE_BASE/diag/crs/<hostname>/crs/trace/alert.log
$ORACLE_BASE/diag/crs/<hostname>/crs/trace/ocssd.trc

# OS side - look for memory pressure, storage path loss, NIC flaps
/var/log/messages

# cluster state right now
crsctl check cluster -all
crsctl stat res -t
olsnodes -n -i -s -t

ASM and shared storage

16. Why does RAC need shared storage, and what are the options?

Every instance mounts the same database, so every node must be able to read and write the same datafiles, control files and redo. In practice that means ASM on shared LUNs, or a certified cluster file system. ASM is the norm because it handles striping, mirroring and rebalancing without a separate volume manager, and Oracle supports it end to end.

17. What are ASM redundancy levels?

External means ASM keeps one copy and trusts the storage array's own RAID. Normal keeps two copies across failure groups. High keeps three. The choice is about which layer you trust to survive a failure — if the array already mirrors, external avoids paying for the same protection twice.

18. What actually happens when a diskgroup fills up?

Writes start failing and the database will hang or crash depending on what could not be written. The subtlety worth mentioning: with normal or high redundancy you must keep enough free space to survive a disk failure and rebalance — that is what REQUIRED_MIRROR_FREE_MB and USABLE_FILE_MB tell you. A diskgroup showing free space can still be unable to tolerate a failure.

19. How do you add a disk safely?

Add it and control the rebalance power. Higher power finishes faster but competes with your workload for I/O, so on a busy system you start low and raise it during a quiet window.

-- add a disk and rebalance gently
ALTER DISKGROUP DATA ADD DISK '/dev/oracleasm/disks/DISK5' REBALANCE POWER 3;

-- watch it
SELECT group_number, operation, state, power, est_minutes FROM v$asm_operation;

-- can this diskgroup still survive a disk loss?
SELECT name, type, total_mb, free_mb, required_mirror_free_mb, usable_file_mb
FROM   v$asm_diskgroup;

20. Where do OCR and the voting files actually sit?

Both live in ASM in a modern install. OCR holds the cluster configuration — resources, their dependencies and their current state. Voting files hold membership. Check OCR health with ocrcheck and list voting files with crsctl query css votedisk. Being able to name the two and say what each stores is a fast credibility win.

Day-2 operations they will probe

21. Start and stop the stack in the right order?

Going down: services, then database instances, then ASM if you are doing it by hand, then clusterware. Coming up: clusterware first, and it brings the rest according to the resource dependencies stored in OCR. In practice you rarely stop ASM manually — you stop the database and let crsctl stop crs take the rest.

# graceful, one node
srvctl stop service -db orcl -service oltp_svc -node node1
srvctl stop instance -db orcl -instance orcl1

# whole stack on this node (as root)
crsctl stop crs
crsctl start crs

# verify services landed where you expect
srvctl status service -db orcl
srvctl relocate service -db orcl -service oltp_svc -oldinst orcl1 -newinst orcl2

22. How do you patch a RAC cluster with zero downtime?

Rolling patching with opatchauto: it patches one node at a time while the others keep serving. Services relocate off the node being patched, the node is patched and restarted, then you move to the next. The honest caveat, which interviewers want to hear: not every patch is rolling-installable. Check the patch README first — if it is not certified for rolling application, you need an outage, and saying so shows you have actually read one.

23. How do you add a node to an existing cluster?

Prepare the new server to match the existing nodes exactly — OS packages, kernel parameters, users and groups, network, storage visibility. Run cluvfy to confirm it is ready, extend Grid Infrastructure with addnode.sh, then extend the database home and add the instance. Ninety percent of failures here are prerequisite drift between the new node and the old ones, which is why cluvfy exists.

24. TAF, FAN, FCF — what is the difference and which do apps really use?

TAF is client-side failover configured in the connect string; it can re-establish a session and even resume a running query, but it cannot replay a transaction. FAN is the event stream the cluster publishes when something changes. FCF is a client subscribing to FAN so it can react immediately instead of waiting for a TCP timeout. Modern application stacks mostly use FCF through a connection pool; the pool tears down dead connections the moment the FAN event arrives. If asked what you would recommend today, say Application Continuity where the driver supports it, because it is the only option that can replay in-flight work.

25. How do you prove a service actually failed over correctly?

Do not answer "I check the alert log". Say you test it: relocate the service deliberately, confirm with srvctl status service that it moved, and confirm from the application side that existing connections were re-established rather than left hanging. Then check v$session on the target instance to see sessions actually arrived. Interviewers are testing whether you verify or assume.

What panels are really testing

Notice the pattern across all 25. Almost none of these reward memorised definitions. They reward three things: knowing which component owns a behaviour, knowing where to look when it breaks, and knowing the caveat that makes the textbook answer wrong in production. When you are unsure of a specific number, say the mechanism and admit the number is configurable — that reads as honest, whereas a confidently wrong default reads as guessing.

Two habits help more than extra reading. Build a two-node cluster yourself, even a virtualised one, and break it on purpose: pull the interconnect, fill a diskgroup, kill a node hard. And practise saying answers aloud, because the gap between knowing a thing and explaining it under pressure is where most candidates lose the offer.

If you want that hands-on exposure with a real cluster rather than slides, our live Oracle RAC training builds a working two-node cluster from scratch and puts you through the failure drills above. You can also read what past students went on to do in our Oracle DBA success stories, or browse the full Oracle RAC course syllabus. For authoritative reference, Oracle's Real Application Clusters Administration and Deployment Guide is the document to keep open.