Ходит популярное мнение, что если включить моментальные снимки (snapshot isolation), а затем перестроить индексы, то все строки таблицы получат дополнительные 14-байтовые теги версионирования. Правда это или миф? Давайте проверим.
2.10.25
Когда добавляются теги версионирования?
Новое в SQL Server 2025: Виртуализация данных с PolyBase
Microsoft SQL Server 2025 представляет серьёзные улучшения в PolyBase, нацеленные на упрощение, повышение безопасности и лучшую совместимость между платформами. Опираясь на новшества, представленные в SQL Server 2022, SQL Server 2025 развивает виртуализацию данных, делая упор на удобство использования, укрепление безопасности за счёт расширенных вариантов аутентификации и улучшенную поддержку Linux.
1.10.25
Включаем умный параллелелизм вставки с помощью OPTIMIZE_FOR_SEQUENTIAL_KEY
Системы с высокой параллельностью на бумаге всегда выглядят впечатляюще. Вы добавляете десятки процессорных ядер, увеличиваете объём памяти, проектируете схему с «лёгкими» вставками и с удовлетворением думаете: «Всё полетит». И, по правде говоря, при небольшой нагрузке так и выходит. Одна сессия, вставляющая строки в простую таблицу, даже не заставляет SQL Server напрячься.
Но картина меняется, как только вы начинаете нагружать систему сотнями параллельных вставок. Внезапно вся вычислительная мощь перестаёт иметь значение, потому что каждый поток бьётся за одно крошечное место в памяти: последнюю страницу кластерного индекса. Это классическая проблема «last-page insert contention problem». Она возникает всякий раз, когда ключ кластерного индекса последовательный — типичные IDENTITY, DATETIME или NEWSEQUENTIALID(). Каждая новая строка естественным образом «тянется» в конец B-дерева. Это звучит упорядоченно и эффективно, но при конкуренции — это ловушка. Вместо распределения вставок по нескольким страницам все они наваливаются на одну «горячую» страницу.
30.9.25
Интеграция SQL Server 2025 с S3
Эта статья и репозиторий GitHub были обновлены для SQL Server 2025 RC1 и Ubuntu 24.04.
Новое в SQL Server 2025: Вам больше не нужно устанавливать службу PolyBase для работы с файлами Parquet в S3. Ранее, с SQL Server 2022, приходилось создавать пользовательский контейнер или вручную устанавливать PolyBase. Теперь интеграция с объектами S3 и поддержка Parquet работают прямо из коробки!
29.9.25
Когда после TRUNCATE страницы станут доступны для повторного использования?
Это вопрос, который мне когда-то прислали — если таблица усекается внутри транзакции, что защищает целостность страниц таблицы в случае отката транзакции? Давайте выясним.
27.9.25
Подробно об очистке фантомных строк
За годы работы в команде Storage Engine я наблюдал много холивара на различных форумах по поводу задачи ghost cleanup. В предыдущих версиях с ней было несколько проблем (см. например, статью базы знаний — KB932115), и небыло доступно достаточно информации об этом. По какой-то причине я не добрался до публикации об этом в своём старом блоге, но сегодня я хочу подробно разобраться со всем этим.
26.9.25
Доказательство того, что записи не всегда физически хранятся в порядке ключа индекса
Я упоминал это в публикации «Анатомия страницы» — существует распространённое заблуждение, будто записи в индексе ВСЕГДА хранятся в том же физическом порядке, что и логический порядок, определяемый ключом индекса. Вот доказательство того, что это неверно (и заодно небольшое знакомство с другими стилями дампа для DBCC PAGE).
25.9.25
Страницы IAM, цепочки IAM и единицы распределения
Это компиляция из ранее опубликованного материала с добавлением новых фрагментов вывода DBCC PAGE.
24.9.25
Анатомия экстента
В предыдущей публикации я рассказал о страницах базы данных — их структуре и некоторых разновидностях страниц. Теперь я хотел бы объяснить, как страницы объединяются в т.н. экстенты. Экстент представляет собой группу из восьми физически последовательных страниц в файле данных. Экстенты всегда выравниваются по границам 64 КБ (то есть по границам 8 страниц), начиная с начала файла. Экстенты и все их свойства остаются неизменными во всех версиях, но способы их использования различаются. Существует два типа экстентов: смешанные экстенты и однородные (uniform) экстенты.
23.9.25
Использование DBCC PAGE и DBCC IND для доказательства, что расщепление не откатывается
Прежде чем переходить к механизму работы, хочу разобрать две команды, которые я буду часто использовать — DBCC PAGE и DBCC IND. Обе они (на момент написания статьи) являются недокументированными и не поддерживаются официально, но абсолютно безопасны в применении, так как активно используются внутри и вне Microsoft при диагностике. Тем не менее, используйте их на свой страх и риск. Эти команды хорошо известны в сообществе MSSQL, я и другие специалисты уже рассказывали о них ранее.
Чтобы показать, как они работают, я приведу простой сценарий, доказывающий, что расщепления страниц никогда не откатываются. У меня был спор на эту тему, и ответ всегда один — нет. Расщепление страницы происходит тогда, когда вставка или обновление должны произойти в определённом месте индексной страницы, но там не хватает места для новой или обновлённой записи. Расщепления выполняются как отдельные «системные» транзакции. После того как системная транзакция зафиксирована, она не может быть отменена — даже если откатывается пользовательская транзакция, частью которой она была.
22.9.25
Анатомия страницы с помощью DBCC PAGE
Очередная статья из серии «Inside the Storage Engine» посвящена устройству страниц баз данных. Страницы нужны для хранения записей — это блок размером 8192 байта (8 КБ) в файле данных базы. Они выровнены по границам 8 КБ внутри файлов данных, начиная со смещения 0 байт в файле. Ниже — упрощённая иллюстрация базовой структуры:
21.9.25
Доступ к Kubernetes API из SQL Server 2025
Хранимая процедура sp_invoke_external_rest_endpoint, появившаяся в версии SQL Server 2025, позволяет обращаться к внешним конечным точкам REST API прямо из SQL Server. Это открывает множество интересных возможностей. Недавно я задумался: ведь Kubernetes тоже предоставляет REST API. Можно ли обратиться к нему напрямую из SQL Server?
Давайте посмотрим, как это сделать. Пошагово план такой:
- Создать локальный центр сертификации (CA), приватный RSA-ключ и подписанный сертификат
- Развернуть обратный прокси в Kubernetes
- Настроить SQL Server для обращения к прокси
- Использовать хранимую процедуру для вызова Kubernetes API через прокси
Подписаться на:
Комментарии (Atom)