Первые 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

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

Накопительный пакет обновления SQL Server 2025 CU9 - KB5122048

Описание: KB5122048

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

Дата выпуска: 15 сентября 2026 г.

SQL Server 2025 — Версия: 17.0.5005.3

Analysis Services — Версия: 17.0.25.223

Краткое описание изменений

CU9 содержит 44 исправления, направленных в основном на безопасность и надёжность.

• Безопасность: устранены уязвимости в аутентификации Entra, RPC/TDS, управляемом резервном копировании, анклавах, расширенных событиях, XML, оптимизаторе запросов, репликации и агенте SQL. 
• Сбои и дампы: исправлены нарушения прав доступа и падения при работе с SESSION_CONTEXT, sys.dm_exec_requests, XML OPTION (USE PLAN), LEFT_SHIFT/RIGHT_SHIFT, OPENROWSET(BULK...), sql_variant в CLR. 
• In-Memory OLTP: исправления для SUBSTRING, nvarchar(max) и параметров сортировки _VSS. 
• PolyBase: улучшена проверка S3-совместимых хранилищ и закрыт незащищённый TCP-прослушиватель. 
• Репликация: повышены безопасность и надёжность транзакционной репликации, репликации слиянием и потоковой передачи событий изменений. 
• Прочее: исправления для агента SQL, WMI, счётчика Buffer cache hit ratio, tempdb, NUMA в Standard, хранилища запросов, аудита и присоединения вторичной реплики к группе доступности.

Накопительный пакет обновления SQL Server 2022 CU27 - KB5104824

Описание: KB5104824

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

Дата выпуска: 15 сентября 2026 г.

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

Analysis Services — Версия: 16.0.43.252

Краткое описание изменений

• Безопасность: устранены уязвимости в аутентификации Entra, анклавах, расширенных событиях, XML, аудите, оптимизаторе запросов, OSF и SqlDataRecord.SetBytes. 
• Сбои и дампы: исправлены падения при XML OPTION (USE PLAN), LEFT_SHIFT/RIGHT_SHIFT, OPENROWSET(BULK...)/BULK INSERT, а также в In-Memory OLTP (SUBSTRING, _VSS, nvarchar(max)). 
• Инфраструктура: повышена надёжность агента SQL, WMI, VSS, ADR/PFS, VSS WITH MOVE, устранена гонка в Linux, исправлено присоединение вторичной реплики к AG с именем 64 символа. 
• PolyBase: улучшена проверка S3-совместимых хранилищ и закрыт незащищённый TCP-прослушиватель. 
• Репликация: повышены безопасность и надёжность транзакционной репликации, репликации слиянием и подписок с обновлением в очереди. 
• Прочее: улучшена обработка Showplan, защита данных внутренней репликации и создание пользователей с Unicode-именами.

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

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

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

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

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

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

Delayed Durability в SQL Server

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

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

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

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

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

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