SQLServer2008如何还原数据库

危险在于：恢复数据库前没有检查文件权限，SQLServer服务帐户没有权限，导致失败。

不要相信这一点：在恢复操作期间不要选中[恢复]选项，仅验证备份文件。

不要：当目标驱动器空间不足时，您将不得不恢复数据，这可能会导致数据损坏。

sql数据库替换还原方法

说实话，刚进入这个行业的时候，我对于数据库的替换是很困惑的。
后来接手一个老项目，发现全是一堆老域名的文章链接。
客户给我的压力很大，所以我硬着头皮。

先说单表字段替换。
这个东西是最简单、最基本的。
我以MySQL的oblog_log表为例，使用REPLACE函数将“bioguider.com”替换为“blog.bioguider.com”。
调试的时候卡了好久，因为REPLACE是区分大小写的。
记得将‘bioguider.com’更改为‘BIOGUIDER.COM’并尝试一下，但没有成功。
后来查手册才发现必须用REPLACE(logtext, 'bioguider.com', 'blog.bioguider.com')，而且中间不能加引号。
实在是让人哭笑不得。
此方法适用于具有数十万条记录的小型表。
如果表太大，效率就会出现问题。

我们来谈谈SQL Server的全库批量替换。
我运行过一次这个东西。
当时，一个客户的网站域名被黑客盗取，更换了新域名。
整个数据库中的数百个表必须更改。
一开始我想换成单表，但是运行了几张表后我就傻眼了——我得写一个存储过程来遍历表和字段，而且还要加上判断文本类型。
代码让我秃头了。
最后我向师父求助。
他编写了一个存储过程并使用 sp_MSforeachtable 运行它，这非常高效。
但请注意，这种操作是有风险的。
那次我也加了事务回滚，但是发现临时表没有加，整条线都快崩溃了。

最可靠的是备份和恢复。
我接手了一个项目，我的前任老板丢失了数据库备份。
最后，我不得不从一周前的备份中恢复它。
使用SSMS拖拽一个备份文件到恢复窗口，点击确定，几分钟就搞定了。
然而，这种方法有一个缺陷。
恢复前必须创建一个空数据库，否则会提示冲突。
记得有一次我用手输入了错误的数据库名称，差点把生产数据库恢复到测试环境中。
幸好同事发现得早。

说实话，现在年轻人使用更高级的解决方案，比如使用ETL工具或者编程语言编写脚本进行替换。
但随着旧项目的堆积，我们还是得回到这些原来的方法。
不过话说回来，如果你不熟悉这些基本操作，遇到紧急情况还是要手忙脚乱的。

如何在SQL Server 2008 R2中还原数据库

说实话，第一次执行这个数据库恢复操作时，我的手心都是汗。
你说的步骤是正确的，但是有几个地方我必须提醒你，否则很容易出问题。

以“覆盖现有数据库”选项为例。
我当时犯了一个错误。
我记得有一次我的手颤抖着，我没有仔细看就点击了“覆盖现有数据库”。
结果呢？ 上周几个同事提交的测试数据全没了。
当时我真想给自己一巴掌。
所以现在我的习惯是在恢复之前先在测试环境中练习一下，或者把原来的数据库备份到别处。

还有“选择一个备份集进行恢复”，这一点非常关键。
例如，如果你同时有一个完整备份+一个差异备份，你就必须弄清楚先恢复哪一个。
我当时有一个项目，数据库管理员逆序选择了差异备份，导致恢复的数据是旧版本。
我花了很长时间才找出问题所在。
说实话，我当时很困惑。

关于 BAK 文件路径有一个小技巧。
如果你的数据库文件在D盘，但是BAK文件在E盘，如果直接点击“添加”，会找不到该文件。
我通常将BAK文件复制到与数据库文件相同的目录中，这样操作起来就容易多了。
当然，这个trick并不适合生产环境，必须按规矩来。

我记得有一次我遇到了一个奇怪的问题。
恢复数据库后，报“资源不足”。
后来查看系统日志，发现临时文件空间不足。
大家在操作的时候也一定要注意这个细节，不要只关注BAK文件本身。

现在我的操作很多，基本上都是右键数据库，直接选择“恢复数据库”。
但每次我都会习惯先检查备份文件的日期，确认是最新版本再继续。
这个习惯多次救了我。

微软的文档确实很详细，但是有一个问题是国内很多公司系统都是中文的，翻译出来的文档偶尔会出现歧义。
我建议您在恢复之前保存关键步骤的屏幕截图，这比阅读文档更容易。

最后说一下我踩过的一个坑：恢复生产数据库时，不要忘记将数据库恢复模式改回“简单模式”。
我的一个朋友就是因为这个原因在恢复系统后不得不花很长时间重新设置备份策略。
这真的很累而且不公平。