트랜잭션 로그

  • 아티클

적용 대상:SQL Server

각 SQL Server 데이터베이스에는 각 트랜잭션에 의해 적용된 모든 트랜잭션 및 데이터베이스 수정 내용을 기록하는 트랜잭션 로그가 있습니다.

트랜잭션 로그는 데이터베이스의 중요한 구성 요소입니다. 시스템 오류가 발생한 경우 데이터베이스를 일관된 상태로 다시 전환하려면 이 로그가 필요합니다.

트랜잭션 로그 아키텍처 및 내부에 대한 자세한 내용은 SQL Server 트랜잭션 로그 아키텍처 및 관리 가이드를 참조하세요.

Warning

이 로그의 파급 효과를 완전히 이해하지 않는 한 이 로그를 삭제하거나 이동하지 마세요.

팁

데이터베이스 복구 중에 트랜잭션 로그 적용을 시작할 알려진 좋은 점은 검사점에 의해 만들어집니다. 자세한 내용은 데이터베이스 검사점(SQL Server)을 참조하세요.

트랜잭션 로그가 지원하는 작업

트랜잭션 로그는 다음 작업을 지원합니다.

  • 개별 트랜잭션 복구
  • SQL Server 시작 시 모든 불완전한 트랜잭션을 복구합니다.
  • 복원된 데이터베이스, 파일, 파일 그룹 또는 페이지를 오류 지점으로 롤포워드
  • 트랜잭션 복제 지원
  • 고가용성 및 재해 복구 솔루션 지원: AlwaysOn 가용성 그룹, 데이터베이스 미러링 및 로그 전달

개별 트랜잭션 복구

애플리케이션이 ROLLBACK 문을 실행하거나 데이터베이스 엔진이 클라이언트와의 통신이 끊어진 때와 같은 오류를 검색할 경우 불완전한 트랜잭션에 의해 수정된 내용을 롤백하는 데 이 로그 레코드가 사용됩니다.

SQL Server 시작 시 모든 불완전한 트랜잭션 복구

서버에 장애가 발생하면 데이터베이스에서 일부 수정 내용이 버퍼 캐시에서 데이터 파일로 옮겨지지 않을 수 있으며 데이터 파일에 불완전한 트랜잭션으로 인한 일부 수정 내용이 그대로 남아 있을 수 있습니다. SQL Server 인스턴스가 시작되면 각 데이터베이스의 복구를 실행합니다. 데이터 파일에 쓰여지지 않은 로그에 기록된 모든 수정 내용은 롤포워드됩니다. 그런 다음, 트랜잭션 로그에서 발견된 모든 불완전한 트랜잭션이 롤백되어 데이터베이스의 무결성이 유지되도록 합니다. 자세한 내용은 복원 및 복구 개요(SQL Server)를 참조하세요.

복원된 데이터베이스, 파일, 파일 그룹 또는 페이지를 오류 지점으로 롤포워드

데이터베이스 파일에 영향을 주는 하드웨어 손실이나 디스크 오류가 발생한 후 데이터베이스를 오류 발생 지점으로 복원할 수 있습니다. 먼저 마지막 전체 데이터베이스 백업 및 마지막 차등 데이터베이스 백업을 복원한 다음, 트랜잭션 로그 백업의 후속 시퀀스를 실패 지점으로 복원합니다.

각 로그 백업을 복원할 때 데이터베이스 엔진은 로그에 기록된 모든 수정 사항을 다시 적용하여 모든 트랜잭션을 롤포워드합니다. 마지막 로그 백업이 복원되면 데이터베이스 엔진은 로그 정보를 사용하여 해당 시점에 완료되지 않은 모든 트랜잭션을 롤백합니다. 자세한 내용은 복원 및 복구 개요(SQL Server)를 참조하세요.

트랜잭션 복제 지원

