Yes, you need a face to face for exadata...

No, that is not exadata's whole deal.

You have 8 pretty good but not huge boxes
With enough IO horsepower to get you to the moon and back
And the ability to use that IO horsepower due to the infiniband connections
And the offloading of predicates to the storage
And the flash cache
And the storage indexes
And the hybrid columnar compression...

All before you get to RAC, if you want it. It is not necessary, it is not mandatory, you can certainly use it - the machine takes full advantage of it - but you don't need to.

Exadata is also a consolidation platform - it is a big machine capable of running lots of applications. It takes a singularly huge application to mandate an entire exadata machine - most of them run many things.

A single node in there is larger than many (I might even say most) peoples needs for a given instance.

see also:
http://www.oracle.com/technetwork/issue-archive/2012/12-mar/o22asktom-1518271.html




you use indexes to return a small number of rows

you use indexes on exadata to return a small number of rows


you use full scans (and hopefully partition pruning, compression, etc) to return more than a small number of rows from a row source.

you use full scans in all systems (and hopefully partitioning pruning, compression, etc) to return more than a small number of rows from a row source.


is the function result cache useful *in any system*? sure, if you have functions that take a measurable amount of time, can be cached, use data that changes slowly (so the cache is not invalidated rapidly) and are called frequently.

is the query result cache useful *in any system*? sure, if you have a query that takes a large set of data, turns it into a smallish set of data and is executed over and over and over again.

and so on - yes, every single feature of the database could be useful in exadata.



If you are doing OLTP - you *better* be using indexes.

If you are doing warehousing - you probably will use less indexes than you did before. IO is not going to be your bottleneck so much here, with query offloading, with tons of current generation cpus, with hundreds of gigabytes of SGA, terabytes of flash - your queries will run significantly differently than they did in the past.

the biggest things you'll have to change (after determining what indexes are actually necessary) will be:

o removal of slow by slow processing, if you have an ETL process that uses row by row (slow by slow) - erase it, start over, use bulk SQL, watch:

http://tinyurl.com/RWP-DW-PART1
http://tinyurl.com/RWP-DW-PART2
http://tinyurl.com/RWP-DW-PART3
http://tinyurl.com/RWP-DW-PART4

o get your resource management under control - you'll have things that used to wait on IO *not* wait on IO. If you try to run hundreds/thousands of things concurrently - you'll melt down (cpu will be your scarce resource) Watch:

http://tinyurl.com/RWP-OLTP-CONNECTIONS

for OLTP and part4 from above for warehousing example

o make sure your programmers know the basics:

http://tinyurl.com/RWP-OLTP-PARSING

No, it doesn't need to be. full scans that bypass the buffer cache are "smart scans", totally transparent to the database engine. the flash cache is 100% transparent to the database engine.