SQL Serverデータベースのログファイルサイズを制御する方法は？

Question

私たちはMSSQL Serverを使用しており、私たちのアプリケーションは毎日重いデータ交換をしています。約。 1日に20K行の新しいデータとデータベース"ログファイルサイズ"が同様に増加し続けています。処理後のデータを削除して、DBサイズを制御し続けるが、「DBログファイル」は増加し続けている。

「DBログファイル」サイズを縮小するために、次のスクリプトを手動で実行しています。また、DB所有者だけがこのプロセスを実行できます。

は自動制御にあっ永久修正「DBログファイル」サイズですか？たとえば、最大4GBを割り当てたいとします。古いログを自動的に消去する必要があります。

USE db1; 
GO 

ALTER DATABASE db1 
SET RECOVERY SIMPLE; 
GO 
--first parameter is log file name and second is size in MB 
DBCC SHRINKFILE (db1_log, 999); 

ALTER DATABASE db1 
SET RECOVERY FULL; 
GO 

よろしく、 ラジ

Answer 1

私はこれを参照してください。データベースの完全バックアップは、トランザクションログが含まれていない、完全復旧モードで

SET RECOVERY FULL; 

を。さらに、サーバーはいかなる状況においてもバックアップされていないログエントリを削除しません。これは、ログファイルが増え続けることを意味します。

"DBログファイル"サイズを自動制御する永続的な修正はありますか？

はい。この問題を解決するには、個別のトランザクションログバックアップを実行する必要があります。and do them often。これにより、ログファイルは妥当なサイズに留まります。おそらく4GBよりもはるかに少ないでしょう。

注意してください。変更を行った後に初めてバックアップを取ると、かなりのバックアップファイルが取得され、完了するまでに時間がかかり、データベースに重大な負荷をかけることがあります。しかし、最初の実行の後、あなたが妥当なスケジュールを選択した場合、物事は静かになります。

さらに、新しいスケジュールで最初のトランザクションログバックアップを完了すると、最終的にトランザクションログファイルを縮小できます。その前にファイルを縮小することには意味がありません。それはまだすべてのスペースを使用していますが、そうでなくても、それは再び大きくなるでしょう。この最初の縮小をしたら、you really shouldn't do it again。手動でファイルを縮小する必要がないように保守スケジュールを設定し、以前の間違いの後に合理的な状態に戻るために今度は縮小するだけです。

Answer 2

どのようにSQL Serverの明確なT-ログ2通りの方法があります。SIMPLE復旧モデルを使用して

1. データベース - チェックポイントが発生した場合、ログはFULLまたはBULK_LOGGED復旧モデルを使用して

2. データベースをクリアしますが、 - あなたがSHRINKFILEを発行する場合は、ログのバックアップに

を発行したとき、T-ログインするだけで時間が縮小されます。

ログファイルのサイズを4GBに自動拡張し、4GBに自動拡張することができます。

USE [master] 
GO 
ALTER DATABASE [DB] MODIFY FILE (NAME = N'DB_log', SIZE = 4096000KB , FILEGROWTH = 4096000KB) 
GO 

あなたのファイルの成長はIn MegabytesなくIn Percentに設定する必要があります。

ファイルサイズをフィックスサイズに制限できますが、これを設定することはお勧めしません。これにより、サイズに達するとアプリケーションが挿入されなくなる可能性があります。

1日のダウンタイム/データ損失に耐えられる場合は、簡単な復旧が可能です。しかし、24時間365日営業の店舗で特定の時点でリカバリする必要がある場合は、データベースをFULLリカバリ（ログをクリーンアップするために必要なログバックアップ）に設定し、RPO/RTO要件についてビジネスに尋ねる必要があります。