Disaster recovery is a topic on the minds of many DBAs. Learn some of the basics about SQL Server disaster recovery from a leading expert in the area, Greg Robidoux of Edgewood Solutions. Greg is currently the Vice Chair for the PASS DBA Special Interest Group (SIG). In addition, he recently gave two presentations at the PASS Summit in Seattle on Change Management and Project Management for DBAs.
Tell us about yourself, your background, your training, and your experience with I have been working in the IT industry for almost 15 years now. I started out working in networking, but moved to database systems early in my career. Over my career I have worked with Sybase, Oracle and most recently with SQL Server. I have worked with small clients with a single SQL Server, to clients with over 100 SQL Servers. Some of the areas that I have worked in with SQL Server include upgrades, disaster recovery planning, change management controls, project management, SAN integrations, product selections, centralized management, and application development on SQL Server 6.5, 7.0 and 2000 platforms.
Tell us about your consulting company.
Edgewood Solutions was founded in January 2002 with the premise of elevating the Microsoft SQL Server platform, by implementing appropriate and necessary components for SQL Server that are sometimes overlooked. There are components, such as disaster recovery, that are often not addressed, but we feel are extremely important to a sound database implementation.
Edgewood is focused on developing key components for SQL Server that most DBAs know they should have, but don’t, because most of their time is consumed with handling immediate database issues. Instead of trying to provide solutions for all aspects of SQL Server, we address areas that should be in place, but are not always addressed. These areas include:
Change Management
Security Policies
Disaster Recovery Planning
Project Management for SQL Server projects
SQL Server Upgrades
Maintenance Planning
Performance Analysis and Tuning
We also research and recommend software products that are developed specifically for SQL Server. We look for best of breed products and offer these solutions to our clients. So far we have partnered with SQL LiteSpeed, Lumigent and Precise Software Solutions. Each of these solutions provides a unique benefit to the SQL Server industry and economies of scale for DBAs addressing numerous projects with tight deadlines.
SQL Server disaster recovery has become a big topic. We all know what the obvious reasons are for preparing a disaster recovery plan. But, what are some of the less obvious reasons why a disaster recovery plan is critical for organizations?
When most people talk about disaster recovery they think about it from a total site disaster. Although this is possible, it is not very likely that an entire site will be wiped out unless the site is in an area prone to natural disasters such as floods, hurricanes or tornadoes.
I think of disaster recovery as eliminating unplanned downtime that severely impacts the business. This can be caused by power outages, inadvertent code that is moved into production, and hardware failure. Most companies that have SQL Server installations are relying on SQL Server to be available 24×7 in order to conduct business. As more and more companies begin to go global with their product offerings, thanks to the Internet, the available window for planned downtime is becoming smaller, and the window for unplanned downtime needs to become non-existent.
One of the items that must be addressed, and is typically overlooked, is actually determining the amount of acceptable downtime for a company, and in turn, developing a thorough plan to meet these needs. It is often difficult to get a realistic time that systems need to be available to users versus availability for maintenance windows. Because this window is not clearly defined, DBAs find it difficult to plan for something that might not be realistic.
What exactly does a disaster recovery plan cover?
As a disaster recovery plan is conceived, it is necessary to address items on both the business and technical sides of the coin. It is my recommendation that the plan covers all aspects of any type of system downtime, whether it is as small as one table or as large as an entire site. The plan should be appropriately based on the business need and not for the sake of only implementing technology that does not resolve the immediate and long-term needs.
Plans and procedures need to be written and implemented that take into consideration all possible threats of unplanned downtime. To address the items of virus, hackers, DBA mistakes, and disasters, the disaster recovery plan is only one component of a fully functional suite of processes that should be implemented. In addition, DBAs need to look at Change Management, Security and general best practices to avoid downtime.