트랜잭션 로그 잘림

업데이트: 2007년 9월 15일

트랜잭션 로그에서 로그 레코드를 삭제하지 않으면 물리 로그 파일이 사용할 수 있는 디스크의 모든 공간을 채울 때까지 계속 증가합니다. 로그 잘림은 트랜잭션 로그에서 재사용할 수 있도록 자동으로 디스크 공간을 해제합니다.

몇 가지 이유로 지연되는 경우를 제외하고 로그 잘림은 다음과 같이 자동으로 수행됩니다.

• 단순 복구 모델의 경우 검사점 후에 수행됩니다.
• 전체 복구 모델 또는 대량 로그 복구 모델에서는 이전 백업 이후에 검사점이 발생한 경우 로그 백업 후에 자동으로 수행됩니다. 자세한 내용은 이 항목 뒷부분에서 "전체 및 대량 로그 복구 모델에서의 로그 잘림"을 참조하십시오.

자동으로 수행되기는 하지만 로그 잘림은 다양한 요소에 의해 지연될 수 있습니다. 로그 잘림을 지연시키는 요소에 대한 자세한 내용은 로그 잘림을 지연시킬 수 있는 요소를 참조하십시오.

중요:
로그 잘림이 오랫동안 지연되면 트랜잭션 로그가 가득 찰 수 있습니다. 트랜잭션 로그가 꽉 찬 경우의 처리 방법은 꽉 찬 트랜잭션 로그 문제 해결(오류 9002)을 참조하십시오.

로그 트랜잭션의 아키텍처에 대한 내용은 이 항목 뒷부분에서 "로그 잘림 작동 방법"을 참조하십시오.

전체 및 대량 로그 복구 모델에서의 로그 잘림

전체 복구 모델 또는 대량 로그 복구 모델에서 로그의 비활성 부분은 해당 로그 레코드가 모두 로그 백업에 캡처되기 전까지 자를 수 없습니다. 이는 연속적인 LSN(로그 시퀀스 번호) 시퀀스를 가진 일련의 로그 레코드인 로그 체인을 유지하는 데 필요합니다. 다음 조건이 있다고 가정할 경우 트랜잭션 로그를 백업할 때 로그가 잘립니다.

• 로그가 마지막으로 백업된 이후 검사점이 발생한 경우. 전체 복구 모델 또는 대량 로그 복구 모델에서 검사점은 필수적이지만 검사점만으로는 로그를 자를 수 없습니다. 검사점 후에도 로그는 적어도 다음 트랜잭션 로그 백업 시까지 그대로 남아 있습니다.
  자세한 내용은 검사점 및 로그의 활성 부분을 참조하십시오.
• 로그 잘림을 차단하는 다른 요소가 없는 경우
  일반적으로 정기적인 백업에서는 나중에 사용할 수 있도록 로그 공간을 정기적으로 확보합니다. 그러나 장기 실행 트랜잭션 같은 다양한 요소로 인해 로그 잘림이 일시적으로 차단될 수 있습니다. 자세한 내용은 로그 잘림을 지연시킬 수 있는 요소를 참조하십시오.
• BACKUP LOG 문에서 WITH NO_TRUNCATE, WITH NO_LOG 또는 WITH COPY_ONLY 중 하나를 지정하지 않는 경우

  중요:
  BACKUP LOG 문의 NO_LOG 및 TRUNCATE_ONLY 옵션은 백업 복사본을 만들지 않고 로그의 비활성 부분을 제거하므로 로그 체인을 끊습니다. 다음 전체 또는 차등 데이터베이스 백업 시까지 미디어 오류로부터 데이터베이스가 보호되지 않습니다. 이 기능은 다음 버전의 Microsoft SQL Server에서 제거됩니다. 새 개발 작업에서는 이 기능을 사용하지 말고, 현재 이 기능을 사용하는 응용 프로그램은 가능한 한 빨리 수정하십시오.

트랜잭션 로그를 백업하려면

• 방법: 트랜잭션 로그 백업(SQL Server Management Studio)
• 방법: 트랜잭션 로그 백업 만들기(Transact-SQL)

로그 잘림 작동 방법

[!참고] 잘라내기를 수행하더라도 물리 로그 파일의 크기는 줄어들지 않습니다. 로그 파일의 실제 크기를 줄이려면 파일을 축소해야 합니다. 물리 로그 파일의 크기를 축소하는 방법은 트랜잭션 로그 축소를 참조하십시오.

