只是想知道你们采用什么样的流程将生产数据转移到场外进行分析？
我读过一些文献，但我不确定所涉及的开销和设置过程。
- 复制：生产既充当分发者又充当发布者。我将采用推送系统，每周更新分析服务器上的数据库
- SSIS：没有经验，但似乎是‘标准’方式？
- 手动：使用 Windows 调度程序压缩我的备份文件并打开与我的分析服务器的 FTP 连接
- 镜像：没有经验但更多用于高可用性？
仅供参考，我正在使用带有 Windows Server 2008 R2 的 SQL Server 2008。我的数据库大约有 36 GB。我只对数据感兴趣。
欢迎使用其他方法！
*编辑 附加信息：我不介意数据库是只读的，并且我希望每周运行一次这个过程。
答案1
您可以查看日志传送，它与您的“手动”方法非常相似，但使用内置 SQL 组件来完成工作并与事务日志备份一起工作。
关于数据库镜像的详细解释和比较请参见http://blogs.technet.com/josebda/archive/2009/04/02/sql-server-2008-log-shipping.aspx
答案2
仅作为建议，您说您的数据库是 36 GB。根据压缩 + 传输速度，您可能会发现将其转储到 USB 驱动器上并通过蜗牛邮件发送更容易。此外，某些 ftp 永远不会允许大于 4GB 的文件。增量推送可能是您的方法，但再次考虑最坏的情况：如果您的数据更改速度快于您的数据库将其推送到复制器的速度，会发生什么？
答案3
我有一个客户需要这个东西。他们无法接受日志恢复时数据库无法访问，因此日志传送被取消。复制是不可能的，因为他们的架构太麻烦了。镜像不起作用，因为它是只读的，他们需要一个可写的数据库……但那些写入确实不是必须返回主服务器。
我最终编写了一个维护计划和一些脚本，对相关数据库（120 GB）进行完整备份，然后使用 xp_cmdshell 将文件复制到另一台 SQL 服务器上的网络共享，最后远程执行一项作业（您可以在计划步骤中设置要在哪个服务器上执行）来恢复数据库。
您可能需要查看 Tara Kizer 的 isp_Restore 脚本，它可以帮助您解决这个问题。 http://weblogs.sqlteam.com/tarad/archive/2005/11/08/8262.aspx 我最终编写了我自己的脚本，因为她的脚本并没有完全满足我的需要，但它至少可以帮助你入门。
答案4
我们有一个 4GB 的数据库，我们很少需要备份来分析问题。数据库太大了，无法在白天生产运行时进行备份。所以我们的解决方案是在晚上生产系统停机时运行备份，并保留最新的备份（我认为我们保留了一周）。
我们的要求之一是需要根据问题将数据库发送到不同的部门。另一个原因是，我们可以将备份文件提供给项目经理，他们无法直接访问任何 SQL 服务器，并且负责将备份发送给适当的收件人。他们不需要管理员参与来获取备份。
使用标准 SQL 服务器工具来安排每日备份。