Ошибки конфигурации MS SQL Server под 1С. Часть 2 - мониторинг, параллелизм и изоляция транзакций

Это вторая часть разбора ошибок конфигурации MS SQL Server под 1С. Первая часть - про планирование и развёртывание: профили нагрузки, дисковая подсистема, баланс ресурсов, инсталляция и виртуализация, читать первую часть. Там же была описана типичная история дефолтного развёртывания сервера на прод или «как не надо».

Побудившая меня написать всё это предыстория такова: сервером СУБД под 1С обычно занимается системный администратор в паре с 1С-разработчиком или франчом, уровень СУБД теряется где-то между их компетенциями. Первая часть была про то, как этот разрыв закладывает проблемы при развёртывании. Вторая (эта) - про то, как этот же разрыв в компетенциях мешает найти причину, когда система уже тормозит «и всё висит, и прод лежит».

Напомню и про два профиля настроек для СУБД из первой части: первый - тяжёлая ERP с одной большой базой, второй - стопка из сотни бухгалтерских баз на одном инстансе. Настройки, о которых пойдёт речь ниже, зависят от профиля использования так же, как зависела схема размещения данных из предыдущей части. К концу статьи станет видно, из чего складывается ответ на вопрос «почему тормозит», и что железо в этом ответе часто ни при чём.

Все звонки начинаются как под копирку

«База висит». «Окна не открываются». «К вечеру всё тормозит так, что документ не провести». Жалобы на сервер 1С звучат одинаково в рознице, в производстве и в бухгалтерии, но причины под одинаковыми симптомами всякий раз оказываются разными. Посмотреть, какие типы ожиданий превалируют на сервере, найти тяжёлые запросы, указать в каких местах и что можно поправить. За каждым этим шагом стоит достаточно узкая компетенция администратора баз данных, отдельная профессия DBA. Разработчики этим навыком, как правило, не владеют, у них другая специализация, отсюда следствие: код, который прекрасно работает на тесте, в проде начинает работать очень тяжело. На тесте нет ни боевых объёмов, ни конкуренции за строки, ни сотни пользователей, проводящих документы одновременно. В проде есть всё и сразу.

Пойдём по этажам, от настроек до уровня виртуализации (про виртуализацию общими мазками, так как это стезя опытных сисадминов и отбирать их хлеб я не намерен, тем более что каждый день выходят новые фичи).

Уровень базы. Модель восстановления и checkpoint

В первой части мы настроили сервер, теперь осталась конфигурация на уровне самих баз. Здесь при развёртывании принимаются два решения, обычно возникающих в момент аварии, когда поисковые запросы в гугл в виде: «журнал транзакций переполнен» и «tempdb переполнилась» пишутся уже с заполненным диском и «лежащим на боку» продом.

Модель восстановления. Это «решение» первое и критичное. Модель восстановления Full сохраняет в журнале все транзакции, пока журнал не попал в резервную копию. Simple отпускает место после контрольной точки. Когда вы создаёте новую базу, она наследует модель от служебной базы model, по умолчанию это Full (recovery model). Сценарий возникает следующий: продуктовая база работает в Full, резервное копирование журнала не настроено, журнал растёт и однажды занимает весь том. Работа встаёт. Потом паника, shrink, переключение в Simple и разорванная цепочка восстановления в придачу. В документации Microsoft это сказано прямым текстом (читайте доки): без достаточно частых бэкапов журнала он может расти, пока не закончится место на диске ¹.

Правильный порядок задаётся при создании базы. Продуктовой базе - режим восстановления Full, плюс бэкапы журнала по расписанию, это же открывает восстановление на произвольный момент времени. Копиям для тестов и разработки - Simple, ну иногда в Simple можно ставить ненагруженные базы, при этом не забывать, что их нужно и можно бэкапить дифференциальным бэкапом с настроенной ротацией.

Checkpoint. Менее важная деталь, но на некоторых продах весьма значимая. Контрольная точка - сброс изменённых страниц из памяти на диск, от этого зависят ровность записи и время восстановления после сбоя. С SQL Server 2016 новые базы создаются с indirect checkpoint, целевое время восстановления 60 секунд, запись и сброс идёт ровным фоном ². База, развёрнутая со старой версии, сохраняет прежний механизм с нулевым значением и automatic checkpoint со всплесками записи. 1С здесь в зоне риска: базы по 5-6 лет переезжают с версии на версию. Нулевое значение у них вероятнее всего. Проверяется запросом к sys.databases по колонке target_recovery_time_in_seconds, исправляется командой ALTER DATABASE. На машинах с большой памятью эффект заметнее всего.

