只是想知道你们采用什么样的流程将生产数据转移到场外进行分析?
我读过一些文献,但我不确定所涉及的开销和设置过程。
- 复制:生产既充当分发者又充当发布者。我将采用推送系统,每周更新分析服务器上的数据库
- 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 服务器工具来安排每日备份。