Этот миф я слышу снова, и снова, и снова…
Это один из самых разочаровывающих мифов, потому что существует так много «официальной» информации от Microsoft и других записей в блогах, которые увековечивают этот миф.
SQL Server предоставляет параметр оптимизации для нерегламентированных рабочих нагрузок (ad-hoc workloads), действующий в рамках всего сервера, который используется для уменьшения объёма памяти, занимаемого одиночными ad-hoc пакетами и связанными с ними планами. Когда этот параметр включён на уровне экземпляра SQL Server, при первом выполнении пакета ad-hoc для любой базы данных на экземпляре сохраняется «заглушка» скомпилированного плана с уменьшенным потреблением памяти. Эта опция сервера OPTIMIZE_FOR_AD_HOC_WORKLOADS доступна начиная с SQL Server 2019, и имет область действия на уровне базы данных.
Я работал над запросом в службу поддержки, в котором наш клиент обнаружил большое количество планов выполнения, потребляющих ресурсы в кэше планов для одного запроса. Я хотел бы поделиться своими выводами и опытом по предотвращению подобных проблем.
Во второй части статьи о новой функции потоковой передачи событий изменений (Change Event Streaming, CES) в SQL Server 2025 я покажу, как собираются события, генерируемые CES. В Части 1 мы подготовили концентратор событий Azure, сгенерировали токен SAS для доступа к нему, создали демонстрационную базу данных CesDemo и включили CES в базе данных. Затем мы добавили таблицы в группу потоков событий, специально подбирая параметры @include_old_values и @include_all_columns. Теперь CES передаёт DML-изменения (операции вставки, обновления и удаления) из этих таблиц в концентратор событий.
Примечание: Эта статья основана на SQL Server 2025 CTP 2.1. Синтаксис и поведение могут претерпеть незначительные изменения к моменту выпуска продукта. Потоковая передача событий изменений (CES) в конечном итоге будет поддерживаться во всех редакциях SQL Server, включая SQL Server 2025 для Windows, SQL Server 2025 для Linux, Azure SQL Database и Managed Instance.
Теперь мы готовы создать клиентское приложение для потребления сгенерированных событий. Но прежде чем начать писать код, давайте установим контекст, чтобы шаги были понятны.
Во-первых, CES лишь записывает данные в концентраторы событий (Event Hubs). Она не знает (и её это не волнует), кто слушает. Задача вашего клиентского приложения (или приложений) — впоследствии потреблять эти события. Наше демонстрационное приложение на C# будет использовать клиентский SDK концентраторов событий (а именно EventProcessorClient) для прослушивания событий.
Каждому клиенту CES нужно где-то записывать прогресс обработки событий. Это называется контрольной точкой (checkpoint), которая работает как «закладка». Используя контрольные точки, клиентские приложения могут останавливаться, а затем возобновлять работу с того места, где они остановились, не обрабатывая повторно уже обработанные события. SDK использует для этого хранилище BLOB-объектов Azure (Azure Blob Storage).
Вы также встретите термин группа потребителей (consumer group). Представьте группу потребителей как «представление» потока с собственной контрольной точкой. Используя несколько групп потребителей (по одной на клиентское приложение), каждое приложение может поддерживать собственную контрольную точку для отметки своего места в потоке событий. Тарифный план Basic позволяет использовать только одну группу потребителей. Переход на (и оплата) более высокого тарифа, чем Basic, позволит вам управлять несколькими клиентскими приложениями, которые одновременно потребляют события из одного концентратора событий, каждое в своём собственном темпе, не мешая друг другу.
Потоковая передача событий изменений (Change Event Streaming, CES) — одна из самых ожидаемых новых функций, которая появится в SQL Server 2025. Она позволяет непрерывно передавать поэтапные изменения из ваших таблиц напрямую в Azure Event Hubs, где несколько приложений-потребителей могут подписываться на данные событий в реальном времени.
Примечание: Эта статья основана на SQL Server 2025 CTP 2.1. Синтаксис и поведение могут претерпеть незначительные изменения к моменту выпуска продукта. Потоковая передача событий изменений (CES) в конечном итоге будет поддерживаться во всех редакциях SQL Server, включая SQL Server 2025 для Windows, SQL Server 2025 для Linux, Azure SQL Database и Managed Instance.
В этой серии из двух частей я покажу, как настроить и сконфигурировать CES (Часть 1), а затем как создать приложение-потребитель для обработки передаваемых изменений (Часть 2).
За всю мою карьеру в сфере данных, как внутри Microsoft, так и в качестве консультанта, я обнаружил, что одна из самых непонятых частей SQL Server — это журнал транзакций. Недостаток знаний о том, как работает журнал транзакций и как им нужно управлять, или просто распространённые заблуждения, могут привести к различным проблемам в производственной среде, включая:
С этой статьи я начинаю серию публикаций (теперь уже здесь, в моём блоге SQLskills) о журнале транзакций: как он работает и как им следует управлять, и в её рамках я затрону все перечисленные выше проблемы. В этой статье я объясню, что такое журналирование и почему оно необходимо.
Переход на зеркальный сервер (failover) может происходить автоматически или быть инициирован вручную.
Автоматический переход выполняется зеркальным сервером (да, именно зеркальным сервером, а не сервером-свидетелем), если зеркальный сервер и сервер-свидетель приходят к согласию, что не могут связаться с основным сервером (этот процесс называется формированием кворума), и состояние сеанса зеркалирования — SYNCHRONIZED (т.е. на основном сервере не было непереданных записей журнала).
Ручной переход выполняете вы — либо потому, что сервер-свидетель отсутствовал (и, следовательно, зеркальный сервер никогда не сможет сформировать кворум, необходимый для автоматического перехода), либо потому, что состояние сеанса зеркалирования на момент выхода из строя основного сервера было отличным от SYNCHRONIZED.
Сандра Делани написала хорошо продуманную запись в блоге под названием Должен ли SQL Server DBA разбираться в Windows Server Failover Clustering? У неё около 20 лет опыта работы администратором баз данных, и она работает консультантом в Straight Path (компании, которую я уважаю). Вы, вероятно, можете догадаться, исходя из её опыта, что да, она считает, что вы должны знать, как настроить, сконфигурировать и устранять неполадки в кластерах Windows. Это хорошая статья, и вам стоит её прочитать.
Но... я не согласен.
Когда кто-то спрашивает об архитектуре SQL Server, рефлекторным ответом обычно становится «Высокая доступность» (High Availability, HA), будто это требование, а не выбор. Но после 20 лет управления средами SQL Server я обнаружила, что высокая доступность часто создаёт больше проблем, чем решает, особенно в организациях определённого типа.
Маркетинговый ажиотаж вокруг зеркалирования баз данных утверждает, что оно обеспечивает мгновенное обнаружение сбоев и мгновенный переход на резервный сервер.
Это не так. Скорость обнаружения сбоя зависит, среди прочего, от того, что именно вышло из строя.
Мгновенная инициализация файлов — малоизвестная возможность 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 Синди Гросс и Дензилом Рибейро — см. их статью Как и зачем включать мгновенную инициализацию файлов.
Если у вас есть возможность — включите эту функцию!
Мы недавно обновили несколько систем до SQL Server 2025. Само обновление ядра прошло гладко, но в наших контурах предварительной подготовки, когда мы планировали переход в прод, возникли три неожиданные проблемы. Ни одна из них не помешала завершению обновления, но все три могли легко сорвать в остальном плавное обновление на месте до SQL Server 2025. Что это были за проблемы и как можно избежать их возникновения?
SQL Server 2025 представляет новую возможность Resource Governor для управления использованием tempdb, а также делает Resource Governor доступным в Standard Edition.
Мне стало интересно: может ли новая функция tempdb в Resource Governor помочь сдержать запросы, которые не используют временные таблицы, но вызывают массовое переполнение данных в tempdb? В документации говорится «да», но я всегда предпочитаю получить практический опыт, когда это возможно.
У меня есть ужасный запрос, который «переливается через край», как автомат с мягким мороженым, объявивший войну. Давайте протестируем новые функции управления tempdb в SQL Server 2025.
У моего класса перерыв на обед — время для записи в блоге! Это интересный вопрос, который возникает периодически (буквально час назад на SQL Server Central) и не очень широко известен.
Существует заблуждение, что вы не можете выполнять динамические административные представления (DMV) в базах данных с уровнем совместимости 80 или ниже. Это не так.
Этот документ помогает диагностировать или решать проблемы, связанные с производительностью репликации.
В SQL Server 2022 появились снимки на уровне хранилища для почти мгновенного восстановления и встроенную поддержку совместимых с S3 хранилищ объектов для масштабируемых и экономичных резервных копий и запросов к внешним данным.
Microsoft SQL Server уже давно является одним из лидеров корпоративного управления данными, обеспечивая работу критически важных приложений в самых разных отраслях. С выпуском SQL Server 2022 компания Microsoft сделала смелый шаг к модернизации взаимодействия баз данных с подсистемами хранения. Новшества сосредоточены на мгновенном восстановлении с помощью снимков и на нативной интеграции с хранилищами объектов, совместимыми с S3, — обе возможности призваны удовлетворить растущие потребности гибридных облачных сред, аналитики по большим данным и систем высокой доступности.
В этой статье подробно рассматриваются эти инновации — не только то, что они делают, но и почему это важно для администраторов баз данных, разработчиков и организаций, работающих в современном мире, где всем управляют данные.
Дата релиза SQL Server 2025: 18 ноября 2025 г.
В этой статье собран подробный обзор нововведений Always On в SQL Server 2025: быстрый фейловер при устойчивых проблемах, ускорение синхронизации при переключениях, улучшения отказоустойчивости после кратковременной потери кворума, усиление безопасности соединений (TLS 1.3 и TDS 8.0), гибкость управления прослушивателями и маршрутизацией трафика, а также поддержка полноценных резервных копий на вторичных репликах. Материал ориентирован на проектирование, внедрение и эксплуатацию HA/DR решений. Подготовлено с помощью GPT5.
Столкнуться с ошибкой при работе с базой данных SQL Server для администратора БД — всё равно что кошмар наяву. Одна из таких ошибок — SQL Server error 1813 при присоединении базы данных: она напрямую затрагивает саму базу, не давая пользователям получить доступ к ней и к хранимым данным. В этом техническом материале мы подробно разберём эту ошибку, её причины и решения, которые помогут её устранить.
Распределение памяти (memory grants) под запросы — один из ключевых и при этом часто недооцениваемых аспектов настройки производительности SQL Server. Если запрос просит больше памяти, чем ему нужно, падает параллелизм. Если слишком мало — происходят проливы в tempdb.
В SQL Server 2025 Microsoft улучшила обратную связь по распределению памяти запроса (query memory grant feedback) и оптимизацию планов выполнения, благодаря чему движок управляет памятью заметно эффективнее, чем в SQL Server 2022. В этой статье мы рассмотрим, как эти изменения влияют на производительность запросов, сравним уровни совместимости 160 и 170.
Должен ли SQL Server DBA понимать, как устроен кластер Windows Server Failover Clustering (WSFC), уметь создавать его или диагностировать проблемы? Или нам, DBA, лучше не выходить за рамки своей зоны? В некоторых организациях проведена чёткая граница между тем, что можно и чего нельзя DBA, а роли инфраструктуры отданы системным администраторам (SA). Это нормально, но это не означает, что DBA не должен уметь разбираться с проблемами FCI (Failover Cluster Instance) или AG (Availability Group) после непланового отказа на уровне кластера. (Да, AG можно создать и без кластера, но здесь мы этот вариант не рассматриваем.)
