Устранение ошибок включения CDC — Часть 1

Автор: Brass Contributor, Troubleshooting CDC enabling failure - Part 1

Недавно мой заказчик столкнулся с двумя интересными проблемами, связанными с CDC, и сегодня я хотел бы поделиться процессом их диагностики и первопричинами.

Проблема:

В выходные заказчик попытался перенести некоторые изменения на производственный сервер. При попытке включить CDC на производственном сервере сначала возникла ошибка безопасности:

#1: Ошибка безопасности:

Msg 22832, Level 16, State 1, Procedure sp_cdc_enable_table_internal, Line 622

Could not update the metadata that indicates table [dbo].[Table_Name] is enabled for 

Change Data Capture. The failure occurred when executing the command 

'[sys].[sp_cdc_add_job] @job_type = N'capture''. 

The error returned was 916: 'The server principal "S-1-9-3-1293060401-1231192665-3834407059-1208013724." 

is not able to access the database "msdb" under the current security context.'. 

Use the action and error to determine the cause of the failure and resubmit the request

Как оптимизировать переключение реплик групп доступности SQL Server

Автор: Aaron Bertrand , Serializing Deletes From Clustered Columnstore Indexes

Мы часто выполняем плановые переключения реплик в группах доступности SQL Server для обслуживания, установки исправлений, обновлений и даже ротации оборудования. Обычно наши переключения выполняются быстро, но иногда они занимают больше времени — и не всегда интуитивно понятно почему, поскольку нет очевидной связи со временем суток, размером базы данных или объёмом транзакций.

Сокращение даже нескольких секунд из этого процесса может улучшить взаимодействие с приложением и конечным пользователем; это также может значительно снизить количество оповещений или, по крайней мере, сократить время, в течение которого оповещения должны быть отключены. Существует множество материалов о том, как правильно выполнять переключения в AG (без потери данных), но гораздо меньше тех, которые сосредоточены на сокращении окна прерывания доступности. Разница обычно заключается в некоторой комбинации объёма повторного выполнения (redo), поведения контрольных точек, открытых транзакций и готовности вторичной реплики.

Я хотел поделиться некоторыми методами, которые я использую, чтобы сделать плановые переключения более быстрыми и предсказуемыми. Некоторые из этих методов хорошо документированы, другие выпестованы из реальных шаблонов, которые я наблюдал во многих средах с SQL Server. Я расскажу о том, что я делаю до, во время и после переключения первичной реплики, чтобы минимизировать прерывания работы пользователей и повысить вероятность того, что они не заметят, что что-то произошло.

Журнал транзакций SQL Server, Часть 2: Архитектура журналирования

Автор: Paul Randal, The SQL Server Transaction Log, Part 2: Log Architecture

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

Разнообразные мифы о контрольных суммах страниц

Автор: Paul Randal, A SQL Server DBA myth a day: (17/30) page checksums

Несколько человек предложили некоторые мифы о контрольных суммах страниц, так что сегодня ещё одно мульти-разоблачительное представление! Ну, по крайней мере, я взволнован :-)

Я подробно описал контрольные суммы страниц в посте в блоге «How to tell if the IO subsystem is causing corruptions?»

Контрольная точка записывает только страницы из зафиксированных транзакций?

Автор: Paul Randal, A SQL Server DBA myth a day: (15/30) checkpoint only writes pages from committed transactions

Контрольная точка записывает только страницы из зафиксированных транзакций

ЛОЖЬ

Этот миф существует целую вечность и связан с непониманием того, как работает общая система журналирования и восстановления. Контрольная точка всегда записывает все страницы, которые были изменены (так называемые «грязные» страницы) с момента последней контрольной точки или с момента считывания страницы с диска. Не имеет значения, зафиксирована транзакция, изменившая страницу, или нет – страница записывается на диск в любом случае. Единственным исключением является tempdb, где страницы данных не записываются на диск в рамках контрольной точки. 

Очистка журнала обнуляет записи журнала?

Автор: Paul Randal, A SQL Server DBA myth a day: (14/30) clearing the log zeroes out log records

Очистка журнала обнуляет записи журнала.

ЛОЖЬ

Журнал транзакций всегда инициализируется нулями при первом создании, ручном расширении или автоматическом расширении. Не путайте это с процессом очистки (clearing) журнала во время обычных операций. Очистка просто означает, что один или несколько VLF (виртуальных файлов журнала) помечаются как неактивные и доступные для перезаписи. Когда происходит очистка журнала, ничего не стирается и не перезаписывается. «Очистка журнала» — это очень сбивающее с толку неправильное название. Оно означает ровно то же самое, что и «усечение журнала», что является ещё одним неудачным термином, потому что размер журнала при этом вообще не меняется.

