MS SQL Server дело тонкое...: Engine

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

23.9.26

Накопительный пакет обновления 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-именами.

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

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

Дальше »

17.9.26

Скрипт для анализа задержек ввода-вывода

Автор: Paul Randal, Capturing IO latencies for a period of time

На обоих моих предконференционных семинарах по статистике ожиданий на PASS Summit и SQLintersection я обещал сделать несколько статей в блоге. Второй в списке — простой скрипт, позволяющий захватить все чтения, записи и задержки ввода-вывода, произошедшие за фиксированный период времени.

Скрипт делает следующее:

Создаёт две временные таблицы.
Захватывает вывод из sys.dm_io_virtual_file_stats в первую таблицу.
Ожидает настраиваемую задержку (строка 41 в скрипте — в примере я сделал её 30 минут).
Захватывает вывод из sys.dm_io_virtual_file_stats во вторую таблицу.
Предоставляет мой обычный вывод статистики виртуальных файлов по результатам.

Дальше »

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: Возникает, когда выполняется операция записи.

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

Дальше »

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 и ждёте.

Дальше »

11.9.26

Как работают JSON-индексы в SQL Server

Автор: Brent Ozar, Database Animations: How SQL Server’s JSON Indexes Work

По многочисленным просьбам в SQL Server 2025 добавили JSON-индексы. Вы можете съесть торт возможности хранить практически не имеющие схемы JSON-блобы как часть каждой строки и при этом получить его, быстро запрашивая конкретные значения.

Дальше »