트랜잭션 로그는 순환 파일입니다. 이 데이터베이스가 생성될 때 물리 로그 파일의 시작 부분에서 논리 로그 파일이 시작됩니다. 새 로그 레코드는 논리 로그의 끝 부분에 추가되며 물리 로그의 끝 방향으로 확장됩니다. 데이터베이스의 트랜잭션 로그는 하나 이상의 물리적 파일에 매핑됩니다. SQL Server 데이터베이스 엔진은 내부적으로 각 물리 로그 파일을 여러 개의 가상 로그 파일로 나눕니다. 로그 잘림은 논리 로그의 시작을 구성하는 비활성 가상 로그 파일을 삭제하여 논리 로그에 사용 가능한 공간을 만듭니다. 트랜잭션 로그 아키텍처에 대한 자세한 내용은 트랜잭션 로그 논리 아키텍처 및 트랜잭션 로그 물리 아키텍처를 참조하십시오.

가상 로그 파일은 다시 사용할 수 있는 공간 단위입니다. 비활성 로그 레코드가 포함된 가상 로그 파일만 자를 수 있습니다. 활성 로그는 데이터베이스 복구에 필요하기 때문에 트랜잭션 로그의 활성 부분인 활성 로그는 자를 수 없습니다. 가장 최근 검사점이 활성 로그를 정의하며 해당 검사점까지 로그를 자를 수 있습니다.

[!참고] 가상 로그 파일의 기능에 대한 자세한 내용은 트랜잭션 로그 물리 아키텍처를 참조하십시오.

검사점을 수행하면 트랜잭션 로그의 비활성 부분은 재사용 가능으로 표시됩니다. 그런 후에는 로그 잘림으로 비활성 부분에 대한 공간을 확보할 수 있습니다. 잘림을 수행하면 비활성 가상 로그 파일이 다시 사용할 수 있도록 공간이 확보됩니다. 결국 새 레코드를 공간이 확보된 가상 로그에 쓰면 해당 가상 로그 파일이 다시 활성화됩니다.

검사점에 기록되는 한 가지 정보는 성공적인 데이터베이스 차원의 롤백을 위해 반드시 있어야 하는 첫 번째 로그 레코드의 LSN(로그 시퀀스 번호)입니다. 이 LSN을 최소 복구 LSN(MinLSN)이라고 합니다. 로그 활성 부분의 시작은 MinLSN이 포함된 가상 로그입니다. 트랜잭션 로그를 자르면 이 가상 로그 파일 앞의 로그 레코드만 다시 사용할 수 있도록 공간이 확보됩니다.

다음 그림에서는 잘림 전과 후의 트랜잭션 로그를 보여 줍니다. 첫 번째 그림은 잘림이 수행되지 않은 트랜잭션 로그를 보여 줍니다. 현재 논리 로그에서 4개의 가상 로그 파일을 사용하고 있습니다. 논리 로그는 첫 번째 가상 로그 파일 앞에서 시작되어 가상 로그 4에서 끝납니다. MinLSN 레코드는 가상 로그 3에 있습니다. 가상 로그 1과 가상 로그 2에는 비활성 로그 레코드만 포함되어 있습니다. 이러한 레코드는 자를 수 있습니다. 가상 로그 5는 사용하지 않았으며 현재 논리 로그에 포함되지 않습니다.

두 번째 그림은 잘림 후의 로그 모습을 보여 줍니다. 가상 로그 1과 가상 로그 2는 다시 사용할 수 있도록 공간이 확보되었습니다. 이제 논리 로그는 가상 로그 3의 시작 부분에서 시작됩니다. 가상 로그 5는 사용하지 않았으며 현재 논리 로그에 포함되지 않습니다.

참고 항목

개념

검사점 및 로그의 활성 부분
데이터베이스 옵션 설정
트랜잭션 로그 백업 작업
데이터베이스 복구 모델 선택
복구 모델 개요

관련 자료

BACKUP(Transact-SQL)
Truncate Method

도움말 및 정보

SQL Server 2005 지원 받기

변경 내역

릴리스	내역
2007년 9월 15일	변경된 내용 로그 잘림은 모든 가상 로그 파일에 활성 로그가 포함되어 있지 않은 경우 자동으로 수행된다는 내용을 설명하는 소개 부분을 수정했습니다. 소개 부분에 있던 아키텍처 정보를 "로그 잘림 작동 방법" 섹션으로 옮겼습니다. 트랜잭션 로그를 백업하는 방법에 대한 링크를 추가했습니다.
2006년 4월 14일	변경된 내용 복구 모델이 로그 잘림에 미치는 영향에 대한 설명을 보강했습니다. 그림에 대한 자세한 설명을 추가했습니다.