データベースの単純または完全復旧モデル？

いつ完全復旧モデルを使用する必要があり、いつデータベースの単純復旧モデルを使用すればよいですか？

デフォルトであるため、常に完全復旧モデルを使用しましたが、今日このエラーが発生しました：

SQL Server用Microsoft OLE DBプロバイダー（0x80040E14）データベース 'DATABASE NAME'のトランザクションログがいっぱいです。ログ内のスペースを再利用できない理由を確認するには、sys.databasesのlog_reuse_wait_desc列を参照してください。

特定のデータベースは、実際にはサーバー上で最小かつ最も非アクティブなデータベースの1つであるため、他のデータベースではなく、このデータベースでログがいっぱいになる方法がわかりません。

ログを圧縮してデータベースに再度アクセスできるようにするには、次のコマンドを使用して、復旧モデルをFULLからSIMPLEに変更し、論理ファイルログを圧縮しました

alter database myDbName SET recovery simple
go
dbcc shrinkfile('LOG FILE LOGICAL NAME', 100)
go

それは助けたが、今私が理解する必要がなぜ、それが助けHOWこの状況が開始され、どのように将来的にはこれを防ぐには？

編集：

毎晩1時に、サーバー上のすべてのデータベースのスクリプト化されたバックアップを行っています。これは、31行のスクリプトで行われています。最も重要な部分は

set @Filename = 'D:\backup\' + convert(varchar, getDate(), 112) + ' - ' + @DBName + '.bak'
set @Description = 'Full backup of database ' + @Filename
BACKUP DATABASE @DBName TO DISK = @Filename WITH INIT , NOUNLOAD , NAME = @Description, NOSKIP , STATS = 10, NOFORMAT

新しい復旧モデルとデータベースの縮小は、このスクリプトと競合しますか？

他の種類のデータベースのバックアップは行っておらず、トランザクションログもバックアップしていませんか？

いつ完全復旧モデルを使用する必要があり、いつデータベースの単純復旧モデルを使用すればよいですか？

データベースのポイントインタイムリカバリが必要な場合は、完全リカバリモデルを使用する必要があります。データベースのポイントインタイムリカバリが不要な場合、およびリカバリポイントとして最後のフルバックアップまたは差分バックアップで十分な場合は、単純なリカバリモデルを使用する必要があります。（注：別の復旧モデル、一括ログがあります。一括ログ復旧モデルの詳細については、このリファレンスを参照してください）

SQL Server用Microsoft OLE DBプロバイダー（0x80040E14）データベース 'DATABASE NAME'のトランザクションログがいっぱいです。ログ内のスペースを再利用できない理由を確認するには、sys.databasesのlog_reuse_wait_desc列を参照してください。

このエラーが発生した理由は（おそらく）トランザクションログをバックアップしていないためです。バックアップされていない場合、トランザクションログ（仮想ログファイル）の「部分」を再利用できないため、トランザクションログファイルを物理的に拡張し続けます（自動拡張が有効でmaxsizeが許可されている場合）。これらのVLFを再利用用にマークし、トランザクションログのバックアップ（およびアクティブなトランザクションがない、レプリケーションの側面など、その他のいくつかの要件）を行うときにトランザクションログの「ラップアラウンド」の性質を許可します。

ログを圧縮してデータベースに再度アクセスできるようにするには、次のコマンドを使用して、復旧モデルをFULLからSIMPLEに変更し、論理ファイルログを圧縮しました

......

それは助けましたが、今、私はそれが助けた理由を理解する必要があります、この状況がどのように始まり、将来これを防ぐ方法は？

これは、データベースを単純な復旧モデルに設定することで、ポイントインタイムの復旧を気にする必要がなくなり、仮想ログファイルを保存してアクティブとしてマークする必要がないことを保証する要件をSQL Serverに伝えるため、現在、チェックポイントプロセスはこれらのVLFを非アクティブとしてマークします。

このMSDNリファレンスからの抜粋/引用：

単純復旧モデルでは、何らかの要因がログの切り捨てを遅らせていない限り、自動チェックポイントがトランザクションログの未使用セクションを切り捨てます。対照的に、完全および一括ログ復旧モデルでは、ログバックアップチェーンが確立されると、自動チェックポイントによってログが切り捨てられることはありません。

次に、物理的なデータベースファイルの縮小を行いました。トランザクションログに空き領域があったため、NTFSファイルを物理的に縮小できました。

少し時間を費やす価値のある読書：

1. 復旧モデル
2. トランザクションログの管理（Gail Shaw）
3. ログの切り捨てを遅らせる要因

編集後に編集：

新しい復旧モデルとデータベースの縮小は、このスクリプトと競合しますか？

このBACKUP DATABASEコマンドは、どちらの復旧モデルでも機能します。日常的なデータベースの縮小については...それをしないでください!!!! 真剣に、それに応じてデータベースのサイズを設定します。完全復旧モデルを利用する場合は、トランザクションログのサイズを抑えるだけでなく、復旧ポイントオブジェクトにも対応するために、定期的かつ頻繁なトランザクションログファイルを実行します。

他の種類のデータベースのバックアップは行っておらず、トランザクションログもバックアップしていませんか？

データベースが完全復旧モデルを利用している場合、はい、トランザクションログバックアップを行う必要があります。データベースが単純復旧の場合、トランザクションログのバックアップを物理的に実行できません。

使用する復旧モデル（単純なものと完全なもの）については、その決定を下すことはできません。あなた、あなたのビジネスチーム、そしてあなたのSLAだけができます。