| Author |
Topic |
|
elwoos
Master Smack Fu Yak Hacker
2052 Posts |
Posted - 2005-07-14 : 10:34:29
|
| Our production server is now 5 years old. It's a 500 MHz, 256 Mb beastie! HOWEVER, on the whole it works fine and has done so for most of those years, our database is about 2Gb and we rarely have more than 30 - 40 user connections at a time. Our largest table has about 100,000 rows AND the system is not critical in the sense that we don't make money directly from it and it has just been down for about 5 hours of "scheduled maintenance" during which time no-one complained.So why am I telling you all this - well, I have the money to buy a replacement server and I think it is time we bought one. My problem is that I may be forced into clustering it i.e. it would be on the same cluster as other production environments which are nothing to do with me. The argument for doing this is that it provides failover capability but I'm not certain that we need it when we may have other alternatives e.g. log shipping (which may also solve some of our problems with long running queries)What do others think given that I am in a situation that is not really typical?thankssteveAlright Brain, you don't like me, and I don't like you. But lets just do this, and I can get back to killing you with beer. |
|
|
Kristen
Test
22859 Posts |
Posted - 2005-07-14 : 12:22:12
|
| I'm reminded of "If it aint broke don't fix it"Having a written, and tested, plan to fix it would be good ... and beware of Murphy's Second Law "If it aint broke you haven't looked hard enough, fix it anyway" !Kristen |
 |
|
|
eyechart
Master Smack Fu Yak Hacker
3575 Posts |
Posted - 2005-07-14 : 12:35:26
|
| does that mean that you would be sharing a server that might also be hosting exchange email or some other app? Can you describe the cluster config a little bit more?-ec |
 |
|
|
KLang23
Posting Yak Master
115 Posts |
Posted - 2005-07-14 : 15:01:19
|
| The advantage of clustering is that is will provide you with a quick way to get your instance back up and running. An "active-active" configuration is usually the best way to keep your investment at work, although you must make sure that if one goes down, the other(s) can handle its load plus the additional load.The downside is that there is (IMHO) a significant maintenance cost - both in terms of manpower, and stuff that just becomes a real PITA with clustering.If you can withstand the downtime - especially like you just mentioned, then clustering really may be more trouble than its worth for you. If you're forced into it however, whaddya gonna do? |
 |
|
|
Michael Valentine Jones
Yak DBA Kernel (pronounced Colonel)
7020 Posts |
Posted - 2005-07-14 : 19:14:20
|
| If you have problems with long running, badly behaving queries, I would keep it away from the cluster. My guess it that they are running something that will get real upset when someone starts their favorite cross join or cursor.Another thing to consider is maintenance windows. Each application has a best time for performing things like re-indexing, DBCC checkdatabase, etc., and you have to make sure those are not running when other applications are running critical processes. I like to place databases that have approximately the same maintenance windows together on the same server.You might want to run performance monitor on your current server and on the cluster to see when each has peaks in CPU, disk IO, and user requests to make sure the applications are compatible. If you are starting a CPU intensive ETL process at 7 am just when the shipping and order entry departments get busy, someone will be un-happy.CODO ERGO SUM |
 |
|
|
elwoos
Master Smack Fu Yak Hacker
2052 Posts |
Posted - 2005-07-15 : 03:25:12
|
| Some good points, cheers guys.The proposed cluster configuration would mean that databases from other departments would be on the same cluster/sql server instance where as at the moment our server has only one application that is for the department I work for so if for example I need to take the server down for some reason I can do fairly easily. I'm slightly concerned about the impact they will have on our system and also concerned about the impact that our system will have on theirs. Maybe it's a luxury to have our current setup. Might Log shipping be a better option for us? The guy who is proposing it is a Network Admin rather than a DBA and so I can see it makes sense from his point of view but I'm not sure it does from minesteveAlright Brain, you don't like me, and I don't like you. But lets just do this, and I can get back to killing you with beer. |
 |
|
|
Kristen
Test
22859 Posts |
Posted - 2005-07-15 : 07:58:07
|
| "I need to take the server down for some reason"Why would you want to do that in the proposed new scenario?(I can see you taking the "Database down/off-line", but taking the server down is less obvious to me)Kristen |
 |
|
|
elwoos
Master Smack Fu Yak Hacker
2052 Posts |
Posted - 2005-07-16 : 18:45:16
|
| I was thinking of when a service pack was being installed or if something had happened to it and it just needed to be rebooted or something.What are the pro's and con's of Log Shipping against clustering? It sounds to me like they are essentially the same thing just that one is from a DBA perspective (and so worries about DBA stuff) and the other is from a network admin thing (and so 0worries about stuff from their persepective)steveAlright Brain, you don't like me, and I don't like you. But lets just do this, and I can get back to killing you with beer. |
 |
|
|
Kristen
Test
22859 Posts |
Posted - 2005-07-17 : 05:21:35
|
| The Service Pack is a one-time deal for all DBs on that server. More DBs = more tsting thatall DBs will sruvive the Service Pack, and more grief if more DBs cause problems after a service pack - a one-DB-per server approach is easier on that score."... had happened to it and it just needed to be rebooted"That is really rare on a SQL-only server IME. Again, its a one-szie-fits-all on a server with loads of databases. We have 86 [production] databases on our most-stuff server. It pretty much only gets rebooted for SP install and major infrastructure/hardware changes. But we are pretty tough about what gets installed on the box and that all DBs are performing well.Kristen |
 |
|
|
|