• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 970
  • Last Modified:

Worth moving tempdb to a RAM drive?

Server performance is always going to be one of my primary issues. We have a big web-based application with lots of back-end processing that leans heavily on temp tables, table variables and temp tables.

Is there a performance increase to be gained by creating a RAM drive and relocating the tempdb on to it? As I understand it, this gets recreated every time the server starts, so I'm not remotely worried about losing the contents if it crashes.

I'm running SQL Server 2000 on a Win2003 box, currently with 2GB installed. The tempdb data/log files never exceed 50MB/10MB respectively.

I'm sure there are technical difficulties to be overcome (like ensuring the RAM drive exists before SQL starts!), but is this worth following through?
0
kenpem
Asked:
kenpem
2 Solutions
 
Aneesh RetnakaranDatabase AdministratorCommented:
0
 
kenpemAuthor Commented:
I've read all the adverts, I was looking for reports of real-world experience from DBAs.
0
 
LowfatspreadCommented:
subscribing...

i'd have thought that giving the memory to the DBMS engine to manage directly would be the best performance wise..

and using Table variables rather than temp tables (@xxx vs #xxx)  would assist that...

but i suppose if you've got "heaps" of memory then a Ram disk .. could assist..

what size of physical database are you envisaging?
how many (concurrent) users  ?
and what level of intermediate result sets, sorting overhead doo you envisage in most of your queries...?


interesting
Lowfatspread
   
0
What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

 
raj_Commented:
if u can alse elaborate the RAID settings, it woiuld be quite hepful for all of us to be more objective in our reply.
0
 
kenpemAuthor Commented:
A simple RAID 0 configuration, nothing fancy, everything on the same drive. Table variables used where possible, queries optimised pretty well. User connection counts vary..... from 5 to 500 at a time - hopefully some more as the business grows, but by then we'll have added some hardware.

There's a lot of data overhead.... as users move around the web site, we do major on-the-fly lookups and calculations to figure out what to present to them - a little like Amazon does ("you may also like...."), but a lot more of it. This is all qualified, sorted & ranked. It's actually pretty cool and not as slow as I had feared, but as I said, I'm always chasing better performance. Some temp tables have been unavoidable, so I was just looking for ways to eke out another 1%.

If it's not worth the bother, at least I'll know that!
0
 
Racim BOUDJAKDJIDatabase Architect - Dba - Data ScientistCommented:
It all depends to what extent your tempdb is a performance bottleneck as opposed to your other databases.  You need to audit your system before making any recommendation of such nature.  
One tip though...tempdb clearly is more utilized in 2005 than 2000 therefore the performance leverage putting the tempdb on RAM drive would be more interesting.

Hope this helps...
0
 
Anthony PerkinsCommented:
Also, keep in mind that variables of type table also use tempdb.
0

Featured Post

Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

Tackle projects and never again get stuck behind a technical roadblock.
Join Now