Значительные различия в производительности между Access в Windows Server 2008 R2 и Windows Server 2019 - PullRequest
2 голосов
/ 02 июля 2019

В нашей компании мы должны поддерживать большую устаревшую систему, основанную на Microsoft Access 2010 в качестве внешнего интерфейса и SQL Server 2008 R2 в качестве внутреннего.Внутренний сервер SQL работает на Windows Server 2008 R2.В настоящее время наши пользователи работают над сеансами Terminal Server на Windows Server 2008 R2.Пару дней назад мы начали тестировать Windows Server 2019 и ноутбуки с последней версией Windows 10. Мы обнаружили большую разницу в производительности при выполнении одних и тех же баз данных Access в разных средах.

Например, созданиеотчет занимает 27 секунд (новая среда) вместо 7 секунд (старая среда).Файл database.accdb идентичен, серверная часть идентична (все еще Windows 2008 R2 Server с SQL Server 2008 R2 и SP2), изменилась только среда выполнения (Windows).

Кто-нибудь из вас имеет представление о том, какобъяснить это?

В Access 2010 таблицы SQL-сервера связаны с использованием источников данных System-DSN.В старой среде используется ODBC (Драйвер: SQL Server, версия: 6.01.7601.17514).

В новой среде я протестировал следующие драйверы:

  • Драйвер ODBC 11 для SQLСервер (2014.120.5543.11)
  • Драйвер ODBC 17 для SQL Server (2017.173.01.01)
  • SQL Server (10.00.17763.01)
  • Собственный клиент SQL Server 10.0 (2009.100.4000.00)
  • Собственный клиент SQL Server 11.0 (2011.110.5058.00)

Я создал новый системный DSN с использованием разных драйверов и обновил связанные таблицы в Access.Но в любом случае производительность все равно плохая.Я также протестировал последнюю версию Access, которая поставляется с Office 2019, но, опять же, она медленная.

Ответы [ 2 ]

0 голосов
/ 05 июля 2019

Хорошо, нужно проверить несколько вещей.

Первое, что нужно проверить:

Запустите диспетчер ODBC и проверьте, включена ли трассировка журнала SQL.Я не знаю почему, но я вижу, что sql logging включен.

Вы ДОЛЖНЫ быть на 100% уверены, что он выключен.

Вы ДОЛЖНЫ запустить диспетчер ODBC из командной строки или из меню «Пуск», поскольку на панели управления используется версия x64 bit, и вы используете Access x32 (я полагаю).

Итак, запустите эту версию:

c: \ Windows \ SysWOW64 \ odbcad32.exe

Так ОЧЕНЬ важно запустить x32.Предполагается, что вы используете файл DSN.Поэтому проверьте эти две настройки:

enter image description here

(убедитесь, что они не отмечены).

Далее?

Ссылочный доступ с использованием IP-адреса сервера sql.

Итак, место произнесения:

myServer \ SQLEXPRESS

Использование:

10.50.10.101 \ SQLEXPRESS

(Конечно, используйте IP-адрес сервера sql, а не приведенный выше «пример» IP).

Вышеприведенные вещи довольно легко проверить.

Все еще нет исправления производительности?

Затем отключите брандмауэр на вашем новом терминальном сервере (я видел, что это ДЕЙСТВИТЕЛЬНО вызывает хаос).

И отключите защитник Windows на новом сервере TS, если он работает.

Приведенные выше советы должны исправить ваши проблемы.

Если вышеупомянутое не работает, тогда следовало бы проверить настройки приоритета для сервера TS (графический интерфейс над сервером).

Однако я держу пари, что приведенные выше чеки должны восстановить вашу производительность.

0 голосов
/ 02 июля 2019

Похоже, что ваши терминальные сеансы удушаются. Несмотря на тот факт, что у вас есть серверная часть SQL Server, Access по-прежнему работает с результирующими наборами, поэтому любые различия в регулировании ресурсов между политиками Server 2008 и Server 2019 могут приводить к блокированию доступа на новом сервере.

Я думаю, ваш ответ будет найден в Windows System Resource Manager . На странице написано, что она не поддерживается, но переход по ссылке «Рекомендуемая версия» приводит к общей странице Server 2019. Вот еще одна статья о том, как WSRM может регулировать сеансы: Использование WSRM для управления динамическим планированием справедливого распределения RDS .

Сравните политику Weighted_Remote_Sessions на серверах 2008 и 2019 гг. Произошли изменения в настройках или поведении по умолчанию или в прошлом была изменена политика сервера 2008, чтобы перейти на текущий уровень производительности.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...