0

クレジット付きのアカウント (約 200.000 レコード) を格納する SQL Server データベースと、トランザクション (約 20.000.000) を格納する別のテーブルがあります。

トランザクションがデータベースに追加されるたびに、クレジットが更新されます。

私がする必要があるのは、(Web サービスを使用して) クライアント プログラムを更新してクレジットをローカルに保存することです。新しいトランザクションがサーバーに追加されるたびに、クライアントにも送信されます (デルタのタイムスタンプを使用します)。私の主な問題は、クライアントの最初のデータ セットを作成することです。すべてのアカウントのリストとトランザクション テーブルの最後のタイムスタンプを提供する必要があります。

これは、このリストとスナップショット内の最後のタイムスタンプを作成する必要があることを意味します。これは、このリストの作成中に更新を行うと、クレジットの合計と最後のトランザクションのタイムスタンプが一致しないことを意味するためです。

設定を調査ALLOW_SNAPSHOT_ISOLATIONし、トランザクションでスナップショット分離を使用しSqlCommandましたが、これを読んだところ、パフォーマンスが大幅に低下します。これは本当ですか、この問題は他の手段で解決できますか?

4

2 に答える 2

1

あわててSIワゴンに飛び乗らないでください。他のすべてのものと同様に、利点と欠点があります。

欠点が懸念されるため、たとえば、アプリケーションはブロック動作を期待している場合や、データの最後のバージョンを待機することをいとわない場合があります。アプリケーションが正しく動作することを確認するために、SI の下でアプリケーションを徹底的にテストする必要があります。さらに、コミットされていないトランザクションによってバージョン ストアが混乱し、tempdb が劇的に増加する可能性があるため、監視は必須です。

また、通常ブロッキングの問題がない場合、SI はやり過ぎかもしれません。

代わりに、必要なものが 1 回限りまたはそれに近いものである場合はdatabase snapshot、データベースの を作成し、そのスナップショットから最初のリストを作成してから、単純にドロップします。

于 2014-04-26T10:45:24.200 に答える
1

しかし、私が読んだことから、これは重大なパフォーマンスの低下を引き起こします。

あなたがそれをどこで読んだのかさえ知りたくありません。公式ドキュメントを紹介します。コストは、行バージョンに使用される追加の tempdb 領域と、古い行バージョンのトラバースに起因します。書き込み速度が遅い場合は、これらの問題は関係ありません。

スナップショット分離は、ブロッキングと一貫性の問題を解決するための恩恵です。それはあなたのシナリオにぴったりです。

スタック オーバーフローに関する多くの SQL Server の質問により、「スナップショット分離はまだ調査しましたか?」とコメントするようになりました。最も活用されていない機能。

Oracle と Postgres では常にオンになっています。

于 2014-04-26T10:23:52.477 に答える