Можно ли использовать динамические административные представления в режиме совместимости 80 (MSSQL 2000)?

Автор: Paul Randal, A DBA myth a day: (13/30) you cannot run DMVs when in the 80 compat mode (T-SQL Tuesday #005);

Нельзя выполнять динамические административные представления (DMV) в режиме совместимости 80.

ЛОЖЬ

Для начала, существует большая путаница относительно того, что означает режим совместимости. Означает ли это, что базу данных можно восстановить/присоединить к серверу SQL Server 2000? Нет. Это означает, что некоторые аспекты синтаксического разбора T-SQL, поведения планов запросов, подсказки и некоторые другие вещи ведут себя так же, как в SQL Server 2000 (или 2005, если вы устанавливаете значение 90 на экземпляре 2008).

У tempdb всегда должно быть по одному файлу данных на ядро процессора?

Автор: Paul Randal, A SQL Server DBA myth a day: (12/30) tempdb should always have one data file per processor core;

Этот миф я слышу снова, и снова, и снова…

У tempdb всегда должно быть по одному файлу данных на каждое ядро процессора.

ЛОЖЬ

Это один из самых разочаровывающих мифов, потому что существует так много «официальной» информации от Microsoft и других записей в блогах, которые увековечивают этот миф.

Оптимизация базы данных для нерегламентированных запросов

Автор: Joe Sack, Database scoped optimizing for ad hoc workloads

SQL Server предоставляет параметр оптимизации для нерегламентированных рабочих нагрузок (ad-hoc workloads), действующий в рамках всего сервера, который используется для уменьшения объёма памяти, занимаемого одиночными ad-hoc пакетами и связанными с ними планами. Когда этот параметр включён на уровне экземпляра SQL Server, при первом выполнении пакета ad-hoc для любой базы данных на экземпляре сохраняется «заглушка» скомпилированного плана с уменьшенным потреблением памяти. Эта опция сервера OPTIMIZE_FOR_AD_HOC_WORKLOADS доступна начиная с SQL Server 2019, и имет область действия на уровне базы данных.

Большое количество планов выполнения для одного запроса

Автор: Jose_Manuel_Jurado, Lesson Learned #494: High number of Executions Plans for a Single Query

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

Новое в SQL Server 2025: Change Event Streaming (Часть 2: Собирание событий)

Автор: Leonard Lobel, Getting Started with Change Event Streaming in SQL Server 2025 (Part 2: Consuming Events)

Во второй части статьи о новой функции потоковой передачи событий изменений (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, позволит вам управлять несколькими клиентскими приложениями, которые одновременно потребляют события из одного концентратора событий, каждое в своём собственном темпе, не мешая друг другу.

Новое в SQL Server 2025: Change Event Streaming (Часть 1: Установка и настройка)

Автор: Leonard Lobel, Getting Started with Change Event Streaming in SQL Server 2025 (Part 1: Setup and Configuration)

Потоковая передача событий изменений (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).

Журнал транзакций SQL Server, Часть 1: Основы журналирования

Автор: Paul Randal, The SQL Server Transaction Log, Part 1: Logging Basics

(Эта статья впервые появилась на SQLperformance.com четыре года назад как часть серии публикаций, до того как этот сайт был законсервирован в конце 2022 года и серия была прервана. Переопубликована здесь с разрешения, с небольшими правками.)

За всю мою карьеру в сфере данных, как внутри Microsoft, так и в качестве консультанта, я обнаружил, что одна из самых непонятых частей SQL Server — это журнал транзакций. Недостаток знаний о том, как работает журнал транзакций и как им нужно управлять, или просто распространённые заблуждения, могут привести к различным проблемам в производственной среде, включая:

• Неуправляемый рост журнала транзакций и потенциальное исчерпание свободного места.
• Проблемы с производительностью из-за повторяющихся операций сжатия журнала транзакций.
• Проблемы с производительностью из-за явления, известного как фрагментация виртуальных файлов журнала (VLF), о котором я писал в этой статье.
• Невозможность восстановить базу данных до желаемой точки во времени с использованием резервных копий журнала транзакций.
• Невозможность выполнить резервное копирование заключительного фрагмента журнала (tail-log backup) во время аварийного восстановления (см. здесь объяснение таких копий).
• Различные проблемы, связанные с переключением при отказе (failover) и производительностью восстановления.

С этой статьи я начинаю серию публикаций (теперь уже здесь, в моём блоге SQLskills) о журнале транзакций: как он работает и как им следует управлять, и в её рамках я затрону все перечисленные выше проблемы. В этой статье я объясню, что такое журналирование и почему оно необходимо.

Миф: Переход на зеркальный сервер при зеркалировании баз данных происходит мгновенно

Автор: Paul Randal, A SQL Server DBA myth a day: (11/30) database mirroring failover is instantaneous;

Переход на реплику при зеркальном отображении баз данных происходит мгновенно

ЛОЖЬ

Переход на зеркальный сервер (failover) может происходить автоматически или быть инициирован вручную.

Автоматический переход выполняется зеркальным сервером (да, именно зеркальным сервером, а не сервером-свидетелем), если зеркальный сервер и сервер-свидетель приходят к согласию, что не могут связаться с основным сервером (этот процесс называется формированием кворума), и состояние сеанса зеркалирования — SYNCHRONIZED (т.е. на основном сервере не было непереданных записей журнала).

Ручной переход выполняете вы — либо потому, что сервер-свидетель отсутствовал (и, следовательно, зеркальный сервер никогда не сможет сформировать кворум, необходимый для автоматического перехода), либо потому, что состояние сеанса зеркалирования на момент выхода из строя основного сервера было отличным от SYNCHRONIZED.

А может, вам вообще не стоит использовать кластеризацию или группы доступности

Автор: Brent Ozar, Maybe You Shouldn’t Even Be Using Clustering or AGs.

Сандра Делани написала хорошо продуманную запись в блоге под названием Должен ли SQL Server DBA разбираться в Windows Server Failover Clustering? У неё около 20 лет опыта работы администратором баз данных, и она работает консультантом в Straight Path (компании, которую я уважаю). Вы, вероятно, можете догадаться, исходя из её опыта, что да, она считает, что вы должны знать, как настроить, сконфигурировать и устранять неполадки в кластерах Windows. Это хорошая статья, и вам стоит её прочитать.

Но... я не согласен.

Вы задумывались о том, чтобы не использовать высокую доступность SQL Server?

Автор: Chrissy LeMaire, Have You Considered Not Using SQL Server High Availability?

Когда кто-то спрашивает об архитектуре SQL Server, рефлекторным ответом обычно становится «Высокая доступность» (High Availability, HA), будто это требование, а не выбор. Но после 20 лет управления средами SQL Server я обнаружила, что высокая доступность часто создаёт больше проблем, чем решает, особенно в организациях определённого типа.

Миф: Зеркалирование баз данных мгновенно обнаруживает сбои

Автор: Paul Randal, A SQL Server DBA myth a day: (10/30) database mirroring detects failures immediately

Database Mirroring мгновенно обнаруживает сбои

ЛОЖЬ

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

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

Миф: Мгновенной инициализацией файлов можно управлять изнутри SQL Server

Автор: Paul Randal, A SQL Server DBA myth a day: (3/30) instant file initialization can be controlled from within SQL Server

Мгновенную инициализацию файлов можно a) включить и b) выключить изнутри SQL Server

