从备份中恢复 SQL 数据库是否会从头重建其表和索引？还是会保持备份时的内部物理顺序？
我们正在使用带有 Quest Lightspeed 压缩备份的 SQL 2000，如果有任何区别的话。
答案1
答案是否定的，无论使用什么备份软件。
备份是物理操作，而不是逻辑操作。它会读取包含已分配页面的所有区段（即，即使仅分配了 8 页区段中的单个页面，它也会备份整个 64K 区段），并按物理顺序执行。
恢复是物理操作，而非逻辑操作。它将范围放在数据文件中的正确位置。
重建索引（或类似操作）是逻辑操作，必须记录。备份和恢复直接操作数据文件，而不经过缓冲池，这是无法做到这一点的原因之一。无法做到这一点的另一个原因是备份和恢复不了解正在备份的数据中包含什么。
但是，无法做到这一点的主要原因是，在恢复操作期间移动页面会破坏 B 树指针。如果页面 A 指向页面 B，但页面 A 被恢复过程移动，那么页面 B 如何更新以指向页面 A？如果立即更新，则可能被其余的恢复过程覆盖。如果延迟更新，那么如果恢复过程恢复了删除页面 A 或页面 B 的某些事务日志怎么办？这根本无法做到。
底线 - 备份和恢复是永远不会改变数据的物理操作。
希望这可以帮助！
PS 虽然它没有直接解决这个问题，但请查看我为 7 月份的 TechNet 杂志撰写的文章，其中解释了各种备份的内部工作原理：了解 SQL Server 备份。九月号的杂志将刊登下一篇有关理解恢复的文章。
答案2
A本国的SQL 备份只是对备份文件逐页转储，因此答案是“否”。Quest lightspeed 备份可能使用某种压缩算法，但它仍然不会“重建”数据文件或索引，而这在大型数据库上会花费大量时间。
答案3
备份是定期进行的，而且非常频繁（我希望如此）。因此，设计师确保备份尽可能快。最快的 I/O 是什么？顺序。您以精确的物理顺序从磁盘读取块，性能最佳。
数据库为什么要执行繁琐的随机 I/O 操作每天晚上，把磁盘的磁头弄得到处都是？差别大约是两个数量级。这样做不可能有任何好处。
答案4
嗯。BradC，你以前用过 Firebird/Interbase 吗？它的主要备份/恢复实用程序/API 更类似于 SSMS/EM 的“复制数据库...”？如果是的话，要知道 MS SQL Server 并不像它。
SQLServer 备份更像是按“原样”恢复的数据库转储 - 因此它更像是“分离-复制-重新附加到其他地方”操作的便捷在线快捷方式。恢复的数据库几乎是原始数据库文件的精确副本（几乎是因为您可以更改恢复的数据库的数据库文件的位置）...