24.26个有关原(Restore)的误区.docVIP

Myth #24:?26个有关还原 Restore 的误区 都是错误的 24 a 可以通过WITH STOPAT参数在完整备份和差异备份的基础上还原到特定时间点 当然不能。虽然这个语法看上去貌似能的样子，但这个语法的最佳实践是你在进行日志还原到特定时间点时带上，这样你的还原就不会超过这个时间点（译者注：比如说还原的第一个日志备份中不包含这个时间点，但你带上这个参数则这个日志备份会被全部还原，直到你还原到包含时间点的日志备份而不用担心还原过头）,对此我之前的一篇文章会更有帮助:Debunking a couple of myths around full database backups。 24 b 使用了WITH CONTINUE_AFTER_ERROR选项之后还可以按照既定的还原顺序进行还原 错误。如果你的备份集有损坏而不得不使用这个选项，那么你的还原顺序将会不复存在。当进行日志还原时日志损坏，那么使用这个选项之前就需要三思而后行，因为这很有可能造成数据不一致的问题。在最坏的情况下会造成数据库中结构被破坏，我不推荐使用这个选项。 24 c 可以将数据库的一部分还原到特定时间点 不能，数据库的每个部分都需要和主文件组时间点一致，否则就无法上线。当然只读文件组除外。 24 d 可以将不同数据库的不同文件组还原到一个新的数据库中 不能，每个数据库的文件头页（译者注：也就是页号为0的页）都有一个GUID，除非这个GUID和另外数据库的GUID一致才能还原（这当然不可能）。 24 e 还原可以去除索引碎片（或是更新统计信息等等） 不能，你备份的是什么还原的就是什么，我之前的一篇文章对此有更详细的解释:blog post over on our SQL Server Magazine QA blog。 24 f 在还原的过程中可以进行数据库收缩 不能，虽然大家都需要这个功能，在开发环境下恢复一个大部分是空的备份集时这就十分有用。但就是不能。 24 g 可以将数据库还原到任何更低版本的实例 不能，这是一个普遍存在的误区。低版本的实例对于高版本的数据库的部分内容有可能无法理解（比如sql server 2005的数据库就无法理解SQL Server 2008数据库的一些内容）。 24 h 可以将数据库还原到任意版本的SQL Server中 错误，比如说SQL Server 2005,一个含有表分区的数据库只能还原到企业版中。在SQL Server 2008只能还原到企业版的数据库包含了如下特性:分区，透明数据加密，CDC,数据压缩。有关这里我已经写过一篇文章，请看:SQL Server 2008: Does my database contain Enterprise-only features?。 24 i WITH STANDBY参数会破坏还原链 不会，这个参数的作用是使得在还原的过程中，保证数据库事务级别的一致性。从还原顺序的角度来说，With Standby参数WITH NORECOVERY并无区别。你可以在还原的过程中停止N次。这也是事务日志传送的机制。经常有人会问在事务传送的辅助服务器进行日志恢复的过程是否能访问，至此你应该知道是可以只读访问的。同时，这个选项也可能造成一些诡异的问题，请看:Why could restoring a log-shipping log backup be slow?。 24 j 如果备份数据库的服务器没有开启即时文件初始化选项，那么恢复的服务器就不能利用这个特性 是否能进行即时文件初始化完全取决于被还原的服务器受否开启这个特性。备份集中不会含有任何有关这点的信息。更详细的内容请看:SQL Server误区30日谈-Day3-即时文件初始化特性可以在SQL Server中开启和关闭。 24 k 还原是从损坏中恢复的最佳办法 不是,并不完全是。这要取决于你有的备份类型。如果损坏的数据比较多，那么利用还原是一个不错的主意，但如果损失的数据比较少并允许一些数据损失的情况下，亦或是由事务日志传送的辅助服务器回传一些日志的情况下，那么downtime就会少很多。最佳办法就是在可接受的数据损失范围内，在尽量少的downtime修复损坏。 24 l 在开始还原之后还可以备份尾端日志 不允许，一旦你开始还原之后，就不再允许备份尾端日志。所以当灾难发生之后，第一件事永远都是查看是否需要备份尾端日志。 24 m 你可以还原到在备份的日志范围之内的任何时间点 这是不对的。如果日志中包含了那些那些仅仅少量日志的操作 比如批量数据导入操作 ，这类操作具有原子性，要么全部还原，要么不还原。这是由于这类操作对于区的进行了修改，但备份集中并没记录何时修改了这些区。你可以通过如下脚本查看日志备份包含的信息量：New script: