CDCを使用して履歴を追跡する場合

26

SQL Server変更データキャプチャは、SQL Serverトランザクションログから履歴データを読み取り、特別なテーブルに保存する機能です。

特別なテーブル値関数（TVF）を使用することにより、ユーザーはこのデータをクエリすることができ、特定のテーブルのすべての変更を取得するか、特定の時間内の変更に起因するネット変更のみを取得することができます。

CDCには特定の利点があります

  • 特定のテーブルまたは列のみを追跡するように構成できます。
  • モデルの変更をある程度まで処理できます。
  • トランザクションログを処理するため、トリガーほどパフォーマンスに大きな影響を与えません。
  • 簡単に有効/無効にでき、追跡する必要のあるテーブルの追加の列は必要ありません。

また、いくつかの欠点もあります。

私はCDCについて多くのことを読みましたが、CDCの使い方を知っていますが、それが自分にとって適切なツールかどうかはまだわかりません。

  1. CDCが適切なツールとなるのはどのタスク/シナリオですか？（たとえば、ユーザーがデータオブジェクトを特定の時点に復元できるようにしますか？監査しますか？データの完全な履歴を表示しますか？）
  2. いつCDCを使用せず、カスタムトリガーベースのソリューションに頼るべきですか？
  3. 運用データベースでCDCを使用し、運用アプリケーション内でCDCデータを利用しても大丈夫ですか？（例：エンドユーザーに表示する）またはこれは明らかにこの機能の誤用ですか？

CDCは監査ツールであるとよく聞きますが、SQL Server Auditの目的はそれではありませんか？両方とも同じタスクの異なるツールですか？または、CDCを他のものに使用できますか？

私の現在のシナリオでは、将来の複数のアプリケーションの基礎となる信頼できるデータフレームワークを構築するように求められます。正確な要件はあいまいですが、1つは、データ履歴を追跡し、他のテーブルのすべての関連データとともに古いエントリを復元できる必要があることです。私は現在、CDCをオプションとして評価していますが、推奨されるユースケースが実際には見つからないため、これが進むべきかどうかは不明です。

私は特定のシナリオに対するアドバイスに感謝しますが、回答では、Change Data Captureを使用するタイミングまたは使用しないタイミングに関する一般的なアドバイスを提供する必要があります。

sql-server  change-data-capture  data-versioning 
— 壮大な
ソース
1
理想的には、「フレームワーク」はこの種の決定を行わないでしょう。個々のプロジェクトに委ねられます。しかし、あなたはこれを行うように求められているので、少なくともこれらの要件を提供している人にその点を指摘します：これを達成するためのさまざまな方法があり、最良の選択は正確な使用法とニーズに大きく依存します。決定に役立つ可能性のある説明（パフォーマンスまたは柔軟性がより重要かどうかなど）を提供できるかどうかを尋ねます。考慮すべきもう1つのオプションは、「フレームワーク」の一部として両方のオプションを開発し、実際のプロジェクトで有効にするオプションを選択できるようにすることです。
— jpmc26 14年
@ jpmc26、この種の質問の決定に時間を費やしている各プロジェクトを停止するために、フレームワークが必要になる場合があります。
— イアンリングローズ14
@IanRingrose私のポイントは、プロジェクトの特定のニーズを考慮せずにその決定を行おうとすると、長期的には解決するよりも多くの問題が発生することです（したがって、実際にその時間を費やすよりもコストがかかります）。これは、一般的なケースでは効果的に決定できない決定です。プロジェクトの詳細を考慮する必要があります。全面的な決定を使用すると、選択したソリューションを使用し、適切なソリューションではないことが判明した場合に違反するという前提のみに基づいて前提を立てるのに時間がかかります。その後、システムを再設計する必要があります。
— jpmc26 14
1
@ jpmc26トリガーベースとCDCベースの両方の履歴追跡、切り替え可能、共通のインターフェースの背後で開発する方法を見つけた場合、私は実際にあなたが提案したソリューションに行くかもしれません。その後、アプリケーションは要件に応じてどちらかを選択できますが、自分で実装することを心配する必要はありません。もちろん、CDCがこの種のタスクに対応していない場合（たとえば、監査にのみ適しているため）、上記の質問に対する適切な回答を得たいと考えています。 。
— マグナティック14
「エージェントが実行されていないかクラッシュしている場合、履歴は追跡されていません」-しかし、再起動された場合、変更は失われません。
— アンディジョイナー

回答:

12

まず、

変更データキャプチャは、SQL ServerのEnterprise、Developer、およびEvaluationエディションでのみ使用できます。

そのため、顧客のいずれかがエンタープライズエディションを使用しない場合、またはエンタープライズエディションを使用するかどうかをまだ知らない場合に、それが決定する場合があります。（仕様には「複数の将来のアプリケーション」が含まれているため、これはあなたにとって本当の問題かもしれません）

トリガーとは異なり、リアルタイムではありませんが、これは長所でもあり短所でもあります。トリガーを使用すると、常に更新が遅くなります。

トリガー（CodeSmithによって生成された）を使用して1つのシステムで作業し、レコードへのすべての変更を追跡し、変更を行ったアプリケーションのモジュールを含む「履歴」テーブルに変更をリンクしました。ユーザーが変更を加えるために使用したUIアイテム。

