Должен ли SQL Server DBA разбираться в Windows Server Failover Clustering?

Автор: Sandra Delany, Should a SQL Server DBA Know Windows Clustering?

Должен ли SQL Server DBA понимать, как устроен кластер Windows Server Failover Clustering (WSFC), уметь создавать его или диагностировать проблемы? Или нам, DBA, лучше не выходить за рамки своей зоны? В некоторых организациях проведена чёткая граница между тем, что можно и чего нельзя DBA, а роли инфраструктуры отданы системным администраторам (SA). Это нормально, но это не означает, что DBA не должен уметь разбираться с проблемами FCI (Failover Cluster Instance) или AG (Availability Group) после непланового отказа на уровне кластера. (Да, AG можно создать и без кластера, но здесь мы этот вариант не рассматриваем.)

Hyper‑V и SQL Server: лучшие практики, о которых нам хочется, чтобы вы знали

Автор: Mike Walsh, Hyper-V and SQL Server Best Practices: What We Wish You Knew

Если вы когда‑нибудь задавались вопросом: «Почему SQL Server на Hyper‑V работает медленнее, чем должен?!», эта заметка может помочь. И да, если бы десять лет назад вы спросили меня о Hyper‑V, я бы, вероятно, лишь усмехнулся. Может, и раньше. Но суть в том, что эта платформа масштабируется, работает, и на фоне «весёлых» нововведений Broadcom/VMware (с соответствующей монетизацией), всё больше клиентов переходят на Hyper‑V. Как и с VMware, здесь важно внимательно отнестись к ряду ключевых настроек.

Спасибо Jeff Iannucci за совместную работу над этой статьёй и за его идеи. Он слишком долго напоминал мне подготовить этот пост и чек‑лист для клиентов — в итоге решил помочь и с написанием.

Мы в Straight Path в основном команда DBA, но нас часто просят помочь с развёртыванием SQL Server на виртуальных машинах Hyper‑V и спрашивают: «Каковы лучшие практики?». Многие (если не большинство) системных администраторов это всё и так знают. Но если вдруг нет, или если в вашей компании «все шляпы» приходится носить вам одному, мы собрали ключевые рекомендации, которые помогут обеспечить высокую доступность и стабильную производительность SQL Server на Hyper‑V.

Это не тайные знания. Но это те вещи, упущенные настройки и неверные решения, которые мы продолжаем встречать на практике, работая с новыми клиентами. И как в нашей статье «VMware and SQL Server best practices» нескольких лет назад, мне гораздо приятнее, когда вы сами находите и исправляете эти моменты, а уж потом зовёте нас для действительно интересных и нетривиальных задач!

sys.dm_db_index_physical_stats со всеми "потрохами"

Автор: Paul Randal, Inside sys.dm_db_index_physical_stats

Давным‑давно, на излёте прошлого века, я написал для SQL Server 2000 команду DBCC SHOWCONTIG, в пару к своему новому изобретению — DBCC INDEXDEFRAG.

А ещё я постоянно носил шорты и люминесцентные оранжевые, жёлтые или зелёные носки.

Многое меняется — скажем, у меня теперь (иногда) есть чувство вкуса. Среди прочего, с появлением в SQL Server 2005 динамических представлений (DMV) DBCC SHOWCONTIG уступил место sys.dm_db_index_physical_stats. Однако под капотом у них один и тот же код — и характеристика ввода‑вывода (I/O) не изменилась.

Эту заметку я собирался написать уже давно, а окончательно подтолкнул меня T‑SQL Tuesday на тему I/O, который сегодня проводит Mike Walsh (blog). Идея отличная, решил присоединиться. Перечитывая перед публикацией, понимаю, что слегка увлёкся (угрохал пару часов) — но это один из моих «детей», так что я имею право! :-)

Отключение очистки «фантомных» записей ради прироста производительности

Автор: Paul Randal, Turning off the ghost cleanup task for a performance gain

