Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Business case for standalone SQL server 1

Status
Not open for further replies.

ruppy

MIS
Sep 12, 2005
3
GB
Hello,

I'm trying to convince my boss that we should not load any other application or services on a soon to be commissioned SQL server. He wants to cut costs and double/triple up servers with multiple disparate applications....

What I'm after is some help putting forward the business case for keeping our SQL server pure. Presently we have a moderate use of SQL in various application and are looking to consolidate onto a single "BIG" server. If anyone has any best practice advice on why keeping the server running just SQL is the best way please post! Likewise, I've had a quick search for any supporting evidence from MS, but turned up blank. Any hardcore DBA out there got any links, post em!
Finally, any anecdotal evidence on problems you may have had in this would be welcome too.

Thanks in advance guys,

R
 
Tell your boss that SQL Server is memory hog! What version of SQL are you installing?
Let say you have 4 GB of memory on the server, and you are using Enterprise edition with AWE enabled. You leave SQL to dynamically manage the memory. SQL is going to take as much memory as it can for data and procedure cache. Other programs will have to request memory from SQL. And if SQL is busy it won't give it up.
What if you have to reboot the box because of a app problem? Now you have to reboot your SQL Server as well.
Also,
This is your company's data (one of it most valuable assets!)
Very few people should have access to it. You don't want other applications which can cause problems for your SQL Server.

- Paul
10qkyfp.gif

- If at first you don't succeed, find out if the loser gets anything.
 
thanks paul, all good.

Anyone got anymore?

R
 
It is always recommend to make SQL a standalone system.

As Paul said SQL is a memory hog. It is also a CPU hog.

SQL assumes that it is the only piece of software installed and it acts accordingly by taking all Memory and CPU resources as it sees fit.

While you can limit the amount of memory that SQL can use, SQL will still try to take all the CPU resources.

What happens when some application that is installed on the SQL Server starts using CPU power. You now have less CPU for your SQL database and everything that it's running will start to slow down.

By adding additional apps to the SQL Server you now need to reserve memory for them out of the memory pool. This leaves less memory for SQL Server to use. The general rule with SQL Server is the more RAM the better. If you are going to get a big SQL Server why screw it up by loading other apps on it.

While you may not see the impact now, you will later on as the load you place on the SQL Server grows over time (which it always does).

Denny
MCSA (2003) / MCDBA (SQL 2000)
MCTS (SQL 2005 / Microsoft Windows SharePoint Services 3.0: Configuration / Microsoft Office SharePoint Server 2007: Configuration)
MCITP Database Administrator (SQL 2005) / Database Developer (SQL 2005)

--Anything is possible. All it takes is a little research. (Me)
[noevil]
 
thanks denny. All of what you say makes good sense.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top