Новый сервер приехал, а SQL Server 2025 не запускается. Считайте не ядра, а логические процессоры на NUMA-узел

Приехал двухсокетный сервер, свежий Windows, поставили SQL Server 2025 — установка прошла, а служба не поднимается. Стартует и сразу падает. Девять из десяти админов в этот момент лезут в права сервисной учётки и в целостность master. А причина — в BIOS: у машины больше 64 логических процессоров на один NUMA-узел, и движок отказывается работать намеренно. Ниже — как за пять минут поставить диагноз, чем это чинится на Intel и AMD, почему виртуалка не спасает автоматически, и как я теперь считаю конфигурацию ещё до подписания счёта.

Диагноз за пять минут: движок останавливает себя сам

Картина всегда одинаковая. Установщик отработал без красных крестов, в Программах и компонентах SQL Server есть, конфигурационный менеджер видит инстанс — а служба не стартует. Запускаешь руками: крутится секунду и падает. В журнале приложений что-то невнятное, ERRORLOG либо пустой, либо обрывается на первых строках инициализации. Дальше начинается стандартный ритуал: проверяем сервисную учётку, права на папку DATA, антивирус, повреждение системных баз. Всё чисто, а сервер по-прежнему мёртвый.

Это не сбой установки. Начиная с SQL Server 2022 (16.x) Cumulative Update 11 Microsoft внесла breaking change: Database Engine не запускается, если обнаруживает конфигурацию, способную превысить 64 логических ядра на один NUMA-узел. То есть движок сознательно себя блокирует. С Cumulative Update 15 установщик стал предупреждать об этом заранее — в мастере установки и в логах Setup — с формулировкой, что конфигурация неподдерживаемая и служба будет остановлена и переведена в отключённое состояние. В SQL Server 2025 (17.x) это вынесено отдельным пунктом в список известных проблем: «SQL Server instances on Windows might fail to start after the installation if the machine has more than 64 logical cores per NUMA node».

Зачем вообще такая жёсткость. Microsoft в документе про лимиты вычислительной ёмкости объясняет прямо: при превышении лимита вы получаете stack dumps и другие проблемы надёжности. Раньше движок на таких машинах формально работал — просто периодически ронялся, и никто не связывал падения с топологией. Теперь он вместо этого честно не стартует. Мне такой размен нравится больше: лучше одна нерабочая пятница на этапе внедрения, чем полгода загадочных дампов на бою.

Важная деталь, из-за которой люди теряют лишний час. После срабатывания защиты служба остаётся не просто остановленной, а с типом запуска Disabled. Вы правите BIOS, перезагружаетесь, ждёте — и опять тишина, потому что служба отключена и стартовать не собирается. Проверяйте тип запуска явно.

• Открыть логи установки в C:\Program Files\Microsoft SQL Server\170\Setup Bootstrap\Log (начать с Summary.txt, потом детальные логи в подпапке с датой) и поискать слова NUMA и logical cores: начиная с 2022 CU15 Setup пишет туда предупреждение.
• Посмотреть последний ERRORLOG: строка вида «SQL Server detected N sockets with M cores per socket and K logical processors per socket» приходит одной из первых, по ней уже видна арифметика.
• Посмотреть топологию на уровне ОС: Диспетчер задач → Производительность → ЦП → правой кнопкой «Изменить представление» → Узлы NUMA. Если узел один, а логических процессоров 128 — диагноз готов.
• Не тратить время на проверку редакции: лимит 64 логических ядра на NUMA-узел не зависит от Standard/Enterprise, он общий для продукта.

Арифметика, которую пропускают все

Ошибка мышления тут ровно одна: считают не то. Смотрят в спецификацию редакции — «Standard до 4 сокетов или 32 ядер, влезаем» — и на этом останавливаются. Или считают физические ядра сервера и радуются, что их 96. Лимит же сформулирован в других единицах: логические процессоры на один NUMA-узел. Три слова, и каждое имеет значение.

Формула простая. Логических процессоров на узел = (ядер на сокет × потоков на ядро) ÷ количество NUMA-узлов на сокет. Потоков на ядро — два, если включён SMT (у Intel он называется Hyper-Threading), и один, если выключен. Количество NUMA-узлов на сокет по умолчанию почти всегда равно единице — и вот тут всё и ломается, потому что современный серверный процессор в одиночку легко даёт больше 64 потоков.

