我正在处理一个非常大的数据库（250+GB），里面有超过 2.25 亿条记录。这个数据库太过庞大，很难操作。这个数据库只能以只读方式使用。
我们正在考虑购买速度更快的硬件，但无论如何，我都在尝试找到使用数据库的最有效方法。此数据库必须每晚从主数据库更新，并且必须将停机时间保持在最低限度。主数据库由第三方维护。
我正在尝试寻找每晚高效更新数据库的最佳方法，但运气不佳。我研究了差异备份和事务日志备份，但要应用其中任何一种，必须先恢复完整的数据库备份。就我而言，这完全违背了差异备份的目的，因为它不会为我节省任何停机时间。我还不如每晚对主数据库进行一次完整备份，然后简单地恢复完整备份，这样会更快。
我希望找到一种解决方案，让我可以进行一次完整备份（或者可能每月一次），然后从那时起简单地应用某种类型的增量备份（基于原始完整备份），这些备份相互建立。这将使停机时间降至最低，因为一旦完成第一次完整备份，我只会每晚应用增量备份。为了提高速度，我会在每次“增量”备份后重建索引。我还没有找到任何真正可行的解决方案。
我曾尝试在测试数据库上执行 WITH STANDBY 完整恢复，这样我就可以查询数据，然后稍后仍应用事务日志，并且只应用事务日志。这在某种程度上取得了有限的成功，因为我无法执行添加索引之类的操作，因为这在技术上是写入数据库。但是，这非常接近我想要的结果，因为数据本身将是只读的。是否有任何解决方案可以像这样工作？我宁愿避免使用 STANDBY 选项，因为它不适合以这种方式使用。
我现在正在深入研究数据库备份和性能，并不断阅读 MSDN，但似乎这个解决方案不是一种选择。我想我会作为最后的手段来询问——肯定有一些人管理着大型数据库，每晚进行恢复是不切实际的。
有什么建议吗？我还欢迎有关性能的建议/页面链接，因为我从未使用过这么大的数据库。
我担心复制可能是唯一的答案。
答案1
日志传送满足了我们的需求，即保持主数据库 (300 GB) 可用，并将日志传送到另一台服务器上的备用副本。每 15 分钟应用一次事务日志。我们的报告使用备用副本。