問題タブ [change-data-capture]

Oracle には、一見競合する 2 つのテクノロジがあります。CDC と DCN。

それぞれの強みは？

一方を使用し、もう一方を使用しないのはいつですか?

Oracle Streams、Oracle Change Data Capture、および Database Change Notification など、類似した Oracle テクノロジがいくつかあります。

これらの違いは何ですか？

それらは Oracle Advanced Queueing に関連していますか?

私の新しいクライアントは、2002 年に作成された小さな VB/Access データベース アプリケーションを持っており、それを最新のものにし、彼が以前から望んでいた新機能をサポートするために書き直したいと考えています。そのため、ローカル マシンで C#.NET 2008 と SQL Server Express 2008 を使用するように変換し、リモート サーバーで WCF と SQL Server 2008 を使用するようにスケーリングする機能を備えています。

彼が興味を持っている新機能の 1 つは、一定期間にわたるデータ変更の完全な履歴を維持し、レポートすることです。以前は、トリガーとストアド プロシージャを使用してこれを行っていましたが、@!#$.

最近、SQL Server 2008 の Change Data Capture 機能をいじりたくてうずうずしていました。最初の 1 時間使ってみたところ、デフォルトで 5 秒ごとに実行されるジョブが SQL Agent に作成されることに気付きました。また、キャプチャしたテーブルのスキーマを変更する必要がある場合は、少し面倒なようです。それ以外は、私の元の方法よりも実装がはるかに簡単に思えます。だから、これらは私の質問です：

1. 最終的にリモート サーバーに移行する可能性がある、または移行しない可能性がある小さなデスクトップ アプリケーションにとって、これはやり過ぎでしょうか?
2. パフォーマンスに関して何を期待すればよいですか? 彼のデータベースのサイズが大きくなるにつれて、コンピューターの動作が遅いという彼からの電話が増えるのでしょうか?
3. 現在本番環境で使用している他の人から知っておくべき、CDC に関するその他の落とし穴はありますか?
4. 小さなデスクトップ アプリケーションにより適した、時間の経過に伴う変化を追跡するお気に入りの方法へのリンクを持っている人はいますか?

ありがとう、

マルク

何百万ものレコードを含む 2 つのテーブル (SQL 2008 を使用して保存) のビューがあります。

今、物理テーブルを使用してこの情報を保存し、次のようなさらに小さなクエリで大きなテーブルをスキャンしないようにします

したがって、パフォーマンスの点でどちらが最良のアプローチですか。

1. 両方のテーブルで変更データ キャプチャを使用し、変更を特定して新しいテーブル 'TbSalesAge' に適用します。
2. 物理テーブルの代わりにマテリアライズド ビューを使用する
3. 他の方法（説明してください...）

PS: リアルタイム レプリカは必要ありません

Microsoftのドキュメントの深淵を深く掘り下げる前に、Change DataCaptureとChangeTrackingの経験がある人が、これらの一方または両方を従来の...に置き換えることができるかどうかを知っているかどうかを知りたいと思います。

「トリガーによって挿入された「実際のテーブル」（元のテーブルのすべてのフィールドに加えて、日付/時刻、ユーザーID、およびDMLアクションフィールド）の証跡テーブルのコピーを監査します。」

...データベーステーブルの監査証跡を設定します。ここで、トリガーは監査証跡テーブルにデータを入力します（これはすべて手動の作業です）。

MSDNの概要ドキュメントでは、変更データのキャプチャと変更の追跡について大まかに説明していますが、これらのツールを使用して従来の監査証跡テーブルを置き換えることができることは、私には十分に明確ではなく、明確に述べられていません。とても頻繁に作りました。

変更データキャプチャと変更追跡を使用した経験のある人は、私に多くの時間を節約できますか、または私が適切なツールを探すことに時間を費やしていることを確認できますか？監査証跡の重要な部分は、テーブルのフィールド（INSERT、UPDATE、DELETE）に対するすべての変更を、いつ発生し、誰が実行したかをキャプチャすることです。これらの変更は通常、監査証跡レポートを介して時系列でエンドユーザーに提供されます。別の質問はどれですか...変更データキャプチャまたは変更追跡が解決策です。このデータは通常のテーブルのデータと同じようにクエリできると思いますか？

