web-dev-qa-db-ja.com

データベースのシンプルまたはフル復旧モデル？

完全復旧モデルを使用する必要がある場合と、データベースに単純復旧モデルを使用する場合

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

Microsoft OLE SQL Server for DB Server（0x80040E14）データベース 'DATABASE NAME'のトランザクションログがいっぱいです。ログのスペースを再利用できない理由を確認するには、sysの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-serversql-server-2008-r2recovery
39
Behrens

完全復旧モデルを使用する必要がある場合と、データベースに単純復旧モデルを使用する場合

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

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

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

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

…….

それは助けになりましたが、なぜ私はそれが助けになったのか、この状況がどのように始まったのか、そしてこれを将来どのように防ぐのかを理解する必要がありますか？

これは、データベースを単純な復旧モデルに設定することで、SQL Serverにポイントインタイムリカバリを気にする必要がないこと、および仮想ログファイルを保持してアクティブとしてマークする必要がないことを確認する必要があることを示したため、役に立ちました。現在、チェックポイントプロセスはこれらのVLFを非アクティブとしてマークします。

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

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

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

時間をかけて読む価値があるもの：

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

編集後の編集：

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

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

他の種類のデータベースのバックアップを実行していないため、トランザクションログも実行していませんか？

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

使用する復旧モデル（シンプルとフル）については、その判断を下すことができません。あなた、あなたのビジネスチーム、そしてあなたのSLAだけができます。

62
Thomas Stringer