SQL Server best practices

[sidewinder]

At the moment, we have SQL running on various servers for various applications - Sophos, BackupExec, Auditwizard, PCE etc. Works well enough but I'm guessing it isnt the most effiiciant method.

 

We will soon be centralising storage with a SAN, and so that will leave some servers, which currently do little more than serve files, free. One in particular is filled with 15k SAS drives, so together with a load of RAM chucked in will be a seriously decent server (and is probably vastly underused by being a file server)

 

So at that point, would utilising that one server for pretty much all our databases be a sensible idea? Because it would give me the flexibility to virtualise the servers running the applications themselves, then just connect them to the SQL server, knowing that it was running on something with fast drives and dedicated.

 

Sensible? Or better not to have it all on one (or 2) server(s)?

 

* I'm leaving out SIMS from all of this since it is managed by the LEA and wouldnt want to step on their toes by moving the database, nor do I want to give ourselves the responsibility!

[apaton]

The answer for me is yes, centralise to a single server.

 

Its almost like virtualisation for SQL, why run on many servers when a single one will do. Less hardware and maintenance, fewer MS SQL and backup licenses etc...

If you don't like all your eggs in one basket, then add High Availability via a MS cluster or a SQL mirror(s).

 

Regards

 

Andy

[rh91uk]

Yes, I would centralise to a signle server but have no other services running on it. We plan to do the same in the summer with a lot of our SQL services. The only thing we are keeping seperate are Eclipse.Net and SIMS.

 

SIMS, I would almost certainly keep to it's own box.

[mjs_mjs]

Sounds like a plan to me. I certainly would have a database server, storage (SAN) and then all the hosts virtual. A bit datacente esk.

[Ric_]

Again, I'm another one in favour of hosting all the SQL on one box... it will seriously cut licensing costs if nothing else. Make sure you use seperate physical disks for OS, databases and transaction logs for maximum performance though.

 

@rh91k: Why do you keep your Eclipse.net DB seperate? I run the Eclipse.net DB on the same server as by XenApp DBs and our attendance DB and it causes no problems... it's even running on SQL 2000!

[Soulfish]

Again, I'm another one in favour of hosting all the SQL on one box... it will seriously cut licensing costs if nothing else. Make sure you use seperate physical disks for OS, databases and transaction logs for maximum performance though.

 

@rh91k: Why do you keep your Eclipse.net DB seperate? I run the Eclipse.net DB on the same server as by XenApp DBs and our attendance DB and it causes no problems... it's even running on SQL 2000!

 

Mainly because of the number of times MLS have to remote in to fix things for us . Unfortunately our librarian is very very picky and since we moved to Eclipse.net in September we've had no end of hassle (not MLS's fault I might add!) with Eclipse.net not working as she expected it would. MLS have been great with trying to fix the problems she's had, and implement the functionality she wants but it means every now and then they remote in and do things to the database for us. Easier to just keep it all on one VM so they can do their bits on the one server

[sidewinder]

Thanks guys, good to get some confirmation from other people!