Which two completely prevent a Smart Scan from occurring?
A.
querying a table containing many chained rows
B.
querying a table containing many migrated rowsC. performing a minimum or maximum function on an indexed column
D.
performing a Fast Full Index scan on a reverse key index
E.
referencing more than 255 columns form an OLTP compressed table in a query
F.
querying a table containing a JSON column
Explanation:
B: Migrated Rows is a special case of chained rows. Migrated rows still affect performance, as they do in conventional storage situations, but with the additional overhead of reducing the beneficial effects of “Smart
Scan” in addition to increasing the number of I/Os
E: Smart Scans – broadly speaking and ignoring edge cases – can only transport a maximum of 254 columns from a single (non-HCC) segment. Requesting more columns will simply disable Smart Scans for that segment.
An interesting limitation to Exadata Smart Scans – if more than 254 columns from a table (not HCC
compressed, more on that in moment) need to be projected, Smart Scans for that particular segment will be disabled and Exadata will fall back to conventional I/O. This means that the number of columns in the projection clause can make a significant difference to performance, since only Smart Scans allow taking advantage of offloading and particularly avoiding I/O via Storage Indexes.
Incorrect Answers:
A: Smart scan can cope with some cases of chained rows
References: http://oracle-randolf.blogspot.se/2013/01/exadata-smart-scan-projection-limitation.html