Операции с индексами в режиме ONLINE — это не сплошные единороги и радуги (об информации по единорогам и радугам см. http://whiteboardunicorns.com/ — безопасно для рабочего просмотра).
Этот миф довольно однозначен — зеркальное отображение баз данных позволяет создавать только одно зеркало для каждой основной базы данных. Если вам нужно несколько копий основной базы данных, рассмотрите возможность использования доставки журналов. Вы можете иметь столько вторичных серверов доставки журналов, сколько вам нужно.
Ещё одна классная особенность доставки журналов заключается в том, что для одного из вторичных серверов можно установить задержку применения, скажем, в 8 часов. Это означает, что резервные копии журналов, сделанные на основном сервере (не правда ли забавно, что в разных технологиях используется разная терминология:
Ладно… эта вводная часть как-то сама по себе развилась…) не будут восстановлены на вторичном сервере доставки журналов, пока не пройдёт 8 часов. Если кто-то удалит таблицу в рабочей среде, она почти сразу же исчезнет и в зеркале (с какой-то задержкой, зависящей от состояния очередей SEND и WAIT в тот момент — но вы не можете остановить этот процесс), а вот на вторичном сервере доставки журналов с задержкой применения таблица останется нетронутой.
Кстати, команда SQLCAT написала очень хорошую статью, разоблачающую миф (который происходит из документации Books Online) о том, что можно зеркалировать только 10 баз данных на один экземпляр — см. Mirroring a Large Number of Databases in a Single SQL Server Instance. Также взгляните на статью базы знаний, которую я написал для CSS, где обсуждается то же самое: KB 2001270 Предварительные условия, ограничения и рекомендации по зеркальному отображению базы данных.
Я продолжаю находить или слышать о весьма полезных функциях, которые я просто упустил. Планирую перечитать все записи о «новых возможностях» для SQL Server (ну, по крайней мере, разделы Transact-SQL!) и посмотреть, что ещё я пропустил, а также другие функции, которые я использовал недостаточно, но которые кажутся полезными.
Узнал я об этой функции несколько недель назад из публикации Джована Поповича в LinkedIn.
И я мгновенно понял, что он имел в виду, говоря о том, насколько полезна будет функция DATE_BUCKET (появившаяся в SQL Server 2022)!
Используя эту функцию, вы можете легко группировать данные в различные временные интервалы, такие как год, месяц, день (что, конечно, достаточно стандартно), но также и в интервалы вроде 2 дней, 6,4 недель и т.д. Я не считаю, что это должно заставить вас отказаться от измерения дат в вашем хранилище данных, но она великолепна, когда вы просто исследуете данные и хотите легко поэкспериментировать с разными интервалами.
Триггеры DDL реализованы как триггеры AFTER, что означает, что операция сначала выполняется, а затем перехватывается триггером (и при необходимости откатывается, если в теле триггера есть оператор ROLLBACK).
Это означает, что они не столь легковесны, как можно было бы предположить.
Мгновенная инициализация файлов — малоизвестная возможность SQL Server, начиная с версии 2005, которая позволяет файлам данных (только им, а не файлам журнала) пропустить обычный процесс инициализации нулями. Это прекрасный способ сократить время простоя при аварии, когда необходимо восстановить базу данных с нуля — поскольку вновь создаваемые файлы данных не тратят (потенциально) часы на заполнение нулями, прежде чем начнется фактическая операция восстановления.
Я уже писал в блоге о заблуждениях, касающихся мгновенной инициализации (см. Заблуждения вокруг мгновенной инициализации файлов), но там не рассматривался этот аспект функции.
Вы не можете включить её изнутри SQL Server. SQL Server выполняет однократную проверку при запуске, обладает ли учетная запись службы SQL Server соответствующим разрешением Windows (Perform Volume Maintenance Tasks, также известным как SE_MANAGE_VOLUME_NAME), и затем мгновенная инициализация файлов включается для этого экземпляра. В отличной статье блога Кимберли Instant Initialization – What, Why and How? есть подробности о том, как включить эту функцию (и многое другое).
Вы можете проверить изнутри SQL Server, работает ли она. Включите флаг трассировки 3004 (и 3605, чтобы вывести результат в журнал ошибок), а затем создайте базу данных. В журнале ошибок вы увидите сообщения, указывающие на то, что файл журнала инициализируется нулями. Если мгновенная инициализация файлов НЕ включена, вы также увидите сообщения об инициализации нулями файла данных.
Вы можете отключить мгновенную инициализацию файлов изнутри SQL Server, хоть и только временно. Включение флага трассировки 1806 отключит мгновенную инициализацию файлов, пока этот флаг активен. Чтобы отключить её навсегда, потребуется удалить разрешение безопасности у учетной записи службы SQL Server.
Эти два флага трассировки были впервые задокументированы в блоге SQL Server Premier Field Engineer специалистами MCM Синди Гросс и Дензилом Рибейро — см. их статью Как и зачем включать мгновенную инициализацию файлов.
Если у вас есть возможность — включите эту функцию!
Когда-то давно, в версии 7.0 и ранее DBCC CHECKDB (и остальные команды проверки согласованности) представляли собой неприятную мешанину вложенного циклического кода на C, который устанавливал блокировки таблиц (а вложенные циклы делали алгоритм по сути порядка n-квадрат - это если среди вас есть программисты). Это было нехорошо, и поэтому…
Каждый раз, когда происходит отработка отказа, должно произойти какое-то восстановление после сбоя. Если транзакция не была зафиксирована на сервере, к которому было подключение, когда сервер/база данных перестал работать, нет способа, чтобы SQL Server автоматически воссоздал весь контекст транзакции и восстановил незавершённую транзакцию на сервере, принимающем отказ — независимо от того, использовалась ли для отработки отказа кластеризация, зеркалирование, доставка журналов или репликация SAN.
Это вопрос, который пришёл по электронной почте от бывшего студента, и я резюмирую его так: каковы семантика усечения журнала в распределённой группе доступности?
Поскольку я не эксперт по группам доступности (я просто знаю достаточно, чтобы быть опасным, ха-ха), я попросил Джонатана подключиться, так как он определённо эксперт по группам доступности! Я буду сокращать до AG термин группа доступности и DAG для распределённой группы доступности в объяснении ниже. Для предстоящего обсуждения неважно, имеют ли рассматриваемые AG синхронные или асинхронные реплики.
Описание: KB5074819
Скачать: SQLServer2022-KB5074819-x64.exe
Дата выпуска: 15 января 2026 г.
Версия: 16.0.4235.2
Описание: KB5074901
Скачать: SQLServer2025-KB5074901-x64.exe
Дата выпуска: 15 января 2026 г.
SQL Server 2025 — Версия: 17.0.4005.7
Мы недавно обновили несколько систем до SQL Server 2025. Само обновление ядра прошло гладко, но в наших контурах предварительной подготовки, когда мы планировали переход в прод, возникли три неожиданные проблемы. Ни одна из них не помешала завершению обновления, но все три могли легко сорвать в остальном плавное обновление на месте до SQL Server 2025. Что это были за проблемы и как можно избежать их возникновения?
Это короткая заметка по статье, которую я увидел сегодня утром на SQLServerCentral, где, казалось, утверждалось, что откат транзакций перемещает данные в моментальные снимки базы данных. Это совершенно не соответствует действительности.
Описание: KB5073031
Скачать: SQLServer2022-KB5073031-x64.exe
SQL Server 2022 — Версия: 16.0.1165.1
Дата выпуска: 13 января 2026г.
Описание: KB5072936
Скачать: SQLServer2022-KB5072936-x64.exe
SQL Server 2022 — Версия: 16.0.4230.2
Дата выпуска: 13 января 2026г.
Описание: KB5073177
Скачать: SQLServer2025-KB5073177-x64.exe
SQL Server 2022 — Версия: 17.0.1050.2
Дата выпуска: 13 января 2026г.
Одна из моих самых больших «болевых точек» — это сжатие файлов данных. Хотя, когда я работал в Microsoft, я отвечал за код сжатия, я не писал его (так что не вините меня! :-)), и это никогда не считалось достаточно серьёзной проблемой для клиентов, чтобы её исправлять. Но мне действительно не нравится процесс сжатия файлов данных.
Важно, не путайте сжатие журнала транзакций со сжатием файлов данных. Сжатие журнала может быть необходимо, если ваш журнал вышел из-под контроля, или как часть процесса устранения чрезмерной фрагментации VLF (см. отличные посты Кимберли здесь и здесь). Однако сжатие журнала должно быть редкой операцией и не должно быть частью какого-либо регулярного обслуживания, которое вы выполняете.
В любом случае, я не говорю об использовании параметра TRUNCATEONLY — всё, что он делает, — это отсекает неиспользуемое пространство в конце файлов — это совершенно нормально. Я говорю о фактическом запуске алгоритма сжатия.
Примечание переводчика: статьи Пола и Кимберли были написаны в те времена, когда доминировали HDD. Сейчас это уже больше экзотика и основу составляют диски SSD. Такие диски значительно превосходят жёсткие диски по производительности и времени доступа, что снижает негативные последствия сжатия данных. Однако, если сжимать данные часто, это может заметно снизить число циклов перезаписи ячеек памяти, которое ограничено, и приблизить срок исчерпания ресурса диска. Это ещё один аргумент, почему не стоит этим злоупотреблять.
SQL Server 2025 представляет новую возможность Resource Governor для управления использованием tempdb, а также делает Resource Governor доступным в Standard Edition.
Мне стало интересно: может ли новая функция tempdb в Resource Governor помочь сдержать запросы, которые не используют временные таблицы, но вызывают массовое переполнение данных в tempdb? В документации говорится «да», но я всегда предпочитаю получить практический опыт, когда это возможно.
У меня есть ужасный запрос, который «переливается через край», как автомат с мягким мороженым, объявивший войну. Давайте протестируем новые функции управления tempdb в SQL Server 2025.
У моего класса перерыв на обед — время для записи в блоге! Это интересный вопрос, который возникает периодически (буквально час назад на SQL Server Central) и не очень широко известен.
Существует заблуждение, что вы не можете выполнять динамические административные представления (DMV) в базах данных с уровнем совместимости 80 или ниже. Это не так.
До сих пор широко распространено заблуждение, что при корректной работе в моделях восстановления FULL или BULK_LOGGED полные или дифференциальные резервные копии могут усекать журнал. Нет. Это НИКОГДА не происходит. Это одна из причин, по которой я посвящаю целый доклад этой теме на конференции PASS в этом году — поведение журнала транзакций, по моему скромному мнению, является одной из самых неправильно понимаемых частей SQL Server.
На этой неделе на форумах и в Twitter было оживлённо: люди сталкиваются с множеством интересных проблем. Я заметил, что существует много заблуждений относительно запуска восстановления (repair), поэтому, чтобы завершить пятницу, я пройдусь по их списку для вас. Вот эти заблуждения, по поводу некоторых из которых мне приходилось спорить с людьми несколько раз и в конце концов прибегать к фразе «Слушайте, я писал код восстановления, мне жаль, но вы не правы», что я ненавижу делать:
