Server Redundancy

Hi, when dealing with SQL server 7.0, much depends on the number of changes made to databases. This will determine, for instance, the number of times per day you back up the transaction log. You should have a good back up plan in mind. Beyond that, I would choose a server system with hardware raid, dual power supplies, ups system. Server clustering really depends on the activity on SQL and costs of downtime. I assume you have some budget considerations, but you can find a great deal of information about SQL and clustering at microsoft's website that focuses on backoffice. I would strongly recommend that you also disable any write back caching on disks because it transactions are in the cache, SQL believes the transactions have been committed. If you had a power failure for example, and the cache is flushed, those transactions are lost and SQL will be unaware of that. There is also extensive information about SQL on SQL magazine's website: www.SQLmag.com
Hope this helps.

So you want a 24/7 system.
you will have to dual everything, processors, power supplies, HDD controlers and of coure have a RAID (0 or 5) installed.
As for the fans, they should be enough to cool the whole system + 1 for redundancy.

As for clustering, It's a good idea if yo ucan afford it. Especialy if you can put the servers in different locations for disaster recovery issues. Clustering have another advantage too in load balancing.
Just remember that having a resilient server is not anexcuse for not doing backups.

Regards,

Haissam

No one mentioned having a good UPS yet. This is essential to ANY server setup. Redundancy can only be built-in to a point. You can easily go overboard with us...dual NICs, dual everything...but in the event of a power loss you ain't doin' squat without a UPS. Your boss will most likely squirm as he sees the price for a good one, but the investment will far exceed the loss you risk by not having one. RAID is an outanding idea, as are redundant power supplies. But do you also install redundant switches?? Like I said, you can easily go overboard. What you end up with will depend a lot on the quality of the equipment you buy and on how many of those $$$ the company is willing to put out. I worked for one firm who actually went so far as to have not one but THREE T1 lines....all on separate physical lines....the reason? You never know when a line may be cut and they NEVER wanted to lose communication. They didn't care about the cost of two full T1 lines sitting at idle, but they wouldn't buy me a decent tape backup.

When making the case for redundancy make sure you do just that...make the case. My experience is that a lot of companies don't understand until it's too late. And by the time something happens it's usually a lot of finger pointing. If you argue that you asked for all of this earlier no one may care.

Okay, so I sound a little jaded....forgive me.

How mission critical will this app be? How much would it cost in loss of business if one element was down more than a few minutes. If it is that critical- there is no such thing as too much redundancy. The answers above are good- I'd like to touch on two points that get over looked.
If you have multiple power supplies- make sure they go to different circuits or UPS's. If a breaker is tripped your system should stay online. The other point would be using dual or quad NICs in a fault tolerant/ load balancing config. Your connectivity should be between redundant network equipment (spread between two switches) and at least two routes out of your network.
When you asked if RAID is neccessary...yes: Use hardware RAID (Not NT RAID). Everything else should be hot swappable (fans/power supplies and disks). If your application will be cluster aware, that is the best way to go. Just remember one reboot drops you below the 99.9% uptime... G'Luck SFO

This question was closed by the author