자동 페이지 복구는 데이터베이스 미러링 및 Always On 가용성 그룹에서 지원됩니다. 특정 유형의 오류가 페이지를 손상시켜 읽을 수 없게 만든 후 데이터베이스 미러링 파트너(주 또는 미러) 또는 가용성 복제본(주 또는 보조)이 페이지를 자동으로 복구하려고 시도합니다. 페이지를 읽을 수 없는 파트너/복제본은 해당 파트너 또는 다른 복제본에서 페이지의 새 복사본을 요청합니다. 이 요청이 성공하면 읽을 수 없는 페이지가 읽을 수 있는 복사본으로 대체되고 일반적으로 오류가 해결됩니다.
일반적으로 데이터베이스 미러링 및 Always On 가용성 그룹은 동일한 방식으로 I/O 오류를 처리합니다. 여기서는 몇 가지 차이점이 명시적으로 설명되어 있습니다.
비고
자동 페이지 복구는 DBCC 복구와 다릅니다. 모든 데이터는 자동 페이지 복구를 통해 유지됩니다. 반면, DBCC REPAIR_ALLOW_DATA_LOSS 옵션을 사용하여 오류를 수정하려면 일부 페이지와 따라서 데이터를 삭제해야 할 수 있습니다.
자동 Page-Repair 시도를 유발하는 오류 유형
데이터베이스 미러링 자동 페이지 복구는 다음 표에 나열된 오류 중 하나에 대해 작업이 실패한 데이터 파일의 페이지만 복구하려고 합니다.
| 오류 번호 | 설명 | 자동 페이지 복구 시도를 발생시키는 인스턴스 |
|---|---|---|
| 823 | 작업은 운영 체제가 데이터에 실패한 CRC(순환 중복 검사)를 수행한 경우에만 수행됩니다. | ERROR_CRC. 이 오류의 운영 체제 값은 23입니다. |
| 824 | 논리적 오류입니다. | 조각난 쓰기 또는 잘못된 페이지 체크섬과 같은 논리적 데이터 오류입니다. |
| 829 | 페이지가 복원 보류 중으로 표시되었습니다. | 모두. |
최근 823 CRC 오류 및 824 오류를 보려면 msdb 데이터베이스의 suspect_pages 테이블을 참조하세요.
자동으로 복구할 수 없는 페이지 형식
자동 페이지 복구는 다음 컨트롤 페이지 유형을 복구할 수 없습니다.
파일 머리글 페이지(페이지 ID 0).
9페이지(데이터베이스 부팅 페이지).
할당 페이지: GAM(전역 할당 맵) 페이지, SGAM(공유 전역 할당 맵) 페이지, PFS(페이지 여유 공간) 페이지.
보안 주 데이터베이스/주 데이터베이스에서 I/O 오류 처리
주 데이터베이스/주 데이터베이스에서 자동 페이지 복구는 데이터베이스가 SYNCHRONIZED 상태이고 주/주 데이터베이스가 여전히 데이터베이스에 대한 로그 레코드를 미러/보조 데이터베이스로 보내는 경우에만 시도됩니다. 자동 페이지 복구 시도의 기본 작업 순서는 다음과 같습니다.
보안 주 데이터베이스/주 데이터베이스의 데이터 페이지에서 읽기 오류가 발생하면 보안 주체/주 데이터베이스는 적절한 오류 상태의 행을 suspect_pages 테이블에 삽입합니다. 데이터베이스 미러링의 경우 주 서버는 미러 서버에서 페이지 복사본을 요청합니다. Always On 가용성 그룹의 경우 기본 복제본은 모든 보조 복제본에 요청을 브로드캐스트하고, 응답한 첫 번째 보조 복제본에서 페이지를 가져옵니다. 요청은 현재 플러시된 로그의 끝에 있는 페이지 ID 및 LSN을 지정합니다. 페이지가 복원 보류 중으로 표시됩니다. 이렇게 하면 자동 페이지 복구 시도 중에 액세스할 수 없습니다. 복구 시도 중에 이 페이지에 액세스하려고 하면 오류 829(복원 보류 중)가 실패합니다.
페이지 요청을 받은 후 미러/보조 데이터베이스는 요청에 지정된 LSN까지 로그를 다시 실행할 때까지 기다립니다. 그런 다음 미러 또는 보조 시스템이 데이터베이스 복사본의 페이지에 액세스하려고 시도합니다. 페이지에 액세스할 수 있는 경우 미러/보조 데이터베이스는 페이지 복사본을 주/주 데이터베이스로 보냅니다. 그렇지 않으면 미러/보조 데이터베이스가 주/주 데이터베이스에 오류를 반환하고 자동 페이지 복구 시도가 실패합니다.
보안 주체/주 서버는 페이지의 새 복사본이 포함된 응답을 처리합니다.
자동 페이지 복구 시도가 의심 페이지를 수정하면 페이지가 suspect_pages 테이블에 복원됨으로 표시됩니다(event_type = 5).
페이지 I/O 오류로 인해 지연된 트랜잭션이 발생한 경우 페이지를 복구한 후 주 노드가 해당 트랜잭션을 해결하려고 합니다.
미러/보조 데이터베이스에서 I/O 오류 처리
미러/보조 데이터베이스에서 발생하는 데이터 페이지의 I/O 오류는 일반적으로 데이터베이스 미러링 및 Always On 가용성 그룹에서 동일한 방식으로 처리됩니다.
데이터베이스 미러링을 사용하면 로그 레코드를 다시 실행하면 미러에서 하나 이상의 페이지 I/O 오류가 발생하면 미러링 세션이 SUSPENDED 상태가 됩니다. Always On 가용성 그룹을 사용하면 보조 복제본이 로그 레코드를 다시 실행하면 하나 이상의 페이지 I/O 오류가 발생하면 보조 데이터베이스가 SUSPENDED 상태가 됩니다. 이때 미러/보조 데이터베이스는 적절한 오류 상태의 행을 suspect_pages 테이블에 삽입합니다. 그런 다음 미러/보조 데이터베이스는 주/주 데이터베이스에서 페이지의 복사본을 요청합니다.
주체 또는 주본은 데이터베이스 복사본의 페이지에 액세스하려고 합니다. 페이지에 액세스할 수 있는 경우 주/주 데이터베이스는 페이지 복사본을 미러/보조 데이터베이스로 보냅니다.
미러/보조 데이터베이스가 요청한 모든 페이지의 복사본을 수신하는 경우 미러/보조 데이터베이스는 미러링 세션을 다시 시작하려고 합니다. 자동 페이지 복구 시도가 주의 대상 페이지를 수정하면 페이지가 suspect_pages 테이블에 복원됨으로 표시됩니다(event_type = 4).
미러/보조 데이터베이스가 주/기본 데이터베이스에서 요청한 페이지를 받지 못하면 자동 페이지 복구 시도가 실패합니다. 데이터베이스 미러링을 사용하면 미러링 세션이 일시 중단된 상태로 유지됩니다. Always On 가용성 그룹을 사용하면 보조 데이터베이스가 일시 중단된 상태로 유지됩니다. 미러링 세션 또는 보조 데이터베이스를 수동으로 다시 시작하면 동기화 단계에서 손상된 페이지가 다시 적중됩니다.
개발자 모범 사례
자동 페이지 복구는 백그라운드에서 실행되는 비동기 프로세스입니다. 따라서 읽을 수 없는 페이지를 요청하는 데이터베이스 작업이 실패하고 오류를 발생시킨 조건에 대한 오류 코드를 반환합니다. 미러된 데이터베이스 또는 가용성 데이터베이스에 대한 애플리케이션을 개발할 때 실패한 작업에 대한 예외를 가로채야 합니다. SQL Server 오류 코드가 823, 824 또는 829인 경우 나중에 작업을 다시 시도해야 합니다.
자동 Page-Repair 시도 확인 방법
다음 동적 관리 뷰는 데이터베이스당 최대 100개의 행을 사용하여 지정된 가용성 데이터베이스 또는 미러된 데이터베이스에 대한 최신 자동 페이지 복구 시도에 대한 행을 반환합니다.
AlwaysOn 가용성 그룹:
sys.dm_hadr_auto_page_repair(Transact-SQL)
서버 인스턴스에서 가용성 그룹에 대해 호스트되는 가용성 복제본의 가용성 데이터베이스에 대한 모든 자동 페이지 복구 시도에 대한 행을 반환합니다.
데이터베이스 미러링:
sys.dm_db_mirroring_auto_page_repair(Transact-SQL)
서버 인스턴스의 미러된 데이터베이스에 대한 모든 자동 페이지 복구 시도에 대한 행을 반환합니다.
또한 참조하십시오
suspect_pages 테이블 관리(SQL Server)
AlwaysOn 가용성 그룹 개요(SQL Server)
데이터베이스 미러링(SQL Server)