Запросы про переполненную tempdb - из той же аварийной серии. Том и размер мы разобрали в первой части, а главный источник её внезапного роста, хранилище версий, разберём ниже, в разделе про изоляцию.

Изоляция транзакций и миф про быстрый Postgres

Это ключевое звено всей конфигурации и с ним связано самое популярное заблуждение при сравнении СУБД.

По умолчанию MS SQL Server работает на уровне изоляции READ COMMITTED в блокировочной реализации. Читающий запрос ставит разделяемые блокировки и ждёт завершения пишущей транзакции, пишущая транзакция ждёт завершения чтения. PostgreSQL построен на версионировании строк (кстати как и Oracle): MVCC работает из коробки для любой базы, читающие запросы получают снимок данных и не ждут пишущих транзакций.

Дальше начинается знакомое до боли шоу. Команда разворачивает тестовую базу 1С на PostgreSQL, запускает и радуется - не тормозит! Из этого делается вывод о превосходстве СУБД, а следом и решение о миграции. Причина наблюдаемого эффекта это разная модель изоляции по умолчанию. В MS SQL Server та же модель включается на уровне базы флагом READ_COMMITTED_SNAPSHOT, после чего читающие запросы работают с версиями строк точно так же, без ожидания блокировок.

По умолчанию этот флаг в коробочном MS SQL Server выключен, OFF (выключено) значение по умолчанию для SQL Server. Касается это всех версий, включая SQL Server 2025 ³. Включён по умолчанию он в облачных Azure SQL Database и SQL database в Microsoft Fabric ³. Отдельная новинка SQL Server 2025 - оптимизированные блокировки. Функция есть, но по умолчанию выключена, включается на каждой базе отдельно и требует заранее включённого ускоренного восстановления ADR, а наибольшую отдачу даёт в паре с включённым RCSI (READ_COMMITTED_SNAPSHOT) ⁴. Самый современный механизм блокировок Microsoft тоже построен вокруг версионирования.

Примеры кода я здесь сознательно не привожу во избежание необратимых последствий неумелых действий. Версионирование меняет профиль нагрузки на tempdb, ADR требует места и меняет механику восстановления, бездумно применённая команда на проде может обойтись фатально. Для тонкой настройки сервера всегда приглашайте квалифицированного DBA, решение о таких опциях принимается предварительно и по совокупности показателей, под конкретную систему.

И ещё один нюанс, который нужен тем, кто обслуживает базы 1С. Платформа 1С 8.3 в управляемом режиме блокировок включает READ_COMMITTED_SNAPSHOT сама, при условии, что у конфигурации снят режим совместимости с 8.2. Современные типовые конфигурации работают в управляемом режиме, флаг у них уже выставлен платформой (возможно меня тут поправят ;) ).

Легаси-конфигурации, та же УПП, работают в автоматическом или смешанном режиме, в этом случае платформа 1С блокировки не контролирует, она перекладывает эту задачу на СУБД, поднимая уровень изоляции транзакции. Для MS SQL это Repeatable Read на объектах, справочниках и документах, и Serializable на необъектах, то есть на регистрах. На Serializable он блокирует не только прочитанные строки, но и диапазоны ключей. Держатся эти блокировки до конца транзакции и не отпускаются сразу после чтения. Вот откуда берутся ожидания на каждой проводке. Дело не в том, что блокировки тут какие-то особенные, их просто больше по охвату и дольше по времени.

RCSI на такой базе бесполезен. Флаг меняет поведение только тех транзакций, которые идут на уровне READ COMMITTED ³. Транзакция на Repeatable Read или Serializable версионирование строк игнорирует, она берёт настоящие блокировки, как будто флага на базе нет. Типичный случай: видим море LCK_M_* в ожиданиях, включаем READ_COMMITTED_SNAPSHOT, перезапускаем, идём смотреть метрики. Не поменялось ничего.

Помогает перевод конфигурации на управляемый режим. Он опускает уровень изоляции до Read Committed, и только после этого версионирование начинает работать, причём платформа 8.3 включит RCSI сама. Порядок причин именно такой: сначала режим конфигурации, потом уровень изоляции, потом уже флаг. Не наоборот.

