特定のテーブルでのロギングの無効化

SQL Server 2005を使用しています。集計情報を含む2つのテーブルがあります。情報は常に更新されており、1日にほぼ5GBのログデータが生成されます。（データベース全体よりも大きい！）ロールバックは本当に必要ないので、これらのテーブルのロギングを無効にしたいと思います。ただし、データベース内の他のテーブルにログオンし続けたいと思います。

データベース内の特定のテーブルのロギングを無効にすることは可能ですか？そうでない場合、2つのテーブルを同じスキーマに配置して、スキーマへのロギングを無効にできますか？2つのテーブルを別のデータベースに移動し、そこでログを無効にする唯一のオプションはありますか？

更新： これらのテーブルのアクティビティをログに記録する必要がない理由を説明します。

2つのテーブルにはGPSデータが含まれているため、かなり大きくなります。最初のテーブルは、フィールド内の6つのAndroidテーブルから生の場所をキャプチャしています。各タブレットからの新しいデータは5〜10秒ごとに送信されます。その情報は、locationA、locationB、travelTimeとして集約されます。最終的には、実際の運転データに基づいて、すべての場所間の移動時間を最短にすることが目標です。データは小都市のみのものであり、小数点第4位までしか正確ではないため、管理可能です。ただし、新しい生データが入力されると、更新が必要な移動時間が遅くなり、新しい移動データが挿入される必要があります。

生データが集約されると、パージされます。長い移動時間に戻ることはないので、これらのテーブルではロールバックはそれほど重要ではありません。

• データベース内の特定のテーブルのロギングを無効にすることは可能ですか？
• 2つのテーブルを同じスキーマに配置してから、スキーマのロギングを無効にできますか？
• 2つのテーブルを別のデータベースに移動し、そこでログを無効にする唯一のオプションはありますか？

ユーザー操作のログを無効にすることはできません。

最小限のログに記録される操作と呼ばれる操作のクラスがあり、トランザクションのロールバックのみが可能です（ロールフォワードも可能です）。しかし、あなたがしていることが適用の基準を満たしているようには思えませんし、それでもとにかく問題を解決できるとは思いません。

SQL Serverソリューションは、ステージングテーブルを、SIMPLE回復中の集計結果データベースとは別の、回復中の新しいデータベースに配置することですFULL。これによってログの量が減ることはありませんが、データのロードによって生成されたログをバックアップする必要がなくなります。（ログと、データベースの復旧モデルの選択に関連するいくつかの要因については、こちらのブログ投稿を参照してください。）

テーブルを別のデータベースに分離すると、ログファイルをより高速なI / Oサブシステム、おそらくローカルに接続されたソリッドステートドライブの小さなアレイに配置する柔軟性が得られます。

また、SQL Serverだけでは問題を解決するのに最適なソリューションではない可能性があることも考慮してください。特定のテーブルのロギングを完全に無効にする機能を提供する他のRDBMSソリューションがあります。データを別のシステムにステージングして集約し、その結果を既存のSQL Serverデータベースにマージします。これは、完全なログとバックアップによって十分に保護されています。

いいえ、スキーマ、テーブル、データベースのレベルに関係なく、SQL Serverへのログインを防ぐ方法はありません。

事実、SQL Serverデータベースで変更または変更を実行するすべてのトランザクションがログに記録されますが、スナップショット分離が使用されている場合、TempDBに関連するバージョンストア関連のトランザクションは例外です。（トランザクションログにログを記録すると、トランザクションをロールバックできることが保証されます（特定の操作では、復旧モデルをBULK Loggedに変更することにより、ログ（最小限のログ操作と呼ばれます）を減らすことができます--- SQL Server Books Onlineで詳細を確認できます

答えは、いつものように、状況によります。
あなたが言ったとき：

集計情報を含む2つのテーブルがあります。情報は常に更新されています

それはどのような集約ですか？
代わりにVIEWを使用してみてください。更新する必要はなく、ロギングもありません。

それができない場合は、より短いトランザクションを使用して、それらの間のログをバックアップしてください。

別のデータベースを使用すると、セキュリティ管理のオーバーヘッドなどが発生し、独自のトランザクションログが作成されます（SIMPLEリカバリモデルでもログが書き込まれ、SQL Serverはログを自動的に切り捨てるだけですが、ディスク領域を解放しません）。このオプションはお勧めしません。 。