链接服务器风险

我正在实现一项新功能，该功能需要来自多台服务器上数据库的数据。我只需要合并所有这些服务器中的数据并对其进行排序。我想到的两个选择是：

1. 使用链接的服务器并编写一个简单的查询，以对将在一台服务器上运行的数据进行合并和排序，并从另一台服务器收集数据。

2. 使用应用程序从所有服务器收集数据，然后将其发送回SQL Server进行排序（不想在应用程序中实现排序）。

我们在SQL Server 2008 r2的活动/活动群集中运行服务器。所有数据库都具有相同的权限，如果您有权访问一个数据库/服务器，则对它们全部都具有权限。这是一个面向公众的应用程序（需要用户登录）。

使用链接服务器有哪些风险？我应该关注任何安全漏洞吗？在主动/主动群集中运行链接服务器是否有任何问题？与替代方案相比，会不会有任何重大的性能问题？

关于链接服务器，似乎普遍存在负面的“嗡嗡声”，但是我找不到任何具体的东西可以使我相信那里确实存在任何问题。

只要您已经考虑了影响，链接服务器就可以很好地工作：

1. 安全性：一个关键考虑因素是，如果您拥有链接服务器，则如果一台服务器受到威胁，则它们都将面临巨大风险。即使您为每个用户使用不同的凭据，不同的服务器（如果唯一的攻击媒介被泄露/发现/猜测的凭据也可能阻止攻击者获取其他资源），该链接也可以有效地绕过所有这些。该链接还将绕过从公共网络隐藏其他数据库的保护，例如，其中一台或多台服务器未向公共接口提供数据的情况，因此通常无法通过防火墙以任何方式看到。您可能会认为“好吧，复制存在同样的风险吗？” 答案是肯定的，但是复制是在单个应用程序数据库之间进行的，并且链接的服务器路由可能会损害同一服务器上的其他数据库，因为链接位于服务器级别而非数据库级别（当然，您可以通过谨慎控制用户访问权限来减轻这种风险权利，但您至少需要在您的计划中意识到这一点）。作为安全性的补充说明：如果服务器不在同一站点上，请确保使用某种形式的VPN链接它们，而不是在公共接口上提供SQL Server。

2. 带宽：如果所有服务器都位于同一个DC中，并且它们之间的连接良好，快速且不受限制，那么您可能不必担心这一点，但是在连接更远的连接时要格外小心，特别是如果您的用户能够运行ad-特殊查询。对于大多数数据集，VPN链路级别的压缩在这里将大有帮助，但是请注意，这将以更大的延迟为代价，这可能会加剧效率问题（请参阅下文）。

3. 效率：如果您只是简单地提取数据块，那么这不是一个大问题（但是请考虑锁定：请参阅我的下一点），但是一旦您通过联接执行任何操作，依此类推，就存在局限性查询计划者可以优化您的请求。如果由于网络延迟而导致服务器不在彼此本地时，如果需要进行许多索引查找，这将创建运行速度非常慢的查询（本地服务器肯定也存在相同的问题，但是程度较小），而是使用索引扫描（减少带宽使用以获取延迟优势）吞噬带宽，如果它持有锁（以避免脏读问题等），这也会影响应用程序的其他部分。

4. 锁定/并发性：脱离服务器将增加查询的运行时间，这将加剧您可能尚不了解的锁定问题，从而严重降低应用程序的并发性和可伸缩性。如果使用常规和/或长期运行的跨服务器查询来关注锁定问题并适当地给出计划者提示，则需要非常小心。

只要您有足够的规定来管理安全和性能问题，尽管可能有更好/更安全/更可靠/更容易获得安全的方法来实现相同目的，但使用链接服务器不会出现问题结果。

我也经历过同样的负面“嗡嗡声”，但是链接服务器面临的唯一问题是可以轻松地在网络上提取大量数据。从DBA的角度来看，即使您有非DBA可以做到这一点，即使他们承诺不滥用它，也很可怕。

在您的情况下，编写自己的应用程序似乎没有任何好处，因为这仍然需要移动数据。听起来您有一个非常简单的权限模型，所以根据环境的不同，可能有必要设置一些特殊权限，以便在不需要链接的地方不使用该链接。

链接服务器为开发人员创造了一种几乎“神奇”的状态。但是，使用一个查询使网络不堪重负变得非常容易，该查询可以在一个请求中从5个服务器返回成千上万的记录，并且您也可以锁定所有5个服务器上的记录。除了经验丰富的DBA之外，我不会让任何人编写查询，除非您培训过1或2位顶级开发人员有关使用一个查询锁定所有数据库的危险。

链接服务器就像毒品一样，一旦使用它们，您将永远不会回头并且想知道为什么您以前从未使用过它们。我从来没有遇到过问题，但是我一直都很小心。