MS Access 2003 + 到 SQL Server 2005 的链接表 + Windows 身份验证 = 慢答案

【问题标题】：MS Access 2003 + linked tables to SQL Server 2005 + Windows Authentication = slowMS Access 2003 + 到 SQL Server 2005 的链接表 + Windows 身份验证 = 慢
【发布时间】：2009-07-24 10:56:13
【问题描述】：

当从 Windows XP 客户端使用 Windows 身份验证时，我们的 MS Access 应用程序与 SQL Server 2005 的链接表很慢。

我们已经使用 SQL Server 身份验证成功运行了它，但现在我们想要迁移到 Windows 身份验证以实现更好的安全控制。

设置：

数据库服务器：Windows 2003 Server、SQL Server 2005 SP2
客户端：Windows XP SP3，SQL Server ODBC 驱动程序 v2000.85.1132.00
MS Access 应用程序：MS Access 2003
连接字符串：
DRIVER=SQL Server;SERVER=[server name];Connect Timeout=300;Trusted Connection=True;APP=Microsoft Office 2003;WSID=[server name];DATABASE=[db name]
服务器上仅启用 TCP/IP 网络协议。

缓慢不会在这些情况下发生：

数据库服务器上的应用程序，SQL Server 身份验证
数据库服务器上的应用程序，Windows 身份验证
Windows XP 客户端上的应用程序，SQL Server 身份验证
客户端上的 SQL Server Management Studio，Windows 身份验证 - 我做了一个小测试，在 SQL MS 中运行了 15 个查询。这进展很快，并且没有在服务器上的安全事件日志中导致任何登录/注销事件。

我已经使用 SQL Server Profiler 和服务器上的事件日志分析了缓慢，它似乎归结为：

应用程序运行查询
与 SQL Server 的新连接已打开（在 SQL Server Profiler 中可见）
验证用户身份（在服务器上的安全事件日志中可见，发生登录/注销事件）。这需要数百毫秒。
查询在 SQL Server 上运行
结果返回到 Access

每个查询都会发生这种情况。某些表单在显示新记录时会运行 +- 10 次查询（更新子表单、加载组合的值等）。这会导致性能非常缓慢。

当然，没有必要为每个查询都设置到 SQL Server 的新连接，重用连接可能会解决问题。我一直在寻找有关如何确保 Access/ODBC 进行正确连接池的信息。我找到了这些 MS 知识库文章：

Frequently Asked Questions About ODBC Connection Pooling
How to Enable Connection Pooling in an ODBC Application

我尝试从 Access 应用程序的主窗体调用 SQLSetEnvAttr 函数，但这并没有改善结果。

非常感谢任何帮助。

【问题讨论】：

您还可以检查在客户端解析进行身份验证的域控制器的名称时是否存在 DNS 问题。我发现 DNS 问题可能是各种与 Access/ODBC/SQL Server 似乎无关的奇怪问题的原因。
我认为芬顿走在了正确的轨道上。前端应用程序是否在与 SQL Server 实例不同的域/林中运行？
你能发布你的连接字符串吗？请混淆您的本地价值观。 :)
您可能还想确保客户端计算机上的 ODBC 驱动程序已更新。在针对 SQL 2005 使用 SQL 2000 ODBC 驱动程序时，我发现了一些奇怪的问题。
感谢您的 cmets。我花了一段时间才看到这个，因为电子邮件通知对我不起作用。 DNS 问题：可能不是原因。这是一个小型本地网络，单个域。 DB server 和 client 都可以解析 DC 的 DNS 名称。连接字符串：已添加到帖子中。 ODBC驱动：客户端（2000.85.1132.00）的ODBC驱动确实比服务器上的（2000.86.3959.00）老。我已经到处搜索了 XP 的更新驱动程序，但无济于事。知道在哪里可以获得更新的驱动程序吗？

标签： sql-server performance ms-access odbc windows-authentication

【解决方案1】：

我的第一个问题是：您在运行域控制器吗？这听起来像是一个疯狂的问题，但我只是想确定一下。尽管越来越少见，但我已经看到组织使用工作组和“直通”身份验证运行 Windows 网络。您描述的症状与在以这种方式设置的网络上观察到的症状相同。

假设您确实设置了正确的域，那么您一定在 Named Pipes 网络堆栈中的某个地方遇到了问题。如果您使用 Windows 身份验证，命名管道是默认协议。如果你有时间，深入了解这不是一个坏主意，但如果你只是想解决你的性能问题，那么我会在你的连接字符串中强制使用 TCP/IP 协议：

DRIVER=SQL Server;SERVER=tcp:[server name];Connect Timeout=300;Trusted Connection=True;APP=Microsoft Office 2003;WSID=[server name];DATABASE=[db name]

注意添加了 tcp: 前缀。我从Jon Galloway's blog.得到这个语法@ TCP/IP 是 SQL Server 身份验证的默认协议。您也可以通过禁用服务器上的命名管道支持来进行协议切换，但这比较麻烦，并且可能导致其他意想不到的问题。

【讨论】：

我们（或者更确切地说，我们的客户）正在运行域控制器，是的。尽管您的建议听起来很有希望，但并没有帮助。命名管道原来已经在服务器上被禁用。所以我们可以确定 TCP/IP 被用作客户端和 SQL 服务器之间的网络协议。
很抱歉听到这没有帮助。您是否尝试过在服务器上启用命名管道？可能是客户端正在尝试命名管道连接并故障转移到 TCP/IP，而故障转移会导致性能下降。当然，如果服务器位于防火墙后面且 MS 网络端口被阻止，这将不起作用。
将尝试启用命名管道并报告。这是否也能解释为什么 SQL Server 身份验证比 Windows 身份验证快，以及为什么 SQL Server 机器几乎对来自 Access 的每个查询都执行登录/注销事件？
这可能有效，但由于我在这个问题上是 0 比 1，我将不做任何保证。我不是网络专家，但我确实从经验中知道 Windows 身份验证喜欢在命名管道上进行操作。我最初的建议是基于这样的想法，即可以通过移出默认的命名管道协议来解决问题，但我们可以通过采用命名管道来解决问题。我在服务器上禁用 NP 的建议是可行的，但实际上我已经得到了结果。 cn string fix 有更好的机会，核心原理是让客户端和服务器协议配置匹配。

【解决方案2】：

检查 Microsoft SQL Server Native Client 在http://www.microsoft.com/downloads/details.aspx?FamilyID=d09c1d60-a13c-4479-9b91-9e8b9d835cdc&displaylang=en

【讨论】：

我已经尝试安装最新的 SQL Server Native Client (microsoft.com/downloads/…)。这包括与我相同版本的 SQL ODBC 驱动程序 (2000.85.1132.00)。它包括 SQL Native Client 的 2005.90.4035.00。我试过用这个连接字符串来使用它：Driver={SQL Native Client};Server=[server name];Connect_Timeout=300;Trusted_Connection=Yes;APP=Microsoft Office 2003;DATABASE=[db name] 相同的结果，仍然很慢。