|
Download
- a Complimentary Copy
of IDC's Report on Data Profiling |
09.10.03
 By
Brad M. McGehee
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 SQL Server.
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.
Access database
Hi there. I am new to this forum and new to
databases. I learned access recently to start
managing our company files and what not (can
you believe all records for employee affairs
were on paper for 260 employees? talk about
stuck in the stone ages!!!) I was wondering
how I would go about doing the following:
There are three tables I need to glean information
from to make a report for the big boss to do
her review stuff ...
|
|
|
What steps are there to creating a disaster recovery plan?
Based on my experience, it is best to start with a small plan and
begin the process with future goals in mind that are tested and
implemented on a predefined schedule. For example:
- Determine the business needs for availability as well as the
corresponding budget for the solution.
- Determine disasters to prevent as well as recover from, including
mistakes, hackers, hardware failure, and database corruption.
- Plan the data collection disaster recovery process.
- Document the environment with a standardized set of documents
relating to the hardware, software, application, and personnel.
- Develop a key contact list and escalation levels.
- Develop a media kit that has all the necessary software versions
and service packs.
- Standardize server configurations across servers.
- Have backups readily available on disk (Look at SQL
LiteSpeed for smaller and faster backups).
- Have spare hardware or servers available.
- Communication plan for the recovery process.
- Testing the plan to ensure success.
- Implement the solution.
- Re-testing and revising the plan as needs change.
- Look at third party tools that can assist with collecting
server information (BindView for SQL Server and NetIQ ConfigurationManager
for SQL Server).
- Look at third party tools for restoring lost data (Lumigent
Log Explorer).
- Lastly, keep documentation up to date.
How big a part does documentation play in a disaster recovery
plan?
Click
Here to Read the Full Article
About the Author:
Brad M. McGehee is a full-time DBA with a large manufacturing company,
and the publisher of http://www.SQL-Server-Performance.Com,
a website specializing in SQL Server performance tuning and clustering.
He is an MVP, MCSE+I, MCSD, and MCT (former).
Brad also runs another website called http://www.WorldClassGear.com
It provides independent gear reviews for backpackers, trekkers,
and adventure travelers.
Read this newsletter at: http://www.sqlpronews.com/2003/0910.html |
|
|
|
View
Post
Click
To Comment