야간 백업으로 트랜잭션 로그가 단순 복구 모드에서 계속 증가하는 이유

복제본으로 즉시 표시하기 전에 Mike Walsh의 트랜잭션 로그가 계속 늘어나거나 공간이 부족한 이유를 읽었습니다 . 하지만 내 상황에 대한 답을 얻지 못했다고 생각합니다. 나는 십여 개의 비슷한 질문들을 살펴 보았지만 관련 질문들은 대부분 "중복"이라고 말하고 Mike의 질문을 지적했다.

세부 정보 : SQL Server 2008 R2에는 ~ 500MB 데이터베이스와 ~ 200MB 데이터 파일과 ~ 300MB 로그 파일이 포함 된 SIMPLE 복구 모드 (내 선택이 아님), 야간 전체 백업이 있습니다. 로그는 즉시 300MB로 증가하지 않지만 몇 개월 동안 천천히 증가합니다. 적어도 sp_who2 및 활동 모니터에 따르면 공개 트랜잭션이 없습니다. 데이터베이스를 마우스 오른쪽 버튼으로 클릭하고 속성을 선택하면 ~ 50MB의 여유 공간이 있음을 알려줍니다. 특히 백업 직후에 전체 로그가 비어 있지 않아야합니까? 단순 모드에서 열린 트랜잭션이없는 한 로그를 비워 둘 수 없습니까?

log_reuse_wait_descfrom sys.databases은 "NOTHING"이라고 말하며 위에서 언급 한 질문과 답변을 바탕으로 공간을 재사용하기 위해 아무것도 기다리지 말아야한다고 말합니다.

'DBCC SHRINKFILE'을 수행하면 로그 파일이 1MB로 줄어들므로 공간을 기꺼이 회수합니다. 매주 로그를 축소하고 제어 할 수 없도록하는 것을 설정할 수는 있지만 SQL Server가 왜 그렇게하는지 혼란 스럽습니다.

그것을 기록하기 위해 300MB가 필요한 미친 거래가 있었는지 이해할 수 있지만, 기본 OLTP와 같은 극단적 인 일은하지 않습니다. Mike의 질문 / 답변에서 :

단순 복구 모델-위의 소개를 통해 단순 복구 모델에 대해 먼저 이야기하는 것이 가장 쉽습니다. 이 모델에서는 SQL Server에 대해 말하고 있습니다. 트랜잭션 로그 파일을 사용하여 충돌을 복구하고 복구를 다시 시작하는 것이 좋습니다 (실제로 선택의 여지가 없습니다. ACID 속성을 검색하면 신속하게 이해됩니다). 충돌 / 재 복구 복구 목적으로 더 이상 필요하면 로그 파일을 재사용하십시오.

SQL Server는 Simple Recovery에서이 요청을 수신하고 복구 / 재시작 복구에 필요한 정보 만 유지합니다. 데이터가 데이터 파일로 강화 되었기 때문에 (더 많거나 적은) SQL Server가 복구 할 수 있다고 확신하면 강화 된 데이터는 더 이상 로그에 필요하지 않으며 잘림으로 표시되어 재사용됩니다.

로그 공간을 재사용해야한다고 말하지만 몇 달 동안 느린 성장으로 인해 실제로는 그렇지 않은 것 같습니다.

내가 무엇을 놓치고 있습니까? SQL Server가 데이터를 "강화 된"것으로 인식하고 로그를 비우는 것을 방해합니까?

(편집) (가) 활동보고 후 - AKA 약간의 지식은 위험하다

이것이 "인기있는 질문"이라는 것을 알게 된 후 7 개월 전에 일어난 일과 다른 사람들에게 슬픔을 덜어주기 위해 배운 것이 무엇인지에 대한 설명이 필요했습니다.

먼저 데이터베이스에서 속성을 볼 때 SSMS에 표시되는 사용 가능한 공간은 데이터 파일에서 사용 가능한 공간입니다. 데이터베이스에서 다음을 실행하여이를 볼 수 있으며 SSMS에서보고 한 사용 가능한 공간은 FileSizeMB와 UsedSpaceMB의 차이입니다.

SELECT
    DB.name,
    MF.physical_name,
    MF.type_desc AS FileType,
    MF.size * 8 / 1024 AS FileSizeMB,
    fileproperty(MF.name, 'SpaceUsed') * 8/ 1024 AS UsedSpaceMB,
    mf.name LogicalName
FROM
    sys.master_files MF
    JOIN sys.databases DB ON DB.database_id = MF.database_id
WHERE   DB.name = 'yourdatabasename'

이것은 정상적인 상황에서 매우 적은 로그 공간 (20MB 이하)을 사용하고 있음을 확인했지만 두 번째 항목으로 이어집니다 ...

둘째, 로그 증가에 대한 나의 인식은 시간이 지남에 따라 천천히 증가했습니다. 그러나 실제로이 타사 응용 프로그램의 패치 적용 담당자는 패치를 적용하는 밤에 로그가 빠르게 성장했습니다. 패치는 단일 트랜잭션으로 수행되었으므로 패치에 따라 200MB 데이터에는 300MB의 로그가 필요했습니다. 다운 추적의 핵심은 https://sqlblog.org/2007/01/11/reviewing-autogrow-events-from-the-default-trace의 Aaron Bertrand의 쿼리였습니다.

