로그 잘림을 지연시킬 수 있는 요소
업데이트: 2006년 7월 17일
로그 잘림은 트랜잭션 로그에서 재사용할 수 있도록 로그 파일의 공간을 해제합니다. 로그의 활성 부분은 축소하여 자르거나 제거할 수 없으므로 로그 레코드가 오랫동안 활성 상태로 유지되면 잘림이 지연될 수 있습니다.
[!참고] 로그 잘림 작동 방식에 대한 자세한 내용은 트랜잭션 로그 잘림을 참조하십시오.
로그 레코드는 이 항목에서 설명하는 여러 상황에서 활성 상태로 유지됩니다. sys.databases 카탈로그 뷰의 log_reuse_wait 및 log_reuse_wait_desc 열을 사용하면 로그 잘림을 막는 요인을 알아낼 수 있습니다.
[!참고] 장기 실행 트랜잭션이나 일시 중지된 데이터베이스 미러링 세션과 같은 일부 요소로 인해 트랜잭션 로그가 꽉 찰 수 있습니다. 트랜잭션 로그가 꽉 찬 경우의 처리 방법은 꽉 찬 트랜잭션 로그 문제 해결(오류 9002)를 참조하십시오.
다음 표에서는 sys.database 카탈로그 뷰의 log_reuse_wait 열과 log_reuse_wait_desc 열의 값을 설명합니다.
log_reuse_wait 값
log_reuse_wait_desc 값
설명
0
NOTHING
현재 재사용 가능한 가상 로그 파일이 한 개 이상 있습니다.
1
CHECKPOINT
마지막 로그 잘림이나 로그 헤더가 가상 로그 파일을 넘어서 이동되지 않았기 때문에 검사점이 발생하지 않았습니다(모든 복구 모델).
로그 잘림 지연을 유발하는 일반적인 이유입니다. 자세한 내용은 검사점 및 로그의 활성 부분을 참조하십시오.
2
LOG_BACKUP
로그의 헤더를 앞으로 이동하기 위해 로그 백업이 필요합니다(전체 또는 대량 로그 복구 모델에만 해당).
.gif "ms345414.note(ko-kr,SQL.90).gif")
참고:
로그 백업은 잘림을 차단하지 않습니다.
로그 백업이 완료되면 로그 헤더가 앞으로 이동하며 일부 로그 공간을 재사용할 수 있게 됩니다.
3
ACTIVE_BACKUP_OR_RESTORE
데이터 백업이나 복원이 진행되고 있습니다(모든 복구 모델).
데이터 백업은 활성 트랜잭션처럼 동작하며 실행 시 잘림을 방지합니다. 자세한 내용은 이 항목의 뒷부분에 나오는 "데이터베이스 백업 작업 및 복원 작업"을 참조하십시오.
4
ACTIVE_TRANSACTION
트랜잭션이 활성 상태입니다(모든 복구 모델).
- 로그 백업 시작 부분에 장기 실행 트랜잭션이 있을 수 있습니다. 이 경우 공간을 해제하려면 다른 로그 백업이 필요할 수 있습니다. 자세한 내용은 이 항목의 뒷부분에 나오는 "장기 실행 활성 트랜잭션"을 참조하십시오.
- 트랜잭션이 지연됩니다(SQL Server 2005 Enterprise Edition 이상 버전만 해당). 지연된 트랜잭션은 일부 사용할 수 없는 리소스 때문에 롤백이 차단된 활성 트랜잭션입니다. 지연된 트랜잭션의 원인 및 지연된 상태에서 빠져나가는 방법에 대한 자세한 내용은 지연된 트랜잭션을 참조하십시오.
5
DATABASE_MIRRORING
데이터베이스 미러링이 일시 중지되거나 성능 우선 모드에서는 미러 데이터베이스가 주 데이터베이스보다 훨씬 뒤처집니다(전체 복구 모델에만 해당).
자세한 내용은 이 항목의 뒷부분에 나오는 "데이터베이스 미러링 및 트랜잭션 로그"를 참조하십시오.
6
REPLICATION
트랜잭션 복제 중에 게시와 관련된 트랜잭션이 배포 데이터베이스로 배달되지 않습니다(전체 복구 모델에만 해당).
자세한 내용은 이 항목의 뒷부분에 나오는 "트랜잭션 복제 및 트랜잭션 로그"를 참조하십시오.
7
DATABASE_SNAPSHOT_CREATION
데이터베이스 스냅숏이 생성되고 있습니다(모든 복구 모델).
로그 잘림 지연을 유발하는 일반적인 이유입니다.
8
LOG_SCAN
로그 검색이 수행되고 있습니다(모든 복구 모델).
로그 잘림 지연을 유발하는 일반적인 이유입니다.
9
OTHER_TRANSIENT
이 값은 현재 사용되지 않습니다.
데이터 백업 작업 및 복원 작업
백업이나 복원 작업 중에는 로그 잘림이 발생할 수 없습니다. SQL Server 2005 이상 버전에서는 데이터 백업 중에 로그 백업이 수행될 수 있습니다. 그러나 데이터 백업 작업에서 모든 트랜잭션 로그를 사용할 수 있어야 하므로 이러한 로그 백업 중에는 로그 잘림이 발생할 수 없습니다. 데이터 백업으로 인해 로그 잘림이 발생하지 않을 경우 해당 백업을 취소하면 즉시 문제를 해결할 수 있습니다 파일 백업을 수행할 때 WITH NO_LOG를 사용하면 로그 잘림이 되지 않는 문제를 해결할 수 있습니다.
로그 잘림에 대한 자세한 내용은 트랜잭션 로그 잘림을 참조하십시오.
| 중요: |
|---|
| BACKUP LOG 문의 NO_LOG 옵션과 TRUNCATE_ONLY 옵션은 이후 버전의 SQL Server에서 제거될 예정입니다. 이러한 옵션은 로그의 백업 복사본을 만들지 않고 비활성 부분을 제거하고 활성 로그를 제외한 모든 부분을 삭제하여 로그를 자릅니다. 이 경우 로그 체인이 끊어집니다. 다음 전체 또는 차등 데이터베이스 백업 시까지 미디어 오류로부터 데이터베이스가 보호되지 않습니다. 따라서 새 개발 작업에서는 두 옵션의 사용을 피하고 현재 두 옵션을 사용하는 응용 프로그램은 수정하는 것이 좋습니다. |
장기 실행 활성 트랜잭션
활성 트랜잭션은 해당 로그가 트랜잭션의 시작 부분이 포함된 로그 레코드부터 활성 상태여야 합니다. 예를 들어 트랜잭션의 시작과 끝을 사용자가 제어하는 경우에는 대개 사용자가 트랜잭션을 시작한 후 트랜잭션에서 사용자의 응답을 기다리는 동안 자리를 비울 때 장기 실행 트랜잭션이 발생합니다. 이 경우 대기 중인 트랜잭션은 로그를 거의 생성하지 않지만 로그 잘림을 방해하여 로그가 커집니다.
[!참고] 장기 실행 트랜잭션을 방지하는 방법은 효율적인 트랜잭션 코딩을 참조하십시오.
데이터베이스 미러링 및 트랜잭션 로그
데이터베이스 미러링을 사용하려면 주 서버 인스턴스가 미러 서버 인스턴스로부터 미러 서버의 디스크에 레코드가 기록되었다는 알림을 받을 때까지 각 로그 레코드가 활성 상태여야 합니다. 미러 서버 인스턴스가 주 서버 인스턴스보다 뒤처지면 그만큼 활성 로그 공간도 증가합니다. 이 경우 데이터베이스 미러링을 중지하고 로그를 자르는 로그 백업을 수행한 다음 해당 로그 백업을 미러 데이터베이스에 적용하고(WITH NORECOVERY 사용) 미러링을 다시 시작해야 할 수 있습니다.
| 중요: |
|---|
| 또한 미러링을 시작하려면 필수 로그 백업 후에 추가 로그 백업이 수행된 경우 추가 로그 백업도 모두 수동으로 적용해야 합니다(항상 WITH NORECOVERY 사용). 최신 로그 백업을 적용한 후 미러링을 시작할 수 있습니다. |
자세한 내용은 데이터베이스 미러링 제거 및 데이터베이스 미러링 설정을 참조하십시오.
트랜잭션 복제 및 트랜잭션 로그
병합 복제 및 스냅숏 복제는 트랜잭션 로그 크기에 영향을 주지 않지만 트랜잭션 복제는 영향을 줄 수 있습니다. 데이터베이스에 트랜잭션 게시가 한 개 이상 있는 경우 게시와 관련된 모든 트랜잭션이 배포 데이터베이스에 배달되기 전까지 로그는 잘리지 않습니다. 트랜잭션 로그가 지나치게 커지고 로그 판독기 에이전트가 일정에 따라 실행되는 경우 일정 실행 간격을 좁히거나 연속 모드에서 실행되도록 설정하십시오. 연속 모드에서 실행되도록 설정(기본값)한 경우 로그 판독기 에이전트가 실행되고 있는지 확인하십시오. 로그 판독기 에이전트의 상태를 확인하는 방법은 방법: 게시 관련 에이전트에 대한 정보 보기 및 작업 수행(복제 모니터)을 참조하십시오.
또한 게시 데이터베이스나 배포 데이터베이스에서 'sync with backup' 옵션을 설정한 경우 트랜잭션이 모두 백업될 때까지 트랜잭션 로그가 잘리지 않습니다. 이 옵션을 설정한 경우 트랜잭션 로그가 너무 방대해지면 트랜잭션 로그 백업 간격을 좁히십시오. 트랜잭션 복제와 관련된 데이터베이스 백업 및 복원 방법은 스냅숏 및 트랜잭션 복제의 백업 및 복원을 위한 전략을 참조하십시오.
복제를 관리하려면
복제를 모니터링하려면
참고 항목
개념
검사점 및 로그의 활성 부분
트랜잭션 로그 잘림
트랜잭션 로그 축소
꽉 찬 트랜잭션 로그 문제 해결(오류 9002)