2008年R2或2014至2016年“镜子”的高可用性选项用于报道？

Question

我是一个BI开发人员，正在研究这个场景的选项。

我将在这个问题的序言中说，我不知道合适的术语，所以我会在可能不是正式SQL术语的术语周围加上“引号”。

假设我有一个运行第三方供应商事务应用程序的SQL 2008 R2 SP1标准实例。我们无法在此数据库上创建或修改索引以优化报告查询的性能，因为它是供应商控制的数据库(一个常见的问题，是吗？)

我们希望有一个从源实例到SQL 2016 Enterprise实例的数据库(而不是整个应用程序)的“镜像”(因为缺少更好/准确的SQL术语)。

2016年的“镜像”将在2008年的R2源数据库中频繁插入/更新/删除“脉冲复制”，比如每隔1分钟(可能是5分钟，可能是10分钟，还不知道什么是可行的)。

2016年的“镜像”将用于报告目的，我们可以在不影响源数据库的同时(可能高达2,000次)的情况下对其进行调优和打击。

因此，“镜像”将成为报表的数据源(不需要从镜像到源进行负载平衡)，而不是实时数据库。

从2008年的R2 来源到2016年的目标失败是无关紧要的，也不是目标。

目标是将源数据库的“副本”或“镜像”复制到目标“镜像”，即在活动数据库的后面1到10分钟，并将“镜像”用于报告(SSRS、SSAS表格、Power BI等)。这样我们就可以自由地通过索引进行性能调优，等等，否则在供应商的数据库中是不允许的。

根据这些信息，“镜像”必须读写索引创建/修改/重新构建/重新构建/重新操作，还是只能读取？

对于这种混合Server版本方案，我们的有效选项是什么？

日志托运？

复制？

数据库镜像？

可用性小组？

其他人？

如果源系统从SQL 2008 R2标准升级到SQL2014企业，答案会改变吗？

我认为我的问题不同于2012+2014的高可用性服务器如何实现，因为需求是不同的，因此不是重复的。

Answer 1

唯一有效的选项是事务性复制。没有变化，因为您的下游版本是2008年R2。在处理类似于AGs的特性时，它通常是Server的主要版本。