Коли використовувати CDC для відстеження історії?

Збір даних про зміни SQL Server - це функція, яка зчитує історичні дані з журналів транзакцій SQL Server та зберігає їх у спеціальній таблиці.

За допомогою використання спеціальних функцій значень таблиці (TVF) він дозволяє користувачеві запитувати ці дані, що дозволяє або отримати всі зміни в певній таблиці, або лише чисті зміни, що були наслідком змін протягом певного часу.

CDC має певні переваги

• Він може бути налаштований лише для відстеження певних таблиць або стовпців.
• Він здатний певною мірою обробляти зміни моделі.
• Це не впливає на продуктивність настільки сильно, як тригери, оскільки працює з журналами транзакцій.
• Він легко вмикається / вимикається і не потребує додаткових стовпців на таблиці, які слід відстежувати.

Він також має деякі недоліки:

• Обсяг даних історії може швидко стати величезним.
• Ви не можете відстежити, хто вніс зміни (принаймні, не для видалень).
• Дані історії потребують певного часу, оскільки вони базуються на журналах транзакцій.
• Це залежить від агента SQL Server. Якщо Агент не працює або виходить з ладу, історія не відстежується.

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

1. Для яких завдань / сценаріїв CDC є правильним інструментом? (наприклад, Дозволити користувачам відновити об'єкт даних до певного моменту? Аудит? Показ усієї історії даних?)
2. Коли вам краще не використовувати CDC, а вдатися до користувацького рішення на основі тригера?
3. Чи нормально використовувати CDC в операційній базі даних та використовувати дані CDC в операційній програмі? (наприклад, показ її кінцевому користувачеві) Або це явно неправильне використання цієї функції?

Я часто чую, що CDC є інструментом аудиту, але хіба це те, для чого призначений аудит SQL Server ? Вони обидва різні інструменти для одного завдання? Або CDC можна використовувати для інших речей?

Мій поточний сценарій полягає в тому, що мене просять створити надійний фреймворк даних, який повинен бути основою для декількох майбутніх додатків. Точні вимоги розмиті, але одна полягає в тому, що вона повинна мати можливість відслідковувати історію даних та відновлювати старі записи разом із усіма пов'язаними даними з інших таблиць. Я зараз оцінюю CDC як варіант, але я не впевнений, чи це шлях, тому що я не можу знайти жодних рекомендованих випадків використання.

Хоча я ціную поради щодо мого конкретного сценарію, у відповідях слід надати загальну пораду щодо того, коли або коли не використовувати Змінити захоплення даних.

По-перше,

Збір даних для збору даних доступний лише у виданнях Enterprise, Developer та Evaluation SQL Server.

Таким чином, це може вирішити для вас, якщо хтось із ваших клієнтів не матиме корпоративних видань, або ви ще не знаєте, чи будете ви використовувати корпоративні видання. (Оскільки специфікація включає в себе "кілька майбутніх додатків", це може бути справжньою проблемою для вас)

На відміну від тригерів це не в режимі реального часу, це є і перевагою, і недоліком. Використання тригерів завжди сповільнює оновлення.

Я працював над однією системою, коли ми використовували тригери (згенеровані CodeSmith), а також відстежуючи всі зміни в записах, ми також пов’язували зміни разом із таблицею "історія", яка включала модуль програми, яка внесла зміни, і елемент інтерфейсу, який користувач використовував для внесення змін.

Однак ви, можливо, найкраще вирішити це на рівні програми, написавши все оновлення до черги повідомлень, яке потім відтворюється для створення бази даних у будь-який момент часу, див. Templaral Patterns в блозі Martin Flowler для хорошого огляду варіантів.

Ось дуже добре написана серія із 9 частин, в якій розглядаються різні способи аудиту змін даних SQL Server. Частини 3, 4 і 5 зосереджуються на CDC. Варто ознайомитися з усіма статтями, оскільки це відповість на ваші запитання, як і в різних сценаріях, де функції будуть доречними та накладними. http://solutioncenter.apexsql.com/tag/methods-for-auditing-sql-server

Для яких завдань / сценаріїв CDC є правильним інструментом? (наприклад, дозволити користувачам відновити об'єкт даних до певного моменту?

Можливо, це залежить.

Аудит?

Так.

Показано повну історію даних?)

Так.

Коли вам краще не використовувати CDC, а вдатися до користувацького рішення на основі тригера?

Коли дані в таблиці змін не відповідають вашим потребам.

Чи нормально використовувати CDC в операційній базі даних та використовувати дані CDC в операційній програмі? (наприклад, показ цього кінцевому користувачеві)

Так.

Або явно це неправильне використання цієї функції?

Ні, це не зловживання цією функцією.

Я зазвичай чую, що CDC є інструментом аудиту, але чи не для цього є аудит SQL Server?

Так.

Вони обидва різні інструменти для одного завдання?

Ні.

Або CDC можна використовувати для інших речей?

CDC можна використовувати для інших речей.

Існує Відстеження змін і Є Зміна даних Захоплення. Обидва мають своє коріння в реплікації.

Відстеження змін забезпечує спосіб подання чистих змін до таблиці. Прикладом використання може бути ручна синхронізація пристрою.

CDC, з іншого боку, відстежує всі невеликі зміни, історію. Можна використовувати цю історію для оновлення сховища даних замість масового копіювання даних, або можна використовувати цю історію як самі дані та генерувати звіти з неї. Таблиця змін не прихована, не має якоїсь дивної схеми чи чогось іншого. Ви можете запитувати його та використовувати дані, скільки завгодно. Просто майте на увазі ... це не реальний час, як сказав Іан. Дані надходять з журналу транзакцій, тому дбайте про них так, як ви б використовували реплікацію, дзеркальне відображення або доставку журналу. За великим рахунком, це буде швидше, ніж тригери. Вам потрібно буде використовувати знімок Snapshot, який має накладні витрати, і вам доведеться подумати про відновлення після аварій.

• http://technet.microsoft.com/en-us/magazine/2008.11.sql.aspx
• http://technet.microsoft.com/en-us/library/bb933875.aspx
• http://technet.microsoft.com/en-us/library/cc645937.aspx
• http://blogs.technet.com/b/dataplatforminsider/archive/2008/01/28/sql-server-2008-case-studies.aspx (знайти на сторінці Змінити захоплення даних)
• http://searchdatamanagement.techtarget.com/news/2240021731/Insurance-firm-picks-Attunity-change-data-capture-tools-over-WebFocus
• Приклад CDC, що використовується для аудиту

Точка корекції. Свого часу зміни даних були доступні лише у перелічених вище версіях. Однак засіб збору даних про зміни стало доступним у стандартному виданні з SP1 2016 року. Таким чином, у багатьох статтях, написаних до 2016 року SP1, звучить так, ніби CDC недоступний для тих, хто використовує Standard Edition. Це вже не так. Документ Microsoft, що описує наявні CDC, знаходиться за посиланням нижче.

https://docs.microsoft.com/en-us/sql/sql-server/editions-and-components-of-sql-server-2016?view=sql-server-2017#DW