Tempdbサイズ戦略
私は最近DBAとしての役割を開始しました。私の最初の仕事は、GDPR法への準拠を支援するために、サードパーティから提供されたデータベースを所有し、再展開することでした。
結果として、私はプロジェクト自体をはるかに超えて見ることができませんでした。いくつかの注意点はありますが、データベースを公開する準備ができた段階になりました。
いくつかの側面の既存のコードは、大規模な一時テーブル（70m以上の行）を作成し、開発データベースがこのプロジェクトで成長したことを知っています。
私の質問は、一時ストレージのインスタンスで、大規模なデータセットを使用するこのプロジェクトと後続のプロジェクトについてです。一時データベースを使用するか、移行先のデータベース内にステージングテーブルを作成して削除する必要がありますか？
私がこれを尋ねる理由は私のライブですtempdb現在のサイズは1GB未満ですが、devは約30に達し、一時テーブルを続行する必要がある場合はtempdb in自動拡張の待機を防ぐために進みます。
提供された追加の詳細に基づいて、一時テーブルではなくステージングテーブルを使用することをお勧めします。
利点は次のとおりです。
- エラーが発生した場合は、トラブルシューティングの途中であったデータをより簡単に表示できます。存在/削除データを（GDPRに関して）制御することもできます。GDPRに関しては、あいまいなtempdbにあるデータよりも簡単です。
- 永続テーブルを利用し、処理が成功するたびにテーブルを切り捨てることで、コードを簡略化できます。
- Tempdbをスラッシュしたり、tempdbに依存している他のことに影響を及ぼしたりすることはありません。
- Jonathonが述べたように、1週間に1回のプロセスのために膨らまない、より安定したtempdbサイズを提供します。
- スキーマは、tempdbのベールの下で多くのデータ処理を行うのではなく、データの使用方法をより明確に示しています。これは個人的な好みですが、将来のメンテナンス/メンテナーにとってはより明確になると思います。
- Tempdbに適したディスクがなく、通常のデータベース用のドライブを使用することで影響を受ける場合を除いて、このアプローチには大きな欠点はありません。
David Browneが提供する欠点：
- 「短所は、Tempdbがテーブルとログレコードをフラッシュしてリカバリ可能性を保証できないため、ユーザーデータベースへの書き込みがより多くのIOを生成することです。これは、データベースが完全リカバリの場合、さらにはAGを使用している場合に悪化します。」
この方法を使用する場合、一般的な選択は、データを個別のステージングデータベースに完全に分離することでもあります。これは、必ずしもAGモードまたは完全復旧モードである必要がないため、いくつかの欠点を軽減するのに役立ちます。