从备份还原SQL数据库是否从头重build其表和索引？ 还是保持它在备份时的内部物理顺序？
我们使用SQL 2000与Quest Lightspeed压缩备份，如果这有什么区别的话。
答案是否定的，无论使用哪种备份软件。
备份是物理操作，而不是逻辑操作。 它读取包含已分配页面的所有盘区（即使只分配了一个从8页扩展盘区中的单个页面，它将备份整个64K盘区），并按物理顺序进行。
还原是物理操作，而不是逻辑操作。 它在数据文件中规定了适当的地方。
重build索引（或类似的东西）是一个逻辑操作，必须logging下来。 备份和恢复直接操作数据文件，而不经过缓冲池，这是无法完成的一个原因。 另一个不能完成的原因是备份和还原不理解被备份的数据中包含的内容。
然而，这不能做的主要原因是在恢复操作期间移动页面会破坏b-tree指针。 如果页面A指向页面B，但页面A被恢复过程移动，页面B如何更新为指向页面A？ 如果它立即更新，则可能会被恢复过程的其余部分覆盖。 如果延迟更新，如果还原过程恢复了删除页面A或页面B的某个事务日志，该怎么办？ 它根本无法完成。
底线 – 备份和恢复是永不改变数据的物理操作。
希望这可以帮助！
PS虽然没有直接解决这个问题，但请查阅我为7月TechNet杂志撰写的文章，其中解释了各种备份如何在内部工作： 了解SQL Server备份 。 9月份的杂志将在理解恢复系列的下一个。
原生 SQL备份只是备份文件的逐页转储，所以答案是“否”。 任务光速备份可能使用某种压缩压缩algorithm，但它仍然不会“重build”数据文件或索引，这将在大型数据库上花费可怕的大量时间。
备份定期和经常进行（我希望）。 所以devise师确保备份尽可能快。 什么是最快的I / O？ 顺序。 您以精确的物理顺序从磁盘中读取块，可以获得最佳性能。
为什么地球上的数据库每一个晚上都要执行繁琐的随机I / O操作，把磁盘的头部砸到什么地方？ 差别将在两个数量级左右。 这是没有可能的收益。
嗯。 BradC，你之前是否和Firebird / Interbase一起工作 – 主备份/恢复实用程序/ API与SSMS / EM的“Copy Database …”更类似？ 如果是这样，知道MS SQL Server是不喜欢它。
一个SQLServer备份更多的是一个数据库转储，它是“AS-IS”恢复的 – 所以它更像是一个“在其他地方进行分离 – 复制 – 重新连接”操作的一个舒适的在线快捷方式。 还原的数据库几乎是原始数据库文件的精确副本（几乎因为您可以更改已还原数据库的数据库文件的位置）…