Три мифа о коэффициенте заполнения (fill factor)

Автор: Paul Randal, A SQL Server DBA myth a day: (25/30) fill factor

Это короткая статья о мифах вокруг коэффициента заполнения (fill factor) — тему, которую я настойчиво прояснял ещё в Books Online для SQL Server 2005.

Миф №25: разные заблуждения о коэффициенте заполнения.

Все ложные

Исправление безопасности для SQL Server 2022 CU21 - KB5068406

Описание: KB5068406

Скачать: SQLServer2022-KB5068406-x64.exe

SQL Server 2022 — версия: 16.0.4212.1

Дата выпуска: 11.11.2025

Исправление безопасности для SQL Server 2022 GDR - KB5068407

Описание: KB5068407

Скачать: SQLServer2022-KB5068407-x64.exe

SQL Server 2022 — версия: 16.0.1160.1

Дата выпуска: 11.11.2025

Исправление безопасности для SQL Server 2019 GDR - KB5068405

Описание: KB5068405

Скачать: SQLServer2019-KB5068405-x64.exe

SQL Server 2019 — версия: 15.0.2155.2

Дата выпуска: 11.11.2025

Исправление безопасности для SQL Server 2019 CU32 - KB5068404

Описание: KB5068404

Скачать: SQLServer2019-KB5068404-x64.exe

SQL Server 2019 — версия: 15.0.4455.2

Дата выпуска: 11.11.2025

Исправление безопасности для SQL Server 2017 GDR - KB5068403

Описание: KB5068403

Скачать: SQLServer2017-KB5068403-x64.exe

SQL Server 2017 — версия: 14.0.2095.1

Дата выпуска: 11.11.2025

Исправление безопасности для SQL Server 2017 CU31 - KB5068402

Описание: KB5068402

Скачать: SQLServer2017-KB5068402-x64.exe

SQL Server 2017 — версия: 14.0.3515.1
Дата выпуска: 11.11.2025

Исправление безопасности для SQL Server 2016 SP3 Azure Connect Feature Pack - KB5068400

Описание: KB5068400

Скачать: SQLServer2016-KB5068400-x64.exe

SQL Server 2016 — версия: 13.0.7070.1

Дата выпуска: 11.11.2025

Исправление безопасности для SQL Server 2016 SP3 - KB5068401

SQL Server 2016 — версия: 13.0.6475.1

Описание: KB5068401

Скачать: SQLServer2016-KB5068401-x64.exe

Дата выпуска: 11.11.2025

Потребление памяти запросами в SQL Server 2025

Автор: SQLYARD, SQL Query Memory Consumption in SQL Server 2025

Распределение памяти (memory grants) под запросы — один из ключевых и при этом часто недооцениваемых аспектов настройки производительности SQL Server. Если запрос просит больше памяти, чем ему нужно, падает параллелизм. Если слишком мало — происходят проливы в tempdb.

В SQL Server 2025 Microsoft улучшила обратную связь по распределению памяти запроса (query memory grant feedback) и оптимизацию планов выполнения, благодаря чему движок управляет памятью заметно эффективнее, чем в SQL Server 2022. В этой статье мы рассмотрим, как эти изменения влияют на производительность запросов, сравним уровни совместимости 160 и 170.

Новое а SQL Server 2025: предвкушение - нечёткое сопоставление уже на подходе!

Автор: Rob Farley, SQL Server 2025 excitement – fuzzy is coming!

Разумнее всего ожидать, что общедоступный релиз SQL Server 2025 состоится в этом месяце. На следующей неделе пройдут две крупные конференции в экосистеме данных Microsoft — Microsoft Ignite и PASS Summit. Почти все последние версии выходили как раз под такие мероприятия, а раз они проходят в одну неделю, то очень вероятно, что именно тогда и прозвучат анонсы.

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

Новое в SQL Server 2025: JSON‑индексы

Автор: Koen Verbeeck, The New JSON Index in SQL Server 2025

Мы начали использовать новый тип данных JSON в SQL Server для хранения JSON в таблице. При выполнении запросов с функциями вроде JSON_VALUE видим, что каждый раз выполняется полный просмотр таблицы. Хорошо бы индексировать JSON, чтобы повысить производительность. Поскольку JSON всё шире применяется в мире данных (например, REST‑API обычно возвращают наборы данных в формате JSON), SQL Server расширяет поддержку JSON прямо в ядре СУБД. В начале 2025 года в предварительной версии SQL Server 2025 появилось несколько новых функций для работы с JSON. Ещё одно дополнение — новый тип индекса: JSON‑индекс.

TRUNCATE TABLE не журналируется - миф!

