brent ozar的sqlserver dba训练课程翻译——第二章：手动恢复数据库

备份的唯一原因

备份的唯一原因是我们可以还原

 

当我第一次成为sqlserver数据库管理员，只要备份工作都能成功运行，我就会觉得一切都很好。我会查看sqlserver代理，保证那些作业都在运行，然后就这样了。

我想只要发生灾难了，我只需要做一个恢复。这能有多难？

 

理论上，我们使用凯德拉的5个简单问题来测试我们的备份策略，并且我们要记住会导致dba被解雇的9个注意事项。

 

在实践中，有一些小问题会困扰我们。当出现问题的时候，我们是否要还原整个数据库——即只恢复几个表还是一个完整的数据库。有些人把生产环境的数据库当做开发环境从而不小心删除了数据库，接下来的事情当然是大家都疯掉了。提前思考我们的备份计划可以使危机处理地更加容易。

 

 

在那里做恢复

​当你恢复代码（存储过程、视图、触发器等）或者表时，不要恢复到生产服务器上。 

我并不喜欢去动生产数据库，当我们面对这些事故时——你就已经有了糟糕的一天。这就是你为什么做还原，还记得吗？

让我们在不同的环境（开发或者测试）做不同的事情，远离生产环境。我也会写如何在开发、测试和生产环境中还原。 

当我们安全的恢复一个数据库后，可以很容易的把数据复制到其他的服务器上面。你可以在生产环境上通过连接服务器安全而简单的访问只读的恢复服务器上的数据库。并且，从生产数据库可以通过连接服务器把数据导到恢复数据库上。 

然后，如果要恢复的数据超过10G，那么你可能必须在生产数据库上恢复以加快速度。我们必须非常小心，并且确保你的脚本和数据库名称正确——我们不想覆盖正在工作中的数据库。这可能需要生产服务器增加额外的空间，在一个紧急情况下，我不得不把tempdb和log文件缩小到1M来释放可用空间。tempdb在一个非常快的磁盘上，并且恢复过程中没出现例如断电等其它问题，因此这次恢复完美的完成了。我们并不会总是这么好运，但这有利于我们想出更多这样的情形。 

一个警告：如果存在依赖性关系，比如一个表和其他表存在依赖关系，而你恢复了这个表，而没有恢复这个表依赖的那个表，那么这会造成伤害。我们不能说到所有的场景——真的，每种情况都是不同的。

 

执行恢复 

使用no recovery选项来恢复最近一次完整备份——这是非常重要的。

这使得数据库处于恢复状态，并且可以恢复其他的备份。如果你忘记了这两点，那么可能你就需要再一次的从头恢复了，所以在你恢复之前，请务必仔细检查。 

如果我恢复的代码或者配置表在上一次完成备份后并没有更改，那么我不会还原之后的差异备份和事务日志备份，我们的目标是尽可能快的完成还原。 

接下来，在还原差异备份后还原事务日志备份（如果你在上一次完整备份后没有差异备份），同样，不要忘了no recovery。 

用图形界面执行这一切实在是糟透了。备份越多，你还原的时间就越长，并且更加容易出错。相反，你需要脚本来管理备份文件夹，找到对应的文件并进行自动回复。在接下来的培训里我们会讨论自动还原模块。 

学习备份和还原知识，我们推荐下列这些文章： 

• Grant Fritchey's SQL Server Backup and Restore for the Accidental DBA
• Brent's DBA Nightmare: SQL Down, No Plans
• Jes's 3 Things You Need to Start Doing to Your Database Server

感谢！我们下周再见！​