(Edited 8/14/2009 to correct links - Paul)
Hello everyone and welcome to the SQL Server Disaster Recovery and Availability forum. The goal of this Forum is to offer a gathering place for SQL Server users to discuss:
- Using backup and restore
- Using DBCC, including interpreting output from CHECKDB and related commands
- Diagnosing and recovering from hardware issues
- Planning/executing a disaster recovery and/or high-availability strategy, including choosing technologies to use
The forum will have Microsoft experts in all these areas and so we should be able to answer any question. Hopefully everyone on the forum will contribute not only questions, but opinions and answers as well. I’m looking forward to seeing this becoming a vibrant forum.
This post has information to help you understand what questions to post here, and where to post questions about other technologies as well as some tips to help you find answers to your questions more quickly and how to ask a good question. See you in the group!
Paul Randal
Lead Program Manager, SQL Storage Engine and SQL Express
Be a good citizen of the Forum
When an answer resolves your problem, please mark the thread as Answered. This makes it easier for others to find the solution to this problem when they search for it later. If you find a post particularly helpful, click the link indicating that it was helpful
What to post in this forum
It seems obvious, but this forum is for discussion and questions around disaster recovery and availability using SQL Server. When you want to discuss something that is specific to those areas, this is the place to be. There are several other forums related to specific technologies you may be interested in, so if your question falls into one of these areas where there is a better batch of experts to answer your question, we’ll just move your post to that Forum so those experts can answer. Any alerts you set up will move with the post, so you’ll still get notification. Here are a few of the other forums that you might find interesting:
How to find your answer faster
There is a wealth of information already available to help you answer your questions. Finding an answer via a few quick searches is much quicker than posting a question and waiting for an answer. Here are some great places to start your research:
SQL Server 2005 Books Onlinne
Download the full version of the BOL from here
Microsoft Support Knowledge Base:
Search the SQL Storage Engine PM Team Blog:
Search other SQL Forums and Web Sites:
How to ask a good question
Make sure to give all the pertinent information that people will need to answer your question. Questions like “I got an IO error, any ideas?” or “What’s the best technology for me to use?” will likely go unanswered, or at best just result in a request for more information. Here are some ideas of what to include:
For the “I got an IO error, any ideas?” scenario:
The exact error message. (The SQL Errorlog and Windows Event Logs can be a rich source of information. See the section on error logs below.)
What were you doing when you got the error message?
When did this start happening?
Any troubleshooting you’ve already done. (e.g. “I’ve already checked all the firmware and it’s up-to-date” or "I've run SQLIOStress and everything looks OK" or "I ran DBCC CHECKDB and the output is <blah>")
Any unusual occurrences before the error occurred (e.g. someone tripped the power switch, a disk in a RAID5 array died)
If relevant, the output from ‘DBCC CHECKDB (yourdbname) WITH ALL_ERRORMSGS, NO_INFOMSGS’
The SQL Server version and service pack level
For the “What’s the best technology for me to use?” scenario:
What exactly are you trying to do? Enable local hardware redundancy? Geo-clustering? Instance-level failover? Minimize downtime during recovery from IO errors with a single-system?
What are the SLAs (Service Level Agreements) you must meet? (e.g. an uptime percentage requirement, a minimum data-loss in the event of a disaster requirement, a maximum downtime in the event of a disaster requirement)
What hardware restrictions do you have? (e.g. “I’m limited to a single system” or “I have several worldwide mirror sites but the size of the pipe between them is limited to X Mbps”)
What kind of workload does you application have? (or is it a mixture of applications consolidated on a single server, each with different SLAs) How much transaction log volume is generated?
What kind of regular maintenance does your workload demand that you perform (e.g. “the update pattern of my main table is such that fragmentation increases in the clustered index, slowing down the most common queries so there’s a need to perform some fragmentation removal regularly”)
Finding the Logs
You will often find more information about an error by looking in the Error and Event logs. There are two sets of logs that are interesting:
SQL Error Log: default location: C:\Program Files\Microsoft SQL Server\MSSQL.#\MSSQL\LOG (Note: The # changes depending on the ID number for the installed Instance. This is 1 for the first installation of SQL Server, but if you have mulitple instances, you will need to determine the ID number you’re working with. See the BOL for more information about Instance ID numbers.)
Windows Event Log: Go to the Event Viewer in the Administrative Tools section of the Start Menu. The System event log will show details of IO subsystem problems. The Application event log will show details of SQL Server problems.