Да, вам стоит подумать о переходе на SQL Server 2025. Но если вы используете учётные записи SQL Server, сначала проверьте это (а если вы здесь, чтобы понять, почему вдруг всё замедлилось, читайте дальше).
В большинстве случаев обновление до SQL Server 2025 проходит довольно гладко. Я бы даже сказал, что обновления до других версий SQL Server тоже проходили гладко, хотя многие пострадали от проблем с производительностью из-за изменения модели оценки кардинальности при обновлении до SQL 2014 (точнее, уровня совместимости 120). «Простым» решением тогда было вернуть уровень совместимости на 110, а затем разобраться, что именно вызывало проблемы. Но в SQL Server 2025 есть ещё одна болевая точка, обойти которую не так просто.
Постоянные читатели знают, что я не люблю писать о реальных ситуациях, через которые проходили заказчики. Хорошо говорить, что я улучшил производительность запроса, добавив индекс или изменив тип данных столбца, но я всегда неохотно упоминаю конкретные продукты или имена клиентов.
Но этот случай уже был упомянут, в том числе с указанием моего имени, так что я спокоен.
Дэвид Маскгрейв — MVP по Dynamics в Перте (ближайший сосед Аделаиды с запада, всего в 2000 км), который время от времени обращается ко мне. Пару месяцев назад мне позвонил Артур Ахиллеос и сказал, что Дэвид порекомендовал меня, чтобы выяснить, почему на машине, обновлённой с SQL Server 2019 до SQL Server 2025, показатели загрузки ЦП резко взлетели. Запросы выполнялись с трудом, и все лихорадочно искали ответ на вопрос, возможен ли откат до SQL Server 2019. Приложением было Dynamics GP.
SQL Server 2025 представляет несколько новых возможностей. Например, интеллектуальная обработка запросов (Intelligent Query Processing) претерпела ряд изменений, таких как оптимизация чувствительности к параметрам (Parameter Sensitivity Optimization) и обратная связь по кардинальности (Cardinality Feedback). Быстрый взгляд на самые ресурсоёмкие запросы показал множество запросов, содержащих более сотни параметров. Моей первой мыслью было, что это может быть болезненно, если ядро пытается оценить чувствительность к параметрам по всем ним. Но дело было не в этом. Или не совсем.
Подключение через SSMS не вызывало особых проблем, и запросы там выполнялись достаточно хорошо.
Мы посмотрели на статистику ожиданий, и среди обычных подозреваемых были связанные с параллелизмом, а также некоторые из категории операционной системы SQL (например, SOS_SCHEDULER_YIELD). Но был один тип ожидания, с которым я раньше не сталкивался. Он появлялся на третьем или четвёртом месте в списке самых больших ожиданий и лишь изредка выпрыгивал на первое место, даже когда длинный список «игнорируемых» типов ожиданий игнорировался (согласно списку SQLskills). Это был тип ожидания PREEMPTIVE_OS_CRYPTOPS. Я дал ссылку на статью SQLskills об этом типе, потому что они чётко дают понять, что это, как правило, проблема Windows, а не SQL (к тому же, SQLskills — это ресурс, к которому всегда стоит обращаться за информацией о типах ожиданий; это отличный источник). На их странице рекомендуется «попросить вашу инфраструктурную команду изучить проблемы с производительностью серверов, предоставляющих криптографические услуги домену (например, сервер для системы управления корпоративными ключами)». И хотя это действительно хороший совет, в нашем случае было не так.
Эта проблема на самом деле находится внутри SQL Server 2025, и что ещё хуже — вы, скорее всего, не заметите её в тестовой среде, если не проводите тестирование в масштабе.
Проблема в том, как SQL Server 2025 хэширует пароли для учётных записей SQL Server, а Dynamics GP использует именно такие учётные записи. Многие старые приложения делают так. По сути, алгоритм PBKDF2 повышает безопасность, применяя хэш SHA-512 100 000 раз. Идея состоит в том, чтобы замедлить атаки методом перебора, но это также замедлит приложения, которые часто выполняют повторную аутентификацию. «Разговорчивые» приложения. Пул соединений может помочь в некоторой степени, но не так сильно, как хотелось бы. Лучше всего использовать учётную запись Windows — доверенную учётную запись для вашего веб-сервиса или пользователя, который запускает приложение. Именно поэтому SSMS может по-прежнему работать нормально, потому что SSMS, скорее всего, подключается от вашего имени. И потому что SSMS не будет таким «разговорчивым», как ваше приложение.
Ваш тестовый стенд, проверяющий корректность логики в новой среде базы данных, может не создавать достаточного количества новых подключений, чтобы это заметить. Возможно, он очень хорошо переиспользует соединения. В любом случае, эта проблема, похоже, ускользает от обнаружения в тестовых средах. Идеально.
Позвольте мне быть ясным... Исправление заключается в использовании учётной записи Windows. Но я понимаю, что вы, возможно, не сможете изменить своё приложение.
Вы не можете просто установить уровень совместимости обратно на SQL 2022, чтобы решить эту проблему, но есть флаг трассировки, который можно использовать. Пару месяцев назад он определённо был недокументированным. Я слышал, что теперь он задокументирован, но не совсем уверен. Я не вижу его описания ни в чём официальном. Так что, возможно, обратитесь в службу поддержки Microsoft. (Хотя когда загрузка ЦП высока, а ваше приложение выходит из строя, вам нужно срочное исправление, и вы не хотите ждать поддержки Microsoft!)
Но даже флаг трассировки не является полным решением.
Вам нужно знать — этот флаг трассировки был задокументирован Майклом Ховардом для SQL Server 2022, чтобы включить это поведение. Вы можете прочитать об этом в статье Support for Iterated and Salted Hash Password Verifiers in SQL Server 2022 CU12 | Microsoft Community Hub. Но в SQL Server 2025 этот флаг трассировки возвращает вас к старому поведению. Возможно, вы захотите знать об этом, если использовали флаг трассировки для соответствия требованиям NIST SP 800-63b. Лично я предпочёл бы другой флаг трассировки для отключения PBKDF2, а не тот же самый, который ранее включал его. Флаг трассировки — 4671. О нём есть несколько статей в блогах, но их недостаточно, чтобы убедить меня, что он полностью поддерживается. Если вы включите его в SQL Server 2022, это может замедлить ваше приложение. Это раздражает.
Флаг трассировки был указан в предыдущем абзаце. Но, пожалуйста, читайте дальше, чтобы узнать полное решение.
В SQL Server 2025 после применения флага трассировки каждый хэш пароля всё ещё будет версией PBKDF2, пока вы не сбросите его с помощью ALTER LOGIN, так что простое применение флага не исправит загрузку ЦП сразу. Механизм входа в систему умён и проверяет, какой алгоритм хэширования был использован, чтобы проверить его правильным образом — либо быстрым методом, либо медленным. Но в SQL 2025 без флага трассировки он обновит успешный хэш до версии PBKDF2 для следующего раза. Таким образом, хитрость заключается в том, чтобы включить флаг трассировки, затем сбросить все пароли (по правде говоря, вероятно, только один), и только тогда производительность вернётся. К счастью, учётные записи будут работать с любым алгоритмом, но любой, кто многократно входит в систему с хэшем PBKDF2, будет нагружать ваш ЦП, пока вы не сбросите пароль.
Подсказка для определения того, какой алгоритм использовался для каждого пароля, — посмотреть на столбец password_hash в представлении sys.sql_logins. Записи PBKDF2 начинаются с 0x03, а старые/быстрые — с 0x02. Оставьте учётную запись sa отключённой (всегда) и с хэшем PBKDF2, потому что именно её вы хотите сделать более защищённой (то же самое для всех учётных записей с ролью sysadmin), но любые изолированные учётные записи приложений могут иметь стиль 0x02 ради вашего ЦП.
И если вам интересно, статья Дэвида об этом находится здесь, включая некоторые инструкции по настройке флагов трассировки.
Я очень надеюсь, что вы читаете это ДО ТОГО, как столкнулись с этим. В противном случае — удачи.
Комментариев нет:
Отправить комментарий