标签: integration

尝试在 sql server 2014 集成服务中创建目录时出现以下错误。知道我在安装或其他任何地方错过了什么吗？

无法访问目录备份文件“C:\Program Files\Microsoft SQL Server\120\DTS\Binn\SSISDBBackup.bak”。确保数据库文件存在，并且 SQL Server 服务帐户能够访问它（Microsoft.SqlServer.IntegrationServices.Common.ObjectModel）

我是一家小型（约 50 名员工）SaaS 公司的 SQL 开发人员（不是 DBA 或架构师）。我的任务是弄清楚如何：

1. 从我们的 100 多个 OLTP 数据库卸载运营报告
2. 允许这些报告针对来自多个客户端数据库的数据运行
3. 我们公司的定位是在未来提供更多基于分析的解决方案

我已经阅读了许多关于各种技术的文章，例如事务复制（特别是多对一/中央订阅者模型）、SQL 服务代理、日志传送、变更跟踪 (CT) 和变更数据捕获 (CDC，我的理解是这仅适用于企业），我不确定最好采用哪种路径。

我希望你们中的一些具有集成专业知识的人可能遇到过与我们类似的设置，并能够为我指明一条成功的道路或指导我找到一些有用的资源。

由于成本限制，我们的解决方案必须适用于 SQL Server 标准版。此外，解决方案必须合理以在我们的小型组织内支持/维护。

基本配置：

我们目前有 100 多个单独的客户端数据库，大多数部署在我们数据中心的 SQL 服务器上，但有些部署在我们可以远程访问的数据中心内的客户端服务器上。这些都是 SQL Server 2008 R2 数据库，但我们计划很快升级到 SQL 2016。

我们使用数据库项目和 dacpac 来确保架构在将要集成的所有客户端数据库中是相同的。但是，由于我们不会强制所有客户端同时升级到新版本，因此升级之间可能存在一些架构差异。如果客户端 A 的软件版本为 1.0 而客户端 B 的版本为 1.1，则解决方案必须足够灵活，不会中断。

操作报告目前直接从每个客户的 OLTP 数据库运行。如果我们不卸载它，我们担心这会对应用程序的性能产生影响。

高级要求：

我们的客户是医院无菌处理部门 (SPD)，他们希望获得有关他们迄今为止处理的内容、库存在哪里等的最新报告。 SPD 全天候处理库存，包括周末和节假日。由于这项工作的主要目的之一是更好地支持运营报告，我们希望数据尽可能接近实时，以继续满足客户的需求。

目前，我们在不同的数据库中有一些 SPD，它们实际上是同一医院系统的一部分。这些客户希望能够针对其系统中的所有 SPD 进行报告。

从战略上讲，我们希望能够轻松汇总所有客户的数据，以支持我们的内部分析计划。我们的期望是我们能够将收集到的运营数据用作数据集市/仓库的来源。

思念至今：

事务复制似乎会提供最“实时”的解决方案。我发现此回复特别有用，但我担心潜在的架构差异对我们不起作用：SQL Server 多对一复制

考虑到在查询处于活动状态时日志无法恢复，日志传送听起来并不理想。我要么必须把每个人都踢出去，以便日志可以恢复，否则数据将变得陈旧。我不清楚这种方法是否可以用于集中来自多个数据库的数据，因为每个传送的日志只会用于它来自的单个数据库。

使用 SQL 服务代理，如果队列无法跟上要处理的消息数量，则延迟可能无法预测。

CT 只为每个表行标识一个版本。延迟取决于我们对每个数据库处理 SSIS 包之类的东西以检索数据并将其插入中央存储库的速度。

我们是否需要考虑单独复制每个数据库，然后可能使用某种数据虚拟化技术来组合来自各种复制源的数据？

您愿意提供的任何建议或方向将不胜感激。

我们正在逐步淘汰旧系统并迁移到新系统。上次我们淘汰旧系统时，我们并行运行两个系统并在两者之间集成数据，直到我们领域中的所有内容完全迁移。在这个过程中，我能够在我们的旧系统和我们的新系统之间建立集成，利用 SQL Server 的变更数据捕获来跟踪变更并逐步集成这些变更。

对于下一次迁移，我们将逐步淘汰的旧系统基于 MySQL v5.1.69 而不是 SQL Server。我不熟悉 MySQL，我想知道是否有任何类似于 CDC 的技术可以在我们当前版本或值得迁移的更新版本的 MySQL 上利用？

编写包含数据库的集成测试是一个常见问题。如果测试更改了数据库，那么它可能会影响其他测试或下一次运行。

我知道我可以将我的测试包装在一个事务中并在测试运行后回滚该事务。但是如果 PostgreSQL 能够提供某种全局快照或一次性覆盖，那就太好了。在理想情况下，这样的功能将涵盖数据库的所有状态，包括模式和存储过程。