bil*_*nkc 21 replication sql-server sql-server-2008-r2
我们的用户需要能够查询大部分是最新的数据库。数据可能会过时长达 24 小时，这是可以接受的。使用生产副本获取和保持第二个数据库最新的最低成本方法是什么？有没有我没有想到的方法？
我们有一个第三方应用程序用于监控股票交易活动。白天，作为各种工作流程的一部分，会发生许多小的变化（是的，这笔交易是有效的。不，这是可疑的，等等）。晚上，我们执行基于大集合的操作（加载前一天的交易）。
我们使用数据库快照。晚上 10 点，我们删除并重新创建快照。然后开始 ETL 处理。这显然对我们的磁盘造成了负担，但允许我们的用户能够在不锁定数据库的情况下查询数据库（他们使用 Access 前端）。他们在深夜和清晨使用它，因此他们会注意到停机时间。
这种方法的问题有两方面。首先，万一夜间处理失败，这种情况并不少见，我们可以恢复导致快照被删除的数据库。另一个问题是我们的处理时间超过了 SLA。在确定了写得不好的查询和缺乏索引后，我们正试图通过与供应商合作来解决这个问题。数据库快照也是造成这种放缓的罪魁祸首，这一点可以从存在与不存在时的速度差异中得到证明——我知道，这令人震惊。
我们打开了数据库集群，但这并没有解决使数据可用的需求，而且通常只会使管理员的生活变得复杂。它已被关闭。
我们上周开始研究复制。我们的理论是，我们可以建立第二个目录并与生产数据库同步。在 ETL 开始之前，我们将切断连接，只有在 ETL 过程完成后才重新启用它。
管理员从快照复制开始，但他担心需要多天的高 CPU 使用率来生成快照以及所需的磁盘消耗。他表示，它似乎在向订阅者发送之前将所有数据写入物理文件，因此我们的 .6TB 数据库将花费 1.8TB 的存储成本。此外，如果生成快照需要数天时间，则它不符合所需的 SLA。
阅读完这篇好文章后，似乎 Snapshot 可能是初始化订阅者的方式，但之后我们希望切换到事务复制以保持同步。我假设打开/关闭事务复制不会强制完全重新初始化？否则，我们将打破我们的时间窗口
我们的数据库处于完全恢复模式，因此数据库镜像是一种选择，但我对它的了解甚至比复制还要少。我确实找到了指示“数据库镜像阻止直接访问数据，镜像数据只能通过数据库快照访问”的SO 答案。
听起来日志传送也可能是一种选择，但这是我一无所知的另一件事。它会是比其他任何解决方案（实施和维护）成本更低的解决方案吗？基于 Remus 的评论“日志传送允许对副本副本进行只读访问，但在应用收到的下一个备份日志时（例如，每 15-30 分钟）将断开所有用户的连接。” 我不确定停机时间会转化为多长时间，因此可能会导致用户有些焦虑。
我上周末才听说使用Sync，还没有研究它。我不想为像这个问题那样具有高知名度的东西引入新技术，但如果它是最好的方法，那就这样吧。
我们在这里做了大量的 SSIS，所以生成几百个 SSIS 包来保持辅助同步对我们来说是一种选择，尽管这是一个丑陋的选择。我不喜欢这样做，因为我不希望我的团队承担很多维护开销。
过去，我听说我们的管理员使用一些 SAN 技术对整个磁盘进行即时备份。也许有一些 EMC 魔法可以用来制作 mdf/ldf 的 uberquick 副本，然后我们可以分离/附加目标数据库。
我认为我们每周进行一次完整备份，每晚进行一次差异，每 15 分钟进行一次 tlog。如果用户可以忍受 3-4 小时的完全恢复中断，我想这可能是一种方法。
Windows 2008 R2、SQL Server 2008 R2（企业版）、VMWare v5 企业版、驱动器映射到 vmdk 文件的 EMC SAN 存储、commvault 处理备份以及源目录中的 0.6TB 数据。这是我们内部托管的第三方应用程序。修改它们的结构通常是不受欢迎的。用户不能不查询数据库并拒绝通过主动识别他们监控的表来完成他们的工作而受到约束。
我们的 DBA 目前纯粹是承包商。专职人员已经启航，我们还没有取代他们。应用程序管理员并不精通 SQL Server 问题，我们有一个存储/VM 管理员团队可以帮助/阻碍这项工作。开发团队目前不参与，但可以根据方法招募。因此，更易于实施和维护的解决方案将是可取的。
我，我在 hosue 的开发方面，所以我只能提出方法，而不必处理事物的管理方面。所以没有时间在管理鞍座上，我很犹豫地说一种方法会优于另一种方法——根据论文，这一切看起来都很棒。我完全愿意按照你们建议的任何方向前进，因为在我看来，这只会让我作为一名 DB 专业人士更有价值。我有一辆独轮车，但没有可用的大屠杀斗篷。
解决@onpnt 的问题
用户当前查看的数据最多滞后 24 小时。数据是截至 2200 年的最新数据
给定的一分钟、一小时和一天的数据变化量不确定如何量化。营业时间，每小时可能有数百次变化。每晚处理，每个工作日数百万行
内部网络，独立的虚拟主机和专用存储
Windows 组将具有对辅助所有表的读取权限
对正常运行时间要求没有严格的定义。用户希望它始终可用，但他们是否愿意为此付费，可能不是那么多。实际上，我会说一天中的 23 小时就足够了。
不经常修改，对于表对象可能每季度一次。对于代码对象，可能每月一次。
没有特殊的安全需求。生产权限将与副本的权限相匹配。尽管在我看来，我们可以撤销用户对 prod 的读取权限，而只允许他们读取副本……虽然不是必需的。
恢复到快照可能是一种选择，但我认为他们没有追求它是有原因的。我会和管理员核对
我的假设是我们只使用其中一种方法，但这是一个很好的点，恢复会破坏“其他”同步技术。他们正在研究如何使用 EMC 快照魔法。正如管理员所描述的那样，他们将在 1900 处拍摄快照并将图像迁移到辅助节点的区域。这应该在 2200 年完成，然后他们将执行辅助数据库的分离和重新附加。
2012-10-29 我们评估了 EMC 快照魔术和其他一些复制选项，但 DBA 认为他们可以最好地找出镜像。对答案投赞成票，因为他们都提供了帮助，并给了我很多选择以及“家庭作业”进行调查。
小智 6
修改它们的结构通常是不赞成的
复制很有可能被淘汰，在那之前我会扔掉同步。（来自 Sync Framework 的现实生活中的高事务性测试）
如果 3-4 小时是您的数据延迟例外，那么日志传送可能是您在只读副本上的最佳选择。但是日志中发生了多少变化？发现这是监控它，看看你需要多快和多少推动。
如果你不能去镜像或升级到 2012 企业版，那将是一个合理的策略，如果你可以去企业，如果不这样做。
SSIS 并不意味着只是转储数据，但它可以做到。但是，您在查找转换方面考虑的太多了，而且该任务在时间和资源上都非常昂贵。虽然，就像我说的，它可以做到。
真的，根据回答几个问题，选择范围会明显缩小