Показаны сообщения с ярлыком Query Optimisation. Показать все сообщения
Показаны сообщения с ярлыком Query Optimisation. Показать все сообщения

13.11.26

Устраняем слепую зону в мониторинге: метрики чтения версий из хранилища версий

Автор: Dimitri_Furman, Microsoft, Closing a monitoring blind spot: version store read metrics

Когда мы попросили две популярные большие языковые модели «составить рейтинг ведущих реляционных СУБД по широте и глубине предоставляемых ими средств мониторинга работы ядра», одна поставила SQL Server на первое место, а другая — на второе. Сотни динамических административных представлений (DMV) и системных представлений каталога, тысячи расширенных событий, XML-представление планов запросов и хранилище запросов (Query Store) позволяют вам или вашему агенту диагностировать и устранять практически любые проблемы производительности.

И всё же иногда обнаруживаются слепые зоны.

12.11.26

ТОР - десять типов ожиданий SQL Server

Автор: Brent Ozar, The Top 10 SQL Server Wait Types, Worldwide

SQL Server использует статистику ожиданий, чтобы отслеживать, чего именно приходится ждать запросам. Вместо того чтобы следить за бесчисленными счётчиками Perfmon и объектами динамических административных представлений, проще всего ускорить выполнение запросов, задав один вопрос: «Чего ждёт мой сервер?» После этого сосредоточьте усилия на самом распространённом типе ожидания на вашем сервере.

Когда вы только начинаете изучать настройку производительности, полезно иметь хотя бы общее представление о том, какие типы ожидания встречаются чаще всего. Больше гадать не придётся: благодаря данным, которые мы собирали на протяжении многих лет с тысяч серверов SQL Server по всему миру, мы можем представить общую десятку самых распространённых ожиданий и показать, какую долю времени сервер проводит в каждом из них.

6.11.26

VLF: когда журнал транзакций превращается в коммуналку

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

Чем больше VLF, тем заметнее просадка производительности. Страдают, причём дружно, почти все участники процесса:

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

Порогом тревоги обычно считают тысячу VLF, хотя некоторые умудряются довести журнал до полутора миллионов. Это уже не повод для гордости, а повод взяться за настройки.

3.11.26

Влияние CPU Ready на ожидания SOS_SCHEDULER_YIELD

Автор: Jonathan Kehayias, CPU Ready Impact on SOS_SCHEDULER_YIELD

Однажды мы с Полом обсуждали ожидания SOS_SCHEDULER_YIELD и пытались разобраться, могут ли показатели этих ожиданий в SQL Server искажаться из-за проблем с планированием выполнения виртуальной машины гипервизором.

Я провёл первые эксперименты в своей лаборатории виртуальных машин, используя как Hyper-V, так и VMware. В результате удалось воспроизвести именно ту ситуацию, о которой говорил Пол и которую он описал в своей статье.

29.10.26

Почему при запросе всей таблицы SQL Server не использует параллелизм

Автор: Brent Ozar, Why You Don’t Get Parallelism When You Ask for The Whole Table

Предположим, вы работаете с копией большой базы данных Stack Overflow и хотите получить сведения обо всех пользователях, например для экспорта данных. SQL Server не распараллеливает такой запрос — даже если использовать подсказку, которая требует построить параллельный план:

SELECT Id FROM dbo.Users;
SELECT Id FROM dbo.Users
    OPTION (USE HINT('ENABLE_PARALLEL_PLAN_PREFERENCE'));

Здесь я выбираю только идентификаторы, поскольку в больших копиях базы данных Stack Overflow таблица Users занимает более 1 ГБ. SQL Server Management Studio требуется очень много времени, чтобы отобразить в сетке результатов данные такого объёма. А демонстрировать медленную работу SSMS — не моя цель. Если вы собираетесь повторять этот пример, убедитесь, что используете актуальную версию SQL Server Management Studio: я не хочу, чтобы во время экспериментов у вас закончилась оперативная память, как это могло происходить в старых версиях SSMS.


Почему же запрос не выполняется параллельно? 

28.10.26

Кто поменял MAXDOP 1 на экземпляре?

Автор: Paul Randal, Who is overriding MAXDOP 1 on the instance?

