Site sponsored by: Idera Try Idera’s new SQL admin toolset
SQL Server Performance

  • Home
  • Articles
  • Forums
  • Tips
  • FAQ's
  • Blogs
  • Software
  • Books
  • About Us
RSS Feeds
Sign in | Join


Article Topics

All Articles
Peformance Tuning
Audit
Business Intelligence
Clustering
Reporting Services
Developer
General DBA
ASP.NET / ADO.NET

SQL Server 2008 - Worth the Wait

SQL Server’s first significant upgrade in three years features a number of envelope-pushing enhancements and improvements. Which will have the greatest impact on SQL administration and development? More...
Latest Articles

Slowly Changing Dimensions in SQL Server 2005
Audit Data Modifications
SQL Server 2008’s Management Data Warehouse
Same Report but Different Methods in SQL Server Reporting Services ...

More     
 
Latest FAQ's

SSIS Lookups are Case Sensitive
Convert Number to Words in SSRS
After installing SP2 on SQL Server 2005 x64, when trying to ...
Remote Name Could not be Resolved in SQL Server Reporting Services ...

More     
   
Latest Software Reviews

SQL Server DBA Dashboard
SwisSQL DBChangeManager
SQLMesh - SQL Server Search Tool
SoftTreeTech SQL Assistant

More     

articles >> general dba >> Learn About SQL Server Disaster Recovery from ...

Learn About SQL Server Disaster Recovery from Greg Robidoux of Edgewood Solutions

By : Brad McGehee
Feb 11, 2003
Printer friendly

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 24x7 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.


    Next Page>>    








Home | Peformance Articles | Audit Articles | Business Intelligence Articles | Clustering Articles | Developer Articles | Reporting Services Articles | DBA Articles | ASP.NET / ADO.NET Articles | DBA FAQ's | Developer Peformance FAQ's | DBA Peformance FAQ's | Developer FAQ's | Clustering FAQ's | Error Messages | Audit Tool Reviews | Backup Tool Reviews | Coding Tool Reviews | Compare Tool Reviews | Documentation Tool Reviews | Design Tool Reviews | Monitoring Tool Reviews | Log Tool Reviews | Reporting Tool Reviews | Clustering Tool Reviews | Security Tool Reviews | Change Management Tool Reviews | Remote Access Tool Reviews | Book Reviews | Security Tool Reviews | QDPMA Performance Tuning | ADO.NET / ASP.NET | Administration | Analysis/OLAP Services | Application Development | Configuration | Components | ETL | Hardware | High Availability | Hints | Index | Misc | Operating Systems | Performance Tuning | Replication | T-SQL | Views