Это особенно болезненно для тех, кто обслуживает несколько баз данных на одном сервере. Достаточно одному приложению вести себя плохо и оставлять транзакции открытыми — и внезапно остальные базы начинают расширять TempDB за пределы доступного места. Причём та транзакция в злосчастном приложении может даже ничего не менять, и раньше сама по себе проблем не вызывала, — но как только она делит TempDB с другими приложениями, начинаются каскадные эффекты.
Недавно возник вопрос: если я обновил базу данных с SQL 2000 или более ранней версии, как понять, будут ли выполняться проверки чистоты данных (data purity), или нет?
Как известно, начиная с SQL Server 2005, DBCC CHECKDB включает проверки «чистоты данных». Они ищут значения столбцов, выходящие за допустимый диапазон для их типов данных. Для баз, созданных в SQL Server 2005 и новее, эти проверки всегда выполняются DBCC CHECKDB и не могут быть отключены. Для баз, созданных в более ранних версиях, всё чуть сложнее.
Этот вопрос всплывает время от времени, в последний раз — сегодня утром во время частного курса (сейчас читает Кимберли): каков размер обратного указателя у переадресованной записи? (И да, я давно не писал ничего по‑настоящему «технического»…)
В куче (heap) возможны переадресующие (forwarding) и переадресованные (forwarded) записи. Это случается, когда запись в куче разрастается так, что уже не помещается на текущей странице. В таком случае запись переносится на новую страницу, а в исходном месте остаётся маленькая переадресующая запись. Переадресующая запись указывает на новое местоположение записи, которая называется переадресованной. Это сделано как оптимизация производительности, чтобы не приходилось изменять все некластерные индексы у кучи из‑за нового адреса записи в этой куче.
Расщепление страниц (page splits) всегда считаются дорогими, но насколько же на самом деле? В этой статье я покажу пример, насколько больше становится журнал транзакций, когда страница в индексе вынужденно расщепляются. Я буду использовать DMV sys.dm_tran_database_transactions, чтобы это продемонстрировать. Список столбцов и краткие пояснения к каждому столбцу можно найти в Books Online — я вспомнил о её существовании благодаря кому‑то в Twitter (увы, не помню, кто это был, и не смог найти упоминание в поиске).
В этой статье я хочу развенчать распространённый миф о том, что null bitmap содержит биты только для допускающих NULL столбцов. Это не так — там по одному биту на каждый столбец в определении таблицы, при условии, что в таблице есть хотя бы один допускающий NULL столбец. «Неиспользуемые» биты всегда равны 1, то есть означают «NULL».
Правка 2016: Этот флаг трассировки требуется во всех версиях SQL Server включая SQL Server 2014. На каждом экземпляре SQL Server в мире он должен быть включён. В SQL Server 2016 поведение, включаемое этим флагом, стало значением по умолчанию, поэтому сам TF1118 больше не требуется и не оказывает эффекта.
Вокруг флага трассировки TF1118 существует немало путаницы и заблуждений. Он переключает выделение страниц в tempdb: вместо одиночных распределений для первых 8 страниц они сразу выделяются как экстент (8 страниц). Он применяется, чтобы при высокой нагрузке ослабить конкуренцию за карты распределения (allocation bitmap contention) в tempdb, которая бывает связана, например, с массовым созданием и удалением маленьких временных таблиц.
Есть несколько мест, которые способны вызвать путаницу, на каждом из которых я остановлюсь по порядку. Затем я докажу, что TF1118 по‑прежнему работает во всех версиях SQL Server вплоть до 2014 включительно.
TempDB — одна из моих неизменных головных болей.
Любой, любой, кто может выполнять запросы на вашем сервере, способен за считанные секунды устроить отказ в обслуживании, просто заполнив TempDB простейшим запросом:
DROP TABLE IF EXISTS #big_problem;
CREATE TABLE #big_problem
(filler VARCHAR(8000));
WHILE 1 = 1
INSERT INTO #big_problem
SELECT REPLICATE('X', 8000)
FROM GENERATE_SERIES(1, 100000);
Этот цикл постепенно заполнит TempDB, и когда одна из попыток в итоге завершится ошибкой, это не беда: сессия останется открытой. Она продолжит занимать всё остальное пространство, мешая другим пользователям (и системным задачам) пользоваться используемыми ресурсами.
Вам уж точно не стоит запускать такое в свой последний рабочий день, выходя за дверь: даже если ваш логин отключат, уже запущенные запросы продолжат выполняться, пока не завершатся, или, как в этом случае, пока не нанесут «добивающий удар» по вашему хранилищу, и файлы TempDB не начнут раздуваться, как брюки Sansabelt, пытающиеся справиться с шведским столом «ешь сколько сможешь». И уж точно не стоит гонять это в цикле. (Если всё же решитесь, убедитесь, что в начале скрипта удаляете таблицу, если она существует).
Если вы ещё не на SQL Server 2025, ваша основная линия обороны — заранее задать файлам данных TempDB нужный максимальный размер и отключить авторасширение. Это... слабая защита. Плохо ведущие себя запросы всё равно могут выгрызть TempDB до нуля, создавая проблемы для остальных.
В предыдущих статьях о FILESTREAM я разбирал структуру каталогов контейнера данных FILESTREAM и то, как сопоставлять каталоги с таблицами и столбцами базы данных. В этой статье я объясню, как и когда работает процесс сборки мусора FILESTREAM, поскольку, похоже, нигде это не задокументировано (даже в статье FILESTREAM Storage in SQL Server 2008, которую я писал для Microsoft — предполагаемая глубина не включала такой низкий уровень деталей). Похоже, существует немало путаницы вокруг того, как выполняются обновления данных FILESTREAM и когда удаляются старые версии файлов FILESTREAM. Я объясню, как всё устроено, а затем покажу на примере.
Защита данных от несанкционированного доступа сегодня — одна из главных задач. SQL Server 2022 предлагает новую функцию Database Ledger, усиливающую безопасность данных. Она защищает данные как от злоумышленников, так и от пользователей с повышенными привилегиями — администраторов баз данных, системных и облачных администраторов.
Database Ledger работает как традиционный реестр, фиксируя историю данных. Когда строка обновляется, SQL Server сохраняет её прежнее значение в таблице истории. Эта возможность использует технологию блокчейна, обеспечивая криптографическую целостность данных. SQL Server хеширует каждую транзакцию по SHA-256, формирует корневой хеш и связывает его с хешем предыдущего блока — создавая надёжную цепочку записей. В этой статье мы познакомимся с новой функцией SQL Server на практическом примере.
Периодически (ладно, честно говоря, очень часто) мой внутренний список «надо бы об этом написать» разрастается до таких размеров, что меня охватывает почти непреодолимое желание. К счастью, эти порывы заканчиваются тем, что я публикую сразу несколько записей — иначе кто знает, в какие неприятности я мог бы вляпаться? :-)
Для начала сегодня — довольно глубокие внутренности о том, как работает журнал транзакций в одной конкретной ситуации. Этот вопрос всплывал несколько раз на последних курсах по внутреннему устройству и обслуживанию, которые я вёл, в модуле про журнал транзакций, так что я решил написать статью, подтверждающую, что мой ответ верен. Проще всего сформулировать вопрос с картинкой, позаимствованной из моей статьи в журнале TechNet Magazine (Ведение журнала и восстановление в SQL Server).
Ещё в первых статьях блога я написал подробное описание «фантомных» записей (ghost records) и процесса их очистки — см. статью «Подробно об очистке фантомных строк». На занятии возник вопрос, который стоит разобрать отдельно: возникают ли «фантомные» записи в кучах (heap)? Ответ — нет, не при обычной работе.
DBCC CHECKDB — одна из важнейших команд в наборе инструментов администратора SQL Server. Она проверяет логическую и физическую целостность всех объектов базы данных, помогая выявлять повреждения на ранней стадии — до того, как они превратятся в кошмар восстановления.
В современных версиях, таких как SQL Server 2022, проверки «чистоты данных» (data purity) по умолчанию встроены в движок, CHECKDB может выполняться параллельно, использовать снимки (снапшоты) и даже запускаться на репликах. Тем не менее запустить эту команду на крупных базах данных в рамках коротких «окон» обслуживания бывает непросто.
В этом материале разобрано, когда и как эффективно запускать CHECKDB, как использовать подходящие параметры и как грамотно планировать его выполнение как для ежедневной эксплуатации, так и для готовности к аварийному восстановлению.