Исправление безопасности для SQL Server 2017 CU31 - KB5128496

Описание: KB51284964

Скачать: SQLServer2017-KB5128496-x64.exe

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

SQL Server 2017 — версия: 14.0.3560.2

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

Описание: KB5128497

Скачать: SQLServer2017-KB5128497-x64.exe

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

SQL Server 2017 — версия: 14.0.2140.2

Знакомьтесь 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. Я создавал его некоторое время и использовал на мероприятиях и в демонстрациях. Теперь я хочу, чтобы он был у всех.

Новое в 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.

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

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

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

Первые 60 секунд инцидента на проде: остановись, определи масштаб, сопоставь

Автор: Jose Manuel Jurado (MICROSOFT), Lessons Learned #555: The First 60 Seconds of a Production Incident: Stop, Scope, Correlate;

Когда кто-то говорит: «База данных упала», начните с четырёх вопросов: что именно отказывает? кто или что затронуто? когда это началось? что изменилось или коррелируется с этим моментом? Затем позвольте доказательствам определить следующий шаг. Остановись. Определи масштаб. Сопоставь. Устраняй с доказательствами.

Когда начинается критический производственный инцидент, первое сообщение, которое мы часто получаем, звучит примерно так: «База данных упала».

В этот момент всё внезапно становится срочным.

• Инженеры открывают панели мониторинга.
• Кто-то начинает проверять журналы.
• Другой просматривает CPU и память.
• Кто-то ещё спрашивает, было ли развёртывание.
• Тестируются соединения.
• Запрашиваются метрики.
• Связываются с командами.

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

Поработав над множеством производственных инцидентов, один урок становится всё более очевидным: первые 60 секунд — это не про решение инцидента. Это про определение инцидента.

Расплывчатое описание проблемы может направить диагностику во множество разных сторон. Точная формулировка проблемы резко сокращает пространство расследования.

В этой статье описывается простой подход, который можно применить в первые моменты инцидента: Остановись. Определи масштаб. Сопоставь.

Динамическое маскирование данных — что это, чем оно не является и как использовать его эффективно

Автор: Madhumita Tripathy MSFT, Dynamic Data Masking – What it is, What it isn’t, and How to use it effectively

В этой статье мы объясним основное назначение функции динамического маскирования данных: Dynamic Data Masking (для упрощения разработки приложений), разберём как она работает и её надлежащие сценарии использования, а также её ограничения. Если вы рассматриваете возможность использования динамического маскирования данных (DDM) или пересматриваете свою стратегию защиты данных, эта информация поможет вам принять обоснованные решения.

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

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

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

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

Одни и те же ключевые слова строки подключения теперь работают во всех наших драйверах SQL Server

Автор: DavidLevy, Microsoft, The same connection string keywords now work across our SQL drivers

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

Мы это исправляем.

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

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

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

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

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

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

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

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

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