로그 판독기 에이전트는 트랜잭션 복제를 위해 구성한 각 데이터베이스의 트랜잭션 로그를 모니터링하고 복제 표시된 트랜잭션을 트랜잭션 로그에서 배포 데이터베이스로 복사합니다. 자세한 내용은 트랜잭션 복제 작동 방법을 참조하세요.

고가용성 및 재해 복구 솔루션 지원

대기 서버 솔루션, Alwayson 가용성 그룹, 데이터베이스 미러링 및 로그 전달은 트랜잭션 로그를 많이 사용합니다.

Always On 가용성 그룹 시나리오에서는 주 복제본의 데이터베이스에 대한 모든 업데이트가 모든 보조 복제본에 있는 별도의 데이터베이스 복사본에서 바로 재생성됩니다. 주 복제본은 각 로그 레코드를 즉시 보조 복제본으로 보내고, 보조 복제본은 들어오는 로그 레코드를 가용성 데이터베이스에 적용하고 지속적으로 로그를 롤포워드합니다. 자세한 내용은 Always On 장애 조치(failover) 클러스터 인스턴스를 참조하세요.

로그 전달 시나리오에서는 주 서버가 주 데이터베이스의 트랜잭션 로그 백업을 하나 이상의 대상으로 보냅니다. 각 보조 서버는 이 로그 백업을 로컬 보조 데이터베이스로 복원합니다. 자세한 내용은 로그 전달 정보를 참조하세요.

데이터베이스 미러링 시나리오에서는 주 데이터베이스에 대한 모든 업데이트 내용이 미러 데이터베이스인 데이터베이스의 전체 복사본에 즉시 재생성됩니다. 주 서버 인스턴스는 들어오는 로그 레코드를 미러 데이터베이스에 적용하여 지속적으로 롤포워드하는 미러 서버 인스턴스에 각 로그 레코드를 즉시 보냅니다. 자세한 내용은 데이터베이스 미러링을 참조하세요.

트랜잭션 로그 특성

SQL Server 데이터베이스 엔진 트랜잭션 로그의 특징:

  • 트랜잭션 로그는 데이터베이스에서 별도의 파일 또는 파일 집합으로 구현됩니다. 로그 캐시는 데이터 페이지의 버퍼 캐시와는 별도로 관리되므로 SQL Server 데이터베이스 엔진에 단순하고, 빠르고, 강력한 코드를 구현할 수 있습니다. 자세한 내용은 트랜잭션 로그 물리적 아키텍처를 참조하세요.

  • 로그 레코드 및 페이지의 형식은 데이터 페이지 형식을 따르도록 제한되지 않습니다.

  • 트랜잭션 로그는 여러 파일에서 구현할 수 있습니다. 트랜잭션 로그에 FILEGROWTH 값을 설정하여 자동으로 확장되도록 파일을 정의할 수 있습니다. 이를 통해 트랜잭션 로그에서 공간이 부족해질 확률이 줄어들며 동시에 관리 오버헤드가 줄어듭니다. 자세한 내용은 ALTER DATABASE(Transact-SQL) 파일 및 파일 그룹 옵션을 참조하세요.

  • 로그 파일 내에서 공간을 다시 사용하는 메커니즘은 빠르며 트랜잭션 처리량에 최소한의 영향을 미칩니다.

트랜잭션 로그 아키텍처 및 내부에 대한 자세한 내용은 SQL Server 트랜잭션 로그 아키텍처 및 관리 가이드를 참조하세요.

트랜잭션 로그 잘림

로그 잘림은 트랜잭션 로그에서 다시 사용할 수 있는 로그 파일의 공간을 확보합니다. 할당된 공간을 채우지 않도록 트랜잭션 로그를 정기적으로 잘라야 합니다. 여러 요인으로 인해 로그 잘림이 지연될 수 있으므로 로그 크기를 모니터링하는 것이 중요합니다. 일부 작업을 최소로 기록하여 트랜잭션 로그 크기에 주는 영향을 줄일 수 있습니다.

