BACKUP LOG TO DISKの後でもログファイルのDBCC SHRINKFILEがサイズを縮小しない
次の情報を持つデータベース[My DB]があります。
SQL Server 2008
MDFサイズ：30 GB
LDFサイズ：67 GB
私はログファイルを可能な限り縮小したかったので、これを行う方法を見つけるための探求を始めました。警告：私はDBAではありません（またはDBAに近づいています）。
最初に、SSMS、DBプロパティ、ファイルに移動し、初期サイズ（MB）の値を10に編集しました。これにより、ログファイルが62 GBに削減されました（入力した10 MBではありません）。そのため、SQLプロファイラーを添付し、DBCC SHRINKFILEが呼び出されていることを確認しました。次に、そのコマンドをクエリエディターに入力すると、結果が表示されます。
DBCC SHRINKFILE (N'My DB_Log' , 10)
出力は次のとおりです。
Cannot shrink log file 2 (My DB_Log) because the logical log file located at the end of the file is in use.
DbId FileId CurrentSize MinimumSize UsedPages EstimatedPages
------ ----------- ----------- ----------- ----------- --------------
8 2 8044104 12800 8044104 12800
(1 row(s) affected)
DBCC execution completed. If DBCC printed error messages, contact your system administrator.
それから私はそれについていくつかの研究をし、これを見つけました：
http://support.Microsoft.com/kb/907511
これは、仮想ログファイルが解放され、シュリンクファイルが機能するように、シュリンクファイルの前にログファイルをバックアップする必要があることを示しています-それが何を意味するのかわかりません...ここで言い換えています:)
そのため、ログファイルをバックアップしてからDBCC SHRINKFILEを実行しようと考えました（以前のDBCC SHRINKFILEコマンドの出力で識別されたMinimumSizeであったため、新しいログファイルサイズを12800に変更しました）
BACKUP LOG [My DB] TO DISK = 'D:\SQLBackup\20110824-MyDB-Log.bak'
GO
DBCC SHRINKFILE (N'My DB_Log' , 12800)
GO
結果は最初の回と同じでした。ログファイルは62 GBまでしか取得できません。
何が間違っているのか、次に何をしようとするのかがわかりません。
既に実行した手順に加えて、ログを圧縮する前に、回復モードを単純に設定する必要があります。
このISは実稼働システムの推奨されるプラクティスではありません...以前の時点まで回復する能力が失われますバックアップ/ログファイル。
例と説明については、この DBCC SHRINKFILE（Transact-SQL） msdnページの例Bを参照してください。
さて、ここにトランザクションファイルの物理サイズを縮小するソリューションがありますが、 なしで 復旧モードをシンプルに変更します。
データベース内で、次のクエリを使用してログファイルのfile_idを見つけます。
SELECT * FROM sys.database_files;
私のインスタンスでは、ログファイルはfile_id 2です。使用中の仮想ログを特定し、次のコマンドでこれを行います。
DBCC LOGINFO;
ここでは、ステータスが2（使用中）か0（無料）かを確認することで、仮想ログが使用中かどうかを確認できます。ファイルを圧縮する場合、空の仮想ログは、ファイルの最後から最初の使用済みステータスに達するまで物理的に削除されます。トランザクションログファイルを圧縮すると、途中で圧縮されることがありますが、すべての空き仮想ログが削除されるわけではありません。
0の後に発生するステータス2に気づいた場合、これはファイルの完全な縮小からの縮小をブロックしています。これを回避するには、別のトランザクションログバックアップを実行し、上記のfile_idとログファイルを縮小するサイズを指定して、すぐにこれらのコマンドを実行します。
-- DBCC SHRINKFILE (file_id, LogSize_MB)
DBCC SHRINKFILE (2, 100);
DBCC LOGINFO;
これにより、仮想ログファイルの割り当てが表示され、願わくば、それがいくらか削減されていることがわかります。仮想ログファイルは常に順序どおりに割り当てられるわけではないため、トランザクションログを数回バックアップしてから、この最後のクエリを再度実行する必要がある場合があります;ただし、通常は1〜2回のバックアップで縮小できます。
このスクリプトは、SQL Server 2008 R2で使用します。
USE [db_name]
ALTER DATABASE [db_name] SET RECOVERY SIMPLE WITH NO_WAIT
DBCC SHRINKFILE([log_file_name]/log_file_number, wanted_size)
ALTER DATABASE [db_name] SET RECOVERY FULL WITH NO_WAIT
これを試して
ALTER DATABASE XXXX SET RECOVERY SIMPLE
use XXXX
declare @log_File_Name varchar(200)
select @log_File_Name = name from sysfiles where filename like '%LDF'
declare @i int = FILE_IDEX ( @log_File_Name)
dbcc shrinkfile ( @i , 50)
Paul Randalのブログでこの問題に関する優れた議論があります。 http://www.sqlskills.com/blogs/paul/post/backup-log-with-no_log-use-abuse-and-undocumented-trace -flags-to-stop-it.aspx
ログファイルの縮小
ログファイルの場合、データベースエンジンはtarget_sizeを使用して、ログ全体のターゲットサイズを計算します。したがって、target_sizeは、縮小操作後のログ内の空き領域の量です。次に、ログ全体のターゲットサイズが各ログファイルのターゲットサイズに変換されます。 DBCC SHRINKFILEは、各物理ログファイルをすぐに目標サイズに縮小しようとします。
ただし、論理ログの一部がターゲットサイズを超えて仮想ログに存在する場合、データベースエンジンはできるだけ多くのスペースを解放し、情報メッセージを発行します。
このメッセージは、ファイルの最後にある仮想ログから論理ログを移動するために必要なアクションを説明しています。アクションの実行後、DBCC SHRINKFILEを使用して残りのスペースを解放できます。
ログファイルは仮想ログファイルの境界までしか縮小できないため、ログファイルを仮想ログファイルのサイズよりも小さいサイズに縮小することはできません。使用されている。仮想ログファイルのサイズは、ログファイルの作成時または拡張時にデータベースエンジンによって動的に選択されます。
- トラブルシューティング：ファイルが縮小しない
縮小操作がエラーなしで実行されたが、ファイルのサイズが変更されていないように見える場合は、次のいずれかの操作を実行して、ファイルに削除する十分な空き領域があることを確認します。
次のクエリを実行します。
SELECT name、size/128.0-CAST（FILEPROPERTY（name、 'SpaceUsed'）AS int）/128.0 AS AvailableSpaceInMB FROM sys.database_files;
DBCC SQLPERFコマンドを実行して、トランザクションログで使用されているスペースを返します。
使用可能な空きスペースが不十分な場合、縮小操作ではファイルサイズをそれ以上縮小できません。
通常、縮小していないように見えるのはログファイルです。これは通常、切り捨てられていないログファイルの結果です。
データベース復旧モデルをSIMPLEに設定することにより、ログを切り捨てできます、またはlogをバックアップしてからDBCC SHRINKFILE操作を再度実行する。
例：
ログファイルを指定されたターゲットサイズに縮小する
次の例では、AdventureWorksデータベースのログファイルを1 MBに縮小します。 DBCC SHRINKFILEコマンドでファイルを圧縮できるようにするには、データベース回復モデルをSIMPLEに設定して、ファイルを最初に切り捨てます。
Transact-SQL
AdventureWorks2012を使用します。
GO
-データベース復旧モデルをSIMPLEに変更して、ログを切り捨てます。
ALTER DATABASE AdventureWorks2012
回復の簡易設定;
GO
-切り捨てられたログファイルを1 MBに縮小します。
DBCC SHRINKFILE（AdventureWorks2012_Log、1）;
GO
-データベース復旧モデルをリセットします。
ALTER DATABASE AdventureWorks2012
リカバリを完全に設定します。
GO
DBCC SHRINKFILE（Logfile、size）を使用すると、ログファイルの末尾から可能な限り切り捨てられます。使用中の最高の仮想ログに到達すると、それ以上縮小することはできません。これについては、SQL Server Books Onlineの以下を参照してください。
http://technet.Microsoft.com/en-us/library/ms189493.aspx
そのため、ログの上限が明確になると、サイズを縮小できます。繰り返しますが、それはまだ使用されているログの量に依存します。ログはバックアップによってクリアできますが、バックアップでは不完全なトランザクションはクリアされないため、バックアップを繰り返した後でもログはハイエンドVLFのままになります。
VLFの増減に関して、元々作成されるログファイルの大きさと、ログファイルの増加の設定はどのくらいですか？少しだけ成長すると、誰もが望むよりも多くのVLFが作成されます。
ログファイルを縮小する一般的なパターンは、結果が得られるまでCHECKPOINT、BACKUP、SHRINKFILE、CHECKPOINT、BACKUP、SHRINKFILEなどです。非常に大きなロールバックなど、ログが圧縮できない理由は多数あります。
シンプルからフルへの切り替えには問題があります：
ここにはルールと例外があります。長時間実行されるトランザクションについては、以下で詳しく説明します。
ただし、完全復旧モードの注意点は次のとおりです。完全復旧モードに切り替えて、最初の完全バックアップを実行しない場合、SQL Serverは完全復旧モデルへの要求を受け入れません。完全復旧モデルに切り替えて最初の完全バックアップを取得するまで、トランザクションログはSimpleの場合と同様に動作し続けます。
ログバックアップなしの完全復旧モデルは不良です：
それでは、それが制御されないログ成長の最も一般的な理由ですか？回答：ログのバックアップなしで完全復旧モードになっています。
これは常に人々に起こります。
なぜこれがよくある間違いですか？
なぜそれが常に起こるのですか？新しいデータベースはそれぞれ、モデルデータベースを見ることで初期復旧モデル設定を取得するためです。
モデルの初期復旧モデル設定は、常に完全復旧モデルです-誰かがそれを変更するまで。したがって、「デフォルトの復旧モデル」はフルと言うことができます。多くの人はこれを認識していないため、ログバックアップなしで完全復旧モデルでデータベースを実行しているため、トランザクションログファイルは必要以上に大きくなります。これが、組織とそのニーズに合わない場合にデフォルトを変更することが重要である理由です）
私は多くの方法を試しましたが、これは機能します。
サンプルコードは DBCC SHRINKFILE にあります。
USE DBName;
GO
-- Truncate the log by changing the database recovery model to SIMPLE.
ALTER DATABASE DBName
SET RECOVERY SIMPLE;
GO
-- Shrink the truncated log file to 1 MB.
DBCC SHRINKFILE (DBName_log, 1); --File name SELECT * FROM sys.database_files; query to get the file name
GO
-- Reset the database recovery model.
ALTER DATABASE DBName
SET RECOVERY FULL;
GO