a) ЛОЖЬ и b) ИСТИНА, соответственно

Мгновенная инициализация файлов — малоизвестная возможность 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: три извлечённых урока

Автор: Aaron Bertrand , Upgrading to SQL Server 2025: Three Lessons Learned

Мы недавно обновили несколько систем до SQL Server 2025. Само обновление ядра прошло гладко, но в наших контурах предварительной подготовки, когда мы планировали переход в прод, возникли три неожиданные проблемы. Ни одна из них не помешала завершению обновления, но все три могли легко сорвать в остальном плавное обновление на месте до SQL Server 2025. Что это были за проблемы и как можно избежать их возникновения?

Тестирование ограничений tempdb в Resource Governor SQL Server 2025 с запросом, вызывающим переполнение на терабайт

Автор: Kendra Little, Testing SQL Server 2025 Resource Governor tempdb Limits with a Query that Spills a Terabyte

SQL Server 2025 представляет новую возможность Resource Governor для управления использованием tempdb, а также делает Resource Governor доступным в Standard Edition.

Мне стало интересно: может ли новая функция tempdb в Resource Governor помочь сдержать запросы, которые не используют временные таблицы, но вызывают массовое переполнение данных в tempdb? В документации говорится «да», но я всегда предпочитаю получить практический опыт, когда это возможно.

У меня есть ужасный запрос, который «переливается через край», как автомат с мягким мороженым, объявивший войну. Давайте протестируем новые функции управления tempdb в SQL Server 2025.