ILog 인터페이스(txlogpub.h)

  • 아티클

일반 하위 수준 로깅 기능을 제공합니다.

CLFS( Common Log File System )는 ILog에서 제공하는 의 상위 집합인 기능을 제공합니다.

상속

ILog 인터페이스는 IUnknown 인터페이스에서 상속됩니다. ILog 에는 다음과 같은 유형의 멤버도 있습니다.

메서드

ILog 인터페이스에는 이러한 메서드가 있습니다.

 
ILog::AppendRecord

로그의 끝에 새 레코드를 씁니다.
ILog::Force

적어도 지정된 LSN을 통해 로그의 내용을 디스크에 강제로 적용합니다.
ILog::GetLogLimits

로그의 현재 범위에 대한 정보를 검색합니다.
ILog::ReadRecord

로그에서 레코드를 읽습니다.
ILog::ReadRecordPrefix

로그에서 레코드의 초기 부분을 읽습니다.
ILog::SetAccessPolicyHint

레코드를 읽을 패턴에 대한 구현에 대한 힌트를 제공합니다.
ILog::TruncatePrefix

로그의 지정된 접두사를 버리므로 더 이상 검색할 수 없습니다.

설명

WAL은 데이터베이스 관리 시스템과 같은 특정 애플리케이션에서 원자성 및 격리된 트랜잭션을 구현하는 데 사용하는 기술입니다. 이 기술에는 이러한 변경 내용을 적용하기 전에 애플리케이션의 리소스에 대한 변경 내용 레코드를 로그에 기록하는 작업이 포함됩니다. 이렇게 하면 필요한 경우(예: 트랜잭션이 실패하거나 중단된 경우) 변경 내용을 되돌릴 수 있습니다. 애플리케이션이 시스템 충돌 또는 전원 오류와 같은 중단에 대해 강력한 트랜잭션을 제공하려면 로깅 구현에서 로그를 강제 적용하는 방법을 제공해야 합니다. 즉, 계속하기 전에 이전에 작성된 레코드가 디스크에 있는지 확인합니다.

ILog를 사용하는 레코드 작성은 순차적인 작업입니다. 즉, 새 레코드는 항상 로그의 끝에 추가됩니다. 로그에 추가된 각 레코드에는 나중에 레코드를 검색하는 데 사용할 수 있는 숫자 식별자인 LSN(로그 시퀀스 번호)이 할당됩니다. 데이터 형식 LSN은 서명된 64비트 값인 LARGE_INTEGER 대한 typedef입니다. 그러나 ILog는 Nnnegative 값이 없는 LSN만 사용합니다. 또한 LSN은 다음 조건을 충족해야 합니다.

  • LSN은 단조롭게 증가하고 있습니다. 레코드 B가 레코드 A 다음에 로그에 기록되면 레코드 B의 LSN이 레코드 A의 LSN보다 커야 합니다.
  • 0과 MAXLSN(0x7FFFFFFFFFFFFFFF)의 값은 ILog의 일부 메서드에 특별한 의미가 있으므로 레코드의 LSN으로 사용하면 안 됩니다.
여기에 있는 조건 외에 ILog 구현에서 LSN을 할당하는 방법에 대한 가정은 할 수 없습니다. 특히 레코드에 LSN에 대한 순차적 값이 할당된다고 가정하는 것은 안전하지 않습니다.

레코드가 로그에 추가된 후에는 수정되지 않을 수 있습니다. 그러나 이전에 작성한 레코드가 더 이상 필요하지 않은 경우(예: 이미 커밋된 트랜잭션의 변경 내용 레코드) ILog 는 로그 잘림을 지원합니다. 이렇게 하면 중요하지 않은 레코드에 사용된 디스크 공간을 다시 사용할 수 있습니다. 로그 잘림은 LSN이 지정된 값보다 작은 모든 레코드를 삭제하는 것으로 구성됩니다.

성능 최적화로 ILog 의 일부 구현은 로그가 강제로 적용될 때까지 메모리의 레코드를 버퍼링할 수 있습니다. 이 경우 특수한 경우 오류 제어 및 복구를 고려해야 합니다. 다음 상황을 고려하세요.

  1. 레코드 A는 로그에 추가되지만 로그는 강제되지 않습니다. ILog 구현은 레코드를 메모리의 버퍼에 복사하고 성공 코드를 반환합니다.
  2. 레코드 B가 로그에 추가되고 ILog 구현에서 로그를 디스크에 강제로 적용하기로 결정합니다. 이는 호출자가 로그를 강제로 요청했거나 메모리 버퍼가 가득 찼기 때문입니다. 그러나 예를 들어 디스크 공간이 부족하여 쓰기 작업이 실패합니다.
이 경우 성공 코드를 반환한 모든 레코드가 먼저 디스크에 기록되도록 보장할 수 없는 한 ILog 구현에서 로그에 추가 레코드를 추가할 수 있도록 하는 것은 부적절합니다. 오류 제어의 가능한 방법 중 하나는 이 상황이 발생할 때 로그를 오류 상태로 고정하여 로그 instance 대한 추가 쓰기를 영구적으로 허용하지 않는 것입니다. 추가된 각 레코드에 대해 로그를 디스크에 강제로 적용하지 않는 호출자는 이 상황이 발생할 수 있음을 깨닫고 적절하게 처리할 수 있어야 합니다.

ILog 파일 기반 구현

Windows 운영 체제는 ILog의 파일 기반 구현을 제공하므로 파일에 대한 미리 쓰기 로깅에 적합한 로그를 만들 수 있습니다. 로그는 파일을 원형 버퍼로 사용하므로 사용되지 않는 공간을 다시 사용할 수 있습니다. 로그가 가득 찼을 때 추가 레코드에 맞추는 데 필요할 수 있는 파일의 크기도 증가할 수 있습니다. 로그에 대한 변경 내용은 원자성으로 이루어지므로 충돌 후 로그 내용을 복구할 수 있습니다. 이 구현에서는 로그 레코드를 추가하기 위해 메모리의 버퍼를 사용합니다. 따라서 호출자가 로그를 강제로 요청하지 않는 한 ILog::AppendRecord 메서드가 반환될 때 레코드가 디스크에 기록되도록 보장되지 않습니다.

다음 CLSID를 사용하여 파일 기반 로그의 instance 만듭니다(CoCreateInstance 참조).

CLSID_SimpleFileBasedLog({E16C0593-128F-11D1-97E4-00C04FB9618A} ).

ILog의 파일 기반 구현은 IFileBasedLogInit 및 IPersistFile 인터페이스를 추가로 지원합니다. IFileBasedLogInit::InitNew를 사용하여 새 로그 파일을 만듭니다. IPersistFile::Load를 사용하여 기존 로그 파일을 엽니다.

이 구현에서는 간단한 오류 제어 정책을 사용합니다. 디스크 전체 오류가 포함된 파일 시스템 수준의 오류로 인해 메서드 중 하나가 실패하면 로그가 오류 상태로 고정됩니다. 이렇게 하면 클라이언트가 파일에 추가 레코드를 추가하거나 잠재적으로 잘못된 레코드를 읽을 수 없습니다. 로그 파일을 계속 사용하려면 로그의 새 instance 만들어야 합니다.

요구 사항

요구 사항 값
지원되는 최소 클라이언트 Windows XP [데스크톱 앱만 해당]
지원되는 최소 서버 Windows Server 2003 [데스크톱 앱만 해당]
대상 플랫폼 Windows
헤더 txlogpub.h

추가 정보

IFileBasedLogInit