Триггеры 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г.
