SQL Server 2008 / R2復旧モデル

特定のサーバー上のほとんどすべてのデータベースは完全復旧モデルを必要とせず（トランザクションログのバックアップは行いません）、デフォルトでは常にデータベースを作成して単純復旧モデルを指定する必要があります。

多くの場合、特定の実際的な理由により、SSMSを使用して多くのデータベースが作成されます。ただし、ミスが発生する可能性があり、オペレーターは単純復旧モデルの指定を忘れることがあります。これにより、数日後、切り捨てられなかった60 GBのログファイルが3つまたは4つあるために、ボックスがディスク領域に苦しむ「驚き」が生じます。

シンプルリカバリモデルを新しいデータベースのデフォルト設定にするには、modelデータベースでリカバリモデルを構成します。しかし、これが推奨されますか？これを行うと、将来的に戻って何らかの形で私に噛まれる可能性がありますか？

ここに3つのオプションのいずれかが表示されます。

1）テンプレートスクリプトを使用して、復旧モデルを明示的に含むデータベースを作成できます。

2）データベースをシンプルに設定modelでき、これを心配する必要はありません。

3）みんなが覚えていることを期待できます。（非推奨）

個人的には2番目に行きます。それがモデルデータベースの目的です。

@ Surfer513に追加

4）ポリシーベースの管理ポリシー。単純な復旧モデルを適用するか、DBが有効でない場合に通知します。

私はモデルを単純に設定することを好んでいますが、これはT-SQLコマンドが使用されてそれを別のものに設定することを妨げません。ポリシーを使用して、復旧モデルがシンプルではないかどうかを評価し、ポリシーによって変更されるようにすることができます。

この MSSQLTip.comの記事はFullのチェックについてですが、Simpleをチェックするだけで簡単にチェックできます。また、データベースでバックアップが行われたことがあるかどうかを確認することもできます。

安全策は、DBをフルモードにすることですが、ログの増加に関する問題が発生します。今いくつかのオプションがあります：

• ログファイルの最大サイズに制限を設けます。この制限に達すると、操作に影響します。利点は、ディスクの領域が不足するシナリオを防ぎ、大きな問題が発生することです。
• ログファイルがウォーターマークを超えたときに起動するアラートを作成し、それを管理します。
• ログ圧縮ジョブをスケジュールします。ログの変更は、DBのパフォーマンスを低下させます。お勧めしません。

DBAとして、回復に役立つすべてのオプションを使用する必要があります。また、ビジネスとのSLAにも依存します。

そうは言っても、いくつかのDBをシンプルモードで管理しています。これは、SLAで概説されている免責事項が原因です。企業はログファイルのドライブに費やさないことにしました（馬を水に連れて行くことはできますが、飲むことはできません）。ビジネスは、バックアップ、復元、およびDRを管理します。DRがあり、失われたお金は、追加のディスク領域で必要だった金額よりも多かった。