SQL Server 2008 R2の圧縮後にログファイルサイズを手動で設定する

その瞬間、やや不本意なDBAになり、何かの助けが本当に必要です。

フルリカバリモードで40GBのデータベースがあり、ログバックアップが構成されておらず、84GBの巨大なログファイルがあります。これまでのところ、この状況を回避するための私の計画は、データベースで完全なログバックアップを実行し、ログファイルを圧縮し、データベースバックアップを使用してログバックアップを毎晩実行し、制御を維持できるように保守計画を推進することです。

私の問題は、ログファイルを何も縮小しないで、月曜日の最初の朝を絶えず成長させておくことです。ファイルがどうあるべきか（データベースの約20％）については大まかな見積もりがあり、できる限り多くの連続したスペースを確保するために、最初から設定します。これは、データベースのプロパティ->ファイルで「初期サイズ」を変更した場合に過ぎませんか？これを実行するには、データベースをオフラインにする必要があると思いますか？

前もって感謝します

最適なサイズだと思うものに縮小するだけです。UIを使用せず、ただ実行してください。たとえば、200 MBが最適なサイズだとします。

USE yourdb;
GO
DBCC SHRINKFILE(yourdb_log, 200);

ログバックアップを1日に1回だけ取得することに関心があり、ポイントインタイムリカバリに関心がない場合は、単純なリカバリモデルに切り替える必要があります。つまり、ログのバックアップは不要です（実際には不可能です）が、ログの内容は自己管理されます。

ログバックアップを意味のあるものにしたい場合は、夜間に完全バックアップを実行し、その直後に単一のログバックアップを実行することを計画しないでください。これにより、完全な復旧モデルが維持され、ログが非常に困難になり、何も購入されなくなります。そのため、ポイントインタイムリカバリが必要な場合は、データ損失の許容範囲を満たすレートでログバックアップをより頻繁に実行してください。15分を超えるデータを失いたくない場合は、15分ごとにログバックアップを実行してください。

ファイル管理は完全にオンラインで行うことができます。回復目的でログ情報を保持する必要性に応じて、2つのパスがあります。

ポイントインタイムリカバリは不要

1. データベースをSIMPLEリカバリに変換します。チェックポイントを実行して、トランザクションをディスクに書き込みます。
2. ログを平坦化します。
3. ログのサイズを適切なサイズに変更します。

また、ログの管理を改善するために、固定の増加量と無制限の増加を設定することをお勧めします。固定の増加量はそれが依存する量であることに注意してください。ログがどれほどの増加を期待できるかに応じて、最初は1〜2 GBを使用することをお勧めします。理想的には、ログはあまり大きくならないので、これによる影響はそれほど大きくないはずです。ログが定期的に増加している場合は、サイズを再確認する必要がある場合があります。

使用して達成：

ALTER DATABASE [foo] 
SET RECOVERY SIMPLE;

CHECKPOINT;

DBCC SHRINKFILE (foo_log,0);

ALTER DATABASE [foo]
MODIFY FILE (NAME=foo_log,SIZE=8000MB,MAXSIZE=UNLIMITED,FILEGROWTH=1000MB);

--Optional if you want the database in full recovery mode 
--for point in time recovery going forward
ALTER DATABASE [foo] 
SET RECOVERY FULL;

ポイントインタイムリカバリが必要

最大の問題は、現在アクティブなVLFセグメントを超えてログファイルを圧縮できないことです。これを確認するにDBCC LOGINFOは、データベースコンテキストで使用できます。Status = 2のセグメントはすべてアクティブです。アクティブなセグメントをクリアするには、そのセグメントで現在アクティブなトランザクションがないときにトランザクションログのバックアップを実行する必要があります。あなたのステップは：

1. トランザクションログのバックアップを実行します。
2. ファイルを縮小します。（理想的にはフラット化しますが、データベースがアクティブな場合、これは困難です）。
3. ログが適切なサイズ、理想的には可能な限り小さくなるまで、手順1と2を繰り返します。
4. ログのサイズを適切なサイズに変更します。

使用して達成：

BACKUP LOG [foo] TO DISK='<Location of t-log backup>';

DBCC SHRINKFILE (foo_log,0);

--Repeat the above until your log file is small "enough"

ALTER DATABASE [foo]
MODIFY FILE (NAME=foo_log,SIZE=8000MB,MAXSIZE=UNLIMITED,FILEGROWTH=1000MB);

ここで何が起こっているのかを理解するための追加のリソース：

• SQL Server復旧モデル

• キンバリートリップのt-logの推奨事項

• データベースチェックポイント

実際には、ログを圧縮するためにデータベースをオフラインにする必要はありません。そして、これはおそらくログを縮小することが良い考えである数少ないケースの1つであると言います。初期サイズを設定することもできますが、縮小を実行して特定のサイズに縮小するように指示する方が簡単です。

USE [DBName]
GO
DBCC SHRINKFILE (N'LogName' , SizeInMg)
GO

また、GUIを使用し、2番目のラジオボタンと、ログの最終的な大きさを示すチェックボックスを使用して、これを行うこともできます。SSMSのオブジェクトエクスプローラーでデータベースを右クリックし、タスク、圧縮、ファイルを選択すると、GUIにアクセスできます。

シンプルモードに関するアーロンの回答を補完するものとして、1日あたり2つ（またはそれ以上）の差分バックアップをスケジュールできます。これにより、シンプルモードを維持しながら、データベース操作のデータ損失ウィンドウを削減できます。