RAMdisk for a virtualized SQL 2008 Enterprise server

We use this product

http://memory.dataram.com/products-and-services/software/ramdisk

Do you use it on a virtualized or a physical server? And for what purpose? Database?

Both physical and virtual, databases, development, rendering, profile storage for terminal servers, for fast retrieval

a free trial version is available for you to try with a small ram drive.

And how customizable is it? Doest it offer any control over the disk properties and data flow towards the physical storage? This is extremely important for us as the guest OS will be hosted on purely ssd based storage and we want to use the ramdisk mainly for reduction of its wear & tear.

There are options to load the ramdisk at the OS start, and regularly save the ramdisk to disk.

I would recommend you download and test, and check out if it meets your requirements.

We are users of the product and we are very happy with it, it meets our requirements.

That sounds good! I've also read a lot about the solution below, as being very good performer and very customizable. Any experience with that product?

http://www.romexsoftware.com/en-us/primo-ramdisk/index.html

I'm afraid not.

Thanks for you help!

Because according to all the research I've done so far, the SQL server does so much reading and writing in small pieces, that the ssd's wear down pretty quickly. The idea behind using the ramdisk is that all most of the r&w is done in ram space and then sent as large chunks to be written to the ramdisk image on the actual ssd. My point is that I do not want to have to buy new drives every few months.

How many data is written per day really to your database?

About reading: doesn't matter. As I said give your SQL Server enough memory to fit the database into memory.

The differences I know: Using SSDs instead of HDDs gives you faster times to a hot cache. Having the normal workload in memory, this will only affect the users at the beginning of the day. Or after a drop clean buffers. Where you can see a diffence: Using SSDs for tempdb. Cause here are physical objects created and must be written to disk. So this gives normally a good speed up. So I would guess this would be also the only area where you may see a performance gain with using RAMdisk.

Here's a last thought: Why not using an hybrid storage array with an large enough write-cache?

What do you think would be a  sufficient amount of write-cache?

And would that be the cache of the raid adapter, or a separate (ssd?) disk dedicated to acting as the cache?

Btw, do you have an actual experience of running the database on ssd's only (in production environment)?

I would go for an out-of-the box product. The necessary amount depends imho on your workloads.

Sorry, I don't follow. Out-of-the-box product for what now? A caching solution or a ramdisk?

We use SSDs in our SAN with no issues, and have SSD caching solutions with no issues, of wear!

Yup, but I'm a database guy, so maybe you need a virtualization hoshi instead. Or a storage gremlin ;)

I'm currently running SSDs in one physical system as tempdb storage. Here I have more write I/O compared to the database and log volumes. But the SSDs are still healthy (running 2 years).

And as a database guy I need to say: Setup a test system to measure it. It depends too often on your concrete workload.

But the most performance with SQL Server is gaind from hot buffers. Use SSDs speed up everything which needs large temp storage, like DW-ETL tasks.

Out-of-the-box hybrid SAN.

With the small database throughput such as ours, there is no gain in using a ramdisk. Providing the SQl server with enough ram should do the trick, while the wear and tear of ssd based storage will be minimal anyway.