THE SQL Server Blog Spot on the Web

Welcome to - The SQL Server blog spot on the web Sign in | |
in Search

Browse by Tags

All Tags » disaster recovery   (RSS)
Showing page 2 of 3 (22 total posts)
  • Pop Quiz: Restore a Database to the Point in Time when a Full Backup Started?

    Recently we've had to interview some SQL Server DBA candidates for our team, and we were looking for the type of open-ended technical questions that would draw out interviewees and let us get a sense of their thought process. A surprisingly simple question came up that seems to work well - it makes the candidate think through and explain ...
    Posted to Merrill Aldrich (Weblog) by merrillaldrich on November 1, 2010
  • The “D” in HADR

    HADR is an acronym that stands for High Availability / Disaster Recovery. Although you can think of these two concepts individually, I prefer to think of them on a continuum. If your system is spread out across multiple locations, for instance, it can be both highly available and able to quickly recover from a disaster. The “D” stands for ...
    Posted to Buck Woody (Weblog) by BuckWoody on July 6, 2010
  • Backup those keys, citizen

    Periodically I back up the keys within my servers and databases, and when I do, I blog a reminder here. This should be part of your standard backup rotation – the keys should be backed up often enough to have at hand and again when they change. The first key you need to back up is the Service Master Key, which each Instance already has built-in. ...
    Posted to Buck Woody (Weblog) by BuckWoody on April 20, 2010
  • Cluster Nodes as RAID Drives

    I'm unable to sleep tonight so I thought I would push this post out VERY early. When you don't sleep your mind takes interesting turns, which can be a good thing. I was watching a briefing today by a couple of friends as they were talking about various ways to arrange a Windows Server Cluster for SQL Server. I often see an ''active'' node ...
    Posted to Buck Woody (Weblog) by BuckWoody on March 25, 2010
  • Have you backed up your keys lately?

    Did you know that you already have a Server Master Key (SMK) generated for your system? That’s right – while a Database Master Key (DMK) is generated when you encrypt a certificate or Asymmetric Key with code, the Server Master Key is generated automatically when you start the Instance. So you should back all of those keys up periodically, and ...
    Posted to Buck Woody (Weblog) by BuckWoody on March 1, 2010
  • Don't get burned by replication of SQL Server files

    Here's a tidbit for those who might have SQL server in their environments, maybe without knowing all the nitty gritty low-down: if you try to use file system replication (robocopy, xcopy, repli-whatever) to maintain a DR server from your production SQL Server, you might be in for a nasty surprise. I recently had to troubleshoot a scenario ...
    Posted to Merrill Aldrich (Weblog) by merrillaldrich on February 1, 2010
  • Plan and Prepare or Just Do It? How about Both!

    I'm kind of a type ''A'' person. OK, I'm a VERY type ''A'' person. I even cook by setting things up ahead of time. I'm definitely more in the ''Plan and Prepare'' camp than the ''Just Do It'' camp. But I do realize that there are times when you just can't stop and prepare. Sure, it would be great to know that server is going to melt down just ...
    Posted to Buck Woody (Weblog) by BuckWoody on January 7, 2010
  • The Dark Sides of Consolidation

    Consolidation, as it applies to databases, is simply putting more databases or SQL Server Instances on less hardware. This is a good thing, normally, because it allows you to save on hardware costs and use what you have at it’s highest capacity. It also saves on energy costs, floor and rack space, and in some cases even licensing and ...
    Posted to Buck Woody (Weblog) by BuckWoody on December 10, 2009
  • Knowledge is how you break the rules

    Last night I had to do something on a production system that you're not supposed to do. It's not important what I did or where I did it, but I will explain why I did it. A friend was in a situation where it was either ''break the rules'' or lose the system. So I did what I had to do, with lots of caveats and explanations on why ...
    Posted to Buck Woody (Weblog) by BuckWoody on December 8, 2009
  • Oh, the horror! Please stop telling people they should shrink their log files!

    I realize that there are some cases where, in an emergency, you need to shrink a log file because it took over the drive.  In SQL Server 2005 and earlier, you could get out of the jam quickly, by issuing a BACKUP LOG WITH TRUNCATE_ONLY (followed by DBCC SHRINKFILE).  In SQL Server 2008, this ''feature'' within BACKUP LOG is no longer ...
    Posted to Aaron Bertrand (Weblog) by AaronBertrand on July 27, 2009
Privacy Statement