1. RAM – RAM is cheep, and easy to upgrade.  For a couple of thousand bucks you could easily add another 32-64 Gigs of RAM (more if you buy off brand).

2. Drive Space – Disks are also cheep (not as cheep as RAM, but close).  You could drop some extra spindles in there and more tempdb off to its own drive, or even break the database into a couple of physical files and double the available IO.

3. Faster CPUs – CPUs usually aren’t all that cheep.  If you have dual core chips, and you want to get some core chips you are probably looking at ~$1500 per chip, so that probably isn’t an option.  Now if you have a single quad core CPU in there, you could drop a second one in double your CPU power.  This will throw off your licensing if this is an internet facing SQL Server.  Those 6 core CPUs may look might sexy, but sadly they are probably way out of your budget at ~$3k each.

Those are pretty much your options.  Now if your IO is being slammed that might be a good place to throw that cash, but if your IO is being slammed is it because of writes or reads?  If it’s because of writes then by all means throw the cash at the storage.  If it is because of reads, then check your hit cache ratio, and page life expediency.  If they are low, then some more RAM is in order.  This will increase the amount of data in cache, increasing the amount of time the data stays in cache, and reducing the IO requirements on to the disk to a crawl.

Everyone wants more CPU power in there servers.  But sadly CPU power is still very expensive, so it isn’t really going to be an upgrade option unless you’ve got a pretty small server.  Not to mention the licensing issues that can quickly lead to if you add more physical CPUs than you are licensed for.

All things being equal I’d probably go for the RAM upgrade.  Long term I think that’ll get you the most bang for the buck, however that’s just me.  And depending on the server I might change my mind.  Before jumping into any system upgrade think carefully about what you want to purchase, what you want to achieve, and make sure that those things cross.

Denny

P.S. My hardware prices were from Dell’s website.  Your prices will vary depending on where you do your shopping.

The answer to this is it depends.

If you need a clear security buffer between the databases so that someone with sysadmin rights to one database can’t have sysadmin rights to another database then seperate instances will be the way to go.  However this separation will come at a cost.  You now have to use twice as much memory loading up the SQL Server binaries into memory, and you now have to tell the instances how much memory each one can use.

With a single instance you simply tell the SQL Server leave 1 Gig of RAM for the OS (or how ever much you leave) and manage the rest for all the databases on the instance.  When you have more than one instance you have to decided how much memory each instance, and therefor each database will get.  If you guess incorrectly your database performance will suffer greatly because of it.

Another place where you may see some pain is your tempdb performance (assuming that both instances use the same tempdb).  Because you are using two difference instances the SQL Server doesn’t know anything about the load that the other one is trying to place on the disk.  If they both try to hit the disk at the same time with a large amount of load you could end up with additional queuing at the disk that you may not see when using a single instance.

Generally speaking I would recommend using a single instance unless you absolutly had to have a security seperation with the RAM settings being my biggest reason for a single instance.

As for reasons to need a seperate instance databases that need access to features that other databases shouldn’t have access to like xp_cmdshell would be one reason.  Applications which require sysadmin rights to the instance thanks to crappy coding would be another.  And a vendor which requires that there support account on the database have sysadmin rights would be a third.  Off the top of my head those would be about the only reason to seperate the instances.

Denny

Denny

Denny

Getting them right in the 32bit versions of SQL Server is a bit harder.  You have to deal with the OS level of enabling the Physical Address Extensions (PAE) and the 3GB switches.  You then need to enable AWE within SQL Server and then set the max memory setting.

If you are using Windows 2003 SP1 or later PAE will enable for you automatically.  The /3GB switch however won’t.  Since I have to add the /3GB switch I like to add the /PAE switch in there as well.  My theory is why make Windows decide to do something automatically when I can simply override the logic and turn it on every time, especially when it’s something that I’m going to want enabled every time the server boots.

 Now as to the max memory setting for SQL Server… There are pretty much two prevailing schools of thought. 

1. Give Windows between .5 and 1 Gig of memory and give SQL the rest.
2. Give SQL 75% of the physical memory and leave the rest for Windows.

I’ve tried both and both seam to work fine.  If you have less memory to work with you will probably want to stick to option 1.  When you start working with huge amounts of RAM (64 Gigs plus) is when Option 2 starts to look more workable.

These rules obviously all start to change when you have more than one instance installed as you need to balance your max memory between the instances.

If you are using less then 2 Gigs of RAM for the instance don’t enable AWE on the instance.  I’ve seen it lead to SQL Server acting strangely and performing very strangely.  When setting your max memory setting for more than one instance don’t forget to add up the max memory for all the instances and make sure to leave Windows room to work with or your server will suffer.

Don’t forget about my post on setting the min server memory setting in SQL Server.

Denny