26.2.26

Обнаружение длинных цепочек IAM

Автор: Paul Randal, The Curious Case of… finding long IAM chains

В предыдущей статье Любопытный случай периодического сбоя запроса к крошечной таблице я описал проблему, с которой Джонатан столкнулся у клиента: очень длинные цепочки IAM и обстоятельства, к ним приведшие.

Вопрос заключался в том, как доказать, что некоторые единицы распределения имеют длину цепочки IAM, непропорциональную объёму данных в единице распределения, без утомительного прохода по каждой цепочке IAM, начиная с первой IAM-страницы (чей идентификатор всегда хранится во внутренней таблице sys.allocation_units).

Ответ заключался в том, чтобы сделать именно это, но устранить утомительность, написав изящный код для этого, используя DMF sys.dm_db_page_info, добавленную в SQL Server 2019, вместо необходимости использовать DBCC PAGE с результатами, INSERT … EXEC'нутыми в таблицу.

(DMF? Да, динамическая административная функция. Помните – все они DMO – динамические административные объекты – и либо представления, либо функции – DMV или DMF. DMV просто просматривают информацию, а DMF должны выполнить некоторую работу. Их для простоты собирательно называют DMV).

В частности, ответ заключался в том, чтобы Джонатан написал этот изящный код :-) и вот он. Попробуйте и дайте мне знать, если найдёте какие-либо индексы с массивными цепочками IAM по сравнению с количеством страниц данных или индексов.

;WITH IAM_PAGES AS
(
    SELECT
        1 AS [IAM_Page_Ordinal],
        P.[object_id],
        P.[index_id],
        P.[partition_number],
        IAU.[total_pages],
        IAU.[used_pages],
        IAU.[data_pages],
        IAM_Page.[file_id],
        IAM_Page.[page_id],
        [pfs_page_id],
        [gam_page_id],
        [sgam_page_id],
        [next_page_file_id],
        [next_page_page_id],
        [is_iam_page]
    FROM sys.partitions P
    INNER JOIN sys.system_internals_allocation_units AS IAU
        ON P.[hobt_id] = IAU.[container_id]
    OUTER APPLY sys.fn_PageResCracker (IAU.[first_iam_page]) AS IAM_Page
    OUTER APPLY sys.dm_db_page_info (
            DB_ID (), IAM_Page.[file_id], IAM_Page.[page_id], 'DETAILED') AS Page_Info
        WHERE IAM_Page.[page_id] <> 0 AND OBJECT_SCHEMA_NAME (P.[object_id]) <> N'sys'
UNION ALL
    SELECT          
        [IAM_Page_Ordinal] + 1,
        IAMP.[object_id],
        IAMP.[index_id],
        IAMP.[partition_number],
        IAMP.[total_pages],
        IAMP.[used_pages],
        IAMP.[data_pages],
        Page_Info.[file_id],
        Page_Info.[page_id],
        Page_Info.[pfs_page_id],
        Page_Info.[gam_page_id],
        Page_Info.[sgam_page_id],
        Page_Info.[next_page_file_id],
        Page_Info.[next_page_page_id],
        Page_Info.[is_iam_page]
    FROM IAM_PAGES AS IAMP
    OUTER APPLY sys.dm_db_page_info (
            DB_ID (), IAMP.[next_page_file_id], IAMP.[next_page_page_id], 'DETAILED') AS Page_Info
        WHERE IAMP.[next_page_page_id] <> 0
),
IAM_Counts AS
(
    SELECT
        [object_id],
        [index_id],
        [partition_number],
        [total_pages],
        [used_pages],
        [data_pages],
        COUNT (*) AS [IAM_Page_Count]
    FROM IAM_PAGES
    GROUP BY [object_id], [index_id], [partition_number],
        [total_pages], [used_pages], [data_pages]
)
SELECT * FROM IAM_Counts
WHERE [data_pages] < [iam_page_count]
--  AND [object_id] = OBJECT_ID ('Schema.TableName')
OPTION (MAXRECURSION 0);
GO


25.2.26

Как оптимизировать переключение реплик групп доступности SQL Server

Автор: Aaron Bertrand , Serializing Deletes From Clustered Columnstore Indexes

Мы часто выполняем плановые переключения реплик в группах доступности SQL Server для обслуживания, установки исправлений, обновлений и даже ротации оборудования. Обычно наши переключения выполняются быстро, но иногда они занимают больше времени — и не всегда интуитивно понятно почему, поскольку нет очевидной связи со временем суток, размером базы данных или объёмом транзакций.

Сокращение даже нескольких секунд из этого процесса может улучшить взаимодействие с приложением и конечным пользователем; это также может значительно снизить количество оповещений или, по крайней мере, сократить время, в течение которого оповещения должны быть отключены. Существует множество материалов о том, как правильно выполнять переключения в AG (без потери данных), но гораздо меньше тех, которые сосредоточены на сокращении окна прерывания доступности. Разница обычно заключается в некоторой комбинации объёма повторного выполнения (redo), поведения контрольных точек, открытых транзакций и готовности вторичной реплики.

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

24.2.26

Введение в транзакции SQL Server

Автор: Paul Randal, SQL101: Introduction to SQL Server Transactions

Одним из фундаментальных понятий в любой реляционной системе управления базами данных (СУБД), такой как SQL Server, является транзакция. За свою консультационную карьеру я видел множество случаев проблем с производительностью, вызванных тем, что разработчики не понимают, как работают транзакции в SQL Server, поэтому в этом учебном руководстве я объясню, что такое транзакции и почему они необходимы, а также некоторые детали их работы в SQL Server. В использовании всего этого есть нюансы, когда задействовано Ускоренное восстановление базы данных (ADR) — темы для будущих статей.

20.2.26

Журнал транзакций SQL Server, Часть 2: Архитектура журналирования

Автор: Paul Randal, The SQL Server Transaction Log, Part 2: Log Architecture

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

19.2.26

Опровержение мифов о FILESTREAM

Автор: Paul Randal, A SQL Server DBA myth a day: (18/30) FILESTREAM storage, garbage collection, and more

Данные FILESTREAM не могут храниться удалённо

Контейнер данных FILESTREAM (придуманное название для структуры каталогов NTFS, в которой хранятся данные FILESTREAM) должен подчиняться тем же правилам локальности, что и обычные файлы данных и журнала базы данных – т.е. он должен быть размещён на хранилище, 'локальном' для сервера Windows, на котором работает SQL Server. К данным FILESTREAM можно получить доступ, используя UNC-путь, при условии, что клиент связался с локальным SQL Server и получил необходимый контекст транзакции для использования при открытии файла FILESTREAM.

17.2.26

Любопытный случай периодического сбоя запроса к крошечной таблице

Автор: Paul Randal, The Curious Case of… occasional query failure on a tiny table

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

Рассматриваемая таблица содержала всего несколько миллионов строк данных с максимальным размером строки 60 байт, и запрос обычно выполнялся за несколько секунд, но иногда он «зависал» и либо его приходилось убивать, либо он выполнялся десятки минут. Диагностические средства, запущенные во время возникновения проблемы, не показывали каких-либо необычных ожиданий, давления на сервер не было, а план запроса, генерируемый при долгом выполнении, был практически таким же.

16.2.26

Структуры хранения #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.

15.2.26

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

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

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

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

14.2.26

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

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

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

ЛОЖЬ

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

13.2.26

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

Автор: 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

12.2.26

Можно ли использовать динамические административные представления в режиме совместимости 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).