Стоит такой перевод некоторой «головной боли». Свойство в Конфигураторе переключается флагом, при этом управляемые блокировки надо расставить в коде явно, объектом БлокировкаДанных. Переключить режим и не расставить их значит получить не тормоза, а гонки. Сервер СУБД страховать перестал, платформа ещё не начала, два пользователя спокойно спишут один и тот же остаток. На эту тему (Блокировки в 1С) на хабре есть отличная статья.

Версионирование объясняет и внезапные вопросы к tempdb. Хранилище версий строк расположено именно в tempdb, одна долгая транзакция не даёт его чистить, версии копятся, tempdb растёт, отсюда и аварийный запрос из предыдущего раздела.

Практический вывод: выяснить режим управления блокировками своей конфигурации. Проверить фактическое состояние флага запросом к sys.databases, после ручного создания базы или манипуляций с восстановлением он может оказаться снят. Перестать сравнивать PostgreSQL с MS SQL Server, у которого версионирование не включено: в таком тесте сравниваются две модели изоляции, а не СУБД.

Про импортозамещение скажу отдельно: для госсектора и КИИ выбор СУБД задан законодательно, мой текст ничего не оспаривает. Речь о частных компаниях, которые принимают решение о миграции на основании теста, поставленного некорректно. Решение о смене СУБД стоит миллионы и месяцы, основание для этого должно быть предельно взвешенным, а не «на тесте не тормозило».

Гигиена безопасности. Учётные записи, gMSA и шифрование бэкапов

Отдельный пласт находок на аудитах к скорости отношения не имеет, а имеет отношение к живучести системы. Это то, под чем работают службы, как сервер 1С ходит в СУБД и в каком виде лежат резервные копии.

Очень часто наблюдаю следующее: службы стоят под локальными учётками или Local System. Сервер 1С подключается к СУБД через SQL-аутентификацию под sa. Пароль sa записан в текстовом файле на рабочем столе, культура обращения с паролями исторически небрежная. Фразы «везде sa, под ним всё работает» я вижу и слышу на аудитах до сих пор. По сути это открытая дыра, учётная запись с полными правами на сервер, пароль которой известен неопределённому кругу людей.

Централизованные хранилища секретов вроде HashiCorp Vault - признак зрелой инфраструктуры, в среднем или малом бизнесе их часто нет. При этом политики безопасности требуют регулярной ротации паролей и служебные учётные записи выпадают из неё первыми, их смена даётся тяжелее всего. Поменял пароль - положил службы, потом вспоминай все места, где он прописан. Поэтому пароль sa остаётся неизменным годами.

Состоит схема безопасности из трёх частей: службы сервера 1С и SQL Server работают под доменными учётными записями, подключение к СУБД идёт через Windows-аутентификацию, а права выдаются под задачу, вместо sysadmin на всё, «потому что так проще».

Вершина этой схемы - gMSA, групповые управляемые учётные записи служб ⁵. Паролем управляют домен и Windows: он генерируется автоматически длиной 240 байт, ротируется без участия человека и без остановки служб. Его не знает ни один сотрудник, его не слить в конфиги и жиру. Эти учётки ещё называют беспарольными, но «беспарольная» сбивает с толку, пароль у учётки есть, просто его меняет система сама. Три-четыре года назад у gMSA случались шероховатости, сейчас их нет, технология считается высоким стандартом защищённости.

Что это даёт. Ротация паролей происходит сама, их смена перестаёт быть праздником для инфраструктуры, на аудите по безопасности больше не придётся объяснять, почему у всех есть sa. Авторизация и права - часть той же дисциплины «кто и как ходит в СУБД», что и «изоляция» из прошлого раздела, только это из раздела безопасности.

Та же гигиена распространяется на резервные копии. Бэкап - это вся база одним файлом (ну может и не вся и не одним), лежит этот файл, как я уже говорил в первой части, на сетевом ресурсе, то есть в месте заведомо более доступном, чем сам сервер. Незашифрованный bak восстанавливается на любом инстансе MSSQL, и у каждого, кто имеет доступ к сетевой папке, оказывается полная копия «учёта» компании. Штатное шифрование резервных копий есть в SQL Server с версии 2014, работает при создании бэкапа и стороннего софта не требует, из редакций оно недоступно только в Express ⁶. Кстати мало где встречаю шифрованные бэкапы при проведении аудитов, в том числе и в банках… ммда.

Особое внимание! Надо помнить, что шифрование опирается на сертификат и сертификат надо хранить внимательно и бережно, создаётся он средствами самой СУБД без танцев с бубном, без него зашифрованный бэкап восстановить невозможно. В документации Microsoft прямо указано: сертификат резервируется отдельно и хранится отдельно от самих копий. Иначе схема защиты данных приведёт к их гарантированной потере: сервер вывели из эксплуатации, сертификат ушёл вместе с ним, и архив бэкапов стал набором нечитаемых файлов.

Остаётся вопрос размещения. Сетевая папка с бэкапами доступна с сервера, а значит, доступна и злоумышленнику, который до сервера добрался, шифровальщики первым делом ищут именно резервные копии. Дополнительная копия бэкапа должна лежать там, куда по сети не дотянуться: на съёмных носителях или хотя бы в облачном «холодном» хранении S3. Холодное хранение стоит недорого и с задачей хранения справляется «на ура». Шифрование при этом остаётся обязательным, копия, уехавшая в чужое облако - это отдать свои данные «чужому дяде на чужой компьютер», надо всегда об этом помнить.

Про сеть вокруг сервера отдельный разговор, удивительных находок там не меньше. Часто вижу сервер СУБД под 1С, который светится в локальной сети как новогодняя ёлка. Порт 1433 открыт для всех, рядом мигает SQL Browser на UDP 1434 и оповещает, какие инстансы на машине живут и на каких портах. Тут же 3389 для удобства администратора, а к нему в комплекте сетевая шара с бэкапами, доступная всему домену.

Правило простое. На сервер СУБД ходит только сервер приложений 1С и админы. Никаких ALL. Клиентские машины пользователей в этом списке отсутствуют, им нужен сервер 1С на 1541 и диапазон рабочих процессов, до СУБД они не ходят. Значит правило на брандмауэре выглядит не как «разрешить 1433 из локальной сети», а как «разрешить 1433 с адреса сервера приложений». Разница между этими двумя строчками покажет «шифровальщик». В первом случае он доползёт до базы с любой заражённой бухгалтерской машины, во втором упрётся в отказ.

То же самое с портами и протоколами. SQL Browser выключается, порт инстанса задаётся статически. Из сетевых протоколов оставляем TCP/IP, именованные каналы отключаем, если под них ничего не написано. RDP наружу не публикуется никогда, вход администратора идёт через VPN, потому что открытый в интернет 3389 остаётся самым популярным способом получить шифровальщика в периметр. Сам MS SQL Server в интернет не смотрит ни при каких условиях, ни через проброс порта на роутере, ни временно и для подрядчика. Подрядчику заводят VPN.

Проверяется всё это быстро и несложно. Сканируем сервер с обычной пользовательской машины и смотрим, чем он отвечает. Список открытых портов, который вы увидите, почти всегда оказывается длиннее того, какой ожидалось увидеть. Тема сетей в компаниях - узкая и специфичная сфера для сисадмина-сетевика, но если такого специалиста нет, или в компании скромная аппаратная сетевая платформа, то правила брандмауэра никто не отменял, здесь на Хабре много на эту тему качественных и полезных статей. Никогда не надо рассчитывать на то, что «мы маленькие, кому мы нужны». Потери данных - это одинаковая боль и для «маленьких», и для «больших».

Территория DBA. Ожидания, параллелизм, tempdb

Последний блок - территория узкого специалиста. Много копий сломано вокруг мониторинга с алертингом, но мониторинг СУБД сам по себе ровным счётом ничего не даёт ни программисту 1С, ни системному администратору. Метрики имеют смысл для того, кто умеет их интерпретировать: анализы выдают пациенту на руки, а читает их врач.

Самая частая ошибка вокруг этой темы - трактовка типов ожиданий как списка ошибок. В интернете хватает статей, где CXPACKET подан как враг, которого надо истребить. Ожидания возникают всегда, так устроен планировщик SQL Server ⁷, поток либо выполняется, либо чего-то ждёт и сервер ведёт учёт этих ожиданий. Тип ожидания - показатель. Это как анализ крови перед походом к врачу, в бланке много показателей, выход некоторых за нормативные пределы сам по себе ещё не говорит о болезни. Трактовка зависит от системы: у тяжёлой ERP и куста бухгалтерий нормы разные и зависят от профиля нагрузки.

