Адаптивные соединения (Adaptive Joins) и распределение памяти в SQL Server

Автор: Kendra Little, Adaptive Joins and Memory Grants in SQL Server

Адаптивные соединения (adaptive joins) позволяют оптимизатору выбирать между хэш-соединением (Hash Join) и соединением вложенными циклами (Nested Loop join) во время выполнения, что может быть фантастически полезно для производительности, когда оценки количества строк могут варьироваться. Недавно, когда Эрик Дарлинг (Erik Darling) преподавал двухдневный курс по T-SQL на PASS Community Data Summit, один из студентов спросил, почему план запроса, в котором адаптивное соединение во время выполнения использовало вложенные циклы, всё равно получило большое распределение памяти (memory grant).

Я не помнила ответа на этот вопрос, но замечательная вещь в совместном преподавании в том, что Эрик его знал: адаптивные соединения всегда начинают выполняться как хэш-соединения, а это означает, что они должны получить распределение памяти заранее. Даже если в итоге запрос переключается на вложенные циклы во время выполнения, это распределение памяти уже было выделено. Это имеет реальные последствия для использования памяти, особенно в средах с высокой конкурентностью (high-concurrency environments).

Когда TempDB растёт «вширь»: как RCSI и длинные транзакции незаметно разрушают SQL Server

Автор: Steve Stedman, When TempDB Grows “Up and to the Right”: How RCSI and Open Transactions Quietly Break SQL Server

Одна из самых опасных проблем SQL Server — та, которую вы не замечаете, пока диск не заполнится, а производственная система не упадёт. TempDB особенно хороша в таком типе отказа — она незаметно растёт в фоновом режиме, пока внезапно не становится проблемой для всех.

Недавно мы просматривали отчёт о распределении пространства TempDB (TempDB Allocation History Report), и он прекрасно проиллюстрировал проблему, с которой мы сталкиваемся всё чаще по мере того, как растёт применение READ COMMITTED Snapshot Isolation (RCSI). RCSI обычно является правильным выбором, но когда что-то идёт не так, TempDB может расти взрывным образом, и большинство команд не понимают почему, пока не становится слишком поздно.

«Нет, мы не обновляемся. Что мы упускаем?»

Автор: Thomas Rushton, “No, we’re not upgrading. What are we missing out on?”

SQL Server 2016 — покойся с миром, RIP, скатертью дорога (хотя последнее звучит как-то слишком сурово). SQL Server 2016 выходит из расширенной поддержки (extended support) 14 июля — в День взятия Бастилии, без комментариев — 2026 года. Это следует из политики фиксированного жизненного цикла Microsoft (Fixed Lifecycle Policy): выпуск, примерно пять лет основной поддержки (mainstream support), в течение которой вы получаете исправления, обновления безопасности, улучшения производительности и функциональности, и ещё примерно пять лет расширенной поддержки (extended support), в течение которой вы получаете обновления безопасности и не многое другое. После этой даты Microsoft крайне редко выпускает какие-либо обновления за пределами платной программы расширенных обновлений безопасности (Extended Security Update, ESU), поэтому продолжение использования продукта, срок поддержки которого истёк (EOL product), следует рассматривать как экстренную меру только для краткосрочного использования.

Чего ждёт SOS_SCHEDULER_YIELD в SQL Server: причины и реакция

Автор: Steve Stedman, Decoding SOS_SCHEDULER_YIELD Wait Type in SQL Server: Causes and Solutions

Узнайте о типе ожидания SOS_SCHEDULER_YIELD в SQL Server: выявите причины, такие как конкуренция за ЦП, и найдите решения для настройки производительности с помощью экспертных советов. Этот тип ожидания возникает, когда задача добровольно уступает своё время ЦП, чтобы позволить другим задачам выполняться, что является естественной частью модели кооперативного планирования SQL Server. Однако, когда эти ожидания становятся частыми или продолжительными, они могут указывать на глубинные проблемы, ухудшающие производительность системы, что делает критически важным понимание их последствий.

