There is a new configuration in DBMS_STATS that can help Oracle to understand that it is working on an Exadata.
Most of the time the FULL TABLE SCAN is more performant than an INDEX SCAN on Exadata systems (i say most of the time, so i mean you have to test by yourself). The problem of this is with default system stats.
With the default system stats does not know that a FTS may be less expensive than accessing an index.
To help Oracle to know it is working on a EXADATA system there is a new GATHER_SYSTEM_STATS mode exclusively for EXADATA.
To enable this new mode you have to execute the following command
This new mode is available from the 126.96.36.199.18 or 188.8.131.52.8 (nore information on Metalink note Oracle Sun Database Machine Setup/Configuration Best Practices [ID 1274318.1])
I have recently hit a bug (that seems to be fixed in the BP6 for Exadata)
But i thought it was interesting to post about this (it may help someone)
When you have a table that is compress, you need to be carefull with Extended statistics cause it had a virtual hidden column to manage those stats. Right now there is no problem, the problems start when you drop the extended stats and try to use incremental stats on the table.
When you drop the extended stats it does not remove the virtual hidden column (first problem) it just set the column as UNUSED because of the compression.
My issue cames from this and the use of the incremental stats which had a bug and does not know anything about UNUSED columns. So each time i was trying to gather stats on the table Oracle was gathering all the stats again and again because it was finding that this UNUSED column did not get any stats…..