Новое а 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 2025: изменения в SUBSTRING

Автор: Steve Jones, T-SQL in SQL Server 2025: Substring Changes

Функция SUBSTRING() долгие годы была одним из моих самых употребимых инструментов — то подправить данные, то для вывода части строки. Хотя это очень полезная функция, у неё было одно досадное ограничение, которое в SQL Server 2025 устранено. В этой короткой статье я рассмотрю это изменение.

С выходом новой версии SQL Server мне хотелось осветить некоторые изменения в коде T‑SQL. Это часть серии о том, как язык T‑SQL развивается в этой версии.

Должен ли 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 (заметьте, что долго идущая транзакция по‑прежнему может, по сути, «заложить» журнал и не давать его очистить, как и в пользовательской базе).

Accelerated Database Recovery для tempdb в SQL Server 2025

Автор: Andrew Pruski, Accelerated Database Recovery for tempdb in SQL Server 2025

Ускоренное восстановление базы данных (Accelerated Database Recovery, ADR) появилось в SQL Server 2019 и обеспечивает быстрое восстановление, мгновенный откат транзакций и агрессивное усечение журнала. Полный обзор того, как ADR этого добивается, приведён в документации.

Теперь в SQL Server 2025 можно включить ADR для tempdb! Быстрое восстановление к tempdb не применимо, но вот мгновенный откат транзакций и агрессивное усечение журнала — на все 100%. Посмотрим, что происходит после включения ADR для tempdb в SQL Server 2025.