Автор: Paul Randal, A SQL Server DBA myth a day: (19/30) TRUNCATE TABLE is non-logged

Это миф невероятно живуч, так что самое время развеять его — и заодно показать наглядный сценарий, подтверждающий вывод.

Миф №19: операция TRUNCATE TABLE не журналируется.

ЛОЖЬ

В пользовательской базе данных не существует «нежурналируемых» операций. Единственные операции, которые SQL Server выполняет без записи пользовательских изменений в журнал, относятся к хранилищу версий в tempdb.

Три мифа о NULL bitmap

Автор: Paul Randal, A SQL Server DBA myth a day: (6/30) three null bitmap myths

NULL bitmap (NULL‑битовая карта) отслеживает, какие столбцы в записи имеют значение NULL, а какие нет. Она существует как оптимизация производительности, позволяющая движку хранения не загружать целиком всю запись в процессор, когда в списке SELECT есть столбцы со значениями NULL, — тем самым уменьшается число проверяющих операций в строках кеша процессора (см. ссылку с подробностями о работе кешей памяти CPU и протоколе MESI). Разберём три распространённых мифа:

Должен ли SQL Server DBA разбираться в Windows Server Failover Clustering?

Автор: Sandra Delany, Should a SQL Server DBA Know Windows Clustering?

Должен ли SQL Server DBA понимать, как устроен кластер Windows Server Failover Clustering (WSFC), уметь создавать его или диагностировать проблемы? Или нам, DBA, лучше не выходить за рамки своей зоны? В некоторых организациях проведена чёткая граница между тем, что можно и чего нельзя DBA, а роли инфраструктуры отданы системным администраторам (SA). Это нормально, но это не означает, что DBA не должен уметь разбираться с проблемами FCI (Failover Cluster Instance) или AG (Availability Group) после непланового отказа на уровне кластера. (Да, AG можно создать и без кластера, но здесь мы этот вариант не рассматриваем.)

Hyper‑V и SQL Server: лучшие практики, о которых нам хочется, чтобы вы знали

Автор: Mike Walsh, Hyper-V and SQL Server Best Practices: What We Wish You Knew

Если вы когда‑нибудь задавались вопросом: «Почему SQL Server на Hyper‑V работает медленнее, чем должен?!», эта заметка может помочь. И да, если бы десять лет назад вы спросили меня о Hyper‑V, я бы, вероятно, лишь усмехнулся. Может, и раньше. Но суть в том, что эта платформа масштабируется, работает, и на фоне «весёлых» нововведений Broadcom/VMware (с соответствующей монетизацией), всё больше клиентов переходят на Hyper‑V. Как и с VMware, здесь важно внимательно отнестись к ряду ключевых настроек.

Спасибо Jeff Iannucci за совместную работу над этой статьёй и за его идеи. Он слишком долго напоминал мне подготовить этот пост и чек‑лист для клиентов — в итоге решил помочь и с написанием.

Мы в Straight Path в основном команда DBA, но нас часто просят помочь с развёртыванием SQL Server на виртуальных машинах Hyper‑V и спрашивают: «Каковы лучшие практики?». Многие (если не большинство) системных администраторов это всё и так знают. Но если вдруг нет, или если в вашей компании «все шляпы» приходится носить вам одному, мы собрали ключевые рекомендации, которые помогут обеспечить высокую доступность и стабильную производительность SQL Server на Hyper‑V.

Это не тайные знания. Но это те вещи, упущенные настройки и неверные решения, которые мы продолжаем встречать на практике, работая с новыми клиентами. И как в нашей статье «VMware and SQL Server best practices» нескольких лет назад, мне гораздо приятнее, когда вы сами находите и исправляете эти моменты, а уж потом зовёте нас для действительно интересных и нетривиальных задач!

sys.dm_db_index_physical_stats со всеми "потрохами"

Автор: Paul Randal, Inside sys.dm_db_index_physical_stats

Давным‑давно, на излёте прошлого века, я написал для SQL Server 2000 команду DBCC SHOWCONTIG, в пару к своему новому изобретению — DBCC INDEXDEFRAG.

А ещё я постоянно носил шорты и люминесцентные оранжевые, жёлтые или зелёные носки.

Многое меняется — скажем, у меня теперь (иногда) есть чувство вкуса. Среди прочего, с появлением в SQL Server 2005 динамических представлений (DMV) DBCC SHOWCONTIG уступил место sys.dm_db_index_physical_stats. Однако под капотом у них один и тот же код — и характеристика ввода‑вывода (I/O) не изменилась.

