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: how much data will the next log backup include?。
24 n)只要备份成功，就可以利用这个备份集进行还原
No,no,no。备份集只是存储在IO子系统的文件，就和数据库的文件一样。它也有损坏的可能。你需要定期检查备份是否被损坏，否则当灾难发生后的惊喜怕你是承受不了。请看:Importance of validating backups。另外一点需要注意的是避免额外的完整备份破坏恢复顺序，这个例子或许会给你一点警示：BACKUP WITH COPY_ONLY – how to avoid breaking the backup chain。
24 o)所有的SQL Server页类型都可以通过单页恢复进行还原
不，一些分配位图的页（译者注：比如GAM,SGMA,FPS页等）不能通过进行单页还原(这类页可以通过SQL Server 2008 的镜像进行自动页修复)。详情你可以看我这篇文章:Search Engine Q&A #22: Can all page types be single-page restored?。