Посчитаем на живых железках 2025–2026 годов. AMD EPYC 9454: 48 ядер, SMT включён — 96 логических процессоров на сокет. При заводском NPS1 это один NUMA-узел на 96 потоков, полтора лимита. EPYC 9654 с 96 ядрами даёт 192 потока на сокет: NPS1 — мимо, NPS2 — 96 потоков на узел, всё ещё мимо, только NPS4 с его 48 потоками на узел проходит. EPYC 9755 на 128 ядер и 256 потоков влезает в NPS4 ровно впритык — 64 на узел, то есть на самой границе. Intel Xeon 6980P: 128 ядер, 256 потоков, при заводской SNC3 получается около 85 потоков на узел — снова превышение, и именно про этот случай Microsoft отдельно пишет, что нужно включать Intel Virtual NUMA.

Обратите внимание на приятную часть: у «мелких» процессоров проблемы нет вообще. Xeon Gold на 32 ядрах с Hyper-Threading — это 64 потока на сокет, ровно лимит. EPYC 9354 на 32 ядрах — то же самое. Xeon 6 серии E-core вроде 6780E имеет 144 ядра, но без SMT, и при SNC3 даёт 48 потоков на узел. Так что паниковать всем подряд не надо: проблема начинается там, где на сокет приходится больше 64 потоков и топология не разделена.

• 48 ядер + SMT, NPS1 → 96 логических на узел → не стартует
• 48 ядер + SMT, NPS2 → 48 логических на узел → работает
• 96 ядер + SMT, NPS2 → 96 логических на узел → не стартует
• 96 ядер + SMT, NPS4 → 48 логических на узел → работает
• 128 ядер + SMT, SNC3 → ~85 логических на узел → не стартует, нужен Intel Virtual NUMA
• 32 ядра + SMT, один узел → 64 логических на узел → работает, но запаса нет

Разбор из практики: часовая мастерская «Точное время», 19 рабочих мест

Часовая мастерская: приёмка и выдача ремонтов, склад запчастей и ремешков, розница, 19 рабочих мест вместе с мастерами за верстаками и кассой. Учёт в 1С (управленческий учёт и квитанции на ремонт) плюс бухгалтерия, обе базы на MS SQL. Старый сервер на 8 ядрах начал сыпать ошибками дисков, и владелец поручил закупку знакомому поставщику со словами «возьмите с запасом, чтобы лет на семь». Поставщик и взял: односокетная платформа на AMD EPYC 9454 (48 ядер, 96 потоков), 256 ГБ памяти, NVMe в зеркале, Windows Server 2025 Standard и SQL Server 2025 Standard.

Меня позвали, когда сервер вторые сутки стоял в стойке с неработающей службой SQL Server. Топология простая: один сокет, SMT включён, NPS1 из коробки — значит, один NUMA-узел на 96 логических процессоров при лимите 64. В логах Setup предупреждение было, его прокликали вместе с остальными жёлтыми треугольниками мастера. В ERRORLOG одной из первых шла строка вида «SQL Server detected 1 sockets with 48 cores per socket and 96 logical processors per socket, 96 total logical processors», а дальше запуск обрывался.

Лечение заняло одну перезагрузку. В BIOS переключил NUMA nodes per socket с NPS1 на NPS2 (у разных вендоров пункт лежит в разных меню, у референсных плат AMD — в ветке AMD CBS), получил два NUMA-узла по 48 логических процессоров. Вернул службе тип запуска Automatic, стартовал — движок поднялся. Дальше SQL Server сам включил automatic soft-NUMA: в каждом аппаратном узле по 24 физических ядра, это больше восьми, поэтому движок нарезал их на soft-NUMA узлы примерно по 8 физических ядер. В sys.dm_os_nodes это видно сразу: узлов больше, чем аппаратных, и отдельно служебный узел с пометкой DAC.

А теперь честная часть разговора с владельцем. SQL Server 2025 Standard использует не больше 32 ядер на инстанс и не больше 256 ГБ под buffer pool. Из 48 купленных ядер 16 базе не достаются вообще, а при лицензировании по ядрам на физическом сервере лицензировать нужно все физические ядра — это требование лицензионного руководства Microsoft, а не документации движка. Нагрузка же у мастерской — две базы 1С на 19 пользователей: по мониторингу за месяц процессор редко поднимался выше 15 %, а суммарный объём баз меньше 40 ГБ. Под такую задачу хватило бы одного процессора на 12–16 ядер и 64–128 ГБ памяти, а сэкономленное стоило вложить во второй диск под бэкапы и ИБП. Сервер уже куплен и возврату не подлежал, поэтому оставили NPS2, SQL Server живёт в виртуальной машине Hyper-V на 16 vCPU, а остальные ядра заняли терминальный сервер и файловые службы. Для малой компании это самый практичный способ не выбросить деньги: лицензии SQL Server тогда считаются по виртуальным ядрам ВМ, а не по всему хосту — детали по вашему договору сверяйте с лицензионным руководством.

• Нагрузка 1С на 19 рабочих мест — это единицы процентов CPU в обычный день и короткие пики при закрытии месяца; решают скорость дисков и память, а не число ядер.
• Standard 2025 — меньшее из 4 сокетов или 32 ядер и 256 ГБ под buffer pool на инстанс; всё, что сверху, движок не использует.
• Лицензирование по ядрам на физическом сервере покрывает все физические ядра, включая те, что редакция не задействует.
• Для небольшого числа пользователей стоит посчитать и модель Server + CAL для Standard: при 19 сотрудниках она бывает дешевле ядерной.
• Express 2025 бесплатен, но ограничен 1 сокетом или 4 ядрами, 1 410 МБ под buffer pool и 50 ГБ на базу — для двух рабочих баз 1С с ростом это тесно.

Чиним в BIOS: Intel SNC и AMD NPS

Штатный способ по документации Microsoft — уменьшить количество логических ядер на узел настройками BIOS или прошивки. Не через SQL Server, не через Windows, а именно на уровне платформы. Есть два семейства настроек, и называются они по-разному.

У Intel это Sub-NUMA Clustering, SNC — раньше та же вещь называлась Cluster-on-Die. Живёт обычно в Advanced → Uncore Configuration. На третьем, четвёртом и пятом поколениях Xeon SNC по умолчанию выключен, и вы включаете SNC2, чтобы получить два NUMA-узла на сокет. На шестом поколении Xeon картина другая: SNC2 или SNC3 включены заводом, но на моделях с очень высоким числом ядер даже трёх узлов на сокет не хватает, чтобы уложиться в 64. Для таких случаев Microsoft рекомендует дополнительно активировать в BIOS фичу Intel Virtual NUMA — она нарезает несколько виртуальных узлов внутри одного физического NUMA-узла. Доступна она только на шестом поколении и новее.

У AMD аналог называется Nodes per Socket. NPS1 — заводской режим, один NUMA-узел на сокет. NPS2 — два узла на сокет, ближайший аналог SNC. NPS4 — четыре узла. Есть ещё NPS0, который в двухсокетной системе склеивает всё в один узел с чередованием памяти по всем каналам — этот режим вам противопоказан, он гарантированно вгоняет в превышение. Где именно лежит настройка, зависит от производителя платы: на референсных прошивках AMD она в ветке AMD CBS (часто DF Common Options → Memory Addressing), у Dell, HPE, Lenovo и Supermicro — в своих разделах процессора или памяти. Ищите по слову NPS.

Отдельно предупрежу про две вещи. Первая: доступность режимов зависит от того, как набита память. На частично заполненных платформах NPS4 может быть недоступен или заметно просаживать пропускную способность, потому что каналы чередуются в пределах узла. Проверяйте на своём стенде, а не по презентации вендора. Вторая: у AMD есть ещё опция «ACPI SRAT L3 Cache as NUMA Domain», которая делает NUMA-домен из каждого L3-кэша. Она решает ту же арифметическую задачу и в списке рекомендаций Microsoft её нет — я бы держал её как запасной вариант, когда NPS4 недоступен, и только с последующим замером производительности, потому что узлов получается сильно больше и планировщику SQL Server это не всегда на пользу.

• Intel, 3–5 поколение Xeon: SNC Disabled по умолчанию → включить SNC2 (два узла на сокет).
• Intel, 6 поколение Xeon: SNC2/SNC3 уже включены; если потоков на узел всё равно больше 64 — дополнительно включить Intel Virtual NUMA.
• AMD: NPS1 по умолчанию → NPS2 или NPS4 по расчёту. NPS0 не использовать.
• Azure Mv3 и другие широкие облачные ВМ: BIOS вам недоступен, единственный документированный путь — отключить SMT реестром.
• После смены режима — полная перезагрузка и повторный подсчёт: топологию проверяем фактически, а не по ожиданию.

