Sql server 将多个表复制到一个表中（从多个数据库）

我有多个相同的数据库（分布在多个服务器上），需要将它们收集到一个单一的点来进行数据挖掘，等等

我们的想法是从每个数据库中提取

表1

，

表2

，…，

表n

，然后将它们合并，并将结果放入一个大型数据库中

为了能够编写查询，并知道每一行来自哪个数据库，我们将向目标表添加一列

DatabaseID

，描述行的来源。 编辑源表不是一个选项，它属于某些专有软件

我们有约40台服务器，约170个数据库，需要复制约40个表

现在，鉴于这应该是：

• 易于设置
• 易于维护
• 如果数据库模式发生更改，最好易于调整
• 可靠，在出现故障时记录/报警
• 添加更多要复制的表并不难

我们已经研究了SSI，但似乎必须将每个表添加为源/转换/目标。我猜它也会与数据库模式紧密相连。对吧?

另一种选择是使用SQL Server复制，但我不知道如何将

DatabaseID

列添加到每个表中。似乎只能复制数据，不能修改数据。 也许我们可以将所有数据复制到单独的数据库中，然后在目标服务器上运行本地作业来合并表？ 如果我们需要添加更多的表来进行复制，这似乎需要做很多工作，因为我们必须为每个数据库重新分发新的发布（手动工作？）

最后一个选项（？）是根据我们的需要编写自定义应用程序。更大的时间投入，但至少能做我们想做的事

更糟的是。。。我们正在使用Microsoft SQL Server 2000。 我们将在6个月内升级到SQL Server 2008 R2，但我们希望该项目能够更快地投入使用

让我知道你们的想法

更新20110721

我们最终得到了一个F#程序，该程序打开了到SQL Server的连接，我们希望在该连接中使用聚合数据库。从那里，我们查询40个链接的SQL Server，从一些表中获取所有行（但不是所有列），并在每个表中添加一行，以说明该行来自哪个数据库ID。 要从中获取的服务器配置、哪些表和哪些列是文本文件配置和硬编码值（heh:D）的组合。 它不是超快速的（目前为止是顺序抓取），但是它是绝对可管理的，并且我们之后进行的数据处理需要更长的时间

未来的改进可以是：

• 如果出现问题（如果服务器不在线等），则改进错误处理
• 实现并行抓取，以减少完成抓取的总时间
• 弄清楚它是否足以只获取一些行，比如只获取添加/更新的行

---

总而言之，它非常简单，对其他产品没有依赖性，并且在实践中效果很好。

没有什么特别之处，但你不能做类似的事情吗

DROP TABLE dbo.Merged

INSERT INTO dbo.Merged
SELECT  [DatabaseID] = "Database1", * FROM ServerA.dbo.Table
UNION ALL SELECT  [DatabaseID] = "Database2", * FROM ServerB.dbo.Table
...
UNION ALL SELECT  [DatabaseID] = "DatabaseX", * FROM ServerX.dbo.Table

优势

• 易于设置
• 易于维护
• 易于调整
• 易于添加更多表

缺点

• 演出
• 可靠测井

---

我们有一个类似的要求，我们采取了不同的方法。首先创建了一个中央数据库来收集数据。然后，我们创建了一个库存表来存储目标服务器/数据库的列表。然后是一个基于vb.net的小型CLR过程，该过程采用SQL查询路径、目标SQL实例名称和存储数据的目标表（这将在添加新目标时消除链接服务器的设置）。这还会向结果集中添加两个附加列。捕获数据时的目标服务器名称和时间戳

然后，我们设置一个ServiceBroker队列/服务，并将目标服务器列表推送到interogate

上面的CLR过程包装在另一个过程中，该过程将消息出列，并在提供的目标服务器上执行SQL。然后将包装过程配置为队列的激活过程

通过这种方式，我们可以实现一点并行性来捕获数据

优点：

• 易于设置易于管理（添加/删除目标）
• 相同的框架适用于多个查询
• 记录表以检查失败的查询
• 独立于每个目标工作，因此如果其中一个目标无法 回应，其他人仍在继续
• 通过禁用队列，可以优雅地暂停工作流（对于 在中央服务器上进行维护），然后恢复收集 我们正在启用它

缺点：

• 需要对服务经纪人有很好的了解
• 应该正确处理有毒信息

---

请让我知道它是否有用

值得一试！我关心的是可靠性，以及从“一般网络错误”中恢复。但这很容易尝试，如果我们不能让它可靠地工作，我们可以放弃它。谢谢我们最终使用了离此不远的东西。@Kolmodin-您可以更新您的问题，以包含最终解决方案。它肯定能帮助别人，满足我的好奇心。