server tracking data что это
Отслеживание изменений в SQL Server 2008
Я думаю, каждый разработчик СУБД рано или поздно сталкивается с задачей отслеживания обращений к БД и событий сервера в целом. И прежде чем выбрать инструмент (или написать его самому), конечно, стоит обратить внимание на решения, которые предлагают сами разработчики СУБД. Хочу поделиться нашим опытом в Brights решения этой задачи для SQL Server 2008.
На данный момент есть 4 таких решения для SQL Server 2008 (для SQL Server 2011 существенных изменений в этой области не предвидится). Некоторые из этих средств пришли из более ранних версий, некоторые появились в 2008. Эти средства во многом пересекаются, поэтому, порой, не просто выбрать один (или более) инструмент для решения конкретной задачи. В этом я постараюсь помочь, проведя краткий обзор каждого инструмента с примером.
1. CT (Change Tracking).
ALTER DATABASE ChangeTracking SET change_tracking = ON
( change_retention = 10 minutes, auto_cleanup = ON )
ALTER TABLE Orders enable change_tracking WITH ( track_columns_updated = ON )
Более детально (описание параметров, примеры использования и детальная информация) в отличной статье.
2. CDC (Change Data Capture)
Средство для отслеживания измененных данных. Основными отличиями от CT являются асинхронная реализация (как писалось выше) и хранение всех версий измененных (CRUD) данных. Для хранения измененных данных CDC использует системные таблицы в схеме cdc. Для каждой таблицы, для которой активирован CDC, создается таблица с названием по типу cdc.dbo_Orders_CT (для таблицы dbo.Orders).
EXEC sys. sp_cdc_enable_table
Примеры запросов к сохраненным данным и развернутое описание в статье.
3. SQL Server Audit
CREATE server audit ServerAudit
TO FILE ( filepath = `D:\Audit\`, maxsize = 1GB )
WITH ( on_failture = CONTINUE )
ALTER server audit ServerAudit WITH ( STATE = ON )
CREATE server audit specification ServerAudit_Permissions
FOR server audit ServerAudit
ALTER server audit specification ServerAudit_Permissions
CREATE DATABASE audit specification SA_MyDb_Orders
FOR server audit ServerAudit
Для настойки аудита, есть удобный визуальный интерфейс в SQL Server Management Studio.
Также, следует отметить, наличие средств стандартизированного аудита спецификации c2 (государственный стандарт США, если верить MSDN, ссылку на стандарт я не нашел), для активации которого следует выполнить:
4. SQL Server Profiler
Всем давно знакомая утилита, поэтому пока на ней останавливаться не буду.
Спасибо.
В планах написать подробно о каждом инструменте, если конечно тема вызовет интерес.
Server-Side Tagging — новый способ отслеживания данных в Google Tag Manager
Соберите все данные для сквозной аналитики вместе с OWOX BI
Соберите все данные для сквозной аналитики вместе с OWOX BI
В этой статье мы хотим рассказать вам про новую фичу от Google Tag Manager — Server-Side Tagging, то есть отслеживание данных на стороне сервера. Этот функционал, по словам его разработчиков, позволяет скрыть бизнес-логику в серверном коде, ускорить загрузку сайта и улучшить защиту пользовательских данных, ограничив доступ к ним сторонних скриптов.
Кстати, если у вас еще не настроена сквозная аналитика, самое время это сделать. С ней вы точно получите больше пользы от ваших данных, независимо от того, каким способом они собираются 🙂
Объедините данные с сайта, из рекламных источников и CRM-систем в Google BigQuery с помощью OWOX BI
Содержание
В чем разница между Client-Side и Server-Side Tracking
Большинство существующих менеджеров тегов, аналитических систем и рекламных сервисов собирают данные с помощью способа Client-Side Tracking, то есть на стороне клиента. Как это работает? Есть сайт или приложение, в которых установлен определенный браузер, и есть сторонний сервис, например Google Analytics. Браузер отправляет запрос напрямую в этот сервис и, если надо, получает ответ. То есть взаимодействие происходит между двумя сторонами: браузером и сторонним сервисом.
При отслеживании данных на стороне сервера (Server-Side Tracking) добавляется промежуточная точка, в случае Google Tag Manager это облачный сервер. Со стороны клиента запрос идет сначала на облачный сервер, затем сервер обрабатывает этот запрос и отправляет в стороннюю систему (Google Analytics). То есть вместо браузера клиента запрос выполняет облачный сервер.
А теперь давайте рассмотрим подробнее основные преимущества и недостатки обоих способов сбора данных.
Отслеживание на стороне клиента
Как мы уже говорили, это наиболее распространенный способ собирать данные с сайта. Отслеживание на стороне пользовательского браузера позволяет получать данные из cookie-файлов, URL параметры, источники перехода, данные об устройстве пользователя, IP-адрес и т. д.
Отслеживание на стороне сервера
Server-Side Tracking — это альтернатива привычному методу отслеживания на стороне клиента, которая позволяет решить проблему с блокировщиками рекламы, передачей конфиденциальных данных и скоростью загрузки страниц.
А теперь давайте рассмотрим те преимущества Server-Side Tracking, на которых команда Google Tag Manager сделала особый акцент.
GTM Server-Side Tracking: заявленные преимущества
Отслеживание на стороне сервера позволяет скрыть бизнес-логику взаимодействия вашего сайта со сторонними приложениями, переместив ее в бэкенд. То есть пользователю будет недоступна информация и логика, которую вы используете для передачи данных. Например, вы сможете отправлять честную маржу в GA и на клиентской стороне в браузере пользователя даже не будет такой переменной.
Этот метод более безопасный в плане движения данных. Информацию, которую вы хотите отправить для аналитики, например, сегмент из CRM, пол или что-то другое, связанное с пользователем, теперь не нужно отдавать на браузер. Соответственно, другим JS скриптам в браузере это будет недоступно.
Как это происходило раньше: допустим, вы хотите получить в GA хэш номера телефона, или пол, или адрес пользователя. Чтобы отправить эту информацию, необходимо сделать ее доступной в DataLayer. А информация из DataLayer доступна всем JavaScript, которые загрузились в браузере. Это общая область видимости, там нет приватных переменных в отличие от Python, например. Если же передавать эту информацию через бэкенд, то она недоступна в окружении JavaScript браузера пользователя.
Кроме безопасности данных, среди преимуществ Server-Side Tracking команда Google также выделяет возможность повысить скорость загрузки сайта, о чем мы писали выше.
Как попробовать Server-Side Tagging в Google Tag Manager
К сожалению, мы пока не можем поделиться с вами инструкцией, как настроить отслеживание на стороне сервера, так как это бета-версия с ограниченным доступом. Чтобы получить к ней доступ, нужно заполнить и отправить Google форму Whitelist.
После того, как вы получите разрешение и инструкцию от Google, для настройки Server-Side Tracking вам понадобятся:
Нам в OWOX BI уже удалось потестировать новый функционал. В двух словах, как он работает и в чем отличие от стандартного отслеживания с помощью Google Tag Manager.
Как работает Client-Side Tracking: у нас есть сайт или приложение. Мы устанавливаем на сайт GTM контейнер и настраиваем в нем теги. Затем контейнер отправляет данные в GA.
Как работает Server-Side: у нас есть сайт либо приложение. Мы опять же настраиваем веб-контейнер GTM со всеми тегами. Далее мы настраиваем окружение на специально выделенном домене. Настраиваем контейнер для этого окружения. И запрос уже уходит не напрямую с браузера через веб-контейнер, а через промежуточное звено в виде облачного сервера:
После стандартной настройки ресурса Google Analytics в него начинают собираться данные:
За использование облачного сервера взимается дополнительная плата, которая зависит от количества пользователей и запросов на вашем сайте.
Выводы
Стоит ли использовать отслеживание на стороне сервера? Ответ на этот вопрос зависит от того, какие данные вы хотите собирать и для каких целей; что для вас важнее — возможность сэкономить время и деньги или возможность передавать в систему аналитики конфиденциальные данные.
Поскольку функционал пока работает в бета-версии, переходить на него полностью и отключать обычное отслеживание не стоит (да это и не получится). Однако вы уже сейчас можете запросить доступ у команды Google, чтобы потестить Server-Side Tracking и определиться, будет ли он полезен для вашего бизнеса.
ПРЕДУПРЕЖДАЮ СРАЗУ — ЭТО НЕ ПАНАЦЕЯ ОТ ТОТАЛЬНОЙ СЛЕЖКИ РАЗРАБОТЧИКОВ WINDOWS. ИБО ИЗБАВИТЬСЯ ОТ НЕЁ НЕВОЗМОЖНО. ПРЕДЛАГАЕМЫЙ ВАРИАНТ — ЛИШЬ ОДИН ИЗ ИНСТРУМЕНТОВ ОБЕСПЕЧЕНИЯ АНОНИМНОСТИ. ЧТОБЫ ПОЛУЧИТЬ БОЛЕЕ ПОЛНОЕ ПРЕДСТАВЛЕНИЕ О ВОПРОСЕ, ЧИТАЙТЕ СТАТЬЮ И ПРИЛАГАЕМЫЕ К НЕЙ ССЫЛКИ. ОДНАКО ПОМНИТЕ, ЧТО ВЫ ТЕРЯЕТЕ КОНФИДЕНЦИАЛЬНОСТИ ГОРАЗДО БОЛЬШЕ, БЕЗРАССУДНО ПОСЕЩАЯ РАЗНОШЁРСТНЫЕ СЕТЕВЫЕ РЕСУРСЫ, ПОКУПАЕТЕСЬ НА ОБЕЩАНИЯ, ИСПОЛЬЗУЕТЕ НЕКАЧЕСТВЕННЫЕ VPN СЕРВИСЫ.
Обратимся к статье поддержки официального сайта Windows, которая разъясняют назначение нового пакета и указанной службы:
Обновление активирует диагностическую службу обнаружения в версиях Windows 8.1, Windows Server 2012 R2, Windows 7 SP1, и Windows Server 2008 R2 SP1. Эта служба обнаружения собирает данные о функциональных проблемах в системе Windows.
Всё… Ни целей, ни характера сбора данных, ни обязательств по нераспространению… Теперь что удалось узнать из технического описания к Windows 10, в котором, как уже говорилось, служба слежения вшита в сборку. Предваряя грозные окрики эксПердов про «полную xрень» уточняю: читал и видел собственными глазами. Оказывается, что когда мы:
На официальном форуме Microsoft ни один из офпредов корпорации не ответил ничего конкретного (кроме невнятного «это обновление опционально: хотите ставьте, хотите — нет») по поводу «зачем вообще служба появилась». Однако уже участились случаи, когда на статические IP в подсети 64.ххх.ххх.ххх, обозначенные как Micrisoft bingbot, с компьютера пользователя отправляется подозрительный трафик. Причём отключение службы вызвало резкий спад по объёму передаваемых данных другими службами и сервисами Windows, не связанных напрямую с DiagTrackService. Сейчас уже, конечно, поздно вам на что-то показывать, но, если вдруг случиться вам заново переустановить свою Windows 10, проверьте как и куда в процессе первого обновления отправляется система. Даю наводку: смотрите на адреса в подсетях 191.*.*.* и 137.*.*.* Хотя, серверов у Microsoft немало и для каждого региона он свой.
Всё вышеперечисленное – истинная правда, заключённая между строк. Всё делается под предлогом «улучшения качества обслуживания» пользователей Windows. Не хотелось бы никого пугать, но раньше это называлось узаконенным вирусом с полноценным кейлоггером. Фотографии с камер не передаются, в личных файлах система не копается… Однако, думаю, каждый бы хотел принимать участие в нераспространении информации о нём. Вот вам и бесплатное обновление до Windows 10. Ну что сказать…
Те, кого настиг приступ паранойи, приступайте незамедлительно.
ВНИМАНИЕ! Перед последующими изменениями, особенно перед этапом удаления службы из Windows, создайте точку восстановления системы. На некоторых компьютерах возможны некоторые неполадки в сетевых настройках, что грозит ограничением доступа в интернет. В случае проблем восстановитесь до контрольной точки!
Со Службой политики диагностики — братом близнецом (кто что обнаружил) поступите также. Доверия к американской корпорации у нас не очень много, потому нужно отключить службу слежения так, чтобы её не было вообще. Для этого:
Что такое Server-side tracking
В 2020 году Google представил server-side tracking — новый уровень возможностей в Google Tag Manager (GTM). Это тип отслеживания событий с помощью серверного контейнера. Традиционно применяется Client-side tracking, в конфигурации которого используется контейнер, размещенный на страницах сайта. Рассказываю, что из себя представляют Server-side и Client-side отслеживания и чем отличается новый подход от старого.
Определение Client-side отслеживания
Когда дело доходит до отслеживания веб-сайтов или мобильных приложений с использованием GTM, обычно применяется трекинг на стороне клиента — Client-side.
Принцип работы системы передачи данных
Прежде всего необходимо установить контейнер менеджера тегов, разместив фрагмент кода JavaScript в исходный код сайта. При загрузке страницы сайта загружается контейнер, срабатывают коды отслеживания и данные о взаимодействии со страницей отправляются в сервисы, собирающие данные. Это может быть Google Analytics, Ads или другие.
При таком типе отслеживания браузер пользователя прямо взаимодействует с сервисами аналитики.
Что такое Server-side отслеживание
Server-side трекинг представляет собой новый тип отслеживания с участием сервера, который вы создаете, управляете им и где размещается контейнер GTM. Таким образом в привычной схеме отслеживания появляется дополнительная составляющая — облачный серверный контейнер. На этом сервере менеджер тегов получает данные из браузера пользователя, модифицирует их, а затем перенаправляет в системы аналитики.
Конфигурация диспетчера тегов выполняется в облачной среде. Вместо того, чтобы передавать данные о событиях прямо в сервисы аналитики, они отправляются в серверный контейнер GTM, а уже потом в системы сбора и анализа данных.
Веб-запросы со стороны пользовательского устройства поступают на сервер, он трансформирует их в события, которые обрабатываются тегами, триггерами, переменными. Принцип их работы не отличается от обычного — теги активируются триггерами после выполнения всех заданных условий.
Есть все же одно отличие — дополнительный объект Client. Эти «клиенты» выступают посредниками между устройством посетителя сайта и облачным контейнером. Информация с устройств поступает в Client, который трансформирует их в события, отправляет в серверный контейнер и после модификации отправляет внешним сервисам.
Теперь возникает логический вопрос: «Зачем усложнять процесс сбора данных добавлением еще одного звена — облачного сервера»? Чтобы разобраться в этом, давайте проанализируем сильные стороны Server-side отслеживания.
Преимущества серверного отслеживания
1. Снижение уровня нагрузки на страницу
Загрузка веб-страницы требует загрузки и обработки множества ресурсов. В том числе и фрагментов кода JavaScript, систем аналитики, которые могут ощутимо влиять на скорость работы сайта.
Server-side tagging дает возможность сократить количество скриптов на сайте благодаря их перемещению в облачный контейнер. Поместив все теги в серверный контейнер, загрузка происходит в облаке, после чего данные отправляются в сервисы аналитики.
То есть при таком подходе информация с браузера пользователя единожды отправляются в облачный контейнер GTM, а уже оттуда отправляются в другие системы.
Это значительно сохраняет ресурсы и влияет на скорость загрузки страницы, что способствует улучшению взаимодействия пользователей с сайтом и в целом ранжированию сайта в поисковых системах.
2. Уменьшение влияния блокировщиков рекламы
Очень часто пользователи устанавливают блокировщики рекламы, которые блокируют не только рекламу, но и запросы google-analytics.com для передачи данных в GA. С использованием серверного отслеживания, обработка запросов выполняется в облачном сервере. Поэтому расширения, блокирующие рекламу, не воздействуют на этот процесс.
3. Повышение уровня защиты пользовательских данных
Подключенные к сайту скрипты внешних аналитических ресурсов обрабатывают гораздо больше информации, чем им «положено». Они могут собирать детальные данные об устройствах, с которых заходит на сайт пользователь, введение личных данных, даже отпечатки пальцев или файлы cookie и тому подобное. Это может привести к утечке личной информации пользователей.
При использовании Server-side отслеживания обработка происходит в облачной среде, доступ к которой есть только у вас.
И никакая третья сторона не имеет прямого доступа к устройству пользователя. Это обеспечивает более высокий уровень конфиденциальности и защиты данных.
4. Контроль передачи данных
Так как сторонние сервисы и инструменты не имеют прямого подключения к устройству пользователя и взаимодействуют только с облачным сервером, это обеспечивает высокий уровень контроля над тем, какие данные и куда отправлять.
Пришли данные, они находятся на собственном сервере и вы можете изменять их, дополнять. Например, перед отправкой данных можно убедиться, что персональная информация исключена из запроса.
Также отправлять определенные данные можно только отдельным сервисам. Поэтому вы можете контролировать, какие данные и каким внешним системам отслеживания отправлять.
Недостатки серверного отслеживания
Несмотря на недостатки серверного отслеживания, которые существуют в бета-версии, этот подход открывает немало возможностей. Думаю, в скором времени функционал значительно доработают и расширят.
Базовые настройки серверного отслеживания
Возможность выбора нового типа отслеживания существует на этапе создания нового аккаунта для вашего сайта или при добавлении нового контейнера в уже существующем аккаунте на вкладке «Администрирование»:
Далее выбираем тип контейнера «Server».
После создания необходимо следовать инструкциям по настройке сервера тегов, которые включают рекомендации по созданию нового проекта на Google Cloud платформе, где и будет размещаться контейнер.
При добавлении аккаунта на Google Cloud платформе необходимо будет ввести ваши платежные данные и создать учетную запись для выставления счетов.
После добавления сервера можно приступать к настройке тегов, триггеров, переменных и клиентов. Но это уже другая история.
Система отслеживания измененных данных (CDC)
В этой статье вы узнаете о системе отслеживания измененных данных (CDC), которая записывает действия в базе данных при изменении ее таблиц и строк. Отслеживание измененных данных является общедоступной функцией в SQL Server и Управляемом экземпляре SQL Azure, а в Базе данных SQL Azure оно доступно в предварительной версии.
Обзор
Отслеживание измененных данных (CDC) использует агент SQL Server для записи действий вставки, обновления и удаления, применяемых к таблице. Тем самым обеспечивается доступ к подробностям этих изменений в легко обрабатываемом реляционном формате. Сведения о столбцах и метаданных, которые требуются для применения изменений к целевой среде, отслеживаются в измененных строках и хранятся в таблицах изменений, отражающих структуру столбцов исходных таблиц. Чтобы потребители данных могли систематически получать доступ к информации об изменениях, предоставляются функции с табличным значением.
Чтобы узнать о системе отслеживания измененных данных, вы также можете обратиться к этому эпизоду раскрытых данных.
CDC и База данных SQL Azure (предварительная версия)
Поддержка отслеживания измененных данных в Базе данных SQL Azure сейчас включена в предварительной версии.
В Базе данных SQL Azure агент SQL Server заменяется планировщиком отслеживания измененных данных, который вызывает хранимые процедуры для запуска периодической записи и очистки таблиц отслеживания измененных данных. Планировщик автоматически запускает запись и очистку в Базе данных SQL без внешних зависимостей в плане надежности или производительности. У пользователей по-прежнему есть возможность выполнять запись и очистку вручную по запросу.
Влияние активации отслеживания измененных данных на производительность Базы данных SQL Azure аналогично влиянию на производительность SQL Server или Управляемого экземпляра SQL Azure. Факторы, которые могут влиять на производительность:
Попробуйте увеличить число виртуальных ядер или перейти на более высокий уровень базы данных, чтобы обеспечить тот же уровень производительности, что и до включения CDC в Базе данных SQL Azure. Внимательно отслеживайте использование пространства и тщательно протестируйте рабочую нагрузку перед включением CDC для рабочих баз данных.
Поток данных
На следующем рисунке показан основной поток данных для системы отслеживания измененных данных.
Экземпляр системы отслеживания
Прежде чем можно будет отслеживать изменения в отдельных таблицах базы данных, необходимо явно активировать систему отслеживания измененных данных в этой базе данных. Это делается с помощью хранимой процедуры sys.sp_cdc_enable_db. После того как база данных будет активирована, с помощью хранимой процедуры sys.sp_cdc_enable_tableисходные таблицы можно определить как отслеживаемые. Если для таблицы активирована система отслеживания измененных данных, создается связанный экземпляр системы отслеживания изменений для распространения данных об изменениях в исходной таблице. Экземпляр системы отслеживания состоит из таблицы изменений и одной-двух функций запроса. Метаданные, подробно описывающие конфигурацию экземпляра системы отслеживания, сохраняются в таблицах отслеживания измененных метаданных cdc.change_tables, cdc.index_columns и cdc.captured_columns. Эти сведения можно получить с помощью хранимой процедуры sys.sp_cdc_help_change_data_capture.
Таблица изменений
Первые пять столбцов таблицы изменений для системы отслеживания измененных данных являются столбцами метаданных. Они предоставляют дополнительные сведения, относящиеся к регистрируемому изменению. Остальные столбцы отражают опознанные отслеживаемые столбцы исходной таблицы по имени и типу. В этих столбцах хранятся данные отслеживаемых столбцов из исходной таблицы.
Каждая операция вставки или удаления, которая была выполнена в исходной таблице, отражается как одна строка в таблице изменений. Столбцы данных в строке, отражающей результаты операции вставки, содержат значения столбов после вставки. Столбцы данных в строке, отражающей результаты операции удаления, содержат значения столбов перед удалением. Операции обновления требуется одна строка для определения значений столбца перед обновлением, и еще одна строка — для значений столбца после обновления.
Каждая строка в таблице изменений содержит также дополнительные метаданные, позволяющие интерпретировать операции изменения. Столбец __$start_lsn определяет номер LSN фиксации, который был присвоен изменению. Зафиксированный номер LSN определяет как операции изменения, которые были проведены в рамках одной транзакции, так и порядок транзакций. Столбец __$seqval можно использовать для упорядочивания дополнительных изменений в этой транзакции. Столбец __$operation регистрирует операцию, связанную с изменением: 1 = удаление, 2 = вставка, 3 = обновление (исходный образ), 4 = обновление (образ после операции). Столбец __$update_mask — это переменная в виде битовой маски, в которой каждому отслеживаемому столбцу соответствует один бит. Для записей операций вставки и удаления все биты в маске обновления всегда будут установленными. У строк операций обновления будут установлены только биты, соответствующие измененным столбцам.
Период действия
Период действия системы отслеживания измененных данных для базы данных — это время, в течение которого данные изменений доступны для экземпляров отслеживания. Период действия начинается с создания первого экземпляра отслеживания для таблицы базы данных и продолжается до настоящего времени.
База данных
Данные, хранящиеся в таблицах изменений, будут неуправляемо расти, если периодически и систематически не усекать эти данные. Процесс очистки системы отслеживания измененных данных отвечает за политику принудительной очистки данных по истечении срока их хранения. Прежде всего он перемещает нижнюю конечную точку периода действия в соответствии с ограничениями по времени. Затем записи таблицы изменений, у которых истек срок действия, удаляются. По умолчанию сохраняются данные за три дня.
Так как процесс отслеживания извлекает информацию об изменениях из журнала транзакций, существует естественная задержка между временем, когда изменение фиксируется в исходной таблице, и временем, когда это изменение записывается в связанную таблицу изменений. Хотя эта задержка обычно мала, важно помнить, что информация об изменениях недоступна, пока процесс отслеживания не обработает соответствующие записи журнала.
Экземпляр системы отслеживания
Период действия важен для потребителей данных об изменениях, поскольку интервал извлечения для запроса должен полностью покрываться периодом действия системы отслеживания измененных данных для экземпляра отслеживания. Если нижняя конечная точка интервала извлечения перекрывает нижнюю конечную точку периода действия, возможна потеря информации об изменениях вследствие слишком агрессивной очистки. Если верхняя конечная точка интервала извлечения перекрывает верхнюю конечную точку периода действия, процесс отслеживания не успеет обработать данные за время, представленное интервалом извлечения, поэтому также возможна потеря информации об изменениях.
Функция sys.fn_cdc_get_min_lsn используется для получения текущего минимального номера LSN для экземпляра отслеживания, а функция sys.fn_cdc_get_max_lsn — для извлечения текущего максимального номера LSN. Функции запроса системы отслеживания измененных данных завершатся ошибкой при запросе данных об изменениях, если заданный диапазон номеров LSN выйдет за пределы этих двух значений номеров LSN.
Обработка изменений исходных таблиц
Обработка изменений столбцов в отслеживаемых исходных таблицах — достаточно трудный вопрос для потребителей потока данных. Хотя включение системы отслеживания измененных данных в исходной таблице не препятствует такого рода DDL-изменениям, система отслеживания помогает снизить их влияние на потребителей за счет неизменности результирующих наборов, которые возвращаются через API-интерфейс, даже при изменениях структуры базовой исходной таблицы. Структура с фиксированными столбцами также отражается в базовых таблицах изменений, к которым получают доступ функции запроса.
Для поддержки работы с таблицей изменений, имеющей фиксированную структуру столбцов, процесс отслеживания, отвечающий за заполнение таблицы изменений, не учитывает новые, не определенные для отслеживания столбцы, если в исходной таблице активирована система отслеживания измененных данных. Если отслеживаемый столбец удаляется, в соответствующих записях изменений указываются значения null. Но если у существующего столбца меняется тип данных, это изменение отражается в таблице изменений, чтобы не допустить потерю данных в отслеживаемых столбцах. Процесс отслеживания также отправляет все изменения в структуре столбцов отслеживаемой таблицы в таблицу cdc.ddl_history. Потребители, желающие получить предупреждение о корректировке, которую, возможно, придется внести в нисходящие приложения, используют хранимую процедуру sys.sp_cdc_get_ddl_history.
Как правило, текущий экземпляр отслеживания продолжает сохранять свой формат, когда DDL-изменения применяются к соответствующей исходной таблице. Однако для таблицы, отражающей новую структуру столбцов, можно создать второй экземпляр отслеживания. Это позволит процессу отслеживания воспроизвести изменения одной исходной таблицы в двух таблицах изменений, имеющих разную структуру столбцов. Таким образом, в то время как одна таблица изменений будет поставлять данные в текущие рабочие приложения, вторая будет служить источником данных для среды разработки, принимающей данные нового столбца. Позволив средству отслеживания одновременно заполнять обе таблицы изменений, можно добиться перехода от одного формата к другому без потери информации. Это может случиться в любое время, когда происходит перекрытие временных шкал двух систем отслеживания измененных данных. Если это влияет на переход, устаревший экземпляр отслеживания можно удалить.
С одной исходной таблицей одновременно можно связать не более двух экземпляров отслеживания.
Связь с агентом чтения журнала
Логика процесса отслеживания измененных данных внедрена в расширенную хранимую процедуру sp_replcmds, во внутреннюю серверную функцию, являющуюся частью программы sqlservr.exe, а также используемую репликацией транзакций, которая считывает изменения из журнала транзакций. Если в базе данных в SQL Server или Управляемом экземпляре SQL активирована только система отслеживания измененных данных, создается задание отслеживания агента SQL Server как средство вызова хранимой процедуры sp_replcmds. Если включена также репликация, для поставки информации об изменениях обоим потребителям используется только агент чтения журнала транзакций. Такой метод значительно снижает возможность состязания, если в одной базе данных активирована как система отслеживания измененных данных, так и репликация.
Переключение между этими рабочими моделями происходит автоматически каждый раз, когда меняется состояние репликации в базе данных с активированной системой отслеживания измененных данных.
В SQL Server и Управляемом экземпляре SQL Azure оба экземпляра логики отслеживания измененных данных требуют запуска агента SQL Server.
Основная задача процесса отслеживания заключается в просмотре журнала и записи данных столбцов и связанных с ними сведений о транзакциях в таблицы изменений системы отслеживания измененных данных. Чтобы обеспечить транзакционно согласованную границу между всеми таблицами изменений, процесс отслеживания измененных данных открывает и фиксирует собственные транзакции по каждому циклу считывания. Он обнаруживает вновь активированные таблицы системы отслеживания измененных данных и автоматически включает их в набор таблиц, в которых отслеживается изменение данных. Точно так же обнаруживается отключение системы отслеживания измененных данных, что приводит к удалению исходной таблицы из набора таблиц, в которых проводится наблюдение за изменением данных. Когда завершается обработка раздела журнала, процесс отслеживания вызывает серверную логику усечения журнала, которая использует данные процесса для определения записей журнала, подлежащих усечению.
Если в базе данных было включено отслеживание измененных данных, то даже в том случае, если в качестве модели восстановления базы данных было выбрано простое восстановление, то точка усечения журнала не будет передвинута далее, пока все отслеживаемые изменения не будут собраны процессом отслеживания. Если процесс отслеживания не выполняется и присутствуют изменения, которые следует собрать, то при выполнении инструкции CHECKPOINT журнал усечен не будет.
Кроме того, процесс отслеживания используется также для ведения журнала DDL-изменений в отслеживаемых таблицах. Инструкции DDL, связанные с системой отслеживания измененных данных, создают записи в журнале транзакций базы данных каждый раз, когда удаляется база данных или таблица с активированной системой отслеживания измененных данных или добавляются, изменяются или удаляются столбцы такой таблицы. Эти записи журнала обрабатываются процессом отслеживания, который затем отправляет соответствующие DDL-события в таблицу cdc.ddl_history. Сведения о событиях DDL, влияющих на отслеживаемые таблицы, можно получить с помощью хранимой процедуры sys.sp_cdc_get_ddl_history.
Задания агентов
Как задание отслеживания, так и задание очистки создаются с помощью параметров по умолчанию. Задание отслеживания запускается немедленно. Оно выполняется постоянно, обрабатывая до 1 000 транзакций за цикл просмотра с 5-секундной задержкой между циклами. Задание очистки запускается ежедневно в 02.00. Оно сохраняет записи таблицы изменений в течение 4320 минут или 3 суток, удаляя до 5000 записей в одной инструкции удаления.
Задания агента системы отслеживания измененных данных удаляются, когда система отключается в базе данных. Задание отслеживания можно также удалить, когда к базе данных добавляется первая публикация и включаются как система отслеживания измененных данных, так и репликация транзакций.
На внутреннем уровне задания системы отслеживания измененных данных создаются и удаляются хранимыми процедурами sys.sp_cdc_add_job и sys.sp_cdc_drop_jobсоответственно. Эти хранимые процедуры открыты для доступа, чтобы администратор мог управлять созданием и удалением этих заданий.
Для остановки и запуска заданий агента системы отслеживания измененных данных используются две дополнительные хранимые процедуры: sys.sp_cdc_start_job и sys.sp_cdc_stop_job.
Запуск и остановка задания отслеживания не приводят к потере информации об изменениях. Это лишь препятствует процессу отслеживания активно просматривать журнал в поисках записей изменения и помещать их в таблицы изменений. Чтобы избежать дополнительной рабочей нагрузки в результате просмотра журнала, в период пиковой нагрузки рекомендуется остановить задание отслеживания и вновь запустить его, когда нагрузка уменьшится.
Оба задания агента SQL Server достаточно гибкие и настраиваемые, чтобы удовлетворить основные потребности среды системы отслеживания измененных данных. Однако в обоих случаях базовые хранимые процедуры, обеспечивающие основные функциональные возможности, открыты для доступа, чтобы сделать возможной дополнительную настройку.
Система отслеживания измененных данных не может работать правильно, когда служба ядра СУБД или служба агента SQL Server работает под учетной записью NETWORK SERVICE. В этом случае может возникать ошибка 22832.
В Базе данных SQL Azure задания агента заменяются планировщиком, который автоматически выполняет запись и очистку.
Различия в параметрах сортировки
Важно учитывать различия в параметрах сортировки между базой данных и столбцами таблицы, настроенных для отслеживания измененных данных. При отслеживании измененных данных используется промежуточное хранилище для заполнения побочных таблиц. Если таблица содержит столбцы типа CHAR или VARCHAR с параметрами сортировки, которые отличаются от параметров сортировки в базе данных, а также если в этих столбцах хранятся символы, не входящие в набор ASCII (например, двухбайтовые символы DBCS), технология отслеживания измененных данных не всегда будет сохранять измененные данные в соответствии с данными в базовых таблицах. Это связано с тем, что с переменными промежуточного хранилища не связаны параметры сортировки.
Чтобы обеспечить согласованность отслеживания измененных данных с базовыми таблицами, следует применять один из приведенных ниже подходов:
Используйте тип данных NCHAR и NVARCHAR для столбцов, содержащих данные, не относящиеся к набору ASCII.
Также можно использовать одинаковые параметры сортировки для столбцов и для базы данных.
Например, если в базе данных используются параметры сортировки SQL_Latin1_General_CP1_CI_AS, можно использовать следующую таблицу:
Технология отслеживания измененных данных может не получать двоичные данные для столбца C2, поскольку он использует другие параметры сортировки (Chinese_PRC_CI_AI). Чтобы избежать этой проблемы, используйте тип NVARCHAR:
Необходимые разрешения
Для включения системы отслеживания измененных данных для SQL Server или Управляемого экземпляра SQL Azure необходимы разрешения системного администратора. Для включения системы отслеживания измененных данных для Базы данных SQL Azure требуется роль db_owner.
Ограничения
Отслеживание измененных данных имеет следующие ограничения:
Linux
CDC теперь поддерживается для SQL Server 2017 в Linux, начиная с CU18, и для SQL Server 2019 в Linux.
Индексы columnstore
Отслеживание измененных данных невозможно включить для таблиц с кластеризованным индексом columnstore. Начиная с SQL Server 2016 его можно включить для таблиц с некластеризованным индексом columnstore.
Вычисляемые столбцы. CDC не поддерживает значения для вычисляемых столбцов, даже если такой столбец определен как материализованный. Вычисляемые столбцы, которые включены в экземпляр системы отслеживания, всегда имеют значение NULL. Это делается намеренно и не является ошибкой.