Смотреть нужно превалирующие типы в процентах и их динамику, свежей дельтой за рабочий период, накопленный итог с последнего перезапуска смешивает ночные регламенты с дневной нагрузкой. Показателю нужна и точка отсчёта - эталонный снимок из спокойного периода. Принцип тот же, что с DiskSpd-прогоном дисков из первой части: сравнивать систему надо с её же прошлым.

Если переводить основные ожидания на язык 1С:

Ожидание	Что это на языке 1С	Куда смотреть в первую очередь
LCK_M_*	Пользователи ждут чужих блокировок, «висит проведение»	Режим блокировок конфигурации, длинные транзакции, код
CXPACKET	Запросы уходят в параллель и тратятся на синхронизацию потоков	cost threshold и MAXDOP; в паре с PAGEIOLATCH - индексы и сканы
WRITELOG	Запись упирается в журнал транзакций	Диск под журналом, поток мелких транзакций
ASYNC_NETWORK_IO	Сервер 1С медленно забирает выданный результат	Жадные выборки в коде; сеть - редкая причина
PAGEIOLATCH	Ожидание чтения страниц с диска	Сначала память и планы запросов, потом уже диски
RESOURCE_SEMAPHORE	Отчёты стоят в очереди за памятью	Гранты памяти, тяжёлые сортировки

Есть один wait_type, который заслуживает отдельного внимания в контексте 1С. У ASYNC_NETWORK_IO есть свойство, о котором мало кто помнит: пока клиент не подтвердил приём результата, сервер не снимает установленные блокировки ⁸. «Жадная» выборка в коде 1С держит блокировки всё время, пока сервер приложений её пережёвывает и превращается в блокировки для всех остальных. Чинится это в коде или в конфигурации сервера приложений, сетевая карта здесь ни при чём.

О сервере приложений. Конфигурирование сервера 1С - не моя специализация, здесь я говорю только то, что достоверно установлено по счётчикам производительности и наблюдениям. Часто вижу следующее: в процессе работы сервер приложений генерирует большой поток временных файлов. Уходит этот поток в два места, в рабочий каталог сервера внутри Program Files, где лежат журналы регистрации и сеансовые данные и в каталог Temp профиля служебного пользователя. Обоим потокам положен быстрый носитель, отдельный диск, желательно NVMe. Переносятся оба штатными средствами: каталог сервера - ключом запуска агента, Temp - переменными среды профиля.

В первой части мы убирали сервер приложений с машины СУБД, кейс с «сервером за три миллиона» начинался именно с этого. Отдельная машина решает половину вопроса, вторая половина - сконфигурировать нормально. Процессор и память здесь так же важны, как у СУБД: сервер приложений, упёршийся в ресурсы, тормозит всё у пользователя при идеально настроенной СУБД. Для DBA это диагностический признак: когда метрики СУБД в порядке, а жалобы продолжаются, смотреть стоит на сервер приложений.

Параллелизм - следующий пласт, и вокруг него сложилась смешная ситуация. Увидев CXPACKET в топе ожиданий, с параллелизмом начинают бороться, как с болезнью, хотя мы только что выяснили, чего стоят такие трактовки показателей. Параллелизм - благо, реализованное в ядре СУБД, возможность исполнить один запрос в несколько потоков сразу. Тяжёлый отчёт, собранный восемью потоками вместо одного, это та польза, за которую заплачено производительностью, ну или ядрами сервера, если хотите. Вопрос в настройках, где параллелизм уместен и с каких порогов начинается.

Пороги MAXDOP и Cost по умолчанию - наследие прежних эпох. Cost threshold for parallelism равен 5 со времён, когда серверы были другими (деревья были большими), сегодня это дефолт для дев-стенда разработчика. На проде с таким порогом в параллель уходят даже лёгкие запросы, и сервер тратит ресурсы на синхронизацию потоков вместо работы. Официальная методика 1С при виде CXPACKET предписывает первым делом выставить MAXDOP = 1, ответ, который выключает параллелизм целиком, вместе с пользой от него для тяжёлых отчётов. Замечу для точности, начиная с SQL Server 2016 SP2 безвредная часть этого ожидания вынесена в отдельный тип CXCONSUMER, так что старые трактовки немного завышают проблему.

