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


24

복제본으로 즉시 표시하기 전에 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;

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

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


실제로 SIMPLE 복구 모델을 사용하는 클라이언트 사이트 데이터베이스 중 하나에서 비슷한 현상을 직접 관찰했습니다. 로그는 (어쨌든, 아직) 성장하지 않지만, 로그 파일에 사용 된 공간 않는 매일 밤 작은 비트에 의해 성장한다. 그리고 데이터베이스 백업이 실행될 때 발생합니다. 아직 원인이 무엇인지, 문제가 있는지 여부를 아직 알지 못했습니다.
RBarryYoung

답변:


20

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

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


300MB의 로그가 필요한 작업을 수행하고 있다고 생각하지는 않지만 일단 완료된 후에도 데이터베이스의 여유 공간으로 표시되지 않습니까? SQL Server Management Studio에서 데이터베이스의 속성을 볼 때 크기는 데이터와 로그의 크기이며 여유 공간이 데이터와 로그의 여유 공간이 될 것으로 기대합니다. 로그의 여유 공간이 표시되지 않습니까? 무료로 표시되지 않았다는 것은 여전히 ​​사용중인 것처럼 보이지만 데이터베이스에 대한 활동은 없습니다.
DerekCate

1
아니요, 일단 완료되면 자동으로 여유 공간이되지 않습니다. 커밋 된 트랜잭션은 제로화되지 않으며 해당 공간은 재사용 가능한 것으로 표시됩니다.
Aaron Bertrand

1
@DerekCate "300MB의 로그가 필요한 작업을 수행하고 있다고 생각하지 않습니다." 그것이 항상 원인이 아니기 때문에 작업량의 양으로 생각하지 마십시오.
Thomas Stringer

자, 이것을 올바르게 이해하고 있음을 확인하기 위해 300MB 로그는 현재 필요하지 않더라도 여유 공간으로 표시되지 않지만 재사용됩니다. 그리고 어느 시점에서 일부 트랜잭션을 처리하는 데 300MB가 필요했습니다. 확인해야 할 새로운 것들. 고맙습니다!
DerekCate

1
고려해야 할 또 다른 사항 : 간단한 복구 데이터베이스의 자동 검사 점은 로그가 이미 70 % 찼을 때만 대기합니다. 따라서 타이밍에 따라 증가하는 로그 활동이 모두 필요하지 않을 수 있습니다.
폴 화이트 GoFundMonica 말한다

6

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

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

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

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

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


만약 50MB의 여유 공간과 300MB의 로그를보고 있다면 fn_DBLOG ()는 로그의 크기가 어떻게 증가하고 있는지에 대한 통찰력을 줄 것입니까?
케네스 피셔

0

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

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

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


DB에서 자동 축소 기능을 사용할 수 없으므로 인덱스 조각화를 피 하려고 합니다. brentozar.com/archive/2009/08/… 우리는 매주 무결성 검사를 받지만 그중 일부로 인덱스를 다시 작성하는 것은 아니라고 생각합니다. 그 외에 GUID가 없으면 모든 테이블에 기본 키인 ID 열이 있습니다.
DerekCate

-3
 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
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.