로그 잘림을 지연시킬 수 있는 요소
로그 잘림은 트랜잭션 로그 파일에서 다시 사용할 수 있도록 로그 파일의 공간을 확보하는 것입니다. 로그의 활성 부분은 축소하여 자르거나 제거할 수 없으므로 로그 레코드가 오랫동안 활성 상태로 유지되면 잘림이 지연될 수 있습니다.
[!참고]
로그 잘림 작동 방식에 대한 자세한 내용은 트랜잭션 로그 잘림을 참조하십시오.
로그 레코드는 이 항목에서 설명하는 여러 조건에서 활성 상태로 유지할 수 있습니다. 로그 잘림이 발생하지 않는 이유는 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 "참고") 참고
로그 백업은 잘림을 허용합니다.
로그 백업을 완료할 때 로그 헤더는 앞으로 이동하여 일부 로그 공간이 다시 사용될 수 있습니다. |
3 |
ACTIVE_BACKUP_OR_RESTORE |
데이터 백업이나 복원이 진행되고 있습니다(모든 복구 모델). 데이터 백업은 활성 트랜잭션처럼 동작하며 실행 시 잘림을 방지합니다. 자세한 내용은 이 항목의 뒷부분에 나오는 "데이터베이스 백업 작업 및 복원 작업"을 참조하십시오. |
4 |
ACTIVE_TRANSACTION |
트랜잭션이 활성 상태입니다(모든 복구 모델).
|
5 |
DATABASE_MIRRORING |
데이터베이스 미러링이 일시 중지되거나 성능 우선 모드에서는 미러 데이터베이스가 주 데이터베이스보다 훨씬 뒤처집니다(전체 복구 모델에만 해당). 자세한 내용은 이 항목의 뒷부분에 나오는 "데이터베이스 미러링 및 트랜잭션 로그"를 참조하십시오. |
6 |
REPLICATION |
트랜잭션 복제 중에 게시와 관련된 트랜잭션이 배포 데이터베이스로 배달되지 않습니다(전체 복구 모델에만 해당). 자세한 내용은 이 항목의 뒷부분에 나오는 "트랜잭션 복제 및 트랜잭션 로그"를 참조하십시오. |
7 |
DATABASE_SNAPSHOT_CREATION |
데이터베이스 스냅숏이 생성되고 있습니다(모든 복구 모델). 로그 잘림 지연을 유발하는 일반적인 이유입니다. |
8 |
LOG_SCAN |
로그 검색이 수행되고 있습니다(모든 복구 모델). 로그 잘림 지연을 유발하는 일반적인 이유입니다. |
9 |
OTHER_TRANSIENT |
이 값은 현재 사용되지 않습니다. |
데이터 백업 작업 및 복원 작업
백업이나 복원 작업 중에는 로그 잘림이 발생할 수 없습니다. SQL Server 2005 이상 버전에서는 데이터 백업 중에 로그 백업이 발생할 수 있습니다. 그러나 데이터 백업 작업에서 모든 트랜잭션 로그를 사용할 수 있어야 하므로 이러한 로그 백업 중에는 로그 잘림이 발생할 수 없습니다. 데이터 백업으로 인해 로그 잘림이 발생하지 않을 경우 해당 백업을 취소하면 즉시 문제를 해결할 수 있습니다.
로그 잘림에 대한 자세한 내용은 트랜잭션 로그 잘림을 참조하십시오.
장기 실행 활성 트랜잭션
활성 트랜잭션은 해당 로그가 트랜잭션의 시작 부분이 포함된 로그 레코드부터 활성 상태여야 합니다. 예를 들어 트랜잭션의 시작과 끝을 사용자가 제어하는 경우에는 대개 사용자가 트랜잭션을 시작한 후 트랜잭션에서 사용자의 응답을 기다리는 동안 자리를 비울 때 장기 실행 트랜잭션이 발생합니다. 이 경우 대기 중인 트랜잭션은 로그를 거의 생성하지 않지만 로그 잘림을 방해하여 로그가 커집니다.
[!참고]
장기 실행 트랜잭션을 방지하는 방법은 효율적인 트랜잭션 코딩을 참조하십시오.
데이터베이스 미러링 및 트랜잭션 로그
데이터베이스 미러링을 사용하려면 주 서버 인스턴스가 미러 서버 인스턴스로부터 미러 서버의 디스크에 레코드가 기록되었다는 알림을 받을 때까지 각 로그 레코드가 활성 상태여야 합니다. 미러 서버 인스턴스가 주 서버 인스턴스보다 뒤처지면 그만큼 활성 로그 공간도 증가합니다. 이 경우 데이터베이스 미러링을 중지하고 로그를 자르는 로그 백업을 수행한 다음 해당 로그 백업을 미러 데이터베이스에 적용하고(WITH NORECOVERY 사용) 미러링을 다시 시작해야 할 수 있습니다.
.gif "중요 정보") 중요 |
|---|
또한 미러링을 시작하려면 필수 로그 백업 후에 추가 로그 백업이 수행된 경우 추가 로그 백업도 모두 수동으로 적용해야 합니다(항상 WITH NORECOVERY 사용). 최신 로그 백업을 적용한 후 미러링을 시작할 수 있습니다. |
자세한 내용은 데이터베이스 미러링 제거 및 데이터베이스 미러링 설정을 참조하십시오.
트랜잭션 복제 및 트랜잭션 로그
병합 복제 및 스냅숏 복제는 트랜잭션 로그 크기에 영향을 주지 않지만 트랜잭션 복제는 영향을 줄 수 있습니다. 데이터베이스에 하나 이상의 트랜잭션 게시를 포함하는 경우 로그는 게시와 관련된 모든 트랜잭션이 배포 데이터베이스에 배달될 때까지 잘리지 않습니다. 로그 판독기 에이전트가 일정에 따라 실행되는 경우 트랜잭션 로그가 너무 방대해지면 일정 실행 간격을 좁히거나 일정이 연속 모드에서 실행되도록 설정하십시오. 연속 모드에서 실행되도록 설정(기본값)한 경우 로그 판독기 에이전트가 실행되고 있는지 확인하십시오. 로그 판독기 에이전트의 상태를 확인하는 방법은 방법: 게시 관련 에이전트에 대한 정보 보기 및 태스크 수행(복제 모니터)을 참조하십시오.
또한 게시 데이터베이스나 배포 데이터베이스에서 'sync with backup' 옵션을 설정한 경우 트랜잭션이 모두 백업될 때까지 트랜잭션 로그가 잘리지 않습니다. 이 옵션을 설정한 경우 트랜잭션 로그가 너무 방대해지면 트랜잭션 로그 백업 간격을 좁히십시오. 트랜잭션 복제와 관련된 데이터베이스 백업 및 복원 방법은 스냅숏 및 트랜잭션 복제의 백업 및 복원을 위한 전략을 참조하십시오.
복제를 관리하려면
복제를 모니터링하려면