I tend to agree and would like to add that the applications I have seen over the last 12 years are not IO bound in spite of well tuned SQL but primarily because of poorly written SQL statements; SQL statements that read or processes more data than is needed to glean the information it wants. At the risk of distorting and generalizing at the same time, I would like to think that most access paths for OLTP systems are likely to be nested loops with index and rowid access paths. To the extent that is true, I would think that that data (index particularly) is in the SGA and consequently in ?real? memory, with the response time component of such an operation bound to the disk io only for the duration of a singleton fetch of the data row served within15-60ms. I am sure there are a number of applications that need sub-sub second response times. I wonder if these applications are better served with a bigger SGA since I would like to think that for singleton reads the vast majority of the time to get the data is in IO call set up and not in retrieving the 2-8k block. I must also wonder if an in memory db like times 10 or a system such as Gemstone are better suited for these applications Long story short, all that rant is about two questions, in my mind 1. Would that $5k would be a worthwhile spend given today?s advancements in disk caches and disk technologies vis-à-vis OLTP systems using a conventional RDBMS? 2. And as Dan indicated below, would it solve the fundamental problem that is plaguing the application Regards, -Krish _____ From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Dan Norris Sent: Sunday, January 06, 2008 3:11 PM To: j.velikanovs@xxxxxxxxx; oracle-l Subject: Re: Flash technology based HDD will it make significant difference for OLTP applications? Hi Jurijs, I don't have any direct experiences to share, but I can say that I have talked to a lot of customers about memory-based storage in the past. The biggest problem I've seen when memory-based storage is considered is that the "solution" is considered before determining what the problem is. That is, if you have a CPU bottleneck, then making the storage faster is not likely to make a positive impact (in fact, possibly a negative impact). If storage latency is your primary issue, then making the disk service time shorter will likely make a big difference. I'm also interested in hearing real-world experiences as I've only talked about this--not implemented it. In most of the cases that I've encountered, I ended up talking the customer out of making a memory-based storage purchase because it wouldn't have addressed the issue that they were trying to solve at the time. I always add the caveat that tuning is an iterative process, so it is likely that eventually storage will become the bottleneck and it may be worth considering such a purchase at that time.