Flash Disks for TEMP space

Question

Hi,
I have noticed that whenever a SQL statement needs to make heavy use of TEMP (GROUP BY, SORT, Etc.) with large amounts of data (2GB up to 50GB) execution time slows considerably. A large part of that time (As reported by OEM SQL-MONITOR) is waiting on reads/writes to TEMP. It occured to me that I could cut off a portion of my cell flash, configure it into grid disk, and create a small disk group for Flash temp space. This wouldn't need to be mirrored, as it is TEMP space. Has anybody tried this? (This is a data warehouse with a large amount of data, so it's not unusual for queries to use 5GB to 10GB of TEMP).
Thanks,
Doug

Answer 1

All,
Well, I had a chance to test this & it actually works very well. The first thing I found was that it is very fast & easy to configure some of the flash into grid disks, and there is no need to even take the databases down or cycle them. On each Cell (using DCLI lets it all be scripted up) you simply drop the flash cache, recreate it smaller, and configure the rest into grid disk. (Reversing it is just as easy). Then, since TEMP does not need to be mirrored, you simple create a disk group specifying External redundancy. Create a TEMP tablespace in this disk group, and you are off and running.
I created a simple SQL that did a GROUP BY and SORT on 10 columns of a 500M row table. That SQL ran 1min, 5 secs using hard disk TEMP and 1 minute flat using flash temp. I ran these repeatedly, and the timings were consistent. This wrote 4GB to TEMP. Then I doubled the amount of data by doing a UNION ALL of the table with itself (in an inline view). This wrote 8GB to TEMP, and the difference between hard and flash temp times grew to about 15 secs. I doubled this a few more times, and the more data written to TEMP, the larger the improvement in run times. (I don't think writes to flash are slower than writes to hard disk ... they seem to be faster. The Oracle engineers would have to answer that one, but the statistics from OEM show the writes to flash TEMP as being faster than to hard disk ... particularly as the volume of data gets larger).
In any event, we have some processes that rebuild a large number of MVs at a time (requiring about 400GB of TEMP). I'm looking at putting someting in place to build a flash TEMP to support this load, and then drop it when the load is complete. We'll try it manually first ... I think we may be looking at cutting significant time off the process.
Thanks,
Doug