페이지 복원 수행
이 항목에서는 전체 복구 모델 또는 대량 로그 복구 모델을 사용하는 SQL Server 데이터베이스와 관련된 내용을 다룹니다. 페이지 복원은 읽기/쓰기 파일 그룹에 대해서만 지원됩니다.
페이지 복원의 목표는 전체 데이터베이스를 복원하지 않고 하나 이상의 손상된 페이지를 복원하는 것입니다. 일반적으로 복원 후보 페이지는 페이지에 액세스할 때 발생한 오류 때문에 "주의 대상"으로 표시됩니다. 주의 대상 페이지는 msdb 데이터베이스의 suspect_pages 테이블에서 확인할 수 있습니다.
[!참고]
모든 페이지 오류에 복원이 필요한 것은 아닙니다. 보조 인덱스와 같은 캐시 데이터에서 발생한 문제는 데이터를 다시 계산하여 해결할 수 있습니다. 예를 들어 데이터베이스 관리자가 보조 인덱스를 삭제하고 다시 작성하면 손상된 데이터는 수정되었더라도 suspect_pages 테이블에 이러한 수정 내용이 반영되지 않습니다.
다중 데이터베이스 페이지는 즉시 복원될 수 있습니다. 로그 파일 백업은 복구 중인 페이지를 포함하는 모든 데이터베이스 파일에 적용됩니다. 파일 복원의 경우와 같이 롤포워드 세트는 단일 로그 다시 실행 과정을 사용하여 진행됩니다.
페이지 복원은 격리된 손상 페이지를 복구하기 위한 기능입니다. 몇몇 페이지를 각각 복원하고 복구하면 복원 작업 도중 오프라인 상태인 데이터의 양이 줄어들어 파일 복원보다 빠를 수 있습니다. 그러나 파일에 있는 여러 페이지를 복원할 경우에는 일반적으로 전체 파일을 복원하는 것이 효율적입니다. 예를 들어 장치의 여러 페이지에서 장치 오류의 가능성을 나타내는 경우 파일을 다른 위치로 복원한 다음 해당 장치를 복구해 보십시오.
페이지 복원 시나리오
SQL Server 2005 이상의 모든 버전에서는 데이터베이스가 오프라인 상태일 때에도 페이지를 복원할 수 있습니다(오프라인 페이지 복원). SQL Server 2005 Enterprise Edition 이상 버전의 경우 페이지를 복원하는 동안 데이터베이스가 온라인 상태이면 데이터베이스도 온라인 상태로 유지됩니다. 데이터베이스가 온라인 상태일 때 페이지를 복원 및 복구하는 것을 온라인 페이지 복원이라고 합니다.
이러한 페이지 복원 시나리오는 다음과 같습니다.
오프라인 페이지 복원
SQL Server 2005 Standard, SQL Server 2005 Express Edition 및 SQL Server 2005 Workgroup 이상 버전은 오프라인 복원만 지원합니다. SQL Server 2005 Enterprise Edition 이상 버전에서는 데이터베이스가 이미 오프라인 상태인 경우 오프라인 복원을 사용합니다. 오프라인 페이지 복원에서 손상된 페이지가 복원되는 동안 데이터베이스는 오프라인 상태가 됩니다. 복원 시퀀스의 마지막에 데이터베이스는 온라인 상태가 됩니다.
페이지 복원이 성공하려면 복원된 페이지가 데이터베이스와 동일한 상태로 복구되어야 합니다. 해당 페이지를 포함하는 파일 그룹을 현재 로그 파일로 가져오려면 손상되지 않은 로그 백업 체인을 마지막 전체 복원 또는 차등 복원에 적용해야 합니다.
온라인 페이지 복원
SQL Server 2005 Enterprise Edition 이상 버전의 경우 상황에 따라 페이지 복원이 온라인으로 자동 수행됩니다. 대부분의 경우 손상된 페이지는 페이지가 복원될 파일 그룹을 비롯한 데이터베이스가 온라인 상태로 유지되는 동안 복원될 수 있습니다. 온라인 페이지 복원은 특히 하드웨어 오류로 인해 손상된 페이지에 유용합니다.
손상된 페이지를 오프라인으로 복원해야 하는 경우도 있습니다. 예를 들어 중요한 특정 페이지가 손상되어 데이터베이스를 시작할 수 없을 수 있습니다. 이러한 경우 오프라인 복원을 사용해야 합니다.
[!참고]
온라인 복원은 메타데이터의 업데이트를 시도하며 중요한 페이지가 포함된 경우 업데이트가 실패할 수 있습니다. 온라인 복원 시도가 실패하면 오프라인으로 복원해야 합니다.
페이지 복원은 페이지 체크섬을 포함하여 SQL Server 2005 이상 버전의 향상된 페이지 수준 오류 보고와 추적을 사용합니다. 페이지가 체크섬과 조각난 쓰기에 의해 손상된 것으로 확인될 경우 이러한 손상된 페이지는 RESTORE 문에서 해당 페이지를 지정하여 복원될 수 있습니다. 페이지 복원은 손상된 소수의 페이지를 복원하기 위한 것입니다. RESTORE 문에서 지정한 각 페이지는 지정한 백업 세트의 페이지로 대체됩니다. 복원된 페이지는 데이터베이스와 일치하는 상태로 복구되어야 합니다. 이때 명시적으로 지정한 페이지만 복원됩니다.
페이지 복원의 제한
데이터베이스 페이지만 복원할 수 있습니다. 다음 항목은 페이지 복원을 사용하여 복원할 수 없습니다.
트랜잭션 로그
할당 페이지: GAM(전역 할당 맵) 페이지, SGAM(공유 전역 할당 맵) 페이지 및 PFS(페이지 여유 공간) 페이지. 자세한 내용은 익스텐트 할당 및 빈 공간 관리를 참조하십시오.
모든 데이터 파일의 0페이지(파일 부트 페이지)
1:9페이지(데이터베이스 부트 페이지)
전체 텍스트 카탈로그
개별 페이지를 복원할 수 없는 경우 기존의 전체 데이터베이스 백업이나 전체 파일 또는 파일 그룹 백업을 사용해야 합니다.
[!참고]
메타데이터 페이지와 같은 특수 페이지를 복원하는 경우에는 온라인 페이지 복원이 실패합니다. 이러한 경우 오프라인 페이지 복원을 사용하십시오.
페이지 복원에 필요한 요구 사항
페이지 복원의 전제 조건은 다음 요구 사항입니다.
데이터베이스는 전체 또는 대량 로그 복구 모델을 사용해야 합니다. 대량 로그 모델을 사용하는 경우 문제가 있을 수도 있습니다. 자세한 내용은 다음 섹션을 참조하십시오.
읽기 전용 파일 그룹의 페이지는 복원할 수 없습니다. 파일 그룹을 읽기 전용으로 설정하려는 시도는 파일 그룹에서 동시에 페이지 복원이 진행되는 경우 실패합니다.
복원 시퀀스는 전체, 파일 또는 파일 그룹 백업으로 시작되어야 합니다.
페이지 복원을 수행하려면 로그 백업 체인이 현재 로그 파일까지 끊어지지 않은 상태여야 하며 현재 로그 파일에 따라 페이지를 최신 상태로 만들도록 백업이 모두 적용되어야 합니다.
파일 복원 시퀀스의 경우와 같이 각 복원 단계에서 롤포워드 세트로 더 많은 페이지를 추가할 수 있습니다.
데이터베이스 백업과 페이지 복원은 동시에 실행할 수 없습니다.
대량 로그 복구 모델 및 페이지 복원
대량 로그 복구 모델을 사용하는 데이터베이스의 경우 페이지 복원에는 다음의 추가 조건이 있습니다.
파일 그룹 또는 페이지 데이터가 오프라인 상태인 동안 백업하는 것은 오프라인 데이터가 로그에 기록되지 않으므로 대량 로그 데이터의 경우 문제가 될 수 있습니다. 오프라인 페이지가 있으면 로그를 백업하지 못할 수 있습니다. 이 경우 가장 최근의 백업으로 복원하는 것보다 데이터가 적게 손실될 수 있으므로 DBCC REPAIR를 사용하십시오.
대량 로그 데이터베이스의 로그 백업에서 잘못된 페이지가 나타나면 WITH CONTINUE_AFTER_ERROR가 지정되지 않는 경우 로그 백업은 실패합니다.
일반적으로 페이지 복원은 대량 로그 복구에서 작동하지 않습니다.
페이지 복원을 수행하는 최상의 방법은 데이터베이스를 전체 복구 모델로 설정하고 로그 백업을 시도하는 것입니다. 로그 백업이 성공하면 페이지 복원을 계속 진행할 수 있습니다. 로그 백업이 실패하면 이전 로그 백업 이후의 작업이 손실되거나 REPAIR_ALLOW_DATA_LOSS 옵션을 사용하여 DBCC를 실행해야 합니다.
기본 페이지 복원 구문
RESTORE DATABASE 문에서 페이지를 지정하려면 페이지를 포함하는 파일의 파일 ID와 해당 페이지의 페이지 ID가 필요합니다. 필요한 구문은 다음과 같습니다.
RESTORE DATABASE database_name
PAGE ='file:page [ ,...n ]' [ ,...n ]
FROM <backup_device> [ ,...n ]
WITH NORECOVERY
PAGE 옵션의 매개 변수에 대한 자세한 내용은 RESTORE 인수(Transact-SQL)를 참조하십시오. RESTORE DATABASE 구문에 대한 자세한 내용은 RESTORE(Transact-SQL)를 참조하십시오.
페이지 복원의 프로시저
페이지 복원의 기본 단계는 다음과 같습니다.
복원하려는 손상된 페이지의 페이지 ID를 확인합니다. 체크섬 또는 조각난 쓰기 오류가 페이지 ID를 반환하고 페이지를 지정하는 데 필요한 정보를 제공합니다. 손상된 페이지의 페이지 ID를 조회하려면 다음 원본 중 하나를 사용하십시오.
페이지 ID의 원본
항목
msdb..suspect_pages
오류 로그
이벤트 추적
DBCC
WMI 공급자
페이지가 들어 있는 전체 데이터베이스, 파일 또는 파일 그룹 백업으로 페이지 복원을 시작합니다. RESTORE DATABASE 문에서 PAGE 절을 사용하여 복원할 모든 페이지의 페이지 ID를 나열합니다.
PAGE ='file:page [ ,...n ]'
가장 최근의 차등 백업을 적용합니다.
후속 로그 백업을 적용합니다.
복원된 페이지의 최종 LSN, 즉 마지막으로 복원된 페이지가 오프라인 상태로 된 시점을 포함하는 데이터베이스의 새 로그 백업을 만듭니다. 시퀀스에서 첫 번째 복원의 일부로 설정되는 최종 LSN은 다시 실행 대상 LSN입니다. 이 페이지를 포함하는 파일의 온라인 롤포워드는 다시 실행 대상 LSN에서 중지할 수 있습니다. 파일의 현재 다시 실행 대상 LSN을 알아보려면 sys.master_files의 redo_target_lsn 열을 확인합니다. 자세한 내용은 sys.master_files(Transact-SQL)를 참조하십시오.
새 로그 백업을 복원합니다. 새로운 이 로그 백업을 적용하면 페이지 복원이 완료되며 페이지를 사용할 수 있습니다.
[!참고]
이 시퀀스는 파일 복원 시퀀스와 유사하며 동일한 시퀀스의 일부로 페이지 복원과 파일 복원을 모두 수행할 수도 있습니다.
예
다음 예에서는 NORECOVERY로 B 파일의 손상된 4페이지를 복원합니다. 그런 다음 두 개의 로그 백업에 NORECOVERY를 적용하고 RECOVERY로 복원되는 비상 로그 백업을 실행합니다.
.gif "중요 정보") 중요 |
|---|
손상된 페이지에 중요한 데이터베이스 메타데이터가 저장되어 있으면 오프라인 페이지 복원 시퀀스가 필요할 수 있습니다. 오프라인 복원을 수행하려면 WITH NORECOVERY 트랜잭션 로그를 백업해야 합니다. |
다음 예에서는 온라인 복원을 수행합니다. 이 예에서 B 파일의 파일 ID는 1이고 손상된 페이지의 페이지 ID는 각각 57, 202, 916 및 1016입니다.
RESTORE DATABASE <database> PAGE='1:57, 1:202, 1:916, 1:1016'
FROM <file_backup_of_file_B>
WITH NORECOVERY;
RESTORE LOG <database> FROM <log_backup>
WITH NORECOVERY;
RESTORE LOG <database> FROM <log_backup>
WITH NORECOVERY;
BACKUP LOG <database> TO <new_log_backup>
RESTORE LOG <database> FROM <new_log_backup> WITH RECOVERY;
GO