Я уже пару раз писал о фантомных (ghost) записях и задаче их очистки (по сути, это единственные разъяснения, о которых мне известно), но сегодня один из MVP коллег спрашивал меня о настройке для отключения этой задачи — не смог её найти для своего клиента.

Мои прежние записи на эту тему:

• Подробно об очистке фантомных строк
• Ghost Cleanup возвращается

Там объяснено, что такое фантомные записи и как работает процесс их очистки.

На больших системах задача очистки может не поспевать за остальной нагрузкой — без шансов «догнать». Это однопоточная задача: представьте 16‑ядерный сервер с массой операций удаления, и один поток, который на одном CPU каждые 5 секунд пытается убрать фантомные записи, образовавшиеся от удалений, выполненных всеми прочими CPU. Очевидно, что очистка будет отставать.

Проблема здесь в том, что задача очистки всё равно будет «всплывать» каждые 5 секунд (каждые 10 секунд в 2008) и начинать удалять фантомы, потенциально ухудшая производительность: удерживая страницы в буферном пуле, порождая журнальные записи и выполняя физические операции ввода‑вывода. Это также один из фоновых процессов, который способен инициировать IO на, казалось бы, полностью бездействующей системе.

Есть способ отключить задачу очистки — флагом трассировки 661, как описано в KB 920093. Но будьте крайне осторожны! Если вы её отключите, место, занятое удалёнными записями, НЕ будет освобождено для повторного использования SQL Server, пока вы явно не сделаете что‑то, чтобы его вернуть, например перестройку индекса.

Иногда предлагают «заставить» очистку пройтись по всему, выполнив скан таблицы или индекса (таким образом поставив все удалённые записи в очередь для очистки). Это альтернативный путь, но он всё равно использует ту же фоновую задачу, а на очень загруженной системе с очень большим числом удалений (внимание, обобщение! :-)) зачастую куда эффективнее убрать «удалённые‑но‑ещё‑не‑возвращённые» записи с помощью reorganize или rebuild индекса.

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

Логирование блокировок и быстрое восстановление

Автор: Paul Randal, Lock logging and fast recovery

Одна из тем, о которых я люблю рассказывать, — журнал транзакций и механизмы журналирования/восстановления. Я читал доклад на эту тему и на PASS, и на SQL Connections, и в обоих случаях обещал опубликовать серию статей о глубинных внутренних аспектах операций журналирования. Перед вами первая из них. Другие мои статьи, посвящённые некоторым деталям журналирования:

• How do checkpoints work and what gets logged (там также объясняется, как стартует восстановление после сбоя: используя загрузочную страницу и самую свежую журнальную запись контрольной точки)
• Finding out who dropped a table using the transaction log
• How expensive are page splits in terms of transaction log?
• Поговорим ещё о циклической природе журнала транзакций
• Ghost Cleanup возвращается
• Подробно об очистке фантомных строк

А теперь — к делу.

В SQL Server в редакции Enterprise существует возможность, называемая быстрое восстановление (fast recovery). Она позволяет базе данных стать доступной для работы сразу после завершения первой фазы восстановления (REDO), ещё до окончания второй (обычно более долгой) фазы (UNDO). Если не понимаете, о чём речь, загляните в мою статью в TechNet Magazine — Ведение журнала и восстановление в SQL Server. Но как SQL Server добивается этого?

Что делает контрольная точка для tempdb?

Автор: Paul Randal, What does checkpoint do for tempdb?

В предыдущей статье я подробно разобрал, как работают контрольные точки и что именно при этом происходит (см. «Как работают контрольные точки и что записывается в журнал транзакций»). А ещё ранее я писал, почему в буферном пуле на загруженной системе может казаться, что там непропорционально много «грязных» страниц tempdb; сейчас хочу чуть подробнее прояснить, почему так и как контрольные точки работают для tempdb. Чтобы посмотреть содержимое буферного пула, см. «Что находится в буферном пуле?».

