Which two actions in a warehousing RAC database may cause concurrent cross-instance calls leading to I/O contention?

The correct answer is A. truncate table statements C. drop table statements. Concurrent Cross-Instance Calls: Considerations In data warehouse and data mart environments, it is not uncommon to see a lot of TRUNCATE These essentially happen on tables containing temporary data. In a RAC environment, truncating tables concurrently from different instances…

Manage Global Resources

Question

Options

Atruncate table statements
Bselect statements referring to non-partitioned tables
Cdrop table statements
Dinsert statements where each instance inserts into different partitions of a partitioned table

How the community answered

(49 responses)

A
82% (40)
B
14% (7)
D
4% (2)

Explanation

Concurrent Cross-Instance Calls: Considerations In data warehouse and data mart environments, it is not uncommon to see a lot of TRUNCATE These essentially happen on tables containing temporary data. In a RAC environment, truncating tables concurrently from different instances does not scale well, especially if, in conjunction, you are also using direct read operations such as parallel queries. As shown in the slide, a truncate operation requires a cross-instance call to flush dirty blocks of the table that may be spread across instances. This constitutes a point of serialization. So, while the first TRUNCATE command is processing, the second has to wait until the first one completes. There are different types of cross-instance calls. However, all use the same serialization mechanism. For example, the cache flush for a partitioned table with many partitions may add latency to a corresponding parallel query. This is because each cross-instance call is serialized at the cluster level, and one crossinstance call is needed for each partition at the start of the parallel query for direct read purposes. Oracle 11g: RAC and Grid Infrastructure Administration Accelerated 14 ?27 What Application Design considerations should I be aware of when moving to Oracle RAC? The general principals are that fundamentally no different design and coding practices are required for RAC however application flaws in execution or design have a higher impact in RAC. The performance and scalability in RAC will be more sensitive to bad plans or bad schema design. Serializing contention makes applications less scalable. If your customer uses standard SQL and schema tuning, it solves > 80% of performance problems Some of the scaleability pitfalls they should look for are: * Serializing contention on a small set of data/index blocks --> monotonically increasing key --> frequent updates of small cached tables --> segment without automatic segment space management (ASSM) or Free List Group (FLG) * Full table scans --> Optimization for full scans in 11g can save CPU and latency * Frequent invalidation and parsing of cursors --> Requires data dictionary lookups and synchronizations * Concurrent DDL ( e.g. truncate/drop ) * Indexes with right-growing characteristics --> Use reverse key indexes --> Eliminate indexes which are not needed * Frequent updated and reads of "small" tables --> "small"=fits into a single buffer cache --> Use Sparse blocks ( PCTFREE 99 ) to reduce serialization * SQL which scans large amount of data --> Perhaps more efficient when parallelized --> Direct reads do not need to be globally synchronized ( hence less CPU for global cache ) RAC: Frequently Asked Questions [ID 220970.1]

Topics

#DDL contention#cross-instance calls#I/O contention#cache fusion

Community Discussion

Mateus R.Mar 17, 2026

Think of a shared office whiteboard that every department has copied onto their own notepad, then someone erases the whole board, now every department has to throw out their copy and redraw from scratch at the same time. That is exactly what TRUNCATE (A) and DROP (C) do in a RAC environment, they are DDL operations that force a global checkpoint and block invalidation across every node simultaneously, so each instance has to coordinate, flush cached blocks, and invalidate shared pool entries all at once, which piles up cross-instance calls and hammers I/O. B and D involve data reads and partition-local writes that RAC handles with far less global drama.

Ingrid P.Mar 18, 2026

The whiteboard analogy captures the broadcast invalidation well, but worth noting that TRUNCATE reclaims space by resetting HWM and deallocating extents, while DROP goes further and removes the segment entirely, so the cross-node coordination overhead is similar in kind but the recovery implications differ meaningfully if something goes wrong mid-operation.

Lena V.Mar 8, 2026

Both truncate and drop table statements trigger cross-instance calls because they require a global checkpoint and block invalidation across all RAC nodes, forcing every instance to flush and synchronize, which hammers shared I/O. Why do you think partition-level inserts on different instances avoid that contention, and what does that tell you about the granularity at which RAC coordinates buffer cache invalidation?

Ingrid P.Mar 23, 2026

A and C are right, both force global locks across all RAC instances.

Full 1Z0-058 Practice