Структуры хранения #3 – In-Memory OLTP

Автор: Hugo Kornelis, Storage structures 3 – Memory-optimized;

После обсуждения традиционного хранения строк на диске (rowstore) в части 1 и колоночных хранилищ (columnstores) в части 2, пришло время обратить наш взгляд в SQL Server на структуры хранения, оптимизированные для памяти.

Оптимизированное для памяти хранение было представлено в SQL Server 2014 в рамках проекта, который имел кодовое название «Hekaton» и позже был переименован в in-memory OLTP. В то время как колоночные индексы были специально нацелены на крупномасштабную аналитическую работу, Hekaton и оптимизированные для памяти таблицы специально предназначены для высоконагруженных OLTP-нагрузок. Полностью устраняя блокировки обычные и краткие и используя предварительно скомпилированный машинный код, где это возможно, время обработки транзакций значительно сокращается, что позволяет достичь пропускной способности, ранее недостижимой.

Название «оптимизированные для памяти» выбрано очень осознанно. Эта функция не просто заменяет дисковое хранилище на хранилище в памяти. Сама структура данных была полностью переработана, чтобы извлечь выгоду из скорости современной памяти и обеспечить безопасный параллельный доступ без использования блокировок или защёлок.

Обратите внимание, что оптимизированные для памяти колоночные индексы, доступные с SQL Server 2016, будут описаны в отдельной статье. Эта статья посвящёна оптимизированным для памяти индексам rowstore.

Разнообразные мифы о контрольных суммах страниц

Автор: Paul Randal, A SQL Server DBA myth a day: (17/30) page checksums

Несколько человек предложили некоторые мифы о контрольных суммах страниц, так что сегодня ещё одно мульти-разоблачительное представление! Ну, по крайней мере, я взволнован :-)

Я подробно описал контрольные суммы страниц в посте в блоге «How to tell if the IO subsystem is causing corruptions?»

Контрольная точка записывает только страницы из зафиксированных транзакций?

Автор: Paul Randal, A SQL Server DBA myth a day: (15/30) checkpoint only writes pages from committed transactions

Контрольная точка записывает только страницы из зафиксированных транзакций

ЛОЖЬ

Этот миф существует целую вечность и связан с непониманием того, как работает общая система журналирования и восстановления. Контрольная точка всегда записывает все страницы, которые были изменены (так называемые «грязные» страницы) с момента последней контрольной точки или с момента считывания страницы с диска. Не имеет значения, зафиксирована транзакция, изменившая страницу, или нет – страница записывается на диск в любом случае. Единственным исключением является tempdb, где страницы данных не записываются на диск в рамках контрольной точки. 

Очистка журнала обнуляет записи журнала?

Автор: Paul Randal, A SQL Server DBA myth a day: (14/30) clearing the log zeroes out log records

Очистка журнала обнуляет записи журнала.

ЛОЖЬ

Журнал транзакций всегда инициализируется нулями при первом создании, ручном расширении или автоматическом расширении. Не путайте это с процессом очистки (clearing) журнала во время обычных операций. Очистка просто означает, что один или несколько VLF (виртуальных файлов журнала) помечаются как неактивные и доступные для перезаписи. Когда происходит очистка журнала, ничего не стирается и не перезаписывается. «Очистка журнала» — это очень сбивающее с толку неправильное название. Оно означает ровно то же самое, что и «усечение журнала», что является ещё одним неудачным термином, потому что размер журнала при этом вообще не меняется.

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

Описание: KB5075211

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

Дата выпуска: 12 февраля 2026 г.

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

Можно ли использовать динамические административные представления в режиме совместимости 80 (MSSQL 2000)?

Автор: Paul Randal, A DBA myth a day: (13/30) you cannot run DMVs when in the 80 compat mode (T-SQL Tuesday #005);

Нельзя выполнять динамические административные представления (DMV) в режиме совместимости 80.

ЛОЖЬ

Для начала, существует большая путаница относительно того, что означает режим совместимости. Означает ли это, что базу данных можно восстановить/присоединить к серверу SQL Server 2000? Нет. Это означает, что некоторые аспекты синтаксического разбора T-SQL, поведения планов запросов, подсказки и некоторые другие вещи ведут себя так же, как в SQL Server 2000 (или 2005, если вы устанавливаете значение 90 на экземпляре 2008).

У tempdb всегда должно быть по одному файлу данных на ядро процессора?

Автор: Paul Randal, A SQL Server DBA myth a day: (12/30) tempdb should always have one data file per processor core;

Этот миф я слышу снова, и снова, и снова…

У tempdb всегда должно быть по одному файлу данных на каждое ядро процессора.

ЛОЖЬ

Это один из самых разочаровывающих мифов, потому что существует так много «официальной» информации от Microsoft и других записей в блогах, которые увековечивают этот миф.

Нечёткое сопоставление строк в SQL Server 2025

Автор: Leonard Lobel, Fuzzy String Matching in SQL Server 2025

Нечёткое сопоставление строк (Fuzzy String Matching) — это процесс поиска строк, которые приблизительно равны, а не точно совпадают. Это критически важная возможность для очистки данных, дедупликации, простого поиска по естественному языку и сопоставления пользовательского ввода с известными значениями.

До сих пор возможности нечёткого сопоставления в SQL Server были ограничены фонетическими сравнениями. Но теперь SQL Server 2025 представляют набор современных функций сходства строк, которые можно запускать напрямую в T-SQL с гораздо большей точностью.

Детализация прав для динамического маскирования данных в SQL Server 2022

Автор: Leonard Lobel, Granular Dynamic Data Masking (DDM) Permissions in SQL Server 2022

Динамическое маскирование данных (Dynamic Data Masking, DDM) — это функция безопасности, представленная ещё в SQL Server 2016. Она скрывает конфиденциальные данные в результирующем наборе запроса, гарантируя, что неавторизованные пользователи не увидят информацию, к которой не должны иметь доступ. Подробное введение в эту функцию можно найти в моей старой статье в блоге.

Эта статья объясняет новые возможности DDM, добавленные в SQL Server 2022, а именно — детализированные разрешения.

Оптимизация базы данных для нерегламентированных запросов

Автор: Joe Sack, Database scoped optimizing for ad hoc workloads

SQL Server предоставляет параметр оптимизации для нерегламентированных рабочих нагрузок (ad-hoc workloads), действующий в рамках всего сервера, который используется для уменьшения объёма памяти, занимаемого одиночными ad-hoc пакетами и связанными с ними планами. Когда этот параметр включён на уровне экземпляра SQL Server, при первом выполнении пакета ad-hoc для любой базы данных на экземпляре сохраняется «заглушка» скомпилированного плана с уменьшенным потреблением памяти. Эта опция сервера OPTIMIZE_FOR_AD_HOC_WORKLOADS доступна начиная с SQL Server 2019, и имет область действия на уровне базы данных.

Большое количество планов выполнения для одного запроса

Автор: Jose_Manuel_Jurado, Lesson Learned #494: High number of Executions Plans for a Single Query

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

Sniffing параметров в SQL Server

Автор: Vivek Johari, Parameter Sniffing in SQL Server

"Parameter Sniffing" (конфиденциальность параметров) в SQL Server происходит, когда план выполнения запроса генерируется с использованием конкретных значений параметров. Последующие выполнения того же запроса могут работать плохо с другими значениями параметров из-за неподходящего кэшированного плана. Вот как можно решить эту проблему: