Описание: KB5089900
Скачать: SQLServer2022-KB5089900-x64.exe
Дата выпуска: 12.05.2026
SQL Server 2022 — Версия: 16.0.4252.3
13.5.26
Исправление безопасности для SQL Server 2022 GDR - KB5091158
Описание: KB5091158
Скачать: SQLServer2022-KB5091158-x64.exe
Дата выпуска: 12.05.2026
SQL Server 2022 — Версия: 16.0.1180.1
Исправление безопасности для SQL Server 2019 CU32 - KB5090407
Описание: KB5090407
Скачать: SQLServer2019-KB5090407-x64.exe
Дата выпуска: 12.05.2026
SQL Server 2019 — версия: 15.0.4470.1
Исправление безопасности для SQL Server 2019 GDR - KB5090408
Описание: KB5090408
Скачать: SQLServer2019-KB5090408-x64.exe
Дата выпуска: 12.05.2026
SQL Server 2019 — версия: 15.0.2170.1
Исправление безопасности для SQL Server 2017 CU31 - KB5090354
Скачать: SQLServer2017-KB5090354-x64.exe
Дата выпуска: 12.05.2026
SQL Server 2017 — версия: 14.0.3530.2
Исправление безопасности для SQL Server 2016 SP3 - KB5089271
Описание: KB5089271
Скачать: SQLServer2016-KB5089271-x64.exe
Дата выпуска: 12.05.2026
SQL Server 2016 — версия: 13.0.6490.1
12.5.26
Устранение проблем соединений с TVP
В этой статье вы узнаете, почему соединение с Table-Valued Parameters (TVP) может разрушить вашу производительность из-за скрытых сбросов в TempDB и как это исправить с помощью надёжного, готового к проду шаблона.
🧠 В двух словах
- ✔️ Статистическая слепота: TVP не хватает статистики распределения, что заставляет оптимизатор делать зафиксированные предположения о кардинальности. 💣
- ✔️ Памятная катастрофа: Заниженные оценки количества строк приводят к недостаточному распределению памяти и массовым сбросам сортировок и хэш-операций на диск (в TempDB). 🚀
- ✔️ Ловушки sniffing'а: Кэширование планов для маленьких наборов данных в TVP приводит к полному отказу, когда позже передаются большие объёмы данных. ✔️
В высокопроизводительных SQL-средах мы полагаемся на TVP для эффективной передачи наборов данных. Но есть и тёмная сторона. Когда вы выполняете соединение (JOIN) с TVP непосредственно внутри хранимой процедуры, вы часто играете в азартную игру с исполнительным движком. Давайте разберём, почему это происходит и как сохранить контроль.
11.5.26
Создание баз данных через прослушивателя контейнерной группы доступности
Контейнерная группа доступности (Contained Availability Group, CAG) предназначена для упрощения высокодоступности и аварийного восстановления путём инкапсуляции системных баз данных (master, msdb) непосредственно внутри самой группы доступности. Это означает, что учётные записи (логины), задания агента SQL Server, учётные данные и прочие метаданные автоматически реплицируются между репликами, устраняя необходимость ручной синхронизации и снижая эксплуатационную сложность.
Начиная с SQL Server 2025 CU1, вы можете создавать или восстанавливать базы данных напрямую через прослушиватель CAG — без подключения к физическому экземпляру — включая специальный ключ контекста сеанса.
10.5.26
Как выбор типа данных влияет на производительность
На одном из занятий, которые мы с Кимберли вели на этой неделе на конференции SQL Connections, мы обсуждали, как выбирать эффективные типы данных. Я хотел бы поделиться этим обсуждением здесь на примере.
9.5.26
Проверка утилизации процессоров запросами за 45 секунд: от симптомов к первопричине
Выявление высокой нагрузки на ЦП — это первый шаг; найти конкретный запрос, который спустил курок, — вот где начинается настоящая работа. В этой статье я покажу вам, как всего за 45 секунд разоблачить главных убийц ЦП в вашем кэше планов.
В двух словах
- ✔️ Время работы (Worker Time) против затраченного времени (Elapsed Time): Высокое время работы относительно продолжительности выполнения указывает на запрос, утилизирующий ЦП, или на высокий параллелизам.
- ✔️ Анализ кэша планов (Plan Cache Mining): Используйте
sys.dm_exec_query_stats, чтобы найти суммарное потребление ЦП с момента последнего перезапуска. - ✔️ Сосредоточьтесь на количестве выполнений: Запрос, который выполняется 1 миллион раз, потребляя по 10 мс, часто опаснее, чем запрос, выполняющийся один раз 10 секунд.
- ✔️ Анализ первопричины: Чрезмерные сортировки, хэширование и скалярные пользовательские функции (Scalar UDF) — обычные подозреваемые в скачках ЦП.
1.5.26
Проверка распределений памяти за 45 секунд: от симптомов к первопричине
Распределения памяти (memory grants) — это молчаливые убийцы конкурентности в SQL Server. В этой статье я покажу вам, как выявить запросы, пожирающие память, и устранить катастрофические ожидания типа RESOURCE_SEMAPHORE всего за 45 секунд — до того, как ваш сервер полностью остановится!
В двух словах
- ✔️ Распределения памяти предназначены для сортировки и хэширования: Это рабочая область оперативной памяти (workspace RAM), полностью отделённая от буферного пула, который кэширует страницы данных. 🛠️
- ✔️ Ожидания RESOURCE_SEMAPHORE: Главный красный флаг, указывающий на то, что запросы выстраиваются в очередь, испытывая голод по исполнительной памяти. 💣
- ✔️ Выявление виновников: Используйте
sys.dm_exec_query_memory_grants, чтобы мгновенно обнаружить запросы, требующие непомерно больших, неоправданных объёмов оперативной памяти. 🧪 - ✔️ Устранение первопричины: В 99% случаев раздувание памяти вызвано устаревшей статистикой или плохим индексированием, а не недостатком физической оперативной памяти на сервере. ✔️
Сталкивались ли вы когда-нибудь со сценарием, когда ваш процессор практически простаивает, дисковый ввод-вывод находится в норме, но пользовательские приложения повсеместно завершаются по тайм-ауту? Добро пожаловать в ужасное узкое место RESOURCE_SEMAPHORE. Это происходит, когда ваш экземпляр исчерпывает рабочую область памяти для выполнения запросов. Давайте разберём, как диагностировать и исправлять проблемы с распределением памяти — от симптомов до первопричин — менее чем за минуту!
30.4.26
Проверка нагрузки на память за 45 секунд
В этой статье я покажу вам свой диагностический план из 5 шагов для выявления губительной нагрузки на память SQL Server менее чем за 45 секунд. Перестаньте гадать и начните точно определять, что именно лишает ваш буферный пул памяти, прежде чем производительность полностью деградирует!
В двух словах
- ✔️ Уровень ОС: Проверьте доступную физическую память – внешнее давление опасно 🛠️
- ✔️ PLE (Page Life Expectancy – ожидаемая продолжительность жизни страницы): Высокое значение – это хорошо, но внезапные падения означают активное перемещение данных в памяти (churn) 📉
- ✔️ Распределения памяти (Memory Grants): Долгие ожидания и огромные объёмы выделенной памяти – чистые убийцы параллелизма ⏳
- ✔️ Менеджеры памяти (Memory Clerks): Найдите, какой именно кэш (CACHESTORE, USERSTORE) ворует вашу оперативную память 🧠
Подписаться на:
Сообщения (Atom)