미러 또는 가용성 그룹을 핫 스페어로 사용하여 오류가 감지되면 페이지를 자동으로 수정할 수 있습니다 (미러링에는 2008 이상, 가용성 그룹은 20 12 의 기능 필요). Mirror 는 마스터 서버에 824 오류가 발생할 경우 미러 서버에 요청을 보내고 손상된 페이지를 미러에서 마스터로 복사하여 문제를 해결합니다. 가용성 그룹의 경우 기본 복제본에서 데이터 페이지가 발견되면 기본 복제본은 모든 보조 복제본에 브로드캐스트를 보내고 첫 번째로 응답하는 보조 복제본의 페이지는 페이지 오류를 수정합니다. 읽기 전용 보조 사본에서 오류가 발생하면 기본 사본에서 해당 페이지를 요청하여 오류를 수정합니다. SQL 서버의 모든 고가용성 기술은 데이터 페이지가 아닌 로그를 기반으로 하기 때문에 어떤 고가용성 기술이든 페이지 오류가 중복 데이터로 확산되지 않는다는 점에 유의해야 합니다.
둘째, 온대기나 냉대기를 사용하여 페이지를 복구합니다. 코드 목록 1 에서 자세한 코드를 제공했으니 자세히 설명하지 않겠습니다.
적절한 백업이 없으면 손상된 데이터 페이지가 클러스터되지 않은 인덱스에 존재하는 경우 다행입니다. 인덱스를 비활성화하고 다시 작성하기만 하면 됩니다.
기본 전체 백업이 있고 로그 체인이 끊어지지 않은 경우 (차등 백업이 누락된 로그를 덮어쓸 수 있는 부분 포함) 백업이 끝난 후 데이터베이스를 복구하여 복구할 수 있습니다.
마지막으로, 기본 작업이 제대로 수행되지 않으면 데이터 손실을 통해 데이터베이스의 일관성을 변경해야 할 수 있습니다. DBCC CheckDB 명령의 REPAIR_ALLOW_DATA_LOSS 를 통해 데이터베이스를 복구할 수 있습니다. 이 방법을 사용하면 데이터 손실이 발생할 수도 있고 발생하지 않을 수도 있지만, 대부분의 경우 데이터 삭제를 통해 일관성이 복구됩니다. REPAIR_ALLOW_DATA_LOSS 를 사용하려면 데이터베이스를 단일 사용자 모드로 설정해야 합니다. 즉, 다운타임이 발생합니다.
어떤 경우든 데이터베이스를 복구할 때는 SLA 충족 여부를 고려해야 합니다. 문제가 생기면 어쨌든 SLA 에 도달하지 못한다는 것을 알게 되면, 이전의 준비를 되돌아보고 실직하지 않기를 기도할 수밖에 없다.