Мне пришёл вопрос по электронной почте: «как могут возникать ожидания латча ACCESS_METHODS_DATASET_PARENT, когда MAXDOP экземпляра установлен в 1?» Этого не должно происходить, так как эта краткая блокировка используется только для координации между потоками, выполняющими параллельное сканирование таблицы или индекса. Однако то, что MAXDOP экземпляра установлен в 1, не означает, что параллелизм не может возникнуть.

Любой может переопределить настройку MAXDOP экземпляра с помощью подсказки запроса.

27.10.26

Некролог на ночное задание по перестроению индексов, 1998–2026

Автор: Pinal Dave, The Nightly Index Rebuild Job, 1998 to 2026: An Obituary

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

23.10.26

Поиск первопричины медленных запросов

Автор: Pinal Dave, Finding the Root Cause of Slow Queries

Поиск первопричины медленных запросов начинается с разделения работы и ожиданий, а затем проверки теорий на планах и истории. Вот вам пример показательного вторника. В 10:12 поиск заказа, который обычно возвращался за 180 миллисекунд, занял 14,8 секунды. Сорок три сеанса накопились за пять минут, и команда приложения захотела новый индекс ещё до обеда. CPU оставался скромным, логические чтения оставались привычными, а кэшированный план совпадал со вчерашним быстрым планом. Запрос провёл почти всю свою жизнь в ожидании LCK_M_S. Ночной процесс инвентаризации оставил открытой транзакцию обновления. Видимый запрос был жертвой, а не виновником. Команда проследовала по blocking_session_id, пока цепочка не закончилась на спящем сеансе. Его последний пакет показывал обновление инвентаризации, и данные транзакции подтвердили незафиксированную работу. Как только этот владелец безопасно зафиксировал транзакцию, задержка упала ниже 200 миллисекунд. Никто не редактировал код жертвы, индексы или статистику.

20.10.26

Взаимоблокировка SQL Server: создайте её сами

Автор: Pinal Dave, SQL Server Deadlock: Build One With Your Own Hands

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

Transaction (Process ID 57) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.

SQL Server разрешает цикл, выбирая одну транзакцию в качестве жертвы, откатывая её и возвращая ошибку 1205. Выжившая транзакция затем может продолжить.

17.10.26

Знакомьтесь sqlsimtools - инструмент для проектирования рабочих нагрузок SQL

Автор: Bob Ward, Microsoft, Introducing sqlsimtools

Много лет назад в далёкой-далёкой галактике мои коллеги из службы поддержки Кит Элмор и Роберт Дорр создали инструмент под названием ostress.exe. На протяжении десятилетий он менял то, как мы воспроизводили проблемы клиентов для SQL Server. Команда разработчиков использовала его, и до недавнего времени я использовал его для демонстраций, книг и примеров. Его магия была простой: ostress мог имитировать множество одновременных пользователей, выполняющих SQL-запросы или скрипты.

Я решил переосмыслить ostress для сегодняшнего мира SQL, и результатом стал sqlsimtools, теперь в публичной предварительной версии по адресу microsoft.github.io/sqlsimtools/. Это бесплатный набор инструментов моделирования рабочих нагрузок с открытым исходным кодом для SQL Server 2019, 2022 и 2025, Azure SQL Database, Azure SQL Managed Instance и SQL database в Microsoft Fabric. Я создавал его некоторое время и использовал на мероприятиях и в демонстрациях. Теперь я хочу, чтобы он был у всех.

16.10.26

Новое в SQL Server 2025: оптимизация плана с опциональными параметрами (OPPO)

Автор: Luca Biondi, SQL SERVER 2025 Optional Parameter Plan Optimization (OPPO). What It Is and Benchmarks — Internal Part 1 Series

SQL Server 2025 наконец атакует одного из старейших убийц производительности: запросы с необязательными параметрами и нестабильные планы выполнения. В этой статье вы узнаете, как OPPO работает изнутри, почему это важно для нагрузок, чувствительных к параметрам, и как провести собственные бенчмарки с реальными тестами T-SQL.

12.10.26

Структуры хранения #7 – Пространственные индексы

Автор: Hugo Kornelis, Storage structures 7 – Spatial indexes

