答えがわからないようです。 トランザクションログが増加し続ける、または領域不足になるのはなぜですか?
そして、誰もがログファイルでバックアップを実行することについて話しているので、それは縮小されます。私はそうしていますが、何も縮小しません!また、非常に長いトランザクションを実行しているとは思いません。
サーバー:SQL Server 2008
回復モード:Full
5日間分のバックアップを保存する保守計画があります。タスク1はバックアップタイプFull
でデータベースをバックアップし、タスク2はトランザクションログをバックアップします。 Verify backup integrity
は両方のタスクでチェックされます。
私のDBの通常.ldf
ファイルは22GBです。上記のタスクを実行すると、.bak
ファイルは435MBですが、.trn.
ファイルは、ldfと同じ22GBです。そして、正常に実行した後、.ldf
私が読んだすべてがそれをすべきだと私に言ったにもかかわらず、まったく縮小しませんか?
ここで何が起こっているのか、なぜログファイルが縮小しないのですか?
別の回答で述べたように、私はこのコマンドを実行してみました:
select name, log_reuse_wait_desc from sys.databases
そして、それはLOG_BACKUP
は、巨大なログファイルを含むデータベース用です。
以下の回答に基づいて、割り当てられた使用済みスペースと混同しています。これらは私の統計です:
理由がわからないので、初期サイズを22GBに設定しました...
割り当てられたスペースと使用済みスペースを混同しています。バックアップを実行した後、このクエリを使用して、割り当て済みスペースと使用済みスペースの違いを確認します。
select file_id
, type_desc
, name
, substring([physical_name],1,3) AS [Drive]
, physical_name
, state_desc
, size / 128 as 'AllocatedSizeMB'
, FILEPROPERTY([name],'SpaceUsed') /128 AS 'SpaceUsedMB' --Addapted from https://sqlperformance.com/2014/12/io-subsystem/proactive-sql-server-health-checks-1
, (1- (FILEPROPERTY([name],'SpaceUsed') / CAST (size AS MONEY))) *100 AS 'PercentFree'
, growth / 128 as 'GrowthSettingMB'
from sys.database_files
order by type_desc Desc, name
GUIを使用して、「初期サイズ」を変更することでログファイルを圧縮できます。
ログがほとんど空に見えても、ログの圧縮に問題がある場合は、- 私の投稿はこちら を参照してください
このバックアップを取ると、データがバックアップされ、ログがクリアされます。ログを実際に縮小する必要がある場合は、DBCC
コマンドを使用してログの実際のサイズを縮小する必要があります。ログファイルをバックアップする頻度に応じて、ログファイルは再び大きくなる可能性があります。
これを実行して、ログの実際のスペースがどれだけ使用されているかを確認してください。
SELECT
[TYPE] = A.TYPE_DESC
,[FILE_Name] = A.name
,[FILEGROUP_NAME] = fg.name
,[File_Location] = A.PHYSICAL_NAME
,[FILESIZE_MB] = CONVERT(DECIMAL(10,2),A.SIZE/128.0)
,[USEDSPACE_MB] = CONVERT(DECIMAL(10,2),A.SIZE/128.0 - ((SIZE/128.0) - CAST(FILEPROPERTY(A.NAME, 'SPACEUSED') AS INT)/128.0))
,[FREESPACE_MB] = CONVERT(DECIMAL(10,2),A.SIZE/128.0 - CAST(FILEPROPERTY(A.NAME, 'SPACEUSED') AS INT)/128.0)
,[FREESPACE_%] = CONVERT(DECIMAL(10,2),((A.SIZE/128.0 - CAST(FILEPROPERTY(A.NAME, 'SPACEUSED') AS INT)/128.0)/(A.SIZE/128.0))*100)
,[AutoGrow] = 'By ' + CASE is_percent_growth WHEN 0 THEN CAST(growth/128 AS VARCHAR(10)) + ' MB -'
WHEN 1 THEN CAST(growth AS VARCHAR(10)) + '% -' ELSE '' END
+ CASE max_size WHEN 0 THEN 'DISABLED' WHEN -1 THEN ' Unrestricted'
ELSE ' Restricted to ' + CAST(max_size/(128*1024) AS VARCHAR(10)) + ' GB' END
+ CASE is_percent_growth WHEN 1 THEN ' [autogrowth by percent, BAD setting!]' ELSE '' END
FROM sys.database_files A LEFT JOIN sys.filegroups fg ON A.data_space_id = fg.data_space_id
order by A.TYPE desc, A.NAME;
実際に利用可能な空き領域がたくさんある場合は、 DBCC SHRINKFILE
コマンドを使用して、ログファイルを必要なサイズに縮小します。
編集:DBCC LOGINFO;
すると、ステータスが2になるため、トランザクションログファイルで使用されているアイテムを確認できます。
[〜#〜]ただし[〜#〜]最初にログファイルが大きくなる原因となったアクティビティは、引き続き発生する可能性があります。のサウンドから、1日に1つのログバックアップしか取っていないと考えています。
あなたがしなければならないのは、データベース全体のバックアップの合間に、1日を通して複数のログのバックアップを取ることです。私は1時間ごとから始めて、最終的に何が最適かを確認することをお勧めします。それがあなたにとって快適な場合は、保守計画を介してこれを続けることができます。それ以外の場合は、保守計画を設定するために Ola Hallengren's スクリプトを使用できます。多くの異なるオプションがあり、頻繁にバックアップを取っている限り、ほとんどの場合それらはすべて非常に優れています。