Question

在一对SQL Server 2014环境中，我们遇到了与链接服务器和同义词相关的一些极端性能问题。似乎SQL Server使用一些distributed query逻辑来确定导致速度明显不同的替代执行路径。我怀疑这是因为有时它决定纯粹远程执行查询，有时它决定从远程服务器中选择所有行并在本地应用where子句，在这种情况下是超过800万行并导致严重延迟。

所以我的问题是，有没有办法让FORCE SQL Server始终远程执行分布式查询，并避免这些性能问题？我们处于这样一种情况：我们需要在存储过程中使用同义词或其他非服务器地址特定的代码，因此4部分寻址不是一个可行的永久选项。

问题案例（5分钟以上执行时间）

-- Returns 1 Row
SELECT  S.* 
FROM    [SYNONYM] S
WHERE   S.ID = 'ABC123'

成功案例（1 +/-秒执行时间）

-- Returns 1 Row
SELECT  T.* 
FROM    [SERVER].[DATABASE].dbo.[TABLE] T
WHERE   T.ID = 'ABC123'

-- Returns 1 Row
SELECT  TOP 1
        S.*
FROM    [SYNONYM] S
WHERE   S.ID = 'ABC123'

引用The top 3 linked server performance killers

据称SQL Server 2014修复了链接服务器统计信息权限
没有加入声明
没有功能

引用Linked Servers（和性能问题）

OPENROWSET ...不会深入了解动态SQL的语法和安全性是多么糟糕
OPENQUERY ...见上文关于OPENROWSET
整理是可能的。远程服务器上的排序规则是非标准的，与本地服务器不同。然而，这并不（很容易）解释为什么某些形式的语法有效，有些形式没有
可能排除网络速度，因为两台服务器位于同一数据中心的同一网络上。此外，某些形式的查询工作证明它是查询级别的问题，而不是网络速度问题。
延长超时并不能解决原始性能问题
我的测试已经证明，包含TOP子句会导致本文声称的OPPOSITE效果。在我的测试中，TOP子句导致性能显着提高

我确认统计数据可以正常访问的尝试也不顺利：

DBCC SHOW_STATISTICS('[SYNONYM]') WITH STAT_HEADER;

收率：

无法处理对象ID #####（对象＆＃34; [SYNONYM]＆＃34;）因为它是一个同义词。如果同义词引用的对象是a 表或视图，使用基础对象重试该操作同义词引用。

当我将其改为4部分名称时：

DBCC SHOW_STATISTICS('[SERVER].[DATABASE].[SCHEMA/DBO].[TABLE]') WITH STAT_HEADER;

它产生：

无法处理对象＆＃39; [服务器]＆＃39;因为它是由四部分组成的名称，任何DBCC命令都不支持。

非常感谢有关同义词和/或链接服务器（SQL Server 2014）的任何建议

Answer 1

这可能是无关的，但请记住，如果您为链接服务器使用OLEDB驱动程序，则在最初处理远程数据集而不是SQL Server时，它们会使用操作系统中的RAM。我已经知道过去的链接服务器性能问题，其中SQL Server被配置为在主机上消耗尽可能多的RAM，然后导致链接的服务器数据拉动，因为操作系统没有足够的RAM来处理远程呼叫。只是值得深思。

SQL Server 2014：链接服务器+同义词+分布式查询=性能低下

1 个答案: