我正尝试节省一些时间来完成那些我经常被要求重复做的任务。
我们有一个内部应用程序，我们称之为“App”。
该应用程序有一个名为“AppLive”的数据库
我们有同一个应用程序的“测试”实例，它使用数据库“AppTesting”。这样我们就可以执行测试等，而不会影响我们的实时数据。
当用户想要开始使用应用程序的测试实例时，系统会要求我“将实时数据导入测试数据库”。他们需要将 AppLive 数据库中最新的实时数据集导入 AppTesting 数据库。
我当前的流程是这样的：
对实时数据库进行最近一次夜间完整备份。删除测试数据库，将 AppLive 备份文件“恢复”到名为 AppTesting 的新数据库（与已删除数据库同名）。
这为我们提供了最新的夜间数据存入测试数据库。
问题在于数据库变得越来越大。它大约有 11GB - 并且备份文件远程存储在 NAS 驱动器上。
因此，我必须等待 45 分钟才能将数据库备份文件传输到 SQL 服务器上，然后开始导入。这又需要很长时间。
我对此的理想解决方案是：
继续每晚对 AppLive 数据库进行完整备份（以满足我们的正常备份要求），并在此基础上进行增量备份 - 这样当我必须将实时数据导入我们的测试数据库时，我就不必处理巨大的 11GB 文件。理想情况下，我希望能够对 MSSQL 管理工作室说“请使用来自 AppLive 的所有新数据更新 AppTest 数据库” - 但我不想安排这个，测试数据必须保持静态，直到我们被要求用新数据更新它。
我希望这足够清楚并且有人能够为我指明正确的方向。
答案1
您有几个选择。
1) 编写 powershell 脚本或其他东西来自动执行恢复。这将使它变成一劳永逸的事情。然后，您可以选择将其与工具的定期运行（例如在星期日）结合到第三个数据库中。这意味着与测试数据库的使用者坐下来，弄清楚他们对陈旧数据的容忍度是多少（即数据库需要多新）。然后，当请求刷新数据时，您删除当前的测试数据库，将恢复的重命名为副本（您可能还想重命名物理文件），然后就可以开始了。
2）日志传送
3）数据库镜像。
对于您要完成的任务而言，选项 2 和 3 似乎有些过度了。