ただし、すべての更新をメッセージキューに書き込むことでアプリケーションレベルでこれを解決するのが最善かもしれません。その後、任意の時点でリプレイされてデータベースが作成されます。オプションの適切な概要については、Martin Flowlerブログの時間パターンを参照してください。

— イアン・リングローズ
ソース
リンクは非常に興味深い読み物です。ありがとうございます。それでも、アプリケーションレベルでこれを解決することは私の場合の選択肢ではありません。私が構築しているフレームワークは、それに基づいたアプリケーションに対して、履歴追跡を含むほとんどの作業を行うことになっています。その後、アプリケーションはデータを保存/取得するための共通のインターフェースと連携しているため、データの保存方法を気にする必要がありません。このタスクは簡単ではありません。
— マグナティック14
また、私は現在、Enterprise Editionを検討していないか、このケースの決定要因ではありません。私が話している将来のアプリケーションは、ほとんどすべて私たちによって構築され、ホストされるでしょう。
— マグナティック14
@atticae、フレームワークはデータベースに限定される必要はありません。データベースの外部で実行されるコードを含めることができます。
— イアンリングローズ14
もちろん、データベースに限定されるものではありません。（この場合、フレームワークとは呼びません。）「アプリケーションレベル」とは、現在の意味を理解しており、現在、リンクについて説明しているTemporal Propertyパターンのバリエーションを使用しています。私が構築するフレームワークは、このインターフェイスを使用するアプリケーションにこのインターフェイスを提供します。それでも、それはインターフェース側の一部であり、これのどれも上で概説した私の質問に本当に答えません。
— マグナティック14
回答ありがとうございます。これはおそらくほとんどの人にとって決定的な要因であるため、これは良い答えであり、おそらく将来の訪問者がCDCを使用しないことを決定するのに役立つと思う しかし、私の質問のほとんどに実際に答えているわけではないと感じているので、私が持っていたすべての質問に答えようとしている唯一のスタシーラライに賞金を贈る必要があります。（答えをもう少し詳しく
— 知り
12

SQL Serverデータの変更を監査するさまざまな方法をレビューする非常によく書かれた9部シリーズです。パート3、4、5はCDCに焦点を当てています。機能が適切でオーバーヘッドのあるさまざまなシナリオのように、これがあなたの質問に答えるので、すべての記事を読む価値があります。 http://solutioncenter.apexsql.com/tag/methods-for-auditing-sql-server

— ブリン
ソース
1
記事をざっと読んだ後、私はまだそれほど賢くありません。ほとんどの記事と同様に、CDCの使用方法と変更追跡との比較について詳しく説明します。しかし、上記の質問には本当に答えていません。
— マグナティック14
9

CDCが適切なツールとなるのはどのタスク/シナリオですか？（たとえば、ユーザーが特定の時点にデータオブジェクトを復元できるようにしますか？

たぶん、それは依存します。

監査？

はい。

データの完全な履歴を表示していますか？）

はい。

いつCDCを使用せず、カスタムトリガーベースのソリューションに頼るべきですか？

変更テーブルのデータがニーズを満たしていない場合。

運用データベースでCDCを使用し、運用アプリケーション内でCDCデータを利用しても大丈夫ですか？（例：エンドユーザーに表示）

はい。

または、これは明らかにこの機能の誤用ですか？

いいえ、この機能の誤用ではありません。

CDCは監査ツールであるとよく耳にしますが、それはSQL Server Auditの目的ではありませんか？

はい。

それらは両方とも同じタスクのための異なるツールですか？

いや

または、CDCは他のものに使用できますか？

CDCは他の用途に使用できます。

変更追跡と変更データキャプチャがあります。両方とも複製にルートがあります。

変更の追跡は、テーブルに正味の変更を提供する方法を提供します。使用例は、ハンドヘルドデバイスの同期です。

一方、CDCはすべての小さな変化、履歴を追跡します。データを一括コピーする代わりに、その履歴を使用してデータウェアハウスを更新したり、その履歴をデータ自体として使用してレポートを生成したりできます。変更テーブルは非表示ではなく、奇妙なスキーマなどもありません。クエリを実行して、必要に応じてデータを使用できます。イアンが言ったように、それはリアルタイムではありません... データはトランザクションログから取得されるため、レプリケーション、ミラーリング、またはログ配布を使用する場合と同様に注意してください。概して、トリガーよりも高速になります。オーバーヘッドのあるスナップショット分離を使用する必要があります。また、災害復旧について考える必要があります。

— スタシラライ
ソース
2

修正点。かつて、変更データキャプチャは上記のバージョンでのみ利用可能でした。ただし、変更データキャプチャは、2016 SP1の標準版で利用可能になりました。したがって、2016 SP1以前に書かれた多くの記事は、Standardエディションを使用している私たちにとってCDCが手の届かないところにあるように聞こえます。これはもはや事実ではありません。利用可能なCDCの概要を示すMicrosoftのドキュメントは、以下のリンクにあります。

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

— ロバート・シーヴァース
ソース
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.