로그 시퀀스 번호 및 복원 계획
이 항목에서는 전체 복구 모델을 사용하는 SQL Server 데이터베이스와 관련된 내용을 다룹니다.
복원 계획에서 가장 중요한 로그 시퀀스 번호(LSN)는 처음과 마지막 LSN입니다. 이들 LSN은 다음 위치에서 얻을 수 있습니다.
msdb에 있는 backupset 테이블. 열의 이름은 first_lsn 및 last_lsn입니다.
RESTORE HEADERONLY 문. 열의 이름은 FirstLSN 및 LastLSN입니다.
각 백업 방식에서 이 값들이 가지는 의미는 다음과 같습니다.
용어 |
정의 |
|---|---|
first_lsn 또는 FirstLSN |
백업 세트에서 첫 번째 또는 가장 오래된 로그 레코드의 로그 시퀀스 번호입니다. 데이터 및 차등 백업에서 첫 LSN은 백업 복구를 수행하는 데 필요한 초기 로그 레코드를 식별하는데 사용됩니다. 로그 백업에서 첫 LSN은 백업에 포함되는 첫 로그 레코드를 식별하는데 사용됩니다. |
last_lsn 또는 LastLSN |
백업 세트 다음에 오는 로그 레코드의 로그 시퀀스 번호입니다. 마지막 LSN은 백업 범위 밖에 있는 다음 로그 레코드를 식별하는데 사용됩니다. 데이터 및 차등 백업, 대량 로그 작업을 포함한 로그 백업에서는 롤포워드가 최소한 이 LSN까지 도달해야 합니다. 그렇지 않으면 복원 중 복사된 데이터의 일관성이 없게 됩니다. 로그 백업에서는 이 LSN 직전까지의 로그 레코드가 로그 백업에 포함됩니다. |
데이터 및 차등 백업에서의 로그 시퀀스 번호
데이터 및 차등 백업에서는 first_lsn과 last_lsn 사이에 있는 로그 데이터가 백업에 포함됩니다. 따라서 last_lsn까지 복구할 때는 로그 백업이 필요하지 않습니다.
데이터 또는 차등 백업의 경우 복원 시퀀스에 백업을 사용할 때 가능한 초기 복구 지점은 last_lsn입니다. 더 이전의 복구 지점이 필요한 경우 더 이전의 백업을 사용해야 합니다.
데이터 또는 차등 백업을 복원한 다음 롤포워드에 어떤 로그 백업을 사용할지 계획할 경우 일반적으로 해당 데이터 또는 차등 백업 이후의 첫 번째 로그 백업으로 시작합니다. 백업 속성을 검사하면 first_lsn이 데이터 또는 차등 백업의 last_lsn보다 작거나 같고 last_lsn이 데이터 또는 차등 로그 백업의 last_lsn보다 큰 로그 백업을 찾을 수 있습니다.
로그 체인 내 로그 백업에서의 로그 시퀀스 번호
새 로그 체인은 데이터베이스가 생성된 이후 첫 번째 전체 데이터베이스 백업 시 또는 단순 복구 모델에서 전체 또는 대량 로그 복구 모델로 전환한 후에 시작됩니다. 체인의 첫 로그 백업에서 backupset.begins_log_chain= 1입니다.
first_lsn 및 last_lsn은 로그 백업을 연속적인 시퀀스(로그 체인)로 연결하는 데 사용됩니다. 연속적인 로그 백업 시퀀스를 사용하면 가장 최근의 데이터 또는 차등 백업, 데이터 누락 또는 손상 이전의 백업 또는 차등 백업에서 데이터베이스를 롤포워드할 수 있습니다.
로그 백업에서 first_lsn은 해당 백업에 있는 첫 번째 로그 레코드의 LSN이며 이 로그 레코드로 시작하는 로그 백업은 LSN이 last_lsn인 로그 레코드 직전까지의 로그 레코드를 포함합니다. 두 로그 백업이 연속적이려면 이전 백업(Backup_A)에 있는 마지막 로그 레코드의 LSN이 이후 백업(Backup_B)에 있는 첫 번째 로그 레코드의 LSN보다 크거나 같아야 합니다. 즉, Backup_A.last_lsn>= Backup_B.first_lsn이어야 합니다. 이 조건이 성립하지 않으면 두 백업간에 간격이 존재하는 것입니다.
이러한 LSN 간 관계의 의미는 다음과 같습니다.
A.last_lsn= B.first_lsn
A.last_lsn= B.first_lsn인 경우 B는 대개 A 이후 즉시 수행된 로그 백업입니다.
이 관계는 다음 그림과 같이 표시됩니다. 로그 백업 B에 있는 로그 레코드 n이 로그 백업 A에서는 last_lsn으로, 로그 백업 B에서는 first_lsn으로 기록됨을 유의하십시오.
.gif "로그 백업 A의 last_lsn이 로그 백업 B의 first_lsn과 같음")
A.last_lsn> B.first_lsn
A.last_lsn> B.first_lsn이면 겹침이 존재하는 것입니다. 겹침은 보통 복사 전용 로그 백업을 만드는 경우 또는 지정 시간 복구 이후 수행된 첫 번째 로그 백업에서 발생합니다. 겹침은 여러 복구 분기 지점과 연관될 수 있습니다. 자세한 내용은 복구 경로를 참조하십시오.
로그 체인 끊어짐의 원인
일반적으로 SQL Server 데이터베이스 엔진은 로그 백업 시퀀스에서 간격이 발생하는 것을 방지하여 로그 체인을 그대로 유지합니다. 그러나 데이터베이스 관리자가 복구 모델을 단순 복구 모델로 변경했다가 전체 또는 대량 로그 복구 모델로 되돌아갈 경우 로그 체인이 끊어질 수 있습니다.
단순 복구 모델을 포함하는 복구 모델 변경은 로그 체인을 끊기 때문에 이러한 변경을 거쳐 롤포워드할 수 없습니다. 전체 또는 대량 로그 복구 모델로 변경한 후 새 차등 기반이나 차등 기반 세트를 만들어야 합니다. 또는 차등 백업을 사용하여 간격을 연결할 수 있습니다.