There are 2 more features that I wanted to present :
For the most part this feature is going to help with read-only/read-mostly workloads because DBSFC is a read-only cache extension. It contains clean blocks that got kicked out of the buffercache/sga and now first get placed in this extended cache. A subsequent read can then be from this fast storage instead of from the originating datafiles. When a block gets modified, it's modified in the standard database buffer cache, written to disk and copied over into the flash cache.
The white paper referenced above provides the details on how to use it and how to configure it in an Oracle Linux environment. You simply specify DB_FLASH_CACHE_FILE and DB_FLASH_CACHE_SIZE and that's it. Any Oracle Database customer using Oracle Linux can make use of this.
It works like this : as an admin you set up a cgroup, give it a name and set up paremeters around which cpu's to use, how much memory to allocate and so forth. The name is really just a simple mkdir in the cgroups virtual filesystem. You then use a new database init parameter process_group_name and when you start the database it will put its processes and as such its resources into that group. alter system set processor_group_name = 'cgroup_name' scope=spfile;. You can do this for each instance and this way you can isolate cpu and memory resources for each instance on a given OS environment. If you use Oracle Linux 5 with uek/uek2 or Oracle Linux 6 with uek/uek2 you can make use of this.
cgroups with Oracle Linux 5 and UEK/UEK2 has to happen manually, through mkdir and echo > controlfiles. In Oracle Linux 6 we have cgroup management utilities.
two more reasons :)...