По своей сути, SOS_SCHEDULER_YIELD отражает давление на ресурсы ЦП, поскольку задачи выстраиваются в очередь для выполнения. Хотя случайные уступки ожидаемы в загруженной среде, чрезмерные ожидания могут указывать на конкуренцию за ЦП, плохо оптимизированные запросы или даже аппаратные ограничения. Определение того, является ли этот тип ожидания симптомом более серьёзной проблемы, требует системного подхода к мониторингу и анализу, что в конечном итоге может привести к значительному повышению производительности.

В этой статье мы разберём тип ожидания SOS_SCHEDULER_YIELD, изучим его причины и то, когда он становится проблемой для вашей среды SQL Server. Мы проведём вас через методы диагностики, чтобы выявить корневые проблемы, и предоставим практические решения для снижения их влияния. Будь вы администратором баз данных (DBA) или разработчиком, понимание и устранение этого типа ожидания поможет обеспечить работу вашей базы данных на пике эффективности.

Клонирование с помощью аварийно-устойчивых снимков в Hyper-V

Автор: Anthony Nocentino, Crash-Consistent Snapshot Cloning - Hyper-V Edition

Если вы следили за моей серией статей о резервном копировании через снимки с помощью T-SQL (T-SQL Snapshot Backup), то большая часть из того, о чём я рассказывал, требовала участия SQL Server в создании снимка: заморозка операций записи, резервное копирование метаданных, скоординированный рабочий процесс. Эта статья покрывает другую сторону этого вопроса: клонирование, устойчивое к аварийному отказу (crash-consistent cloning). Никакой заморозки записи. Никакого резервного копирования. Никакого восстановления на момент времени. Просто клон тома «сырых» данных, который SQL Server автоматически восстанавливает при подключении.

Бывают дни, когда я хочу бросить всё это с кэшем планов и Хранилищем запросов!

Автор: Brent Ozar, There Are Days When I Feel Like Giving Up on the Plan Cache and Query Store

В теории мониторинг производительности SQL Server довольно прост:

1. Изучите главные типы ожиданий (wait types) на сервере.
2. Найдите запросы, вызывающие эти типы ожиданий.
3. Исправьте эти запросы или улучшите реакцию сервера на них (индексы, настройки и т.д.).

Но на практике шаг 2 ужасен, потому что:

• Приложения отправляют на сервер баз данных непараметризованные строки.
• Пользователи Entity Framework строят запросы с FromSqlRaw или string.Format().
• Пользователи Entity Framework пишут запросы с .Contains, который создаёт непараметризованный список IN, даже когда ищут всего одно значение (в EF9 стало лучше).
• Люди пишут неаккуратный динамический SQL, который просто вставляет значения прямо в строку запроса.
• Разработчики SaaS-решений помещают каждого клиента в собственную базу данных, и планы не переиспользуются между базами данных.

Создание баз данных через прослушивателя контейнерной группы доступности

Автор: Attinder_Pal_Singh. Creating a Contained Availability Group and Enabling Database Creation via CAG Listener

Контейнерная группа доступности (Contained Availability Group, CAG) предназначена для упрощения высокодоступности и аварийного восстановления путём инкапсуляции системных баз данных (master, msdb) непосредственно внутри самой группы доступности. Это означает, что учётные записи (логины), задания агента SQL Server, учётные данные и прочие метаданные автоматически реплицируются между репликами, устраняя необходимость ручной синхронизации и снижая эксплуатационную сложность.

Начиная с SQL Server 2025 CU1, вы можете создавать или восстанавливать базы данных напрямую через прослушиватель CAG — без подключения к физическому экземпляру — включая специальный ключ контекста сеанса.

Проверка нагрузки на память за 45 секунд

Автор: Luca Biondi, Check Memory Pressure in 45 Seconds. The "45 Seconds DBA Series" – What Real DBAs Check First | Part 4