編集：時間に関係なく、恒久的な監査証跡が必要です。Change Data Captureはトランザクションログに関係していることがわかります。そのため、これは私には有限に聞こえます。

Microsoft サポートでチケットを開く前に、コミュニティを試してみようと思いました!

SQL 2008 R2 (開発者版、現在) で変更データ キャプチャを使用している開発中のアプリケーションがあります。特に複雑なクエリについては、クエリをストアド プロシージャにラップし、共通のパラメーターを公開して、クライアントでの複雑さを回避したいと考えました (通常の引数)...

いずれにせよ、スタンドアロン クエリとしての次のステートメントは、境界条件に関係なく約 3 ～ 5 秒で実行されますが、ストアド プロシージャとしてのまったく同じステートメントは 1.5 分に跳ね上がります。同じ結果を生成します。さらに、実行中の SP バージョンは、実行中にユーザー ID を数回切り替えるようです... また、SP の実行中に CPU 使用率が急上昇します。

何かご意見は？

クエリ:

関連するストアド プロシージャ:

SP を実行するスクリプト:

上記のテキストに示されているように、クエリとして、約 3 ～ 5 秒かかります (Management Studio で)。Stored Proceure として、1.5 分。.Net フレームワーク プロバイダー (System.Data.SqlClient) 経由のクエリとして、1.5 分。OleDb SQLNCLI10 プロバイダー経由のクエリとして、3 ～ 5 秒。Framework または OleDb を介した SP として、1.5 分。

何かご意見は？

asp.net mvc2アプリケーションにログ機能を実装しています。この機能は、データベースとしてSqlServer2008を使用し、データモデルとしてEntityFrameworkを使用します。

SqlServerのCDC機能を有効にすると、ログの変更がうまくいきますが、古いログデータの一部が消去されていることに気づきました。

CDCが記録を保持するデフォルトの期間を知っている人はいますか。また、それを無期限に設定する方法を知っている人はいますか。

SQL Server 2008 の変更データ キャプチャ機能をテーブルでテストしていたときに、スタックが発生しました。

• CDC が有効になっているテーブルは 1 つだけです。
• CDC がどのように応答するかをテストするためにテーブルにさまざまな DDL 変更を行った後、テーブルを削除しました。
• 以前のテストでは、テーブルを削除すると、CDC は CT テーブルと、削除されたテーブルに関連するメタ データも削除します。
• CT テーブルがまだ存在し、そのレコードが cdc.change_tables テーブルに存在するため、最後の drop ステートメントは CDC によって検出されなかったようです。
• cdc.change_table レコードが存在し、SQL Server メタ データ内の存在しないオブジェクト ID にリンクされているため、テーブルの CDC を無効にしたり、同じ名前で新しく作成されたテーブルの CDC を有効にしたりすることはできません。
• データベースの CDC を無効にしようとしましたが、停止する前にコマンドが 1 時間実行され、応答がありませんでした。
• データベースの CDC を無効にしようとしたときに、Management Studio で SQL Server エージェントのジョブ リストが応答しなくなりました (ロック要求のタイムアウト)。CDC の無効化コマンドをキャンセルした後も、エージェントは応答しませんでした。
• Agent サービスを再起動してみました。正常に停止しましたが、起動中 (最終段階と思われるもの) にハングしました。サービスは現在、「開始中」ステータスのままになっています。

サーバーを再起動して、エージェントを再度実行しようとしています。

データベースはまだ開発中であり、データが含まれていないため、データベースを削除して再作成できますが、問題を修正する他の方法はありますか? これまでに読んだことはすべて、CDC リソースを直接いじってはならないことを示しています。cdc.change_tables レコードと関連する CT テーブルを削除してはいけない本当の理由はありますか?

システムの不安定性を示す CDC に関する同様の問題を経験した人はいますか?

編集: エージェントを再度実行した後、change_tables レコードと CT テーブルを手動で削除しようとしましたが、テーブルを有効にしようとすると、CDC メタデータに関連する一連のエラーが発生しました。ただし、データベース全体の CDC を正常に無効にしてから、再度有効にすることができました。もちろん、これにより、CDC 機能に関連するすべてのリソースが削除されました。