Виртуализация: не спасение по умолчанию

Первый совет, который вы услышите в комьюнити, звучит так: положите SQL в виртуалку и раздайте ей побольше виртуальных сокетов с меньшим числом ядер на сокет. Совет верный по духу, но опасно упрощённый. Гостевая ОС видит не вашу настройку «сокетов», а виртуальную NUMA-топологию, которую ей нарисовал гипервизор — и связь между этими двумя вещами не такая прямая, как кажется.

На VMware vSphere начиная с 6.5 количество ядер на сокет по умолчанию отвязано от построения vNUMA: платформа сама решает, как нарезать узлы, ориентируясь на физическую топологию хоста. Поэтому «сделал 8 сокетов по 8 ядер» может не дать ровно ничего. Смотреть надо на расширенные параметры виртуальной машины — numa.vcpu.maxPerVirtualNode задаёт максимум vCPU на виртуальный узел, а numa.vcpu.followcorespersocket определяет, слушается ли вообще раскладка по сокетам. Названия и поведение параметров различаются между версиями vSphere, поэтому сверяйтесь с документацией именно своей версии, а результат проверяйте изнутри гостя.

На Hyper-V всё честнее и проще: есть прямой параметр. Set-VMProcessor с ключом MaximumCountPerNumaNode задаёт, сколько логических процессоров попадёт в один виртуальный NUMA-узел. Ставите 32 или 48 — и гость видит нужное количество узлов. Только помните, что физическую топологию хоста это не меняет: если на хосте один узел на 96 потоков, вы получите виртуальные узлы, размазанные по физическому, с соответствующими штрафами на доступ к памяти. Правильный порядок — сначала разделить NUMA на хосте в BIOS, потом уже рисовать vNUMA под него.

Отдельный случай — облако, где BIOS вам не отдадут. Для Azure серии Mv3, которая может превышать лимит, Microsoft документирует обходной путь: отключить SMT двумя параметрами реестра и перезагрузить ВМ. Сначала проверяем соотношение ядер и логических процессоров, потом вносим изменения:

Get-CimInstance -ClassName Win32_Processor | Select-Object -Property "NumberOfCores", "NumberOfLogicalProcessors"

reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v FeatureSettingsOverride /t REG_DWORD /d 8264 /f
reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v FeatureSettingsOverrideMask /t REG_DWORD /d 3 /f

После перезагрузки число логических процессоров должно совпасть с числом ядер. Цена вопроса — прирост от многопоточности, но в OLTP-нагрузке 1С это обычно менее болезненно, чем неработающий сервер. Перед правкой реестра сделайте его резервную копию.

Что не работает: четыре популярных заблуждения

Soft-NUMA не помогает. Автоматическая soft-NUMA включена по умолчанию начиная с SQL Server 2016: если при старте движок видит больше восьми физических ядер на NUMA-узел или сокет, он сам делит узел на soft-NUMA узлы, в идеале по восемь ядер (допустимо от четырёх до восьми). Но это внутренняя раскладка планировщиков SQLOS, аппаратную топологию, которую видит Windows, она не меняет. В документе Microsoft про лимит 64 логических ядра на узел soft-NUMA среди способов решения не названа — называются только SNC, NPS, Intel Virtual NUMA и отключение SMT в Azure.

Маска сходства процессоров тоже не обход. Идея «выдам инстансу affinity на 64 процессора, и он успокоится» выглядит логично, но как поддерживаемый способ обхода нигде не описана: движок отказывается стартовать по обнаруженной топологии машины, а не по тому, сколько процессоров он собирается использовать. Не тратьте на это вечер.

«Поставлю с включённым SNC, а потом выключу» — прямой путь в неподдерживаемую конфигурацию. Microsoft описывает этот сценарий буквально: на некоторых машинах после установки SQL Server вы физически сможете отключить SNC или NPS и получить больше 64 логических ядер на узел. Такая конфигурация не поддерживается. Оно даже поедет — ровно до первого stack dump, ради предотвращения которого весь этот лимит и вводился. И в саппорте вам справедливо скажут идти в BIOS.

