트랜잭션 로그 잘림
트랜잭션 로그에서 로그 레코드를 삭제하지 않으면 물리 로그 파일에 사용할 수 있는 디스크 공간이 모두 로그 레코드로 채워집니다. 로그 잘림은 트랜잭션 로그에서 다시 사용할 수 있도록 자동으로 논리 로그의 공간을 확보합니다.
여타의 이유로 지연된 경우를 제외하고 로그 잘림은 다음과 같이 자동으로 발생합니다.
단순 복구 모델에서 검사점 이후
전체 복구 모델 또는 대량 로그 복구 모델에서 로그 백업 후(이전 백업 이후에 발생한 검사점이 있는 경우). 자세한 내용은 이 항목의 뒷부분에 나오는 "전체 및 대량 로그 복구 모델에서의 로그 잘림"을 참조하십시오.
로그 잘림은 자동으로 수행되지만 여러 요소로 인해 지연될 수 있습니다. 로그 잘림을 지연시킬 수 있는 요소에 대한 자세한 내용은 로그 잘림을 지연시킬 수 있는 요소를 참조하십시오.
.gif "중요 정보") 중요 |
|---|
로그 잘림이 장시간 지연될 경우 트랜잭션 로그가 꽉 찰 수 있습니다. 전체 트랜잭션 로그를 처리하는 방법은 꽉 찬 트랜잭션 로그 문제 해결(오류 9002)을 참조하십시오. |
로그 잘림에 대한 아키텍처 정보는 이 항목의 뒷부분에 나오는 "로그 잘림 작동 방법"을 참조하십시오.
전체 및 대량 로그 복구 모델에서의 로그 잘림
전체 복구 모델 또는 대량 로그 복구 모델에서 로그의 비활성 부분은 모든 로그 레코드가 로그 백업에 캡처될 때까지 자를 수 없습니다. 왜냐하면 연속적인 시퀀스의 LSN(로그 시퀀스 번호)으로 된 일련의 로그 레코드인 로그 체인을 유지하는 데 필요하기 때문입니다. 다음 조건이 있다고 가정할 경우 트랜잭션 로그를 백업할 때 로그가 잘립니다.
로그가 마지막으로 백업된 이후 검사점이 발생한 경우. 전체 복구 모델 또는 대량 로그 복구 모델에서는 검사점이 반드시 필요하지만 검사점만으로는 로그를 자를 수 없습니다. 검사점 후에도 로그는 적어도 다음 트랜잭션 로그 백업 시까지 그대로 남아 있습니다.
자세한 내용은 검사점 및 로그의 활성 부분을 참조하십시오.
로그 잘림을 차단하는 다른 요소가 없는 경우
일반적으로 정기적인 백업에서는 나중에 사용할 수 있도록 로그 공간을 정기적으로 확보합니다. 그러나 장기 실행 트랜잭션 같은 다양한 요소로 인해 로그 잘림이 일시적으로 차단될 수 있습니다. 자세한 내용은 로그 잘림을 지연시킬 수 있는 요소를 참조하십시오.
BACKUP LOG 문에서 WITH COPY_ONLY를 지정하지 않는 경우
트랜잭션 로그를 백업하려면
로그 잘림 작동 방법
[!참고]
잘라내기를 수행하더라도 물리 로그 파일의 크기는 줄어들지 않습니다. 로그 파일의 실제 크기를 줄이려면 파일을 축소해야 합니다. 물리 로그 파일의 크기를 축소하는 방법은 트랜잭션 로그 축소를 참조하십시오.
트랜잭션 로그는 순환 파일입니다. 데이터베이스가 생성될 때 물리 로그 파일의 시작 부분에서 논리 로그 파일이 시작됩니다. 새 로그 레코드는 논리 로그의 끝 부분에 추가되며 물리 로그의 끝 방향으로 확장됩니다. 데이터베이스의 트랜잭션 로그는 하나 이상의 물리 파일에 매핑됩니다. SQL Server 데이터베이스 엔진은 내부적으로 각 물리 로그 파일을 여러 개의 가상 로그 파일로 나눕니다. 로그 잘림은 논리 로그의 시작 부분에서 비활성 가상 로그 파일을 삭제하여 논리 로그의 공간을 확보합니다. 트랜잭션 로그 아키텍처에 대한 자세한 내용은 트랜잭션 로그 논리 아키텍처 및 트랜잭션 로그 물리 아키텍처를 참조하십시오.
가상 로그 파일은 다시 사용할 수 있는 공간 단위입니다. 비활성 로그 레코드가 포함된 가상 로그 파일만 자를 수 있습니다. 활성 로그는 데이터베이스 복구에 필요하기 때문에 트랜잭션 로그의 활성 부분인 활성 로그는 자를 수 없습니다. 가장 최근 검사점이 활성 로그를 정의하며 해당 검사점까지 로그를 자를 수 있습니다.
[!참고]
가상 로그 파일의 기능에 대한 자세한 내용은 트랜잭션 로그 물리 아키텍처를 참조하십시오.
검사점을 수행하면 트랜잭션 로그의 비활성 부분은 재사용 가능으로 표시됩니다. 그런 후에는 로그 잘림으로 비활성 부분에 대한 공간을 확보할 수 있습니다. 잘림을 수행하면 비활성 가상 로그 파일이 다시 사용할 수 있도록 공간이 확보됩니다. 결국 새 레코드를 공간이 확보된 가상 로그에 쓰면 해당 가상 로그 파일이 다시 활성화됩니다.
검사점에 기록되는 한 가지 정보는 성공적인 데이터베이스 차원의 롤백을 위해 반드시 있어야 하는 첫 번째 로그 레코드의 LSN(로그 시퀀스 번호)입니다. 이 LSN을 최소 복구 LSN(MinLSN)이라고 합니다. 로그 활성 부분의 시작은 MinLSN이 포함된 가상 로그입니다. 트랜잭션 로그를 자르면 이 가상 로그 파일 앞의 로그 레코드만 다시 사용할 수 있도록 공간이 확보됩니다.
다음 그림에서는 잘림 전과 후의 트랜잭션 로그를 보여 줍니다. 첫 번째 그림은 잘림이 수행되지 않은 트랜잭션 로그를 보여 줍니다. 현재 논리 로그에서 4개의 가상 로그 파일을 사용하고 있습니다. 논리 로그는 첫 번째 가상 로그 파일의 앞에서 시작하고 가상 로그 4에서 끝납니다. MinLSN 레코드는 가상 로그 3에 있습니다. 가상 로그 1과 가상 로그 2에는 비활성 로그 레코드만 포함되어 있습니다. 이러한 레코드는 자를 수 있습니다. 가상 로그 5는 사용하지 않았으며 현재 논리 로그에 포함되지 않습니다.
.gif "4개의 가상 로그가 있는 트랜잭션 로그")
두 번째 그림은 잘림 후의 로그 모습을 보여 줍니다. 가상 로그 1과 가상 로그 2는 다시 사용할 수 있도록 공간이 확보되었습니다. 이제 논리 로그는 가상 로그 3의 시작 부분에서 시작됩니다. 가상 로그 5는 아직 사용되지 않았으며 현재 논리 로그에 포함되지 않습니다.
.gif "4개의 가상 로그 파일로 나뉘어진 로그 파일")