Показаны сообщения с ярлыком Change Tracking. Показать все сообщения
Показаны сообщения с ярлыком Change Tracking. Показать все сообщения

22.9.26

Обменяйте устойчивость на производительность

Автор: Aaron Bertrand, Delayed Durability in SQL Server 2014

Отложенная устойчивость (Delayed Durability) — это появившаяся в последний момент в SQL Server 2014, но интересная возможность; её краткая суть в лифтовой презентации звучит буквально так:

«Обменяйте устойчивость на производительность».

Сначала немного предыстории. По умолчанию SQL Server использует журнал упреждающей записи (write-ahead log, WAL), что означает, что изменения записываются в журнал до того, как им разрешено быть зафиксированными. В системах, где записи в журнал транзакций становятся узким местом и где есть умеренная терпимость к потере данных, у вас теперь есть возможность временно приостановить требование ждать сброса журнала и подтверждения. Это буквально убирает букву D из ACID, по крайней мере для небольшой части данных (подробнее об этом позже).

Вы в некотором роде уже идёте на эту жертву сейчас. В полной модели восстановления всегда есть некоторый риск потери данных, просто он измеряется во времени, а не в размере. Например, если вы резервируете журнал транзакций каждые пять минут, вы можете потерять почти до 5 минут данных, если произойдёт что-то катастрофическое. Я говорю здесь не о простом переключении при сбое, а о том, что сервер буквально загорится или кто-то споткнётся о шнур питания — база данных вполне может оказаться невосстановимой, и вам придётся вернуться к моменту последней резервной копии журнала. И это при условии, что вы вообще тестируете свои резервные копии, восстанавливая их куда-нибудь — в случае критического сбоя у вас может не оказаться той точки восстановления, о которой вы думаете. Мы, конечно, склонны не задумываться об этом сценарии, потому что никогда не ожидаем, что плохие вещи™ произойдут.

25.8.26

Убивают ли задержки ввода-вывода вашу производительность?

Автор: Paul Randal, Are I/O latencies killing your performance?

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

Я запускал опрос, попросив выполнить код для расчёта средних задержек ввода-вывода и отправить мне результаты и получил результаты с 1094 случайных серверов по всему миру, на которых размещено 25445 баз данных, и мне потребовалось некоторое время, чтобы загрузить все результаты в SQL Server для агрегации данных. Вот они.

28.6.26

Настройка производительности CDC

Автор: Штеффен Краузе (Steffen Krause)

Соавторы: Санджай Мишра (Sanjay Mishra), Гопал Ашок (Gopal Ashok), Грег Ивкофф (Greg Yvkoff), Жуй Ван (Rui Wang)

Технические рецензенты: Бурзин Патель (Burzin Patel), Денни Ли (Denny Lee), Гленн Берри (Glenn Berry, MVP SQL Server), Джозеф Сак (Joseph Sack), Линдси Аллен (Lindsey Allen), Майкл Редман (Michael Redman), Майк Рутрафф (Mike Ruthruff), Пол С. Рэндал (Paul S. Randal, SQLskills.com), Tuning the Performance of Change Data Capture in SQL Server 2008

Краткое содержание: Отслеживание изменений данных (Change Data Capture, CDC) — это новая функция в SQL Server, которая предоставляет простой способ отслеживания изменений данных в наборе таблиц базы данных для последующей передачи этих изменений во вторую систему, например, в хранилище данных. В этом документе содержатся рекомендации по настройке параметров отслеживания изменений данных для максимальной производительности захвата данных при минимальном влиянии на производительность производственной нагрузки. Область действия этого документа ограничена захватом изменяемых данных и процессом очистки. Запрос изменённых данных не входит в область действия данного технического документа.

2.3.26

Безопасная очистка потерянных записей в Change Tracking (часть 2)

Автор: Mohamed_Baioumy_MSFT, Part 2: Safely Cleaning Orphaned Records in Change Tracking Side Tables

Область применения: База данных SQL Azure (с включенным отслеживанием изменений)

Краткое повторение (Часть 1)

В Части 1 мы рассмотрели, как обнаружить ""Orphaned записи во вспомогательных таблицах отслеживания изменений — строки, чей sys_change_xdes_id больше не имеет соответствующей записи транзакции в таблице фиксации (sys.syscommittab). Эта ситуация часто приводит к неожиданному росту размера отслеживания изменений и симптомам "stuck cleanup", потому что данные сопоставления, необходимые для нормальной очистки, отсутствуют.

Ссылка на Часть 1: Выявление потерянных записей в Change Tracking (часть 1)

Почему нужна Часть 2

Распространенный "корневой шаблон", который мы наблюдаем на практике:

  • Очистка вспомогательных таблиц пытается удалить устаревшие метаданные
  • Некоторые удаления из вспомогательных таблиц завершаются сбоем (блокировки, тайм-ауты, ошибки)
  • Очистка таблицы фиксации всё равно выполняется (или пользовательский рабочий процесс удаляет данные из таблицы фиксации без проверки удаления из вспомогательных таблиц)
  • Оставшиеся строки вспомогательных таблиц теперь ссылаются на значения xdes_id, которые больше не существуют в sys.syscommittab → образуются потерянные записи

В документации Microsoft Learn также подчеркивается, что очистка syscommittab зависит от очистки вспомогательных таблиц — очистка таблицы фиксации должна происходить только после очистки вспомогательных таблиц.

Этот скрипт из Части 2 сосредоточен на удалении потерянных, осиротевших строк из вспомогательных таблиц (и не затрагивает sys.syscommittab), чтобы логика очистки могла снова стабилизироваться.

1.3.26

Выявление потерянных записей в Change Tracking (часть 1)

Автор: Mohamed_Baioumy_MSFT, Identifying Orphaned Records in Change Tracking Side Tables (Read‑Only Health Check)

Когда в SQL Server включено отслеживание изменений (CT, Change Tracking), компонент ядра СУБД сохраняет облегчённые метаданные об изменениях, чтобы приложения могли запрашивать: "что изменилось, начиная с версии X?". Внутреннее устройство CT подразумевает наличие:

  • Вспомогательной таблицы для каждой отслеживаемой пользовательской таблицы. В ней хранятся метаданные изменений на уровне строк (включая идентификатор транзакции).
  • Таблицы фиксации (commit table), в которой хранятся зафиксированные транзакции, затронувшие любую таблицу с включенным отслеживанием изменений. Динамическое административное представление (DMV) sys.dm_tran_commit_table отображает объединение частей этой таблицы фиксации, находящихся в памяти и на диске.

При нормальной работе очистка CT удаляет устаревшие строки из вспомогательных таблиц, а затем — соответствующие более старые строки из таблицы фиксации, основываясь на настроенном периоде хранения. Внутренняя логика очистки использует "безопасную точку очистки", получаемую из настроенного периода хранения, и сопоставляет это астрономическое время с версией CT с помощью системной хранимой процедуры sys.sp_changetracking_time_to_csn.