MS Access 2003 + связанные таблицы с SQL Server 2005 + Аутентификация Windows = медленно

Question

Приложение MS Access со связанными таблицами с SQL Server 2005 работает медленно при использовании Windows Authentication от клиентов Windows XP.

Мы успешно его использовали с использованием проверки подлинности SQL Server, но теперь мы хотим перейти на проверку подлинности Windows для лучшего контроля безопасности.

Установка:

• Сервер баз данных: Windows 2003 Server, SQL Server 2005 с пакетом обновления 2
• Клиент: Windows XP SP3, ODBC для SQL Server драйвер 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 сеть включена на сервере.

Медлительность делает не происходит в таких ситуациях:

• App на сервер БД, SQL Authentication Server
• App на сервер БД, проверка подлинности Windows
• App на клиенте Windows XP, Аутентификация SQL Server
• SQL Server Management Studio на клиенте, проверка подлинности Windows. Я провел небольшой тест с запуском 15 запросов в SQL MS. Это быстро и не вызывало никаких событий входа/выхода из системы в журнале событий безопасности на сервере.

Я проанализировал медлительность с помощью SQL Server Profiler и журнал событий на сервере, и он, кажется, сводится к следующему:

1. Приложение выполняет запрос
2. Новое соединение SQL Server открывается (видимо в профиле SQL Server)
3. Идентификатор пользователя проверяется (отображается в журнале событий безопасности на сервере, происходит событие входа/выхода из системы). Это занимает несколько сотен миллисекунд.
4. Запрос выполняется на SQL Server
5. Результаты возвращаются для доступа

Это происходит для каждого запроса. Некоторые формы запускают + - 10 запросов при показе новой записи (обновление подформ, загрузка значений для комбо и т. Д.). Это приводит к очень низкой производительности.

Конечно, настройка нового подключения к SQL Server для каждого запроса не требуется, и повторное использование соединений может решить проблему. Я искал информацию о том, как убедиться, что Access/ODBC делает правильный пул соединений. Я нашел эти статьи MS KB:

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

Я пытался вызвать функцию SQLSetEnvAttr от главной формы приложения Access, но это не улучшило результаты.

Любая помощь очень ценится.

Answer 1

Проверка Microsoft SQL Server Native Client на http://www.microsoft.com/downloads/details.aspx?FamilyID=d09c1d60-a13c-4479-9b91-9e8b9d835cdc&displaylang=en

Answer 2

Первый вопрос у меня есть: вы работаете контроллер домена? Это может звучать как сумасшедший вопрос, но я просто хочу убедиться. Хотя все реже и реже, я видел, как организации запускали сети 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. Вы также можете сделать коммутатор протокола, отключив поддержку Named Pipes на сервере, но это скорее хлопот и может вызвать другие непредвиденные проблемы.