Откат на SQL Server 2019, «который не ругается», — плохая сделка. Защиты там нет, потому что она появилась в 2022 CU11, но физика та же: широкий узел даёт проблемы надёжности независимо от версии движка. Плюс вы сознательно ставите редакцию, которая уже вне основной поддержки, на сервер, купленный на пять лет вперёд. И ещё, раз уж речь о совместимости: SQL Server 2025 не поддерживается на Windows Arm64 в принципе — в документации прямо сказано, что поддерживаются только x86-64 процессоры Intel и AMD с числом ядер до 64 на NUMA-узел.

• Автоматическая soft-NUMA — не обход: она делит узлы больше 8 физических ядер для планировщика, но аппаратный узел остаётся прежним.
• ALTER SERVER CONFIGURATION SET PROCESS AFFINITY — не обход, не документирован как решение.
• Установка при разделённой топологии с последующим отключением SNC/NPS — явно неподдерживаемая конфигурация.
• Отключение SMT на bare-metal — арифметически работает, но вы теряете половину логических процессоров; на физическом сервере это последний вариант, а не первый.
• Понижение версии SQL Server — убирает сообщение, но не убирает причину.

Движок поднялся: проверяем soft-NUMA, группы процессоров и MAXDOP

Когда служба стартовала, я не закрываю задачу, пока не посмотрю, что движок увидел на самом деле. Первое — ERRORLOG: строка «SQL Server detected N sockets with M cores per socket…» заканчивается фразой «using K logical processors based on SQL Server licensing». Если K меньше общего числа логических процессоров, вы упёрлись в лимит редакции. Следом идут строки «Automatic soft-NUMA was enabled because SQL Server has detected hardware NUMA nodes with greater than 8 physical cores» и «Node configuration: node N: CPU mask…» — по ним видно, как узлы разложены по процессорам. Второе — два системных представления, которые показывают то же самое в таблице:

SELECT cpu_count, hyperthread_ratio, socket_count, cores_per_socket,
       numa_node_count, scheduler_count, softnuma_configuration_desc
FROM sys.dm_os_sys_info;

SELECT node_id, node_state_desc, memory_node_id, processor_group,
       cpu_count, online_scheduler_count
FROM sys.dm_os_nodes;

В sys.dm_os_sys_info колонка numa_node_count учитывает и физические, и soft-NUMA узлы, а softnuma_configuration_desc показывает режим: ON — автоматический, MANUAL — через реестр, OFF — только аппаратные узлы. В sys.dm_os_nodes поле processor_group показывает группу процессоров Windows, memory_node_id — к какому аппаратному узлу памяти относится soft-NUMA узел, а узел с состоянием DAC зарезервирован под выделенное административное подключение.

Группы процессоров Windows — отдельная арифметика, которую часто путают с лимитом NUMA. Группа процессоров в Windows — это статический набор до 64 логических процессоров, и ОС старается держать один NUMA-узел в одной группе. Машина с 128 логическими процессорами получит две группы по 64. Начиная с Windows Server 2022 процессы по умолчанию могут выполняться на процессорах всех групп, но группы никуда не делись: их видно в processor_group. Лимит SQL Server в 64 логических ядра на NUMA-узел — это требование самого движка, а не следствие групп Windows, поэтому «Windows ведь умеет больше 64 процессоров» ничего не меняет.

Третье — MAXDOP. Рекомендации Microsoft для SQL Server 2016 и новее считают логические процессоры на NUMA-узел, причём под узлом понимается soft-NUMA узел, если автоматическая soft-NUMA включена. Один NUMA-узел и до 8 логических процессоров — MAXDOP не больше их числа; один узел и больше 8 — MAXDOP 8. Несколько узлов и до 16 логических процессоров на узел — MAXDOP не больше числа логических процессоров на узел; больше 16 на узел — половина логических процессоров на узел, но не больше 16. Цель — чтобы потоки параллельного запроса оставались внутри одного узла. Значение 0 разрешает использовать до 64 процессоров и в большинстве случаев не рекомендуется. С SQL Server 2019 установщик сам предлагает MAXDOP по числу процессоров — это значение стоит проверить, а не принимать вслепую.

Для 1С есть своя поправка. В рекомендациях фирмы 1С по работе с MS SQL традиционно встречается MAXDOP = 1, потому что OLTP-запросы платформы короткие, а параллельные планы на них чаще мешают. Я в небольших базах обычно начинаю именно с этого, а для отдельных тяжёлых отчётов и регламентных операций вроде перестроения индексов задаю параллелизм точечно — хинтом, опцией MAXDOP в команде обслуживания индексов или группой рабочей нагрузки Resource Governor, которая в Standard 2025 доступна. Меняется параметр без перезапуска службы:

EXECUTE sp_configure 'show advanced options', 1;
RECONFIGURE;
EXECUTE sp_configure 'max degree of parallelism', 1;
RECONFIGURE;

• ERRORLOG: строки «detected … sockets», «using K logical processors based on SQL Server licensing», «Automatic soft-NUMA was enabled», «Node configuration».
• `sys.dm_os_sys_info`: `cpu_count`, `socket_count`, `cores_per_socket`, `numa_node_count`, `softnuma_configuration_desc`.
• `sys.dm_os_nodes`: `processor_group`, `memory_node_id`, `cpu_count`, `online_scheduler_count` по каждому узлу.
• MAXDOP по таблице Microsoft для узлов после soft-NUMA; для баз 1С — отдельно по рекомендациям 1С.
• Группа процессоров Windows — до 64 логических процессоров; это не то же самое, что лимит SQL Server на NUMA-узел.

Как я теперь закупаю железо под SQL Server в 2026 году

После пары таких историй у меня в шаблоне технического задания на сервер появился отдельный пункт, который заполняется до отправки счёта на согласование. Считаем логические процессоры на NUMA-узел при заводских настройках платформы и отдельно — при доступных режимах SNC/NPS. Если при дефолте больше 64, в спецификации сразу фиксируем нужный режим BIOS. Это тридцать минут работы, которые экономят простой на внедрении и иногда — сотни тысяч на лицензиях.

Дальше — правило, которое звучит контринтуитивно для того, кто привык покупать «побольше». Под SQL Server Standard лучше столько ядер, сколько редакция реально использует и нагрузка реально требует, а не максимум, что влез в бюджет. Для компании на 20–50 рабочих мест это обычно один процессор на 12–24 ядра: топология пригодна без ухищрений, лимиты редакции не упираются, а деньги уходят в память и быстрые диски — для 1С и OLTP они важнее числа потоков. Standard-редакция SQL Server 2025 берёт меньшее из 4 сокетов или 32 ядер (в SQL Server 2022 и более ранних лимит был 24 ядра) и до 256 ГБ под buffer pool, Express — меньшее из 1 сокета или 4 ядер и 1 410 МБ, Enterprise при лицензировании по ядрам ограничен только максимумом операционной системы. Считайте по своей редакции, а не по «максимально возможному».

На что можно забить. Не надо панически перепроверять сервера, где на сокет приходится 64 потока и меньше — их большинство у компаний до 50 рабочих мест, и они этой проблемы не увидят никогда. Не надо переставлять уже работающий SQL Server 2019 или 2022 без CU только ради этой темы: если он живёт стабильно и топология не менялась, спокойно планируйте это на следующий цикл обновления. И не надо отключать SMT «на всякий случай» — это дорого и почти всегда лишнее.

А на что забивать нельзя. Первое — на предупреждения установщика: с CU15 SQL Server пишет об этой конфигурации прямым текстом, и его прокликивают потому, что жёлтых треугольников в мастере всегда много. Читайте Summary.txt после установки, это одна минута. Второе — на регламент обновления прошивок: обновление BIOS сбрасывает настройки на дефолт, а дефолт для AMD это NPS1, и работавший сервер после планового окна не поднимется. Заведите на такие машины строчку в паспорте и проверяйте топологию сразу после обновления, до того как отдадите сервер пользователям.

• В ТЗ на закупку: расчёт логических процессоров на NUMA-узел при дефолтном BIOS и при доступных режимах SNC/NPS.
• Не покупать ядра «на вырост» сверх лимита редакции: Standard 2025 использует до 32 ядер, а лицензии по ядрам покрывают все физические ядра.
• Сверить лимиты редакции: Standard 2025 — меньшее из 4 сокетов или 32 ядер и 256 ГБ buffer pool; Express — 1 сокет или 4 ядра, 1 410 МБ, 50 ГБ на базу.
• Помнить, что core-based лицензии покрывают все физические ядра сервера, даже те, которые редакция не использует.
• Записать нужный режим BIOS в паспорт сервера и проверять его после каждого обновления прошивки.
• После установки открыть Summary.txt и прочитать предупреждения, а не закрыть мастер по кнопке Close.

Частые вопросы