SQL Server 2008 R2への挿入が最初にRAMにキャッシュされることをどのように保証できますか？

「バースト性」のデータストリームを想像してください。つまり、10,000個のイベントが非常に速く到着し、その後1分間何も続かない場合があります。

あなたの専門家のアドバイス：SQLのC＃挿入コードを書くと、SQLがすべてのデータをRAMにキャッシュするという保証があります。これを達成するために、SQLサーバー自体のセットアップのパターン、または書き込み先の個々のSQLテーブルをセットアップするパターンを知っていますか？

もちろん、RAMに独自のキューを作成するという独自のバージョンを実行できますが、いわば旧石器時代の石Aを再発明したくありません。

書いてみて、何が起こるか見てみましたか？既知のボトルネックはありますか？

アプリがブロックされるのを防ぐ必要がある場合、書き込みをキューに入れてデータベース呼び出しを延期する方法があります。ただし、1秒または2秒でキューがクリアされると思われますが、これで問題ない場合はキューが必要ですか？

または、ステージングテーブルにスプールして、後でフラッシュできますか？この手法を使用して、1分あたり何百万もの新しい行の持続的な書き込みを処理します（実際にはシンプルリカバリのステージングDBを使用します）。しかし、行の書き込みの経験があるまで実装しませんでした。

注：SQL Serverのすべての書き込みがされます書き込みログ先行（WAL）プロトコルの一部としてディスクを行う行きます。これは、その書き込みのt-logエントリに適用されます。

行を含むデータページは、ある時点でディスクに移動します（時間、使用、メモリ負荷などに基づきます）が、通常、データはとにかくメモリに格納されます。これは「チェックポイント」と呼ばれ、メモリからデータを排除せず、変更をフラッシュするだけです（2011年11月24日編集）

編集：

上記の最後の段落に基づいた全体的な考慮事項については、このデータベースのLDFを専用のディスクセットにシフトして、パフォーマンスを向上させます。ステージングデータベース（MDF / LDFごとに1つ）に同じ。データベースサーバーに（通常はSANを介して）数十または3つの異なるボリュームを使用することは非常に一般的です

何かが足りない場合を除き、これはACIDの耐久性要件（http://en.wikipedia.org/wiki/ACID）に違反します。つまり、アプリケーションがデータをRAMに「書き込み」、サーバーがクラッシュすると、データは失われます。

したがって、求めるのは、データベースへの最終的なストレージのキューとして機能する非データベースシステムか、実行中の処理に対して十分に高速なデータベースシステムのいずれかです。最初に後者を試してみて、それで十分かどうかを確認することをお勧めします。トラブルを借りないでください。

このために一度データセットを使用しました。到着したデータセットに行を挿入していましたが、2秒ごとにデータベースに行をフラッシュする別のスレッドがありました。また、xmlドキュメントを使用してcachinを実行し、1回の呼び出しでxmlをデータベースに渡すこともできます。これはさらに優れている場合があります。

よろしく

ピョートル