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

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

A.
truncate table statements

B.
select statements referring to non-partitioned tables

C.
drop table statements

D.
insert statements where each instance inserts into different partitions of a partitioned table

Explanation:
Concurrent Cross-Instance Calls: Considerations
In data warehouse and data mart environments, it is not uncommon to see a lot of TRUNCATE
operations.
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.
D60488GC11
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 )
Look for:
* 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]