如何每周转移一个数据库用于分析目的

您可以查看日志传送，与“手动”方法非常相似，但使用内置的SQL组件来完成这些工作，并使用事务日志备份。

数据库镜像的一个很好的解释和比较可以在http://blogs.technet.com/josebda/archive/2009/04/02/sql-server-2008-log-shipping.aspx

作为一个单纯的build议，你说你的数据库是36演出。 根据传输的压缩率和速度，您可能会发现将其转储到USB驱动器上更容易，而蜗牛邮寄它。 此外，一些ftp将永远不会允许大于4GB的文件。 增量推动可能是你的方式，但再次考虑最坏的情况：如果你的数据变化比你的数据库可以推送到复制器更快？

我有一个客户谁需要这个确切的事情。 当日志恢复时，他们无法接受数据库无法访问，因此日志传送失败。 复制是不可能的，因为他们的模式将是太多的ha </s>。 镜像将无法工作，因为它是只读的，而且它们需要一个可写的数据库…但这些写入不必返回到主服务器。

我最终编写了一个维护计划和几个脚本来完成对数据库的完整备份（120 GB），然后使用xp_cmdshell将文件复制到另一个SQL Server上的networking共享，然后最后远程执行作业（您可以设置要在计划步骤中执行的服务器）来执行数据库还原。

你可能想看看塔拉·凯泽的isp_Restore脚本，可以帮助你。 http://weblogs.sqlteam.com/tarad/archive/2005/11/08/8262.aspx我写了自己的脚本，因为她没有做我所需要的，但至less应该让你开始&#x3002;

日志传送非常适合进行分析，但要做好备份和将数据传输到另一个服务器/实例的高开销的准备。 此外，日志传送意味着实时数据和分析数据之间的延迟。 之后，您只能移动事务日志备份，这在理论上较小。

在我们的环境中，我们每天都会login船舶，因为pipe理层在上午进入办公室时运行报告，而这些报告通常需要大量的支持。

我们有一个4GB的数据库，我们很less需要备份分析问题。 数据库太大，无法在白天进行生产。 所以我们的解决scheme是在我们的生产系统停机的时候在晚上进行备份，并保留最近的备份（我认为我们保留了一周）。

我们的一个要求是数据库需要根据问题发送到不同的部门。 另一个原因是，我们可以将备份文件提供给项目经理，他们不能直接访问任何SQL服务器，他们负责将备份发送给相应的收件人。 他们不需要pipe理员来获取备份。

每日备份使用标准的SQL服务器工具进行计划。

假设您的目标分析数据库与您的生产数据库是相同的平台，最简单的解决scheme是每周进行一次增量备份，然后将其应用于分析数据库。 如果你的数据库增长速度不是很快，增量文件应该在合理的时间内传输。

如果您要传输的数据types与您当前正在生产的数据库types不同，则可以使用像Pentaho数据集成这样的ETL工具。 一个ETL工具是一个更好的解决scheme，如果你只关心一些表，而不是全部。