我正在制作一个非常大的数据库（超过250个演出），超过2.25亿条logging。 这个数据库很难从其庞大的规模工作。 这个数据库只能作为只读使用。
我们正在寻找更快的硬件，但是我试图find最有效的方式来处理数据库。 该数据库必须每晚从主数据库更新，停机时间必须保持最短。 主数据库由第三方维护。
我试图find最好的方法来有效地更新数据库每晚，但我没有很多运气。 我研究了差异备份和事务日志备份，但为了应用其中的任何一个，必须首先恢复完整的数据库备份。 在我的情况下，这完全违背差异备份的目的，因为它不会节省我的任何时间。 我不妨每晚在master数据库上完成一次完整的备份，然后简单地恢复完整的备份，这样做会更快。
我希望find一个可以完成一次完整备份（或者一个月一次）的解决scheme，然后从那时开始，只需应用一些基于相互构build的增量式备份（基于原始完整备份） 。 这将使宕机时间降到最低，因为一旦完成第一次完整备份，我只能每晚应用增量备份。 我会简单地重build每个“增量”备份后的索引速度。 我还没有find像这样真正可行的解决scheme。
我已经尝试在testing数据库上做一个完全还原WITH STANDBY，这样我就可以查询数据，然后再应用事务日志和事务日志。 这是一个有限的成功，因为我不能做像添加索引，因为这是技术上写入数据库。 但是，这与我所寻找的非常接近，因为数据本身将是只读的。 有没有解决scheme是这样工作的？ 我宁愿避免使用STANDBY选项，因为它并不意味着以这种方式使用。
我现在正在深入研究数据库备份和性能，并不断阅读MSDN，但似乎这个解决scheme不是一个选项。 我以为我会问最后的手段 – 当然这里有一些pipe理大型数据库的地方，夜间恢复是不切实际的。
有什么build议么？ 我也开放给build议/链接到性能的页面，因为我从来没有一个数据库这么大的工作。
恐怕复制可能是唯一的答案。
日志传送满足了我们的需求，即保持主（300 GB）数据库可用，并将日志传送到另一台服务器上的备用副本。 事务日志每15分钟应用一次。 我们的报告利用备用副本。