С возвращением в серию о внутреннем устройстве структур хранения. Я начал с обзора стандартных типов хранения в выпусках о дисковом rowstore, колоночных индексах, оптимизированном для памяти хранилище и оптимизированных для памяти колоночных хранилищах, а затем перешёл к специализированным структурам хранения в частях об XML-индексах и JSON-индексах. Теперь пришло время рассмотреть пространственные индексы.

1.10.26

Перестаньте оправдывать снижение коэффициента заполнения расщеплением страниц (ИИ врёт)

Автор: Brent Ozar, Database Animations: Stop Using Page Splits to Justify Lowering Fill Factor

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

Вы отслеживаете не тот показатель.

26.9.26

О размере ключа индекса, глубине индекса и производительности

Автор: Paul Randal, On index key size, index depth, and performance

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

24.9.26

Почему широкий кластерный индекс обходится дороже, чем вы думаете

Автор: Steve Stedman, Why a Wide Clustered Index Costs More Than You Think

Ночное задание обслуживания индексов раньше завершалось до прихода сотрудников. Теперь оно выполняется долго, и никто не добавил столько строк, чтобы объяснить лишний час. Где-то в этой базе данных широкий кластерный индекс тихо делает каждое перестроение дороже, чем оно должно быть.

22.9.26

Обменяйте устойчивость на производительность

Автор: Aaron Bertrand, Delayed Durability in SQL Server 2014

Отложенная устойчивость (Delayed Durability) — это появившаяся в последний момент в SQL Server 2014, но интересная возможность; её краткая суть в лифтовой презентации звучит буквально так:

«Обменяйте устойчивость на производительность».

Сначала немного предыстории. По умолчанию SQL Server использует журнал упреждающей записи (write-ahead log, WAL), что означает, что изменения записываются в журнал до того, как им разрешено быть зафиксированными. В системах, где записи в журнал транзакций становятся узким местом и где есть умеренная терпимость к потере данных, у вас теперь есть возможность временно приостановить требование ждать сброса журнала и подтверждения. Это буквально убирает букву D из ACID, по крайней мере для небольшой части данных (подробнее об этом позже).

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

21.9.26

Delayed Durability в SQL Server

Автор: Paul Randal, Delayed Durability in SQL Server 2014

Одна из интересных новых возможностей SQL Server — отложенная устойчивость (delayed durability, доступна во всех редакциях), которая подробно описана в Books Online здесь.

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

16.9.26

Что такое GitHub Copilot в SQL Server Management Studio?

Автор: Vivek Johari, What Is GitHub Copilot in SQL Server Management Studio?

GitHub Copilot в SQL Server Management Studio приносит ИИ прямо в SSMS. Он может помочь вам писать T-SQL, объяснять запросы, исправлять ошибки, улучшать SQL, понимать объекты базы данных и исследовать проблемы SQL Server.

Вместо того чтобы всегда писать SQL с нуля, вы можете описать, что хотите, на обычном английском и попросить Copilot помочь.

Например:

Find the top 10 customers by total sales in 2026.

Copilot может помочь превратить это требование в T-SQL.

Это может сэкономить время, особенно при работе с незнакомыми базами данных или сложным SQL.

Однако Copilot — это помощник, а не замена знаниям SQL или администратору баз данных.

12.9.26

CXSYNC_PORT и перекос параллелизма: как найти неэффективный параллельный запрос в SQL Server 2022

Автор: Erik Darling, https://erikdarling.com/a-little-about-the-cxsync_port-wait-in-sql-server-2022/

Параллельный план выполнения существует ради одной идеи: разделить работу между несколькими потоками, чтобы сократить время запроса. Если запрос выполняется на DOP 8, вы ожидаете, что он будет примерно в восемь раз быстрее последовательного — с поправкой на то, что параллелизм масштабируется не всегда линейно. Но нередко бывает иначе. Запрос получает восемь потоков, а почти вся работа достаётся одному из них. Остальные семь простаивают, а вы платите за CPU и ждёте.

8.9.26

Что такое остаточный предикат (residual predicate) и почему это плохо?

Автор: Brent Ozar, Database Animations: What’s a Residual Predicate and Why Is It Bad?

Обычно, когда вы смотрите на план выполнения и видите поиск по индексу (index seek), за которым следует поиск по ключу (key lookup), это означает, что запрос выполняется относительно быстро.