Shown: Select two reasons why the statement would have produced so many “cell single block physical read” waits compared to “cell smart table scan” waits.

You are monitoring and evaluating a create index statement on your Database Machine and have
run the following query after executing statement, providing the output. Shown:

Select two reasons why the statement would have produced so many “cell single block physical
read” waits compared to “cell smart table scan” waits.

A.
There are huge numbers of migrated rows in the table on which the index is being built.

B.
There is an uncommitted transaction that has modified one block of the table on which the
index is being built, in each cell.

C.
Thereis a transaction that has modified one block of the table on which the index is being built
in each cell, which committed after the create index began.

D.
There are huge numbers of chained rows in the table on which the index is being built.

E.
There is a ROWID column in the table on which the index is being built.

Explanation:
A:It could be that row migration.
D:It could be that row migration or chained rows could cause it.
Note:
*Some facts about scans:
Scans exists in “OLTP” systems
Exadata smart scan requires a direct path read.

A direct path read is chosen at runtime based on internal heuristics
The STORAGE clause in an explain plan doesnt necessarily mean you
will perform a smart scan.
*The buffer caching in certain “OLTP” environments can
occasionally induce conventional reads when smart
scan is faster.
*Typically see cell multiblock physical read instead of cell
smart table scan waits
*No one-size-fits-all solution can be given here but it is
very fixable.