Готовых метрик или шаблонов в этом разделе не будет. MAXDOP и cost threshold задаются осознанно: на каждом сервере и под каждой нагрузкой значения свои, стандартных метрик для универсального совета здесь никогда нет. Больше того, за один раз эти параметры не выставляются. По ним строятся наблюдения, значения подкручиваются по результатам и такая настройка занимает продолжительное время, в моей практике до двух-трёх месяцев. Профили из первой части задают направление: ERP с тяжёлыми отчётами выигрывает от параллелизма, кусту бухгалтерий он нужен реже, а точные значения даёт наблюдение за конкретной системой.

Tempdb закрывает список. Через неё проходят временные таблицы, сортировки, перестроения и хранилище версий из раздела про изоляцию. Практика по ней устоялась: несколько файлов данных равного размера, по числу логических процессоров, при восьми и больше достаточно восьми на старт ⁹, преаллокация вместо роста мелкими шагами, одинаковый шаг автороста у всех файлов. Инсталлятор MSSQL с 2016 года сам предлагает разумное число файлов, это ещё один довод против инсталляции «далее - далее» из первой части.

Постоянный мониторинг из всего этого складывается по-разному, настраивается достаточно быстро и работает долго: история типов ожиданий и основных счётчиков плюс включённый и настроенный Query Store на продуктивных базах. С SQL Server 2017 Query Store хранит и статистику ожиданий в привязке к конкретным запросам, с SQL Server 2022 включён по умолчанию для новых баз ¹⁰. База, восстановленная со старой версии, сохраняет прежние настройки, поэтому Query Store надо настраивать и включать отдельно. Данные копятся сами и ждут того, кто сможет их прочитать :)

Здесь возникает закономерный вопрос, который я считаю главным во всей теме, кому мониторить? Если мониторить некому, в чём смысл мониторинга? Алерты настраиваются на уровне базы данных, завязаны на метрики и типы ожиданий, разобраться в которых может узкий специалист. Пришедшее по почте письмо о превышении порога журнала транзакций - алерт важный, только кому он придёт? Программисту 1С и системному администратору эти письма ни о чём не говорят, а судьба такого алертинга без постоянного DBA проверена не раз. Неделю-две письма читают, потом пропускают, потом о них забывают, и о самом мониторинге после создания больше никто не вспоминает.

Мониторинг нужен тому, кто будет мониторить, и закладываться на это надо ещё при настройке. Нужен постоянный надзор, как минимум алерты должны приходить DBA. Если штатной позиции в компании нет, её закрывает внешний специалист на сопровождении, нормальная практика для среднего бизнеса, где нагрузка не оправдывает полной ставки.

Где деньги Зин?

Итак, что стоит делать, прежде чем бежать за новым сервером. Сначала снимается статистика ожиданий и нагрузка с текущего сервера. Из неё становится ясно, где именно система теряет время, в блокировках, в коде, в дисках или в ресурсах, только после этого решают: настройка и оптимизация, доработка кода, железо или миграция. Диагностика одного инстанса занимает несколько дней, чаще трёх дней достаточно. Три дня против бюджета на сервер, который может и не помочь. Вот такая вот нехитрая арифметика :)

P.S. За кадром остались план обслуживания (индексы, статистики, проверки целостности, особенно острые для профиля «сто баз за одну ночь») и стратегия резервного копирования. По объёму находок на аудитах каждая из этих тем заслуживает отдельного разбора, они будут (если модераторы меня опять не заблочат :) ).

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

Ссылки

1. Recovery models - SQL Server, Microsoft Learn ↩

2. Database checkpoints - SQL Server, Microsoft Learn ↩

3. Transaction locking and row versioning guide - Microsoft Learn ↩ ↩² ↩³

4. Optimized locking - SQL Server, Microsoft Learn ↩

5. Group Managed Service Accounts overview - Microsoft Learn ↩

6. Backup encryption - SQL Server, Microsoft Learn ↩

7. sys.dm_os_wait_stats - Microsoft Learn ↩

8. Troubleshoot slow queries resulting from ASYNC_NETWORK_IO wait type - Microsoft Learn ↩

9. tempdb database - Microsoft Learn ↩

10. Monitor performance by using the Query Store - Microsoft Learn ↩