로그 잘림은 SQL Server 데이터베이스의 논리 트랜잭션 로그에서 비활성 가상 로그 파일(VLF)을 삭제하여 물리적 트랜잭션 로그에서 다시 사용할 수 있도록 논리 로그의 공간을 확보합니다. 트랜잭션 로그가 잘리지 않으면 결국 실제 로그 파일에 할당된 모든 디스크 공간이 채워집니다.

어떤 이유로 로그 잘림이 지연되지 않는 한 공간이 부족하지 않도록 하려면 다음 이벤트 후에 잘림이 자동으로 발생합니다.

  • 단순 복구 모델에서 검사점 뒤
  • 전체 복구 모델 또는 대량 로그된 복구 모델에서 이전 백업 이후 검사점이 발생한 경우 로그 백업 후에 잘림이 발생합니다(복사 전용 로그 백업이 아닌 경우).
  • FULL 복구 모델을 사용하여 데이터베이스를 처음 만드는 경우 필요에 따라 전체 데이터베이스 백업을 만들 때까지 트랜잭션 로그가 다시 사용됩니다(SIMPLE 복구 데이터베이스와 유사).

자세한 내용은 이 문서 뒷부분에 나오는 로그 잘림을 지연시킬 수 있는 요소를 참조하세요.

참고 항목

로그 잘림을 수행하더라도 물리적 로그 파일의 크기는 줄어들지 않습니다. 실제 로그 파일의 크기를 줄이려면 로그 파일을 축소해야 합니다. 실제 로그 파일의 크기를 줄이는 방법에 대한 자세한 내용은 트랜잭션 로그 파일의 크기 관리를 참조하세요.
그러나 로그 잘림을 지연시킬 수 있는 요소에 유의하세요. 로그 축소 후 스토리지 공간이 다시 필요하면 트랜잭션 로그가 다시 커지고 로그 증가 작업 중에 성능 오버헤드가 발생합니다.

로그 잘림을 지연시킬 수 있는 요소

로그 레코드가 오랜 시간 동안 활성 상태로 유지되면 이 문서의 앞부분에서 언급한 것처럼 트랜잭션 로그 잘림이 지연되고 트랜잭션 로그가 가득 찰 수 있습니다.

Important

가득 찬 트랜잭션 로그에 응답하는 방법에 대한 자세한 내용은 전체 트랜잭션 로그 문제 해결(SQL Server 오류 9002)을 참조하세요.

실제로 로그 잘림은 여러 가지 이유로 지연될 수 있습니다. sys.databases 카탈로그 뷰의 log_reuse_wait 및 log_reuse_wait_desc 열을 쿼리하여 로그 잘림을 방지하는 것이 무엇인지 알아봅니다. 다음 표에서는 이러한 열 값에 대해 설명합니다.

log_reuse_wait 값 log_reuse_wait_desc 값 설명
0 NOTHING 현재 하나 이상의 재사용 가능한 VLF(가상 로그 파일)가 있습니다.
1 CHECKPOINT 마지막 로그 잘림 이후 검사점이 발생하지 않았거나 로그의 헤드가 아직 VLF(가상 로그 파일) 이상으로 이동하지 않았습니다. (모든 복구 모델)

이는 로그 잘림을 지연시키는 일반적인 이유입니다. 자세한 내용은 데이터베이스 검사점(SQL Server)을 참조하세요.
2 LOG_BACKUP 트랜잭션 로그를 자르려면 먼저 로그 백업이 필요합니다. (전체 또는 대량 로그된 복구 모델만 해당)

다음 로그 백업이 완료되면 일부 로그 공간을 재사용할 수 있습니다.
3 ACTIVE_BACKUP_OR_RESTORE 데이터 백업 또는 복원이 진행 중입니다(모든 복구 모델).

데이터 백업이 로그 잘림을 방지하는 경우 백업 작업을 취소하면 즉각적인 문제가 발생할 수 있습니다.
4 ACTIVE_TRANSACTION 트랜잭션이 활성 상태입니다(모든 복구 모델).

