我们已为客户端的.NET Web应用程序配置SQL Server 2012数据库事务复制，以在不同的SQL Server上分发SQL事务和报告。
我们已经实现了对SQL-Node1的事务复制作为主数据库服务器，我们在SQL-Node2上配置了主数据库的复制，以便将报告提取到我们的Web应用程序中，该应用程序具有大量的事务和数据上载excel表单每天大约有1000万条目。
在两个SQL Server 2012实例上配置复制后，几周后我们遇到了一些性能问题，发现在将文件上传到数据库时某些资源被锁定，这就是应用程序无法访问这些表和数据的原因。还发现当用户访问我们的Web应用程序时，服务器在白天执行的速度太慢。
现在我们正在寻找在SQL Server 2012的不同3个节点上分配负载。在Web应用程序将访问和交换SQL-Node1上的数据的情况下，报告查询从SQL-Node2获取拉取数据，SQL-Node3将习惯于将Excel工作表数据上传到数据库，该数据库将在所有其他SQL节点上进行复制。
当前设置，所有服务器都具有Windows Server 2008 Standard和SQL Server 2012 Enterprise Edition。
数据库大小约：15 GB /使用的复制：在SQL节点2上配置的SQL Node1 / Subscriber角色上配置的事务/分发器角色。
我们正在寻找解决方案来解决上述问题，这些问题可以分配不同的负载（报告，数据上传，事务）以及在所有SQL节点之间复制数据。
哪些功能在SQL Server 2012 HA，SQL Server复制或SQL Server镜像中对上述场景有效？
快速回复将受到高度赞赏....
答案 0 :(得分：1)
因为您在多个节点上发生了更改（节点1处的事务数据，节点3处的Excel上载），“以上都不是”。所有上述技术都建立在数据变化发生在一个位置并传播给其他位置的基础之上。你可以看看点对点复制，但看起来有点过分。
如果是我，我会尝试诊断文件上传过程为什么会破坏性能并修复/解决这个问题。完成后，我会将该流程移回节点1并实施可用性组以满足您的报告需求（增加HA的额外奖励）。
答案 1 :(得分：0)
所有这些技术都会陷入在一次大型交易中完成的大量数据导入。我建议把它作为一个类似ETL的功能。导入到临时表中并以一口大小的块将数据迁移到生产表中（测试许多数据行大小以找到最适合您环境的大小）。对于具有您正在讨论的工作负载的HA，群集上的2个服务器应该可以正常复制。