August 12, 2008 at 8:54 am
Basically it is another one of those (IMHO) server admins messing in the database admin's hair.
We have a vendor app that is going to be installed, I went down and met with the vendor's DBA and we chatted about reporting, how our custom applications can talk to the vendor DB, etc...
I want to attach the vendor's database to our existing SQL Server and then I can report off it with ease, share data for applications we develop that will utilize the vendor's database, etc...
The vendor says that is totally fine and sees no reason for a separate SQL Server to have it installed on.
The windows server admins want to setup a separate server and have MSSQL server installed on it and then dedicate it entirely to the vendor database. (The vendor database will have <10 users)
So I plead my case about how it is much simpler from a programming development, reporting, and DBA standpoint to just attach the vendor database to the existing SQL Server.
They want to setup a separate server because they believe it would be more stable.
I suggest instead we setup that separate server, but let it mirror our existing MSSQL server then if anything goes wrong not only can the vendor database fail over but all our other databases as well.
They seem to think this suggestion makes no sense and they are firm in the "separate server = more stable" I also explained the horror that is linked servers and since about 80% of our applications will pull data from the vendor database, that's a lot of pain to go around 🙁
Also I saw this thread: http://www.sqlservercentral.com/Forums/Topic549629-146-1.aspx which is sort of along the same lines.
Anyway, thoughts?
August 12, 2008 at 9:00 am
I would definitely push the concept of mirroring if they insist on setting up a separate server. If this database will have < 10 users, the server will be so under-utilized, they will never recover the cost. As long as your current SQL Server is running smoothly and has resources available, there is simply no reason to dedicate such a small app to that small of a user base.
August 12, 2008 at 9:14 am
Their main concern seems to be all about "stability" I can't seem to help them understand that having a seperate server is no more "stable" than having it on our existing Production server (which works fine and has never had any database releated issues).
I wonder if there are some Microsoft best practices I could reference, or SOMETHING I can use other than my just saying "Look, I'm the DBA this is what I do for a living, you're just going to have to trust me on this. Here are all the reasons I have for wanting to attach it to the existing server and use that other server for mirring/failover"
I guess some way to help support my case?
August 12, 2008 at 9:24 am
I assume you have already searched Microsoft's site for "best practices" and came up empty. My only suggestion is to look for examples where people are running multiple databases without issues and point them to those examples. At my last job, I had almost 90 different databases running on a single server. Here in my new job, I have only 24 databases on a single server but it still handles the load of 150+ users just fine (on only 4GB of RAM I might add).
What is the processor and memory utilitization currently at on your production box?
August 12, 2008 at 9:34 am
Oh about 3%....
Seriously, you can't even see it on the graph it is so close to the bottom.
Simply because we don't have that much traffic.
Most of our users look at reports, but I schedule those to run during off hours and then cache for the next day. A few of the real time reports don't actually execute against our server but a server back at enterprise HQ.
The rest are our custom applications which are EXTREMELY NOT taxing on the database. (Web apps and we will NEVER have more than 200 users) and the majority of those are "line staff" who won't use the applications on a day to day basis anyway. They use the reports, which again are pregenerated or coming from somewhere else.
Long story short: MSSQL server resources are not a concern for us at this point. The only weak point is a RAID 5 array that houses our .mdfs but again we are 98% read only. So while we have a lot of things planned to be built, none of them are overly taxing applications.
(Additionally, if we get to that point, I see no reason why we can't get a new server, go RAID 10, upgrade the RAM, etc... and then just replace the existing production server with that)
This server exists basically to replace all our old MS Access database apps with a proper SQL Server backed. So if Access could hack it, you can bet SQL server can slice, dice, and make Julian fries without breaking a sweat 🙂
August 12, 2008 at 9:44 am
So really, they are wanting to pay for two severely under-utilized boxes? You could take that to management so they can't spend the money.
Anyhow, the thought just occurred to me - I wonder if they are confusing security with stability? That is the only semi-logical reason I could see for wanting to setup a separate server. However, you mentioned the need for reporting from this database as well. From personal experience, I can assure you that linked servers are a royal pain to be avoided if at all possible.
If they really want to address the reliability issue, having a database running on a single server is more of a problem since you create the "all eggs in a single basket" syndrome. By running on a dedicated server, they actually introduce more risk than having your databases properly mirrored.
When we make our move from 2000 to 2005, we will be consolidating from four servers to two. There just isn't a need to all of the extra horsepower. We are actually going to be moving our SQL Servers into VMs so we can better utilize the hardware. I wonder how your network admins would feel about that?
August 12, 2008 at 9:49 am
SQL Server in VM's have some performance issues as I understand it (though that is changing as well).
Though I have asked about getting VM's setup to use for testing (for development programming, etc...), but that has been struck down.
I'm sort of living in a "Windows NT" world here, they like to run about 8 years behind the current tech level for whatever reason.
So you can see how that can drive some people crazy, but others consider it a great thing.
Different strokes for different folks I guess.
Thanks for the feedback though, I do appreciate it.
If anyone else has any thoughts I'm all ears as well.
August 12, 2008 at 10:05 am
under 10 user connections!
i would home on an existing instance
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
August 12, 2008 at 10:08 am
But how can I get them to understand that is my issue...
They just say "BUT THE VENDOR DATABASE IS SO IMPORTANT IT MUST HAVE ITS OWN BOX!!!!!"
To which I reply, "Hey, how about fail over with another server, and we house it on our exisitng production database"...
They just don't get it for whatever reason. Maybe they never will I guess.
They are windows server admins and apparently for Windows important = seperate box???
I think I'll point out the total underutilization to management, this is a tight year $$ wise anyway, I'm sure they'll understand that part of the reasoning for using our existing SQL server, if they don't understand and of the hundred technical reasons.
August 12, 2008 at 10:20 am
I think I saw you say you are still running Windows NT? In my experience with NT, it wasn't very stable. When I started doing system administration with SQL Server, I always requisitioned a new box for each new app. It was hard enough to keep it all running as it was without adding something else to the mix.
The difference there is that another database is NOT another application to support. It isn't anything more than having another file on a file server or another printer on a print server. In those cases, the purpose for the box is to be a file server and nothing else or a print server and nothing else. In your case, it is a SQL Server and nothing else. With utilization so low, it really is akin to putting more files and printers on those respective servers. They certainly wouldn't setup a new file server for each application that needs files would they?
August 12, 2008 at 10:27 am
Ah, good analogy.
Perhaps I can approch it from that stand point.
They don't have a seperate network file server for EACH folder on the network file share either.
There isn't an issue with security there either. You just assign permissions to each folder, and that's the end of it.
(SQL Server is on WinServer 03 thank goodness, but we do have, or had until just recently older boxes....)
August 12, 2008 at 10:36 am
Sometimes it is necessary to have different servers because they have different maintenance windows for the applications.
One might have a downtime window of 0100-0600 on Saturday and Sunday, and the other might have a maintenance window of 2100-2359 every day. If you want to patch the OS, you would not have a window when both applications are inactive.
August 12, 2008 at 10:43 am
Michael Valentine Jones (8/12/2008)
Sometimes it is necessary to have different servers because they have different maintenance windows for the applications.One might have a downtime window of 0100-0600 on Saturday and Sunday, and the other might have a maintenance window of 2100-2359 every day. If you want to patch the OS, you would not have a window when both applications are inactive.
IMHO, this doesn't really matter. Make sure the users know when you have scheduled your maintenance window and that all applications will be down during that time. I did this regularly at my previous job and I was affecting nearly 30,000 users. As long as my users knew when I would have the application down, they were fine with it.
August 12, 2008 at 10:50 am
Michael Valentine Jones (8/12/2008)
Sometimes it is necessary to have different servers because they have different maintenance windows for the applications.One might have a downtime window of 0100-0600 on Saturday and Sunday, and the other might have a maintenance window of 2100-2359 every day. If you want to patch the OS, you would not have a window when both applications are inactive.
Good point, but in this case it doesn't apply.
The existing server NEEDS the vendor database for the existing server's applications to function (because 80% of them will talk to the vendor DB).
If the vendor database goes offline, the existing server may as well do the same.
If the existing server goes offline no one can get reports out of the vendor database because we utilize reporting services and a lot of the reports will still be housed on the exisitng server. (I really have NO DESIRE to setup a seperate reporting services install just to service a single database.... ugh what a PITA, let alone managing dual permissions...)
Though I understand what you are getting at and how in some situations that would make good sense.
August 12, 2008 at 11:57 am
jim.powers (8/12/2008)
Michael Valentine Jones (8/12/2008)
Sometimes it is necessary to have different servers because they have different maintenance windows for the applications.One might have a downtime window of 0100-0600 on Saturday and Sunday, and the other might have a maintenance window of 2100-2359 every day. If you want to patch the OS, you would not have a window when both applications are inactive.
IMHO, this doesn't really matter. Make sure the users know when you have scheduled your maintenance window and that all applications will be down during that time. I did this regularly at my previous job and I was affecting nearly 30,000 users. As long as my users knew when I would have the application down, they were fine with it.
It really depends on the needs of the business, and is not something that can always be dictated by IT or a DBA. You certainly cannot say this is never an issue.
Viewing 15 posts - 1 through 14 (of 14 total)
You must be logged in to reply to this topic. Login to reply