로그 백업을 시작할 때 장기 실행 트랜잭션이 있을 수 있습니다. 이 경우 공간을 확보하려면 다른 로그 백업이 필요할 수 있습니다. 장기 실행 트랜잭션은 트랜잭션 로그가 일반적으로 각 자동 검사점에서 잘리는 단순 복구 모델을 비롯한 모든 복구 모델에서 로그 잘림을 방지합니다.

트랜잭션이 지연됩니다. 지연된 트랜잭션은 사용할 수 없는 리소스로 인해 롤백이 차단되는 활성 트랜잭션입니다. 지연된 트랜잭션의 원인 및 이러한 트랜잭션을 지연된 상태에서 벗어나게 하는 방법에 대한 자세한 내용은 지연된 트랜잭션(SQL Server)을 참조하세요.

장기 실행 트랜잭션은 tempdb의 트랜잭션 로그를 채울 수도 있습니다. Tempdb는 정렬을 위한 작업 테이블, 해시용 작업 파일, 커서 작업 테이블 및 행 버전 관리와 같은 내부 개체에 대한 사용자 트랜잭션에서 암시적으로 사용됩니다. 사용자 트랜잭션에 데이터 읽기(SELECT 쿼리)만 포함되더라도 내부 개체를 만들고 사용자 트랜잭션에서 사용할 수 있습니다. 그런 다음, tempdb 트랜잭션 로그를 채울 수 있습니다.
5 DATABASE_MIRRORING 데이터베이스 미러링이 일시 중지되거나 성능 우선 모드에서는 미러 데이터베이스가 주 데이터베이스보다 훨씬 (전체 복구 모델만 해당)

자세한 내용은 데이터베이스 미러링(SQL Server)을 참조하세요.
6 복제 트랜잭션 복제 중에 게시와 관련된 트랜잭션은 여전히 배포 데이터베이스에 배달되지 않습니다. (전체 복구 모델만 해당)

트랜잭션 복제에 대한 자세한 내용은 SQL Server Replication를 참조하십시오.
7 DATABASE_SNAPSHOT_CREATION 데이터베이스 스냅샷이 만들어지고 있습니다. (모든 복구 모델)

이는 로그 잘림 지연의 일상적이고 일반적으로 간단한 원인입니다.
8 LOG_SCAN 로그 검색이 발생합니다. (모든 복구 모델)

이는 로그 잘림 지연의 일상적이고 일반적으로 간단한 원인입니다.
9 AVAILABILITY_REPLICA 가용성 그룹의 보조 복제본에서 해당하는 보조 데이터베이스에 이 데이터베이스의 트랜잭션 로그 레코드를 적용합니다. (전체 복구 모델)

자세한 내용은 Always On 가용성 그룹 개요(SQL Server)를 참조하세요.
10 - 내부 전용
11 - 내부 전용
12 - 내부 전용
13 OLDEST_PAGE 데이터베이스가 간접 검사점을 사용하도록 구성된 경우 데이터베이스에서 가장 오래된 페이지는 검사점 LSN(로그 시퀀스 번호)보다 오래되었을 수 있습니다. 이 경우 가장 오래된 페이지는 로그 잘림이 지연될 수 (모든 복구 모델)