В этой статье я покажу вам свой диагностический план из 5 шагов для выявления губительной нагрузки на память SQL Server менее чем за 45 секунд. Перестаньте гадать и начните точно определять, что именно лишает ваш буферный пул памяти, прежде чем производительность полностью деградирует!

В двух словах

• ✔️ Уровень ОС: Проверьте доступную физическую память – внешнее давление опасно 🛠️
• ✔️ PLE (Page Life Expectancy – ожидаемая продолжительность жизни страницы): Высокое значение – это хорошо, но внезапные падения означают активное перемещение данных в памяти (churn) 📉
• ✔️ Распределения памяти (Memory Grants): Долгие ожидания и огромные объёмы выделенной памяти – чистые убийцы параллелизма ⏳
• ✔️ Менеджеры памяти (Memory Clerks): Найдите, какой именно кэш (CACHESTORE, USERSTORE) ворует вашу оперативную память 🧠

Автоматическое исправление планов (Automatic Plan Correction) в SQL Server

Автор: theSQLSith, Query plan regressions got you down? Here's how can Automatic Plan Correction turns it around

Регрессии планов запросов донимают? Вот как автоматическое исправление планов (Automatic Plan Correction) может всё изменить.

Автоматическое исправление планов (Automatic Plan Correction, APC) — это одна из тех функций, о которой я довольно часто беседую с заказчиками, инженерами поддержки и широким сообществом SQL. Она входит в семейство автоматической настройки (Automatic Tuning) и незаметно выполняет свою работу, начиная с SQL Server 2017, обнаруживая регрессии планов запросов и автоматически принудительно применяя ранее известный хороший план для восстановления производительности. Но один из частых вопросов звучит так: как же APC на самом деле решает, произошла ли регрессия? И насколько оно уверено в этом решении?

Начиная с SQL Server 2022 CU4 и продолжая в SQL Server 2025, мы внесли значительные улучшения в статистическую модель, которую APC использует для обнаружения регрессий. В этой статье мы рассмотрим, что изменилось, почему это важно и как вы можете этим воспользоваться.

Проверка узких мест ввода-вывода за 45 секунд

Автор: Luca Biondi, Check IO Bottlenecks in 45 Seconds. The "45 Seconds DBA Series" – What Real DBAs Check First | Part 5

В этой статье я покажу вам, как выявить узкие места ввода-вывода SQL Server менее чем за 45 секунд с помощью специализированных динамических административных представлений (DMV). Перестаньте гадать между задержкой и пропускной способностью и начните исправлять реальные очереди к системе хранения!

Работают ли многоядерные процессоры лучше, чем одноядерные?

Автор: Paul Randal, Search Engine Q&A #5: Do multi-core CPUs perform better than single-core CPUs?

Вот интересный вопрос, который прислал мне мой друг Стив Джонс из SQL Server Central — будет ли один процессор с двумя ядрами работать лучше, чем два одноядерных процессора? Оба варианта имеют два вычислительных ядра, но аппаратная архитектура разная — какой из них обеспечит лучшую производительность SQL Server? Что ж, однозначного ответа нет — всё зависит от многих факторов! Я обсуждал эту тему с Джеромом Халмансом, бывшим коллегой по команде Storage Engine в SQL Server, и с его разрешения я основываю эту статью на нашем обсуждении.

Проверка состояния TempDB за 45 секунд

Автор: Luca Biondi, SQL Server Parameter Sniffing: The Bug That Isn’t a Bug (But Breaks Everything)

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

Когда сервер работает медленно, но метрики CPU и ввода-вывода выглядят нормально. Когда планы выполнения выглядят приемлемо, но что-то всё равно не так. Когда запросы нестабильны — то быстры, то еле ползут — и пользователи жалуются, хотя вы не видите ничего очевидного...

Вот где многие администраторы баз данных тратят часы.

👉 Помните: TempDB часто оказывается замешана, но почти никогда не является первопричиной.

