Lazy Log Truncation

Lazy Log Truncation

 

• Version : SQL Server 2012

 

SQL Server에서 트랜잭션에 대한 모든 기록은 트랜잭션 로그에 남게 된다. 로그 백업을 진행 함으로써 트랜잭션 로그를 비우는데 일부 상황에서 트랜잭션 로그가 비워지지 않았다. 다음 사례를 통해 알아 보자.

 

지난 포스트에는 일반적으로 LDF가 잘리지 않는 이유에 대해서 다룬적 있다.

• LDF가 잘리지 않는 이유 : http://sqlmvp.kr/140194327713

 

로그 백업을 실행하였는 데에도 트랜잭션 로그가 잘리지 않는 경우는 어떤 것이 있을까? 이번 포스트는 SQL Server Premier Field Engineer Blog에 게시된 내용으로 필자가 읽고 이해한 내용을 바탕으로 정리하였으며 번역의 오류나 기술적 오류 가능성을 미리 알려 둔다. 자세한 내용은 원문을 참고하길 바란다.

 

Avaliability Group 백업 시나리오 테스트 중 트랜잭션 로그에 이상한 점이 발견 되었다. 이 문제는 Lazy Log Truncation 에 관한 문제였다.

트랜잭션의 VLF에 대한 자세한 내용은 아래 링크를 참고 한다.

• 트랜잭션 로그 물리 아키텍처 : http://sqlmvp.kr/140187358202

 

일반적인 트랜잭션 로그의 최초 모습을 확인해 보자. 처음 데이터베이스를 생성하였으며 전체 백업을 수행하고 현재의 가상 로그 파일을 표시하려면 DBCC LOGINFO를 실행 한다.

USE [SW_TEST2] GO   DBCC LOGINFO --you see here that there are 8 VLFs with 1 that has a status of 2 GO

 

 

Status의 값이 2인 상태가 현재 로그의 활성 부분이다. 아래 스크립트를 실행하여 데이터베이스에 몇 가지 작업을 수행한다.

CREATE TABLE test1 ( myvarchar varchar(5000)) GO   INSERT INTO test1 VALUES( replicate('*',5000)) GO 5000   DELETE FROM test1

 

DBCC LOGINFO를 통하여 현재 트랜잭션 로그를 포함하고 있는 VLF를 살펴 보자. 가상 로그파일이 활성 트랜잭션을 포함하고 있는 것을 확인 할 수 있다.

DBCC LOGINFO GO

 

 

 

트랜잭션 백업을 수행하여 가상 로그 파일을 삭제하고 DBCC LOGINFO를 실행하여보자. FSeqNo 35번이 여전히 활성화 상태로 표시되어 있다. 로그 파일이 잘리려면 복제(미러링, CDC, 복제, 기타 등)등의 활성 트랜잭션레코드를 포함하지 않을 경우에만 전체 가상 로그파일이 잘린다. 또한 VLF 상태가 1이 되어야 한다.

 

BACKUP LOG SW_TEST2 TO DISK = N'C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\Backup\SW_TEST2.trn' WITH NOFORMAT, NOINIT, NAME = N'LLTTest-Transaction Log Backup', SKIP, NOREWIND, NOUNLOAD, STATS = 10 GO   DBCC LOGINFO --after the tlog backup all but one of the VLFs are inactive (status 0) GO

 

 

 

다시 한번 아래 스크립트를 실행하여 보자. 로그 파일의 시작 부분이 롤오버 되는 것을 확인 할 수 있다.

INSERT INTO test1 VALUES( replicate('*',5000)) GO 5000 GO   DELETE FROM test1 GO   DBCC LOGINFO --Nothing special here, you can see more active VLFs GO

 

 

트랜잭션 백업을 통하여 가상 로그파일을 잘라 보자. 가상 로그 파일 중 하나를 0으로 취소하지 않았다.

BACKUP LOG SW_TEST2 TO DISK = N'C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\Backup\SW_TEST2.bak' WITH NOFORMAT, NOINIT, NAME = N'LLTTest-Transaction Log Backup', SKIP, NOREWIND, NOUNLOAD, STATS = 10 GO   DBCC LOGINFO GO

 

 

 

다시 한번 아래 스크립트를 실행하여 보자. FSeqNo 32 - 35이 40 - 43로 대체 되었다. 가상 로그가 계속 활성 상태로 간주되더라도 그들은 이전 트랜잭션 로그 백업의 일부가 된 이후 재사용 할 수 있었다.

INSERT INTO test1 VALUES( replicate('*',5000)) GO 5000   DELETE FROM test1 --Spoiler Alert: IT WORKS!! GO   DBCC LOGINFO GO

 

 

우리는 미러링 등 가용성 그룹 시나리오에서 Lazy Log Truncation 에 대한 가상 로그 파일을 표시하는 것으로 나타났다. 하지만 가상 로그파일이 필요하지 않는 한 실제로 로그파일을 자르지 않았다. 왜 그럴까? 다른 부분에서 로그를 사용하기 때문에 유지하는 듯 하다. 복제에서 동일한 지점에서 복제 트랜잭션 로그를 얻기 위해 복원을 해야 하는 경우 로그 백업 수를 최소화 하기 위해 추가한다.

 

 

[참고자료]

• http://blogs.msdn.com/b/sql_pfe_blog/archive/2013/06/27/lazy-log-truncation-clearing-of-sql-transaction-log-vlf-status-deferred.aspx
• LDF가 잘리지 않는 이유 : http://sqlmvp.kr/140194327713
• 트랜잭션 로그 물리 아키텍처 : http://sqlmvp.kr/140187358202

 

 

 

2013-10-07 / 강성욱 / http://sqlmvp.kr