I’m hosting this month’s T-SQL Tuesday blog party, but that doesn’t mean I can’t participate. I posted the invitation last week, and hopefully we’ll have a large number of people participating today.

The Cost of HADR

I’ve dealt with a lot of business people over the years, and for a variety of reasons. At one job, I worked for a small company, literally about 50 people, and we had a number of systems critical to our business. We had a large fax server, receiving hundreds of faxes a day from overseas. We had a large imaging server/platform in which we stored our faxes along with quite a bit of other business correspondence that we needed a record of, and we had an inventory management/sales system running on SQL Server that people used every day to run the business.

These were all important systems, and if they were down, business would slow to a crawl. The owner of the company wanted to take advantage of all our technology and mandated “no downtime” and “zero data loss” to my boss, the VP of sales for the company. He was, of course, happy to push this down to me as a goal for the next year.

This was in 1997, and as I investigated our possibilities for achieving this, I realized very quickly that it wasn’t a good move for the company. Clustering in SQL Server v6.5 was shaky and hard to install and maintain. Marathon Technologies had a machine that was basically a “cluster-in-box” that would do a lot of what we wanted, but it would have been around a $30k server. Since our two SQL Servers cost about $7k together, this didn’t seem like a great solution to me.

Instead I investigated what downtime cost us. What would it cost in terms of work and salary if we had to re-enter data that might be lost. We had been down for various periods of time due to different events, and the business had survived, even one day when we were shut completely down for 2 days.

It quickly came to light that we’d have to be down for over a week to really cost the business more than $30k, and that was debatable. We could still conduct lots of work on paper and over the phone, so it didn’t make sense to aim for zero data loss and zero downtime. I explained it to my boss, laid out a simple case for him with a few numbers highlighted, and the provided an alternative for investment in a little redundancy, designed to minimize losses, but not prevent them.

In the end the big boss agreed. He hadn’t really meant zero loss, after all, anyone in business knows that there are always going to be some losses. What he wanted was his business to keep running, cost effectively. That’s what we gave him at a much more reasonable price.