DECLARE @path NVARCHAR(260);

SELECT 
    @path = REVERSE(SUBSTRING(REVERSE([path]), 
    CHARINDEX('\', REVERSE([path])), 260)) + N'log.trc'
FROM    sys.traces
WHERE   is_default = 1;

SELECT 
   DatabaseName,
   [FileName],
    SPID,
    Duration,
    StartTime,
    EndTime,
    FileType = CASE EventClass 
       WHEN 92 THEN 'Data'
       WHEN 93 THEN 'Log'
    END
FROM sys.fn_trace_gettable(@path, DEFAULT)
WHERE
    EventClass IN (92,93)
ORDER BY
    StartTime DESC;

이는 고객이 데이터베이스를 사용하지 않는 특정 저녁에 로그가 증가하고 있음을 보여줍니다. 그로 인해 패치를 적용한 사람과 수수께끼에 대한 답변을 나누는 대화가 나왔습니다.

답변에 도움을 주신 분들께 다시 한 번 감사드립니다.

우리가 원인을 추측하는 것은 불가능하지만 SQL Server는 로그 파일을 300MB로 늘리지 않고 마지막 축소 작업 이후 어느 시점에서 300MB로 커집니다. 많은 로그 공간 (일부 큰 트랜잭션 또는 작은 동시 트랜잭션으로 인해). 당신은 (나는이 이야기 로그 파일 증가 이벤트를 추적해야 할 것이다 여기 와 여기에 시도 할 때 또는 왜 당신이 다음 300 MB로 증가 할 것이다, 파일 증가 설정은 MB 또는 뭔가 300 로그도 경우에이 (어떻게 좁힐) 활성 트랜잭션을 수용하기 위해 1MB 이상의 공간이 필요한 즉시)

어쨌든 로그 파일이 300MB에 도달하면 축소해야한다고 생각하는 이유는 무엇입니까? 실제로 Mike의 질문 에 대한 모든 답변을 철저히 읽었습니까 ? 로그 파일을 1MB로 줄이면 최대 트랜잭션 시간 동안 다시 커질 수 있기 때문에 로그 파일이 자체적으로 축소되지 않으므로 총 시간이 낭비됩니다. 그 동안 모든 여유 공간으로 무엇을 하시겠습니까?

현재 테스트의 모든 ( DBCC SHRINKFILE, log_reuse_wait_desc)는 단순히 권리를 증명하는 지금 당신이 적절하게 트랜잭션 로그의 가상 로그 파일을 재사용하고 있습니다. 그러나 자동 증가 이벤트가 트랜잭션 로그 파일에서 발생하면 로그를 재사용 할 수 없다는 반응입니다.

때때로, 그것은 지속적인 상태 가 아닙니다 (현재보고있는 증상이없는 상태에서 지금 당신에게 어떻게 보이는지). 단순 복구 모델에서도이 동작을 유발할 수있는 몇 가지 사항이 있습니다.

가장 좋은 방법은 데이터 수집 작업을 설정 log_reuse_wait_desc하여 데이터베이스 의 데이터를 정기적으로 가져 와서 어딘가에 정기적으로 기록하는 것입니다. 그런 다음 로그 재사용이 부족한 원인을 리버스 엔지니어링 할 수 있어야합니다.

로그 공간을 재사용해야한다고 말하지만 몇 달 동안 느린 성장으로 인해 실제로는 그렇지 않은 것 같습니다.

위에서 언급했듯이 일반적으로 트랜잭션 로그 재사용이 부족한 지속적인 상태는 아니므로 (잘못 구성된 트랜잭션과 같은 몇 가지 경우를 제외하고), 이러한 상황 이 발생 하는 시점을 정확히 찾아야합니다 . 경량 진단 데이터 수집은 좋은 시작이되어야합니다.

DB에서 자동 축소가 활성화되어 있습니까? 인덱스 재 구축을 수행하는 유지 관리 계획을 예약 했습니까?

자동 축소 후 인덱스 유지 관리로 인해 상당한 로그 볼륨이 생성됩니다.

GUID의 클러스터형 인덱스와 같은 DB 디자인 문제가있는 경우 인덱스 유지 관리 자체만으로도 상당한 로그 볼륨이 발생합니다.

 create table #dblog (Databasename varchar(100),
                     logsize float,
                     logspace%] float,
                     [Status] int)

 insert into #dblog
 EXEC ('DBCC sqlperf(logspace)') 

 select * from #dblog

 alter table #dblog 
 add [lgspace used GB] float;

 update #dblog 
 set [lgspace used GB ] = (logsize*[logspace%]/1024)

 update #dblog 
 set [logsize] =([logsize]/1024)

 alter table #dblog 
 drop column [Status];

 select * from #dblog

 drop table #dblog