Контрольная точка для tempdb выполняется только тогда, когда файл журнала tempdb заполнен на 70% — это делается, чтобы по возможности не допускать роста журнала tempdb (заметьте, что долго идущая транзакция по‑прежнему может, по сути, «заложить» журнал и не давать его очистить, как и в пользовательской базе).

Accelerated Database Recovery для tempdb в SQL Server 2025

Автор: Andrew Pruski, Accelerated Database Recovery for tempdb in SQL Server 2025

Ускоренное восстановление базы данных (Accelerated Database Recovery, ADR) появилось в SQL Server 2019 и обеспечивает быстрое восстановление, мгновенный откат транзакций и агрессивное усечение журнала. Полный обзор того, как ADR этого добивается, приведён в документации.

Теперь в SQL Server 2025 можно включить ADR для tempdb! Быстрое восстановление к tempdb не применимо, но вот мгновенный откат транзакций и агрессивное усечение журнала — на все 100%. Посмотрим, что происходит после включения ADR для tempdb в SQL Server 2025.

Как работают контрольные точки и что записывается в журнал транзакций

Автор: Paul Randal, How do checkpoints work and what gets logged

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

SQL Server и большие страницы: подробное объяснение

Автор: Bob Ward, SQL Server and Large Pages Explained

В на Europe PASS Summit я читал доклад о диагностике памяти. В нём упомянул, что SQL Server будет использовать большие страницы (Large Pages), если включён trace flag 834. На конференции Кристиан Болтон, хорошо известный MVP из Великобритании, заметил, что видел в ERRORLOG сообщения о «large pages», хотя trace flag у него был выключен. Тогда я ответил, что не представляю, как такое возможно. Что ж, Кристиан, вы ничего не выдумали.

Вскоре тема всплыла снова, когда я помогал коллегам из CSS разбираться с тем же вопросом. Самое время углубиться и разобраться, что же там на самом деле происходит.

TempDB: призрак Version Store

Автор: SWYS SQL, TEMPDB: The Ghost of VersionStore

Ближе к 30 октября некоторые серверы баз данных начинают вести себя странно, словно хотят поддержать атмосферу Хэллоуина. На этой неделе один из моих серверов вёл себя именно так. Последние месяцы он работал без проблем, но сегодня его TempDB начала стремительно заполняться. Разумеется, это потребовало расследования — и я обнаружил, что причиной неожиданного роста TempDB стал Version Store. Самое странное было в том, что одна база данных занимала почти всё пространство TempDB в Version Store, хотя в ней не было открытых транзакций. Действительно жуткая история!

Хранилище версий не очищается, если хоть в одной базе есть открытые транзакции

Автор: Brent Ozar, The Version Store Won’t Clear If ANY Database Has Open Transactions

Это особенно болезненно для тех, кто обслуживает несколько баз данных на одном сервере. Достаточно одному приложению вести себя плохо и оставлять транзакции открытыми — и внезапно остальные базы начинают расширять TempDB за пределы доступного места. Причём та транзакция в злосчастном приложении может даже ничего не менять, и раньше сама по себе проблем не вызывала, — но как только она делит TempDB с другими приложениями, начинаются каскадные эффекты.

CHECKDB со всех сторон: как понять, будут ли выполняться проверки чистоты данных?

Автор: Paul Randal, CHECKDB From Every Angle: How to tell if data purity checks will be run?

Недавно возник вопрос: если я обновил базу данных с SQL 2000 или более ранней версии, как понять, будут ли выполняться проверки чистоты данных (data purity), или нет?

Как известно, начиная с SQL Server 2005, DBCC CHECKDB включает проверки «чистоты данных». Они ищут значения столбцов, выходящие за допустимый диапазон для их типов данных. Для баз, созданных в SQL Server 2005 и новее, эти проверки всегда выполняются DBCC CHECKDB и не могут быть отключены. Для баз, созданных в более ранних версиях, всё чуть сложнее.