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

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. Выжившая транзакция затем может продолжить.

19.10.26

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

Описание: KB5128492

Скачать: SQLServer2025-KB5128492-x64.exe

Дата выпуска: 13 октября 2026 г.

SQL Server 2022 — Версия: 17.0.1145.4

Краткий перечень исправлений:

  • PolyBase: усилена проверка данных, устранены падения при работе с внешними источниками, добавлена валидация схемы delta-таблиц, исправлена небезопасная десериализация очереди отката, обновлена обработка разделяемой памяти. 
  • Backup Restore (VDI): устранены переполнения буфера и выходы за границы памяти при открытии виртуальных устройств и обработке данных; ужесточена проверка размеров и границ. 
  • Extended Events: устранены уязвимости раскрытия информации и отказа в обслуживании при чтении специально сформированных файлов .xel. 
  • Extensibility: обновлён сторонний компонент распаковки архивов; исправлено небезопасное чтение памяти в параметрах AI_GENERATE_EMBEDDINGS; устранены повреждения и раскрытие памяти в парсинге протокола SQL Satellite. 
  • Replication: повышена безопасность и надёжность очередей обновляемых подписок, метаданных безопасности, Log Reader Agent, change feed и потоковой передачи событий; исправлено переполнение буфера при >250 записей 
  • WebSync; усилены проверки авторизации; исправлены проблемы валидации данных. 
  • High Availability: добавлена проверка размера фрагментов FILESTREAM на вторичных репликах. 
  • Query Store: улучшена обработка входных данных Showplan. 
  • Distributed Query: исправлен сбой подключений через MSDASQL при отсутствии UID в строке провайдера. 
  • SQL Trace: ограничена обработка LoginSid размером внутреннего буфера для предотвращения выхода за границы.

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

Описание: KB5126934

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

Дата выпуска: 13 октября 2026 г.

SQL Server 2022 — Версия: 16.0.4305.5

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

Описание: KB5128493

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

Дата выпуска: 13 октября 2026 г.

SQL Server 2022 — Версия: 16.0.1210.3

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

Описание: KB5128494

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

Дата выпуска: 13 октября 2026 г.

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

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

Описание: KB5128495

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

Дата выпуска: 13 октября 2026 г.

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

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.

1.10.26

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

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

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

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

29.9.26

Исследование алгоритма пропорционального заполнения

Автор: Paul Randal, Investigating the proportional fill algorithm

Это тема, которая недавно всплыла в списке рассылки Microsoft Certified Master, и которую я продвигаю из-за её последствий для производительности, так что я подумал, что из неё получится интересная статья.

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 здесь.

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

18.9.26

Ваш план обслуживания перестраивает индексы, которыми никто не пользуется

Автор: Pinal Dave, Your Index Rebuild Maintenance Plan Is Rebuilding Indexes Nobody Uses

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

15.9.26

Резервные копии снимком на вторичных репликах группы доступности

Автор: Andrew Pruski, T-SQL Snapshot Backups on Availability Group Secondary Replicas

Одной из моих любимых возможностей SQL Server 2022 были резервные копии снимком (Transact-SQL snapshot backup). Возможность использовать снимки современных систем хранения для создания согласованных на уровне приложения снимков наших баз данных — это прорыв для всех, кто имеет дело с очень большими базами данных и изо всех сил пытается уложиться в RPO при заданном RTO.

Однако согласованные на уровне приложения снимки требуют, чтобы запись ввода-вывода базы данных была приостановлена/заморожена/остановлена… и (справедливо) это может заставить администраторов баз данных нервничать.

14.9.26

Выясняем причину длительных ожиданий IO_COMPLETION и WRITE_COMPLETION

Автор: Paul Randal, Causes of IO_COMPLETION and WRITE_COMPLETION SQL Server wait types

Во многих наборах статистики ожиданий, которые я анализировал, появляются ожидания IO_COMPLETION и WRITE_COMPLETION (но никогда как самый распространённый тип ожидания).

Официальные определения этих типов ожиданий:

  • IO_COMPLETION: Возникает в ожидании завершения операций ввода-вывода. Этот тип ожидания, как правило, представляет операции ввода-вывода, не связанные со страницами данных. Ожидания завершения ввода-вывода страниц данных отображаются как ожидания PAGEIOLATCH_*.
  • WRITE_COMPLETION: Возникает, когда выполняется операция записи.

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

9.9.26

Выясняем причину длительных ожиданий ASYNC_IO_COMPLETION

Автор: Paul Randal, A cause of high-duration ASYNC_IO_COMPLETION waits

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

Официальное определение ASYNC_IO_COMPLETION: «Происходит, когда задача ожидает завершения операций ввода-вывода.» Очень полезно — НЕТ!

7.9.26

Уровень совместимости и оценщик кардинальности в SQL Server

Автор: Vivek Johari, Compatibility Level vs. Cardinality Estimator in SQL Server: A Complete Guide;

Если вы когда-либо занимались настройкой производительности SQL Server, вы почти наверняка сталкивались с двумя терминами, которые постоянно путают: уровень совместимости (Compatibility Level, CL) и оценщик кардинальности (Cardinality Estimator, CE). Они звучат так, будто могут быть одним и тем же, поскольку изменение одного часто влияет на поведение другого. Но это два разных понятия в ядре SQL Server, и понимание того, где они пересекаются, а где расходятся, необходимо для всех, кто занимается обновлениями, миграциями или настройкой запросов.

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

4.9.26

Промежуточная материализация (Query Memory Spills)

Автор: Klaus Aschenbrenner, Query Memory Spills

Иногда, когда вы смотрите на планы выполнения, вы можете увидеть, что у оператора SELECT иногда есть так называемый грант памяти (Memory Grant). Этот грант памяти указывается в килобайтах и необходим для выполнения запроса, когда некоторым операторам (например, Sort/Hash) в планах выполнения требуется память для выполнения — так называемая память запроса (Query Memory).