我是一家小型SaaS公司（约50名员工）的SQL开发人员（不是DBA或架构师）。我的任务是弄清楚如何：
- 从我们100多个OLTP数据库中卸载运营报告
- 允许这些报告针对来自多个客户端数据库的数据运行
- 定位我们的公司以在将来提供更多基于分析的解决方案
我已经阅读了许多有关各种技术的文章，例如事务复制（特别是多对一/中央订户模型），SQL服务代理，日志传送，变更跟踪（CT）和变更数据捕获（CDC），我的理解是这仅适用于企业），我不确定最好采用哪种方法。
我希望一些具有集成专业知识的人可能会遇到与我们类似的设置，并且能够指出成功的道路或将我引向一些有帮助的资源。
由于成本限制，我们的解决方案必须在SQL Server Standard Edition中运行。另外，解决方案必须合理，才能在我们的小型组织内提供支持/维护。
基本配置：
目前，我们有100多个单独的客户端数据库，大多数部署在我们数据中心的SQL服务器上，但是有些部署在我们数据中心内的客户端服务器上，我们可以远程访问这些数据库。这些都是SQL Server 2008 R2数据库，但是我们计划很快升级到SQL 2016。
我们使用数据库项目和dacpacs来确保所有要集成的客户端数据库中的架构都是相同的。但是，由于我们不强制所有客户端同时升级到新版本，因此升级之间可能会存在一些架构差异。如果客户端A在软件版本1.0上并且客户端B在软件版本1.1上，则解决方案必须足够灵活，以免损坏。
当前，操作报告直接从每个客户端的OLTP数据库运行。如果我们不卸载应用程序，则会担心它会对应用程序性能产生影响。
高级要求：
我们的客户是医院无菌处理部门（SPD），他们需要有关其到目前为止所处理的内容，库存在何处等的最新报告。SPD每天（包括周末和节假日）的过程库存。由于这项工作的主要目的之一是更好地支持运营报告，因此我们希望数据尽可能接近实时，以继续满足客户的需求。
目前，我们在单独的数据库中有一些SPD，这些数据库实际上是同一医院系统的一部分。这些客户希望能够针对其系统中的所有SPD进行报告。
从战略上讲，我们希望能够轻松汇总所有客户的数据以支持我们的内部分析计划。我们的期望是，我们将能够使用收集到的运营数据作为数据集市/仓库的来源。
思念至今：
事务复制似乎将提供最“实时”的解决方案。我发现此响应特别有用，但我担心由于存在架构差异的可能性，因此对我们不起作用：SQL Server多对一复制
鉴于查询活动时日志无法还原，日志传送听起来并不理想。我要么将所有人踢出去，以便可以恢复日志，否则数据将变得过时。我不清楚该方法是否可用于集中多个数据库中的数据，因为每个出厂的日志仅适用于它来自的单个数据库。
使用SQL Service Broker，如果队列无法跟上要处理的消息数量，则延迟可能是不可预测的。
CT仅为每个表行标识一个版本。延迟时间取决于我们对每个数据库处理诸如SSIS包之类的东西以检索数据并将其插入中央存储库的速度。
我们是否需要考虑分别复制每个数据库，然后使用某种数据虚拟化技术来组合来自各种复制源的数据？
您愿意提供的任何建议或指示将不胜感激。