Эту заметку я собирался написать уже давно, а окончательно подтолкнул меня T‑SQL Tuesday на тему I/O, который сегодня проводит Mike Walsh (blog). Идея отличная, решил присоединиться. Перечитывая перед публикацией, понимаю, что слегка увлёкся (угрохал пару часов) — но это один из моих «детей», так что я имею право! :-)

Отключение очистки «фантомных» записей ради прироста производительности

Автор: Paul Randal, Turning off the ghost cleanup task for a performance gain

Я уже пару раз писал о фантомных (ghost) записях и задаче их очистки (по сути, это единственные разъяснения, о которых мне известно), но сегодня один из MVP коллег спрашивал меня о настройке для отключения этой задачи — не смог её найти для своего клиента.

Мои прежние записи на эту тему:

• Подробно об очистке фантомных строк
• Ghost Cleanup возвращается

Там объяснено, что такое фантомные записи и как работает процесс их очистки.

На больших системах задача очистки может не поспевать за остальной нагрузкой — без шансов «догнать». Это однопоточная задача: представьте 16‑ядерный сервер с массой операций удаления, и один поток, который на одном CPU каждые 5 секунд пытается убрать фантомные записи, образовавшиеся от удалений, выполненных всеми прочими CPU. Очевидно, что очистка будет отставать.

Проблема здесь в том, что задача очистки всё равно будет «всплывать» каждые 5 секунд (каждые 10 секунд в 2008) и начинать удалять фантомы, потенциально ухудшая производительность: удерживая страницы в буферном пуле, порождая журнальные записи и выполняя физические операции ввода‑вывода. Это также один из фоновых процессов, который способен инициировать IO на, казалось бы, полностью бездействующей системе.

Есть способ отключить задачу очистки — флагом трассировки 661, как описано в KB 920093. Но будьте крайне осторожны! Если вы её отключите, место, занятое удалёнными записями, НЕ будет освобождено для повторного использования SQL Server, пока вы явно не сделаете что‑то, чтобы его вернуть, например перестройку индекса.

Иногда предлагают «заставить» очистку пройтись по всему, выполнив скан таблицы или индекса (таким образом поставив все удалённые записи в очередь для очистки). Это альтернативный путь, но он всё равно использует ту же фоновую задачу, а на очень загруженной системе с очень большим числом удалений (внимание, обобщение! :-)) зачастую куда эффективнее убрать «удалённые‑но‑ещё‑не‑возвращённые» записи с помощью reorganize или rebuild индекса.

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

Логирование блокировок и быстрое восстановление

Автор: Paul Randal, Lock logging and fast recovery

Одна из тем, о которых я люблю рассказывать, — журнал транзакций и механизмы журналирования/восстановления. Я читал доклад на эту тему и на PASS, и на SQL Connections, и в обоих случаях обещал опубликовать серию статей о глубинных внутренних аспектах операций журналирования. Перед вами первая из них. Другие мои статьи, посвящённые некоторым деталям журналирования:

• How do checkpoints work and what gets logged (там также объясняется, как стартует восстановление после сбоя: используя загрузочную страницу и самую свежую журнальную запись контрольной точки)
• Finding out who dropped a table using the transaction log
• How expensive are page splits in terms of transaction log?
• Поговорим ещё о циклической природе журнала транзакций
• Ghost Cleanup возвращается
• Подробно об очистке фантомных строк

А теперь — к делу.

В SQL Server в редакции Enterprise существует возможность, называемая быстрое восстановление (fast recovery). Она позволяет базе данных стать доступной для работы сразу после завершения первой фазы восстановления (REDO), ещё до окончания второй (обычно более долгой) фазы (UNDO). Если не понимаете, о чём речь, загляните в мою статью в TechNet Magazine — Ведение журнала и восстановление в SQL Server. Но как SQL Server добивается этого?

Что делает контрольная точка для tempdb?

Автор: Paul Randal, What does checkpoint do for tempdb?

В предыдущей статье я подробно разобрал, как работают контрольные точки и что именно при этом происходит (см. «Как работают контрольные точки и что записывается в журнал транзакций»). А ещё ранее я писал, почему в буферном пуле на загруженной системе может казаться, что там непропорционально много «грязных» страниц tempdb; сейчас хочу чуть подробнее прояснить, почему так и как контрольные точки работают для tempdb. Чтобы посмотреть содержимое буферного пула, см. «Что находится в буферном пуле?».

Контрольная точка для tempdb выполняется только тогда, когда файл журнала tempdb заполнен на 70% — это делается, чтобы по возможности не допускать роста журнала tempdb (заметьте, что долго идущая транзакция по‑прежнему может, по сути, «заложить» журнал и не давать его очистить, как и в пользовательской базе).