MS SQL 2008 all on RAM?
Solution 1:
It depends what you mean by "all in RAM".
If you are wanting to run your database from a RAM drive you will find that this is unlikely to be possible (unless you have some sort of RAM drive card that looks to the OS like a normal disk, i.e. presents a SATA or PATA interface) as SQL Server will refuse. It assumes any data it writes is important enough to keep and will not risk it by writing it to a volatile storage medium. You might be able to fool it by running it in a VM and running that VM from a RAM drive, but I would not recommend trying this both for the same reason (you loose all the data if a power-loss or reboot situation occurs) and due to the fact there would be a collection of other performance hits from the virtualisation solution to worry about.
If your problem is slow read activity (i.e. a lot of operations that result in reading from disk, then just increase the amount of RAM in the machine to be larger than the usual working set or better still larger than the whole database. This way, unless you have an edition of SQL Server that imposes artificial RAM limits (IIRC Express Edition will not use more than 1Gb), it will use the abundance of memory to keep anything it reads cached in RAM where it can be read quickly next time it is needed. If you wish to pre-load the data into RAM any time after it is cleared (i.e. after a reboot due to installing updates) then you can write a script that forces all index and data pages to be scanned and therefor read into memory.
If the problem is due to many write operations, then optimising your disk layout may help. Without knowing more about your database we can't give specific hints, but the standard rules of thumb (like try keeping your data files, transaction logs and tempdb on separate physical drives) might help.
Solution 2:
By default SQL Server will use all the available RAM in the server. Best practice is to configure the SQL Server is have 2-4 Gigs less RAM available than the server actually has (depending on what else is installed, how much SQL CLR you are using, etc). The SQL Server will make use of the memory in the server as the buffer cache so that the data needs to be read from disk as infrequently as possible. The more RAM the SQL Server has available to it the more data that the SQL Server can load into memory. In a perfect work the SQL Server will read from the disk almost never (except on start up as the data has to be read from disk as some point) so that the only disk IO which is needed is write IO.
Solution 3:
Running SQL Server on a RAM disk is just like configuring a machine's pagefile to be in RAM: it will break the expectations the system has.
SQL Server is actually a lot like an operating system, it has its own version of processes, threads, has its own memory manager, and other things. So what would happen if we run SQL Server on a RAM disk?
- We lose database consistency. If the server were to fail, we would lose data. SQL Server in its standard configuration will not lose committed data.
- We will end up using memory inefficiently, because SQL Server will use its buffer pool and various caches for data that is in RAM already. In the worse case scenario, you will limit SQL Server to less than 50% of the memory your system has. The majority would end up being used to store the database and/or log files, and SQL Server would still attempt to put things into its internal, optimized buffer pool and lack sufficient memory to buffer things.
The first is the most important. SQL Server on RAM disk will no longer have transactional consistency in the event of a failure. Nothing else should matter to you, but I can say with certainty that there are no technical benefits to running SQL Server's database or log files on a RAM disk that can possibly outweigh the risks.