Индексы под всеми углами: Как определить, используется ли индекс?

Автор: Paul Randal, Indexes From Every Angle: How can you tell if an index is being used?

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

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

Чтение заголовков файлов SQL Server с помощью DBCC FILEHEADER

Автор: Anthony Nocentino, Reading SQL Server File Headers with DBCC FILEHEADER

Недавно я глубоко погрузился в изучение дисковых структур SQL Server, и одно из моих любимых направлений — это перечитывание серии статей Пола Рэндала (Paul Randal) о страницах заголовков файлов. Если вы её не читали, сделайте это прямо сейчас. В ней рассказывается о том, что такое страницы заголовков файлов, что они содержат и что происходит при их повреждении. Эта статья развивает эту концепцию. Я буду использовать DBCC FILEHEADER для чтения заголовка каждого файла пользовательской базы данных на сервере и отвечу на вопрос, который возникает чаще, чем можно подумать: можно ли определить, какие файлы принадлежат одной базе данных, исключительно по заголовку файла, без обращения к sys.databases?

Короткий ответ — да, и поле, которое делает это возможным, называется BindingId. Давайте разбираться.

"Все" мифы о резервном копировании

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

Пришло время грандиозного финала!

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

В завершение я представляю вам 30 мифов о резервном копировании — по одному на каждый день апреля. Вчера вечером я сел писать эту статью и не добрал несколько мифов, поэтому обратился за помощью к великолепному сообществу SQL в Twitter — слишком много людей, чтобы перечислять (вы знаете, кто вы) — я благодарю вас!

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

Итак, поехали, последний выпуск…

Мифы о модели восстановления BULK_LOGGED

Автор: Paul Randal, A SQL Server DBA myth a day: (28/30) BULK_LOGGED recovery model

Модель восстановления BULK_LOGGED продолжает сбивать людей с толку…

Мифы о коэффициенте заполнения (fill factor)

Автор: Paul Randal, A SQL Server DBA myth a day: (24/30) twenty six restore myths

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

Миф о том, что эскалация блокировок происходит сначала с уровня строки на уровень страницы, а затем с уровня страницы на уровень таблицы

Автор: Paul Randal, A SQL Server DBA myth a day: (23/30) lock escalation

Миф №23: эскалация блокировок происходит сначала с уровня строки на уровень страницы, а затем с уровня страницы на уровень таблицы.

ЛОЖЬ

Нет, никогда. Эскалация блокировок в SQL Server  всегда переходит непосредственно к блокировке таблицы.

Углублённая диагностика и информативные панели мониторинга

Автор: Pinal Dave, Deeper Diagnostics and Actionable Dashboards

Большинство инструментов мониторинга баз данных созданы не для той аудитории. Панели мониторинга предназначены для успокоения руководителей, оповещения откалиброваны для удовлетворения контрольных списков соответствия требованиям, а отчёты отформатированы для ежеквартальных обзоров. Ничто из этого не полезно в 10 часов вечера, когда приложение возвращает тайм-ауты, а дежурный разработчик просит обновлений каждые три минуты. То, что нужно администратору баз данных в этот момент, — это инструмент, который уже имеет контекст. Не сырые данные, которые нужно собирать в условиях стресса. Не список превышенных порогов. А реальный контекст: что выполнялось, что находилось в ожидании, что изменилось и как это сравнивается с тем, что является нормальным для данного конкретного экземпляра в это время суток. Это более сложная задача, чем кажется, и большинство инструментов мониторинга её не решают. Давайте поговорим об углублённой диагностике и информативных панелях мониторинга.

Миф о том, что регулятор ресурсов позволяет управлять активностью ввода-вывода

Автор: Paul Randal, A SQL Server DBA myth a day: (22/30) resource governor allows IO governing

Регулятор ресурсов (Resource Governor) — это замечательная возможность с SQL Server 2008, но существуют некоторые заблуждения относительно того, что он может делать…