web-dev-qa-db-ja.com

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

現時点でやや不本意なDBAになり、本当に何か助けが必要です。

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

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

前もって感謝します

sql-server-2008transaction-log
10
Tim Alexander

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

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

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

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

6
Aaron Bertrand

ファイル管理は完全にオンラインで行うことができます。回復目的でログ情報を保持する必要性に応じて、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);

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

12
Mike Fal

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

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

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

2
Kenneth Fisher

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

2
Fabricio Araujo