只是想知道你们有什么样的流程可以将生产数据转移到异地进行分析？
我已经阅读了一些文献，但我不确定所涉及的开销和设置过程。
- 复制：生产既是分销商又是出版商。我将使用一个推送系统，每周在我的分析服务器上更新我的数据库
- SSIS：没有经验但似乎是“标准”方式？
- 手动：使用 Windows 调度程序压缩备份文件并打开到我的分析服务器的 FTP 连接
- 镜像：没有经验但更多用于高可用性？
仅供参考，我将 SQL Server 2008 与 Windows Server 2008 R2 一起使用。我的数据库大约有 36 个演出。我只对数据感兴趣。
欢迎其他方法！
*编辑 附加信息：我不介意数据库是只读的，我希望每周运行一次这个过程。
您可以查看日志传送，这与您的“手动”方法非常相似，但使用内置 SQL 组件来完成工作并使用事务日志备份。
可以在http://blogs.technet.com/josebda/archive/2009/04/02/sql-server-2008-log-shipping.aspx看到对数据库镜像的一个很好的解释和比较
仅作为建议，您说您的数据库是 36 gigs。根据压缩和传输速度的不同，您可能会发现将其转储到 USB 驱动器上并通过邮寄方式更容易。此外，某些 ftp 永远不会允许大于 4GB 的文件。增量推送可能是您的方式，但请再次考虑最坏的情况：如果您的数据更改速度快于数据库将其推送到复制器的速度会怎样？
我有一个客户需要这个确切的东西。他们无法接受日志恢复时无法访问的数据库，因此日志传送已结束。复制是不可能的，因为他们的模式太麻烦了。镜像不起作用，因为它是只读的，而且他们需要一个可写的数据库……但这些写入不必返回到主服务器。
我最终编写了一个维护计划和一些脚本，这些脚本对相关数据库（120 GB）进行了完整备份，然后使用 xp_cmdshell 将文件复制到另一个 SQL 服务器上的网络共享，最后远程执行作业（您可以在计划步骤中设置要在哪个服务器上执行）来恢复数据库。
您可能想查看 Tara Kizer 的 isp_Restore 脚本，它可以帮助您解决这个问题。 http://weblogs.sqlteam.com/tarad/archive/2005/11/08/8262.aspx 我最终编写了自己的脚本，因为她的脚本并没有完全符合我的要求，但它至少应该让你开始。
日志传送非常适合分析，但要为初始备份和将数据传输到另一个服务器/实例的高开销做好准备。此外，日志传送意味着实时数据和分析数据之间存在延迟。之后，您只需移动理论上更小的事务日志备份。
在我们的环境中，我们每晚记录船舶，因为管理层在早上进入办公室时会运行报告，而这些报告通常需要大量的数据透视。
我们有一个 4GB 的数据库，我们很少需要备份来分析问题。数据库太大，无法在生产运行的白天进行备份。所以我们的解决方案是在晚上生产系统出现故障时运行备份，并保留最新的备份（我认为我们保留了一周）。
我们的要求之一是需要根据问题将数据库运送到不同的部门。另一个原因是，我们可以将备份文件提供给项目经理，他们没有直接访问任何 SQL 服务器的权限，他们负责将备份发送给适当的收件人。他们不需要让管理员参与来获取备份。
每日备份是使用标准 SQL 服务器工具安排的。
假设您的目标分析数据库与生产数据库是同一平台，最简单的解决方案是每周进行一次增量备份，然后将其应用到您的分析数据库。如果您的数据库增长速度不是很快，增量文件应该可以在合理的时间段内传输。
如果您要传输到其他数据库类型而不是当前在生产中运行的数据库类型，那么像Pentaho Data Integration这样的 ETL 工具可能更适合。如果您只关心一些表而不是所有表，ETL 工具是一个更好的解决方案。