SQL Server and other applications
-
I have been told that it's 'best practice' to NOT have any other application on the same server as SQL Server.
Is this true? Can someone point me to 'official' documentation that says that?
My bosses want to add other applications to my server and I'm saying it's a bad idea. So of course they want it in writing from an official source.
Thanks for any help with this.
-SQLBill
-
It's a bad idea in general because SQL is competing with other applications for resources. You tend to separate your database from the applications.
That being said, it's not horrible in all cases. This site has IIS and SQL sharing one box.
What type of apps does he want to install?
Steve Jones
-
I'm not sure yet, but knowing this guy they are going to be power/memory hogs.
Problem is that I may have already lost out...I've heard that he's already bought the application and got it approved by saying he could just put it on my server. Of course when he told this to upper management, I was never involved. (In fact I'm still not supposed to know about it happening).
When I finally 'find out' about this, I'm going to need more than just my word that this is a bad thing to do. My concerns/arguments will be ignored since I don't have documentation that this is a bad thing to do. And as the powers that be never bought a test/development server, there's no way to test it. It'll go straight on the production server.
-SQLBill
-
It happens, I know it's happened to me. All you can do is document and voice your concerns as a CYA and deal with it the best you can.
Let us know when it comes in and we may be able to help. One nice thing would be to set the memory for SQL so the allocation / deallocation isn't taking overhead.
Steve Jones
-
I posted a similar topic a few weeks back and didn't get back much in the way of replies. Everyone agrees it's a bad idea, but there's not much out there in the way of documentation as to why it's a bad idea. If your server is powerful enough and you don't have a large user base there might not be too much reason for concern.
We have a manager of another group here who purchased a Pervasive SQL application that she wants to install (slam dunk, really) onto a production SQL server box (this is the situation that led to my previous post). I can only say that I'm very glad that I'm not on point for this project. Definitely agree with Steve in getting your concerns documented up front.
Best of luck and please let us know how it goes.
"Remember to take credit for the good things you say and do." Anonymous
My hovercraft is full of eels.
-
We're running into two problems here. One, nothing from Microsoft is going to imply that you can't share a server with other applications. I searched for a while and came across a lame little case study talking about divine.net http://www.microsoft.com/resources/casestudies/casestudy.asp?CaseStudyID=10867
search on the keyword "dedicated" and there's a little blurb talking about deciding on dedicated/shared according to your needs.
Other than that I can't give you much that isn't just anecdotal or cheering. I managed an IT department for a small software company that had about 15 servers. Most had SQL Server and multiple other applications. (We learned that SQL Server and Oracle on the same box was a very bad idea!)
At any rate, the biggest problem was usually that SQL Server doesn't share well with others. It's a bit of a memory hog (SQL7) and in several cases of theoretically identical machines it would ignore the memory limitations you set and grab most if not all the memory in the server.
If your server is big enough and especially if it's advanced server (?) where you can stipulate that these particular processors and memory are for this particular application you should be fine. However, if SQL Server dogs your nemesis's application it could end up making you out to be the bad guy.
"I met Larry Niven at ConClave 27...AND I fixed his computer. How cool is that?"
(Memoirs of a geek) -
Baseline the server now before the application is installed. When the application is put on the server, if everything tanks, you have the baseline to refer back to as a control.
K. Brian Kelley
http://www.truthsolutions.com/
Author: Start to Finish Guide to SQL Server Performance Monitoring
K. Brian Kelley
@kbriankelley -
Nice CYA tactic!
Good thinking!
"I met Larry Niven at ConClave 27...AND I fixed his computer. How cool is that?"
(Memoirs of a geek) -
Although I always recommend a dedicated SQL Server, I couldn't find any concrete statement either, except for one comment:
quote:
If you expect SQL Server to be busy, do not run any other service with it.—SQL Server Development Team
That comes from http://www.microsoft.com/sql/techinfo/tips/administration/sqlserverpdc.asp
Cheers,
- Mark
Cheers,
- Mark -
Also keep in mind that putting multiple apps gives the vendors the opportunity to point fingers at each other and slow your support.
Steve Jones
http://www.sqlservercentral.com/columnists/sjones
The Best of SQL Server Central.com 2002 - http://www.sqlservercentral.com/bestof/
-
If you're looking for reasons why not to put SQL and IIS on the same box....
http://www.sqlservercentral.com/columnists/dpoole/sqlandiisonthesamebox.asp
-
quote:
Nice CYA tactic! Good thinking!hey, something new learned for today on this SNAFU day.
CYA could become one of my favorites acronyms
Although the tactic is not very constructive or creative, and moves nothing, it's undoubtebly neccessary.
Frank
--
Frank Kalis
Microsoft SQL Server MVP
Webmaster: http://www.insidesql.org/blogs
My blog: http://www.insidesql.org/blogs/frankkalis/[/url] -
Thanks to all of you for the input.
I am working on baselining my server as suggested. I already have a basic baseline, but I'm going to improve on it.
I have SQL Server 2000 on Win2K Advanced Server box. My storage space is 932GB. I have 4 CPU and 4GB of RAM.
However, SQL Server is used for one application and it is 'constantly' doing INSERTS, so CPU usage is normally 53% to 94% every minute.
I'm going to check out the sites everyone provided and just keep documenting as much as I can. I'm also going to try and 'lock' as much memory as possible for SQL Server's use.
If the other application IS installed and it fails....oh well, I can say TOLD YOU IT WAS A BAD IDEA!
-SQLBill
-
One approach may be to find out what the other vendor (for your bosses app) says about having to share a server with SQL Server?
k2
-
It really all comes down to "people's" productivity and the server's reliability. If the People using the apps and the SQL Server are getting results in what they Perceive to be a reasonable amount of time, your company has saved some money not buying another server. In a perfect hassle free world, of course we'd always run one app per server to minimize interaction and maximize productivity of the air breathers. In the real world, what's good overall for the business as a whole is not always what makes the DBA's life the easiest.
I would run the performance monitor and get average CPU and other relative readings down as a baseline, but I'd also measure from the DB user's point of view how long the worst reports and queries are taking. After that App is installed, go back and show how the people were affected, not how your own little world was affected and you'll gain stature in your company for getting "the big picture" and not just protecting your turf.
Student of SQL and Golf, Master of Neither
Student of SQL and Golf, Master of Neither
Good thinking!Viewing 15 posts - 1 through 15 (of 16 total)
You must be logged in to reply to this topic. Login to reply