각 SQL Server 데이터베이스에는 각 트랜잭션에 의해 적용된 모든 트랜잭션 및 데이터베이스 수정 내용을 기록하는 트랜잭션 로그가 있습니다. 트랜잭션 로그가 가득 차지 않도록 정기적으로 잘라내야 합니다. 그러나 일부 요인은 로그 잘림을 지연할 수 있으므로 로그 크기를 모니터링하는 것이 중요합니다. 일부 작업을 최소로 기록하여 트랜잭션 로그 크기에 주는 영향을 줄일 수 있습니다.
트랜잭션 로그는 데이터베이스의 중요한 구성 요소이며 시스템 오류가 있는 경우 데이터베이스를 일관된 상태로 되돌리기 위해 트랜잭션 로그가 필요할 수 있습니다. 트랜잭션 로그를 삭제하거나 이동하기 전에 이를 수행했을 때 발생할 결과를 완전히 이해해야 합니다.
비고
데이터베이스 복구 중에 트랜잭션 로그 적용을 시작할 알려진 좋은 점은 검사점에 의해 만들어집니다. 자세한 내용은 데이터베이스 검사점(SQL Server)을 참조하세요.
항목 내용
이점: 트랜잭션 로그에서 지원하는 작업
트랜잭션 로그는 다음 작업을 지원합니다.
개별 트랜잭션의 복구.
SQL Server 시작 시 모든 불완전한 트랜잭션을 복구합니다.
복원된 데이터베이스, 파일, 파일 그룹 또는 페이지를 오류 지점으로 롤포워드
트랜잭션 복제 지원
고가용성 및 재해 복구 솔루션 지원: Always On 가용성 그룹, 데이터베이스 미러링 및 로그 전달.
트랜잭션 로그 잘림
로그 잘림은 트랜잭션 로그에서 다시 사용할 수 있는 로그 파일의 공간을 확보합니다. 로그 잘림은 로그가 채워지지 않도록 하는 데 필수적입니다. 로그 잘림은 SQL Server 데이터베이스의 논리 트랜잭션 로그에서 비활성 가상 로그 파일을 삭제하여 물리적 트랜잭션 로그에서 다시 사용할 수 있는 논리 로그의 공간을 확보합니다. 트랜잭션 로그가 잘리지 않으면 결국 실제 로그 파일에 할당된 모든 디스크 공간을 채웁니다.
이 문제를 방지하기 위해 어떤 이유로 로그 잘림이 지연되지 않는 한 다음 이벤트 후에 잘림이 자동으로 발생합니다.
단순 복구 모델에서 검사점 뒤
전체 복구 모델 또는 대량 로그 복구 모델에서는 이전 백업 후에 검사점이 발생한 경우, 로그 백업 후에 로그 잘림이 발생합니다 (복사 전용 로그 백업은 예외입니다).
자세한 내용은 이 항목 의 뒷부분에 있는 로그 잘림을 지연할 수 있는 요인을 참조하세요.
비고
로그 잘림은 실제 로그 파일의 크기를 줄이지 않습니다. 실제 로그 파일의 물리적 크기를 줄이려면 로그 파일을 축소해야 합니다. 실제 로그 파일의 크기를 줄이는 방법에 대한 자세한 내용은 트랜잭션 로그 파일의 크기 관리를 참조하세요.
로그 잘림을 지연할 수 있는 요소
로그 레코드가 오랫동안 활성 상태로 유지되면 트랜잭션 로그 잘림이 지연되고 잠재적으로 트랜잭션 로그가 채워질 수 있습니다.
중요합니다
전체 트랜잭션 로그에 응답하는 방법에 대한 자세한 내용은 전체 트랜잭션 로그 문제 해결(SQL Server 오류 9002)을 참조하세요.
로그 축소는 다양한 요인에 의해 지연될 수 있습니다. sys.databases 카탈로그 뷰의 log_reuse_wait 및 log_reuse_wait_desc 열을 쿼리하여 로그 잘림을 방지하는 항목을 검색할 수 있습니다. 다음 표에서는 이러한 열 값에 대해 설명합니다.
| log_reuse_wait 값 | log_reuse_wait_desc 값 | 설명 |
|---|---|---|
| 0 | 아무것도 | 현재 재사용 가능한 가상 로그 파일이 하나 이상 있습니다. |
| 1 | 점검 지점 | 마지막 로그 잘림 이후 검사점이 발생하지 않았거나 로그의 헤드가 아직 가상 로그 파일 이상으로 이동되지 않았습니다. (모든 복구 모델) 이는 로그 잘림을 지연시키는 일반적인 이유입니다. 자세한 내용은 데이터베이스 검사점(SQL Server)을 참조하세요. |
| 2 | 로그 백업 | 트랜잭션 로그를 자르려면 먼저 로그 백업이 필요합니다. (전체 또는 대량 로그된 복구 모델만 해당) 다음 로그 백업이 완료되면 일부 로그 공간을 재사용할 수 있습니다. |
| 3 | 활성 백업 또는 복구 | 데이터 백업 또는 복원이 진행 중입니다(모든 복구 모델). 데이터 백업이 로그 잘림을 방지하는 경우 백업 작업을 취소하면 즉각적인 문제가 발생할 수 있습니다. |
| 4 | 활성화된 거래 | 트랜잭션이 활성화되어 있습니다(모든 복구 모델). 로그 백업을 시작할 때 장기 실행 트랜잭션이 있을 수 있습니다. 이 경우 공간을 확보하려면 다른 로그 백업이 필요할 수 있습니다. 장기 실행 중인 트랜잭션은 트랜잭션 로그가 일반적으로 각 자동 검사점에서 절단되는 단순 복구 모델을 포함한 모든 복구 모델에서 로그 절단을 방지합니다. 트랜잭션이 지연됩니다. 지연된 트랜잭션은 사용할 수 없는 리소스로 인해 롤백이 차단되는 활성 트랜잭션입니다. 지연된 트랜잭션의 원인 및 이러한 트랜잭션을 지연된 상태에서 벗어나게 하는 방법에 대한 자세한 내용은 지연된 트랜잭션(SQL Server)을 참조하세요. 장기 실행 트랜잭션은 tempdb의 트랜잭션 로그를 채울 수도 있습니다. Tempdb는 정렬을 위한 작업 테이블, 해시용 작업 파일, 커서 작업 테이블 및 행 버전 관리와 같은 내부 개체에 대한 사용자 트랜잭션에서 암시적으로 사용됩니다. 사용자 트랜잭션에 데이터 읽기(SELECT 쿼리)만 포함되더라도 내부 개체를 만들고 사용자 트랜잭션에서 사용할 수 있습니다. 그런 다음 tempdb 트랜잭션 로그를 채울 수 있습니다. |
| 5 | 데이터베이스 미러링 | 데이터베이스 미러링이 일시 중지되거나 성능 우선 모드에서는 미러 데이터베이스가 주 데이터베이스보다 훨씬 (전체 복구 모델만 해당) 자세한 내용은 데이터베이스 미러링(SQL Server)을 참조하세요. |
| 6 | 복제 | 트랜잭션 복제 중에 게시와 관련된 트랜잭션은 여전히 배포 데이터베이스에 배달되지 않습니다. (전체 복구 모델만 해당) 트랜잭션 복제에 대한 자세한 내용은 SQL Server Replication를 참조하십시오. |
| 7 | 데이터베이스 스냅샷 생성 | 데이터베이스 스냅샷이 만들어지고 있습니다. (모든 복구 모델) 이는 로그 잘림 지연의 일상적이고 일반적으로 간단한 원인입니다. |
| 8 (여덟) | 로그_스캔 | 로그 스캔이 진행 중입니다. (모든 복구 모델) 이는 로그 잘림 지연의 일상적이고 일반적으로 간단한 원인입니다. |
| 9 | 고가용성_복제본 | 가용성 그룹의 보조 복제본에서 해당하는 보조 데이터베이스에 이 데이터베이스의 트랜잭션 로그 레코드를 적용합니다. (전체 복구 모델) 자세한 내용은 AlwaysOn 가용성 그룹 개요(SQL Server)를 참조하세요. |
| 10 | - | 내부 전용 |
| 11 | - | 내부 전용 |
| 12 | - | 내부 전용 |
| 13 | 가장 오래된 페이지 | 데이터베이스가 간접 검사점을 사용하도록 구성된 경우 데이터베이스에서 가장 오래된 페이지가 검사점 LSN보다 오래되었을 수 있습니다. 이 경우 가장 오래된 페이지는 로그 잘림을 지연할 수 있습니다. (모든 복구 모델) 간접 검사점에 대한 자세한 내용은 데이터베이스 검사점(SQL Server)을 참조하세요. |
| 14 | 기타 일시적 | 이 값은 현재 사용되지 않습니다. |
| 16 | XTP_CHECKPOINT | 데이터베이스에 메모리 최적화 파일 그룹이 있는 경우 자동 In-Memory OLTP 검사점이 트리거될 때까지 트랜잭션 로그가 잘리지 않을 수 있습니다(로그 증가 512MB마다 발생). 참고: 트랜잭션 로그를 512MB 크기 이전에 자르려면 해당 데이터베이스에 대해 검사점 명령을 수동으로 실행합니다. |
최소 로깅할 수 있는 작업
최소 로깅에는 지정 시간 복구를 지원하지 않고 트랜잭션을 복구하는 데 필요한 정보만 로깅하는 작업이 포함됩니다. 이 항목에서는 백업이 실행되는 경우를 제외하고 단순 복구 모델뿐만 아니라 대량 로그 복구 모델에서 최소로 기록되는 작업을 식별합니다.
비고
메모리 최적화 테이블에는 최소 로깅이 지원되지 않습니다.
비고
전체 복구 모델에서는 모든 대량 작업이 완전히 기록됩니다. 그러나 대량 작업에 대해 일시적으로 데이터베이스를 대량 로그 복구 모델로 전환하여 대량 작업 집합의 로깅을 최소화할 수 있습니다. 최소 로깅은 전체 로깅보다 효율적이며 대량 트랜잭션 중에 사용 가능한 트랜잭션 로그 공간을 채우는 대규모 대량 작업의 가능성을 줄입니다. 그러나 최소 로깅이 적용될 때 데이터베이스가 손상되거나 손실된 경우 실패 지점까지 데이터베이스를 복구할 수 없습니다.
전체 복구 모델에서 완전히 기록되는 다음 작업은 단순 및 대량 로그된 복구 모델에서 최소로 로깅됩니다.
대량 가져오기 작업(bcp, BULK INSERT 및 INSERT... SELECT). 테이블로 대량 가져오기가 최소로 기록되는 경우에 대한 자세한 내용은 대량 가져오기에서 최소 로깅을 위한 필수 조건을 참조하세요.
비고
트랜잭션 복제를 사용하도록 설정하면 대량 로그 복구 모델에서도 BULK INSERT 작업이 완전히 기록됩니다.
SELECT INTO 작업.
비고
트랜잭션 복제를 사용하도록 설정하면 대량 로그 복구 모델에서도 SELECT INTO 작업이 완전히 로깅됩니다.
큰 값 데이터 형식의 부분 업데이트는 새 데이터를 삽입하거나 추가할 때 UPDATE 문의 WRITE 절을 이용합니다. 기존 값을 업데이트할 때는 최소 로깅이 사용되지 않습니다. 큰 값 데이터 형식에 대한 자세한 내용은 데이터 형식(Transact-SQL)을 참조하세요.
WRITETEXT 및 UPDATETEXT 문은
text,ntext, 및image데이터 형식 열에 새 데이터를 삽입하거나 추가할 때 사용됩니다. 기존 값을 업데이트할 때는 최소 로깅이 사용되지 않습니다.비고
WRITETEXT 및 UPDATETEXT 문은 더 이상 사용되지 않으므로 새 애플리케이션에서 사용하지 않도록 해야 합니다.
데이터베이스가 단순 또는 대량 로그된 복구 모델로 설정된 경우 작업이 오프라인 또는 온라인으로 실행되는지 여부에 관계없이 일부 인덱스 DDL 작업이 최소로 로깅됩니다. 최소 로깅된 인덱스 작업은 다음과 같습니다.
CREATE INDEX 작업(인덱싱된 뷰 포함)
ALTER INDEX REBUILD 또는 DBCC DBREINDEX 작업.
비고
DBCC DBREINDEX 문은 더 이상 사용되지 않으므로 새 애플리케이션에서 사용하지 않아야 합니다.
DROP INDEX 새 힙 다시 빌드(해당하는 경우).
비고
DROP INDEX 작업 중 인덱스 페이지 할당 취소는 항상 완전히 로깅됩니다.
관련 작업
Managing the transaction log
트랜잭션 로그 백업(전체 복구 모델)
트랜잭션 로그 복원(전체 복구 모델)
또한 참조하십시오
트랜잭션 내구성 제어
대량 가져오기에서 최소 로깅을 위한 필수 구성 요소
SQL Server 데이터베이스 백업 및 복원
데이터베이스 검사점(SQL Server)
데이터베이스의 속성 보기 또는 변경
복구 모델(SQL Server)