간접 검사점에 대한 자세한 내용은 데이터베이스 검사점(SQL Server)을 참조하세요.
14 OTHER_TRANSIENT 이 값은 현재 사용되지 않습니다.
16 XTP_CHECKPOINT 메모리 내 OLTP 검사점을 수행해야 합니다. 메모리 최적화 테이블의 경우 마지막 검사점 이후 트랜잭션 로그 파일이 1.5GB보다 커지면 자동 검사점이 수행됩니다(디스크 기반 테이블과 메모리 최적화 테이블 모두 포함).
자세한 내용은 메모리 최적화 테이블의 검사점 작업 및 [메모리 내 최적화 테이블의 로깅 및 검사점 프로세스](https://blogs.msdn.microsoft.com/sqlcat/2016/05/20/logging-and-checkpoint-process-for-memory-optimized-tables-2/)를 참조하세요.

최소한으로 로깅할 수 있는 작업

최소 로깅에는 지정 시간 복구를 지원하지 않고 트랜잭션을 복구하는 데 필요한 정보만 로깅하는 작업이 포함됩니다. 이 문서에서는 대량 로그된 복구 모델 및 단순 복구 모델(백업이 실행 중인 경우 제외)에서 최소 로깅되는 작업을 식별합니다.

참고 항목

메모리 최적화 테이블에는 최소 로깅이 지원되지 않습니다.

참고 항목

전체 복구 모델에서는 모든 대량 작업을 완전히 기록합니다. 그러나 대량 작업에 대해 일시적으로 데이터베이스를 대량 로그 복구 모델로 전환하여 대량 작업 집합의 로깅을 최소화할 수 있습니다. 최소 로깅은 전체 로깅보다 효율적이며 대량 트랜잭션 중에 사용 가능한 트랜잭션 로그 공간을 채우는 대규모 대량 작업의 가능성을 줄입니다. 그러나 최소 로깅을 적용 중일 때 데이터베이스가 손상 또는 손실되는 경우 데이터베이스를 실패 지점으로 복구할 수 없습니다.

전체 복구 모델에서 완전히 기록되는 다음 작업은 단순 및 대량 로그된 복구 모델에서 최소로 로깅됩니다.

트랜잭션 복제를 사용하는 경우 대량 로그 복구 모델에서도 BULK INSERT 작업이 모두 기록됩니다.

트랜잭션 복제를 사용하는 경우 대량 로그 복구 모델에서도 SELECT INTO 작업이 모두 기록됩니다.

  • 새 데이터를 삽입 또는 추가할 때 UPDATE 문의 .WRITE 절을 사용하여 큰 값 데이터 형식을 부분적으로 업데이트하는 작업. 기존 값이 업데이트되면 최소 로깅이 사용되지 않습니다. 큰 값 데이터 형식에 대한 자세한 내용은 데이터 형식(Transact-SQL)을 참조하세요.

  • text, ntext 및 image 데이터 형식 열에 새 데이터를 삽입하거나 추가할 때 WRITETEXT 및 UPDATETEXT 문 기존 값이 업데이트되면 최소 로깅이 사용되지 않습니다.

    Warning

    WRITETEXT 및 UPDATETEXT 문은 더 이상 사용되지 않으므로 새 애플리케이션에서 사용하지 마세요.

  • 데이터베이스가 단순 또는 대량 로그된 복구 모델로 설정된 경우 작업이 오프라인 또는 온라인으로 실행되는지 여부에 관계없이 일부 인덱스 DDL 작업이 최소로 로깅됩니다. 최소 로깅된 인덱스 작업은 다음과 같습니다.

    • CREATE INDEX 작업(인덱싱된 뷰 포함)

    • ALTER INDEX REBUILD 또는 DBCC DBREINDEX 작업

      Warning

      DBCC DBREINDEX 문은 더 이상 사용되지 않습니다. 새 애플리케이션에서 사용하지 마세요.

      참고 항목

      인덱스 빌드 작업은 최소 로깅을 사용하지만 동시에 실행되는 백업이 있는 경우 지연될 수 있습니다. 이 지연은 단순 또는 대량 로그된 복구 모델을 사용할 때 최소 로깅된 버퍼 풀 페이지의 동기화 요구 사항으로 인해 발생합니다.

    • DROP INDEX 새 힙 다시 빌드(해당하는 경우) DROP INDEX 작업 중의 인덱스 페이지 할당 취소는 항상 모두 로깅됩니다.

관련 작업

트랜잭션 로그 관리

트랜잭션 로그 백업(전체 복구 모델)

트랜잭션 로그 복원(전체 복구 모델)

참고 항목