CLFS 로그 시퀀스 번호
CLFS(Common Log File System)에서 지정된 스트림의 각 로그 레코드는 LSN(로그 시퀀스 번호)으로 고유하게 식별됩니다. 스트림에 레코드를 쓰면 이후 참조를 위해 해당 레코드를 식별하는 LSN을 다시 가져옵니다.
특정 스트림에 대해 만든 LSN은 엄격하게 증가하는 시퀀스를 형성합니다. 즉, 지정된 스트림의 로그 레코드에 할당된 LSN은 항상 동일한 스트림에 이전에 기록된 로그 레코드에 할당된 LSN보다 큽니다. 다음 함수는 지정된 스트림에서 로그 레코드의 LSN을 비교하는 데 사용할 수 있습니다.
CLFS_LSN_NULL 및 CLFS_LSN_INVALID 상수는 유효한 모든 LSN의 하한 및 상한입니다. 유효한 모든 LSN은 CLFS_LSN_NULL 보다 크거나 같습니다. 또한 유효한 LSN은 CLFS_LSN_INVALID 미만입니다. CLFS_LSN_NULL 유효한 LSN인 반면 CLFS_LSN_INVALID 유효한 LSN은 아닙니다. 그럼에도 불구하고 이전 목록의 함수를 사용하여 CLFS_LSN_INVALID 다른 LSN과 비교할 수 있습니다.
각 스트림에 대해 CLFS는 기본 LSN과 마지막 LSN이라는 두 개의 특수 LSN을 추적합니다. 또한 각 개별 로그 레코드에는 관련 로그 레코드의 체인을 만드는 데 사용할 수 있는 두 개의 특수 LSN(이전 LSN 및 실행 취소 후 LSN)이 있습니다. 다음 섹션에서는 이러한 특수 LSN에 대해 자세히 설명합니다.
기본 LSN
클라이언트가 스트림에서 첫 번째 레코드를 작성하면 CLFS는 기본 LSN을 첫 번째 레코드의 LSN으로 설정합니다. 기본 LSN은 클라이언트가 변경할 때까지 변경되지 않은 상태로 유지됩니다. 스트림의 클라이언트가 스트림의 특정 지점 이전에 더 이상 레코드가 필요하지 않은 경우 ClfsAdvanceLogBase 또는 ClfsWriteRestartArea를 호출하여 기본 LSN을 업데이트할 수 있습니다. 예를 들어 클라이언트에 처음 5개의 로그 레코드가 더 이상 필요하지 않은 경우 기본 LSN을 여섯 번째 레코드의 LSN으로 설정할 수 있습니다.
마지막 LSN
클라이언트가 스트림에 레코드를 쓸 때 CLFS는 마지막 LSN을 항상 기록된 마지막 레코드의 LSN이 되도록 조정합니다. 클라이언트가 스트림의 특정 지점 이후에 더 이상 레코드가 필요하지 않은 경우 ClfsSetEndOfLog를 호출하여 마지막 LSN을 업데이트할 수 있습니다. 예를 들어 클라이언트가 10번째 레코드 다음에 기록된 레코드가 더 이상 필요하지 않은 경우 마지막 LSN을 10번째 레코드의 LSN으로 설정하여 스트림을 잘릴 수 있습니다.
스트림의 활성 부분
스트림의 활성 부분은 기본 LSN이 가리키는 레코드로 시작하고 마지막 LSN이 가리키는 레코드로 끝나는 스트림의 부분입니다. 다음 다이어그램에서는 기본 LSN 및 마지막 LSN이 스트림의 활성 부분을 설명하는 방법을 보여 줍니다.
참고 스트림에 보관 꼬리가 있는 경우 스트림의 활성 부분은 기본 LSN 또는 보관 꼬리가 가리키는 레코드에서 시작되며, 그 중 더 작은 값입니다. 보관에 대한 자세한 내용은 보관 을 위한 CLFS 지원을 참조하세요.
이전 LSN
두 개의 활성 데이터베이스 트랜잭션(트랜잭션 A 및 트랜잭션 B)이 동시에 동일한 스트림에 레코드를 쓰고 있다고 가정합니다. 트랜잭션 A가 레코드를 쓸 때마다 레코드의 이전 LSN을 트랜잭션 A에서 작성한 이전 로그 레코드의 LSN으로 설정합니다. 즉, 역순으로 트래버스할 수 있는 트랜잭션 A에 속하는 로그 레코드 체인을 형성합니다. 체인은 이전 LSN이 CLFS_LSN_INVALID 설정된 트랜잭션 A에 의해 작성된 첫 번째 로그 레코드로 끝납니다. 마찬가지로 트랜잭션 B는 기록되는 각 로그 레코드의 이전 LSN을 설정하여 자체 로그 레코드 체인을 만듭니다.
다음 다이어그램의 화살표는 로그 레코드의 이전 LSN이 특정 트랜잭션에 속한 체인의 이전 레코드를 가리키는 방법을 보여 줍니다.
다음 LSN 실행 취소
트랜잭션이 휘발성 메모리의 데이터 개체를 5번 업데이트하고, 네 번째 및 다섯 번째 업데이트를 롤백한 다음, 여섯 번째 업데이트를 수행한다고 가정해 보겠습니다. 트랜잭션이 업데이트되면 로그 레코드 1, 2, 3, 4, 5, 5', 4' 및 6을 기록합니다. 로그 레코드 1~5는 업데이트 1~5의 변경 내용을 설명합니다. Record 5'는 업데이트 5를 롤백하는 동안 변경된 내용을 설명하고, record 4'는 업데이트 4를 롤백하는 동안 변경된 내용을 설명합니다. 마지막으로, 레코드 6은 업데이트 6의 변경 내용을 설명합니다. 숫자 1, 2, 3, 4, 5, 5', 4', 6은 로그 레코드의 LSN이 아닙니다. 이 설명의 목적을 위해 로그 레코드의 이름을 지정하는 데 사용되는 숫자일 뿐입니다.
롤백을 설명하는 로그 레코드 5' 및 4'를 CLR(보정 로그 레코드)이라고 합니다. 트랜잭션은 각 CLR의 실행 취소 후 LSN을 업데이트가 롤백(실행 취소)된 로그 레코드의 선행 작업(트랜잭션에서 작성한 레코드 중)으로 설정합니다. 이 예제에서 레코드 5'의 실행 취소 후 LSN은 레코드 4의 LSN이고 레코드 4'의 실행 취소 다음 LSN은 레코드 3의 LSN입니다.
일반 로그 레코드(CLR이 아닌 레코드)에는 트랜잭션에서 작성한 이전 로그 레코드로 실행 취소된 다음 LSN이 설정됩니다. 즉, 일반 레코드의 경우 실행 취소된 다음 LSN과 이전 LSN은 동일합니다.
이제 시스템 오류가 있다고 가정하고 다시 시작하는 동안 전체 트랜잭션을 롤백해야 합니다. 복구 코드 로그 레코드 6을 읽습니다. 레코드 6의 데이터는 레코드 6이 CLR이 아닌 일반 레코드임을 나타내므로 복구 코드 업데이트 6을 롤백합니다. 그런 다음, 복구 코드 레코드 6의 실행 취소 후 LSN을 검사하고 레코드 4'를 가리키는 것을 찾습니다. 레코드 4'의 데이터는 CLR임을 나타내므로 복구 코드 업데이트 4를 롤백하지 않습니다. 대신 레코드 4'의 실행 취소 후 LSN을 검사하고 레코드 3을 가리키는 것을 찾습니다. 레코드 3은 CLR이 아니므로 복구 코드 업데이트 3을 롤백합니다. 업데이트 5와 4는 일반 정방향 처리 중에 이미 롤백되었기 때문에 복구 중에 롤백되지 않습니다. 마지막으로 복구 코드 업데이트 2와 1을 롤백합니다.
다음 다이어그램의 화살표는 실행 취소 후 LSN이 업데이트가 이미 롤백된 레코드를 건너뛰는 데 사용할 수 복구 코드 메커니즘을 제공하는 방법을 보여 줍니다.
