Reg: Exadata and /*+ FULL */ hint -

Question

Hi Experts,
Recently, our database got migrated to Exadata environment, and a DBA told me that using the /*+ FULL */ hint in the query increases the query performance.
Doubt -
1) Does it actually enhance performance?
2) I read some articles and got some information that Exadata does some kind of "Smart Scan" and "Cell Offloading" which makes the query efficient. But how does FULL hint contribute here?
This links talks something about this, but not sure if correct - Some Hints for Exadata SQL Tuning - Part III - SQL Optimizer for Oracle - SQL Optimizer for Oracle - Toad World
Please share your thoughts and advise.
Thanks and Regards,
-- Ranit
( on Oracle 11.2.0.3.0 - Exadata )

Answer 1

Ranit -
Lots of good advice given by others. A little more to add to the comments already made...
Using a full hint as a general tuning rule on Exadata would not be a good idea, just like the sometimes proposed notion of dropping all indexes on Exadata to performance is not a good idea. As Mohamed mentions, a key performance optimization for Exadata are the smart scans, which do require direct path reads. Pushing for smart scans is what drives these types of ideas; because, other than the index fast full scan, index scans will not smart scan. However, smart scanning isn't always faster. OLTP type queries that are looking for one or two rows out of many are still usually faster with an index even on Exadata. If you find using a hint like FULL does improve a query's performance, then just as with using hints in general, it's better to determine why the optimizer is not picking the better execution plan, a full table scan in this case, in the first place; and resolve the underlying issue.
What you will probably find is you are over-indexed on Exadata. If you have control of the indexes in your environment, test by making certain indexes invisible and seeing if that helps performance. Indexes that were created to eliminate a percentage, even a large percentage, of rows, but not almost all rows for queries are candidates to be dropped. You definitely want to tune for direct path reads.
This is done by doing index evaluations as described; making sure your stats are accurate and up-to-date; as mentioned by Franck, be sure to gather the Exadata system stats - as this is the only thing that helps the optimizer be Exadata aware. And also, especially if you are running a data warehouse workload, you can look into using parallelism. Running queries in parallel, often even with a degree as little as 2, will help prompt the optimizer to favor direct path reads. Parallelism does need to be kept in check. Look into using the DBRM to help control parallelism - possibly even enabling parallel statement queuing.
Hopefully these will give you some ideas of things to look at as you enter the realm of SQL Tuning on Exadata.
Good luck!
-Kasey