스냅샷 및 트랜잭션 복제 백업 및 복원 전략

스냅샷 및 트랜잭션 복제에 대한 백업 및 복원 전략을 설계할 때 고려해야 할 세 가지 영역이 있습니다.

• 백업할 데이터베이스는 무엇인가요?

• 트랜잭션 복제에 대한 백업 설정입니다.

• 데이터베이스를 복원하는 데 필요한 단계입니다. 이는 선택한 복제 및 옵션의 유형에 따라 달라집니다.

이 항목에서는 다음 세 섹션의 각 영역에 대해 설명합니다. Oracle 게시에 대한 백업 및 복원에 대한 자세한 내용은 Oracle 게시자에 대한 백업 및 복원을 참조하세요.

데이터베이스 백업

스냅샷 및 트랜잭션 복제의 경우 다음 데이터베이스를 정기적으로 백업해야 합니다.

• 게시자의 게시 데이터베이스입니다.

• 배포자의 배포 데이터베이스입니다.

• 각 구독자의 구독 데이터베이스입니다.

• 게시자, 배포자 및 모든 구독자의 마스터 및 msdb 시스템 데이터베이스입니다. 이러한 데이터베이스는 서로 및 관련 복제 데이터베이스와 동시에 백업되어야 합니다. 예를 들어 게시 데이터베이스를 백업하는 동시에 게시자에서 마스터 및 msdb 데이터베이스를 백업합니다. 게시 데이터베이스가 복원된 경우 마스터 및 msdb 데이터베이스가 복제 구성 및 설정과 관련하여 게시 데이터베이스와 일치하는지 확인합니다.

정기적인 로그 백업을 수행하는 경우 복제 관련 변경 내용을 로그 백업에 캡처해야 합니다. 로그 백업을 수행하지 않으면 복제와 관련된 설정이 변경될 때마다 백업을 수행해야 합니다. 자세한 내용은 업데이트된 백업이 필요한 일반적인 작업을 참조하세요.

트랜잭션 복제에 대한 백업 설정

트랜잭션 복제에는 배포 데이터베이스 및 게시 데이터베이스에서 설정할 수 있는 백업 옵션과 동기화 를 사용하는 것이 포함됩니다.

• 항상 배포 데이터베이스에서 이 옵션을 설정하는 것이 좋습니다.

  배포 데이터베이스에서 이 옵션을 설정하면 게시 데이터베이스의 로그에 있는 트랜잭션이 배포 데이터베이스에 백업될 때까지 잘리지 않습니다. 배포 데이터베이스를 마지막 백업으로 복원할 수 있으며 누락된 트랜잭션은 게시 데이터베이스에서 배포 데이터베이스로 전달됩니다. 복제는 영향을 받지 않고 계속됩니다.

  배포 데이터베이스에서 이 옵션을 설정해도 복제 대기 시간에는 영향을 주지 않습니다. 그러나 이 옵션은 배포 데이터베이스의 해당 트랜잭션이 백업될 때까지 게시 데이터베이스의 로그 잘림을 지연합니다. (게시 데이터베이스에서 더 큰 트랜잭션 로그를 만들 수 있습니다.)

• 애플리케이션에서 추가 대기 시간을 허용할 수 있는 경우 게시 데이터베이스에서 이 옵션을 설정하는 것이 좋습니다.

  게시 데이터베이스에서 이 옵션을 설정하면 트랜잭션이 게시 데이터베이스에 백업될 때까지 배포 데이터베이스에 배달되지 않습니다. 게시자가 최종 게시 데이터베이스 백업을 복원할 때, 복원된 게시 데이터베이스에 없는 트랜잭션이 배포 데이터베이스에 있을 가능성이 전혀 없습니다.

  트랜잭션이 게시자에서 백업될 때까지 배포 데이터베이스에 배달할 수 없으므로 대기 시간 및 처리량이 영향을 받습니다. 예를 들어 트랜잭션 로그가 5분마다 백업되는 경우 게시자에서 트랜잭션이 커밋된 시간과 트랜잭션이 배포 데이터베이스에 전달된 시점과 그 이후에 구독자 사이에 5분의 대기 시간이 추가로 발생합니다.

  비고

  백업과 동기화 옵션을 사용하면 게시 데이터베이스와 배포 데이터베이스 간의 일관성이 보장되지만 이 옵션은 데이터 손실을 보장하지 않습니다. 예를 들어 트랜잭션 로그가 손실된 경우 마지막 트랜잭션 로그 백업 이후 커밋된 트랜잭션은 게시 데이터베이스 또는 배포 데이터베이스에서 사용할 수 없습니다. 이는 비복제 데이터베이스와 같은 작동을 보입니다.

백업 옵션을 사용하여 동기화를 설정하려면

• 복제 Transact-SQL 프로그래밍: 트랜잭션 복제에 대해 조정된 백업 사용(복제 Transact-SQL 프로그래밍)

복제와 관련된 데이터베이스 복원

최근 백업을 사용할 수 있고 적절한 단계를 따르는 경우 복제 토폴로지의 모든 데이터베이스를 복원할 수 있습니다. 게시 데이터베이스의 복원 단계는 복제 유형 및 사용되는 옵션에 따라 달라집니다. 그러나 다른 모든 데이터베이스에 대한 복원 단계는 형식 및 옵션과 독립적입니다.

복제는 복제된 데이터베이스를 백업이 만들어진 동일한 서버 및 데이터베이스로 복원하도록 지원합니다. 복제된 데이터베이스의 백업을 다른 서버 또는 데이터베이스로 복원하는 경우 복제 설정을 유지할 수 없습니다. 이 경우 백업이 복원된 후 모든 게시 및 구독을 다시 만들어야 합니다.

게시자

다음 유형의 복제에 대해 제공되는 복원 단계가 있습니다.

• 스냅샷 복제

• 읽기 전용 트랜잭션 복제

• 구독 업데이트가 포함된 트랜잭션 복제

• 피어 투 피어 거래 복제

이 섹션에서 설명하는 msdb 및 master 데이터베이스의 복원은 네 가지 형식 모두에 대해 동일합니다.

게시 데이터베이스: 스냅샷 복제

1. 게시 데이터베이스의 최신 백업을 복원합니다. 2단계로 이동합니다.

2. 게시 데이터베이스 백업에 모든 게시 및 구독에 대한 최신 구성이 포함되어 있나요? 그렇다면 복원이 완료됩니다. 없는 경우 3단계로 이동합니다.

3. 게시자, 배포자 및 구독자에서 복제 구성을 제거한 다음 구성을 다시 만듭니다. 복원이 완료되었습니다.

   복제를 제거하는 방법에 대한 자세한 내용은 sp_removedbreplication(Transact-SQL)를 참조하세요.

게시 데이터베이스: Read-Only 트랜잭션 복제

1. 게시 데이터베이스의 최신 백업을 복원합니다. 2단계로 이동합니다.

2. 실패하기 전에 게시 데이터베이스에서 백업 설정과의 동기화 를 사용하도록 설정되었나요? 그렇다면 3단계로 이동합니다. 아니요이면 5단계로 이동합니다.

   설정을 사용하도록 설정하면 쿼리 SELECT DATABASEPROPERTYEX('<PublicationDatabaseName>', 'IsSyncWithBackup') 는 '1'을 반환합니다.

3. 복원된 백업이 완료되었으며 up-to-date인가요? 모든 게시 및 구독에 대한 최신 구성이 포함되어 있나요? 그렇다면 복원이 완료됩니다. 없는 경우 4단계로 이동합니다.

4. 복원된 게시 데이터베이스의 구성 정보는 up-to없습니다. 따라서 구독자에 배포 데이터베이스의 모든 미해결 명령이 있는지 확인한 다음 복제 구성을 삭제하고 다시 만들어야 합니다.

   1. 모든 구독자가 배포 데이터베이스의 미해결 명령과 동기화될 때까지 배포 에이전트를 실행합니다. 복제 모니터에서 배포되지 않은 명령 탭을 사용하거나 배포 데이터베이스의 MSdistribution_status 보기를 쿼리하여 모든 명령이 구독자에게 전달되는지 확인합니다. b단계로 이동합니다.

      배포 에이전트를 실행하는 방법에 대한 자세한 내용은 복제 에이전트 시작 및 중지(SQL Server Management Studio) 및 복제 에이전트 실행 파일 개념을 참조하세요.

      명령을 확인하는 방법에 대한 자세한 내용은 배포 데이터베이스에서 복제된 명령 및 기타 정보 보기(복제 Transact-SQL 프로그래밍) 및 복제 모니터를 사용하여 정보 보기 및 작업 수행을 참조하세요.

   2. 게시자, 배포자 및 구독자에서 복제 구성을 제거한 다음 구성을 다시 만듭니다. 구독을 다시 만들 때 구독자에 이미 데이터가 있는지 지정합니다. 복원이 완료되었습니다.

      복제를 제거하는 방법에 대한 자세한 내용은 sp_removedbreplication(Transact-SQL)를 참조하세요.

      구독자에 이미 데이터가 있음을 지정하는 방법에 대한 자세한 내용은 수동으로 구독 초기화를 참조하세요.

5. 게시 데이터베이스에서 백업과 동기화 옵션이 설정되지 않았습니다. 따라서 복원된 백업에 포함되지 않은 트랜잭션은 배포자 및 구독자에게 전달되었을 수 있습니다. 이제 구독자에게 배포 데이터베이스의 모든 미해결 명령이 있는지 확인한 다음 복원된 백업에 포함되지 않은 트랜잭션을 게시 데이터베이스에 수동으로 적용해야 합니다.

   중요합니다

   이 프로세스를 수행하면 게시된 테이블이 백업에서 복원된 다른 게시되지 않은 테이블의 지정 시간보다 더 최근 시점으로 복원될 수 있습니다.

   1. 모든 구독자가 배포 데이터베이스의 미해결 명령과 동기화될 때까지 배포 에이전트를 실행합니다. 복제 모니터에서 배포되지 않은 명령 탭을 사용하거나 배포 데이터베이스의 MSdistribution_status 보기를 쿼리하여 모든 명령이 구독자에게 전달되는지 확인합니다. b단계로 이동합니다.

      배포 에이전트를 실행하는 방법에 대한 자세한 내용은 복제 에이전트 시작 및 중지(SQL Server Management Studio) 및 복제 에이전트 실행 파일 개념을 참조하세요.

      명령을 확인하는 방법에 대한 자세한 내용은 배포 데이터베이스에서 복제된 명령 및 기타 정보 보기(복제 Transact-SQL 프로그래밍) 및 복제 모니터를 사용하여 정보 보기 및 작업 수행을 참조하세요.

   2. tablediff 유틸리티 또는 다른 도구를 사용하여 게시자를 구독자와 수동으로 동기화합니다. 이렇게 하면 게시 데이터베이스 백업에 포함되지 않은 구독 데이터베이스에서 데이터를 복구할 수 있습니다. c단계로 이동합니다.

      tablediff 유틸리티에 대한 자세한 내용은 복제된 테이블의 차이점 비교(복제 프로그래밍)를 참조하세요.

   3. 복원된 백업이 완료되고 up-to-date인가요? 모든 게시 및 구독에 대한 최신 구성이 포함되어 있나요? 그렇다면 sp_replrestart 저장 프로시저를 실행하여 배포자 메타데이터를 사용하여 게시자 메타데이터를 다시 동기화합니다. 복원이 완료되었습니다. 아니요인 경우 d단계로 이동합니다.

   4. 게시자, 배포자 및 구독자에서 복제 구성을 제거한 다음 구성을 다시 만듭니다. 구독을 다시 만들 때 구독자에 이미 데이터가 있는지 지정합니다. 복원이 완료되었습니다.

      복제를 제거하는 방법에 대한 자세한 내용은 sp_removedbreplication(Transact-SQL)를 참조하세요.

      구독자에 이미 데이터가 있음을 지정하는 방법에 대한 자세한 내용은 수동으로 구독 초기화를 참조하세요.

게시 데이터베이스: 구독 업데이트로 트랜잭션 복제

1. 게시 데이터베이스의 최신 백업을 복원합니다. 2단계로 이동합니다.

2. 모든 구독자가 배포 데이터베이스의 미해결 명령과 동기화될 때까지 배포 에이전트를 실행합니다. 복제 모니터의 배포되지 않은 명령 탭을 사용하거나 배포 데이터베이스의 MSdistribution_status 보기를 쿼리하여 모든 명령이 구독자에게 전달되는지 확인합니다. 3단계로 이동합니다.

   배포 에이전트를 실행하는 방법에 대한 자세한 내용은 복제 에이전트 시작 및 중지(SQL Server Management Studio) 및 복제 에이전트 실행 파일 개념을 참조하세요.

   명령을 확인하는 방법에 대한 자세한 내용은 배포 데이터베이스에서 복제된 명령 및 기타 정보 보기(복제 Transact-SQL 프로그래밍) 및 복제 모니터를 사용하여 정보 보기 및 작업 수행을 참조하세요.

3. 지연 업데이트 구독을 사용하는 경우 각 구독자에 연결하고 구독 데이터베이스의 MSreplication_queue(Transact-SQL) 테이블에서 모든 행을 삭제합니다. 4단계로 이동합니다.

   비고

   대기 중인 업데이트 구독을 사용하고 테이블에 ID 열이 포함된 경우 복원 후에 올바른 ID 범위가 할당되었는지 확인해야 합니다. 자세한 내용은 ID 열 복제를 참조하세요.

4. 이제 구독자에게 배포 데이터베이스의 모든 미해결 명령이 있는지 확인한 다음 복원된 백업에 포함되지 않은 트랜잭션을 게시 데이터베이스에 수동으로 적용해야 합니다.

   중요합니다

   이 프로세스를 수행하면 게시된 테이블이 백업에서 복원된 다른 게시되지 않은 테이블의 지정 시간보다 더 최근 시점으로 복원될 수 있습니다.

   1. 모든 구독자가 배포 데이터베이스의 미해결 명령과 동기화될 때까지 배포 에이전트를 실행합니다. 복제 모니터를 사용하거나 배포 데이터베이스의 MSdistribution_status 보기를 쿼리하여 모든 명령이 구독자에게 전달되는지 확인합니다. b단계로 이동합니다.

   2. tablediff 유틸리티 또는 다른 도구를 사용하여 게시자를 구독자와 수동으로 동기화합니다. 이렇게 하면 게시 데이터베이스 백업에 포함되지 않은 구독 데이터베이스에서 데이터를 복구할 수 있습니다. c단계로 이동합니다.

      tablediff 유틸리티에 대한 자세한 내용은 복제된 테이블의 차이점 비교(복제 프로그래밍)를 참조하세요.

   3. 복원된 백업이 완료되고 up-to-date인가요? 모든 게시 및 구독에 대한 최신 구성이 포함되어 있나요? 그렇다면 sp_replrestart 저장 프로시저를 실행하여 배포자 메타데이터를 사용하여 게시자 메타데이터를 다시 동기화합니다. 복원이 완료되었습니다. 아니요인 경우 d단계로 이동합니다.

   4. 게시자, 배포자 및 구독자에서 복제 구성을 제거한 다음 구성을 다시 만듭니다. 구독을 다시 만들 때 구독자에 이미 데이터가 있는지 지정합니다. 복원이 완료되었습니다.

      자세한 내용은 sp_removedbreplication(Transact-SQL)을 참조하여 복제를 제거하는 방법에 대해 알아보십시오.

      구독자에 이미 데이터가 있음을 지정하는 방법에 대한 자세한 내용은 수동으로 구독 초기화를 참조하세요.

게시 데이터베이스: 피어 투 피어 트랜잭션 복제

다음 단계에서 게시 데이터베이스 A, B 및 C 는 피어 투 피어 트랜잭션 복제 토폴로지입니다. 데이터베이스 A와 C는 온라인 상태가 되며 제대로 작동합니다. 데이터베이스 B는 복원할 데이터베이스입니다. 여기서 설명하는 프로세스, 특히 7단계, 10단계 및 11단계는 피어 투 피어 토폴로지에 노드를 추가하는 데 필요한 프로세스와 매우 유사합니다. 이러한 단계를 수행하는 가장 간단한 방법은 피어 투 피어 토폴로지 구성 마법사를 사용하는 것이지만 저장 프로시저를 사용할 수도 있습니다.

1. 배포 에이전트를 실행하여 데이터베이스 A 및 C에서 구독을 동기화합니다. 2단계로 이동합니다.

   배포 에이전트를 실행하는 방법에 대한 자세한 내용은 복제 에이전트 시작 및 중지(SQL Server Management Studio) 및 복제 에이전트 실행 파일 개념을 참조하세요.

2. B에서 사용하는 배포 데이터베이스를 계속 사용할 수 있는 경우 배포 에이전트를 실행하여 데이터베이스 B와 A, 데이터베이스와 B 및 C 간에 구독을 동기화합니다. 3단계로 이동합니다.

3. B에 대한 배포 데이터베이스에서 sp_removedistpublisherdbreplication 실행하여 B가 사용하는 배포 데이터베이스에서 메타데이터를 제거합니다. 4단계로 이동합니다.

4. 데이터베이스 A 및 C에서 데이터베이스 B에서 게시에 대한 구독을 삭제합니다. 5단계로 이동합니다.

   구독을 삭제하는 방법에 대한 자세한 내용은 게시 구독을 참조하세요.

5. 데이터베이스 A의 로그 백업 또는 전체 백업을 수행합니다. 6단계로 이동합니다.

6. 데이터베이스 B에서 데이터베이스 A 의 백업을 복원 합니다. 이제 데이터베이스 B 에는 데이터베이스 A의 데이터가 있지만 복제 구성은 없습니다. 백업을 다른 서버로 복원하면 복제가 제거됩니다. 따라서 데이터베이스 B에서 복제가 제거되었습니다. 7단계로 이동합니다.

7. 데이터베이스 B에서 게시를 다시 만든 다음 데이터베이스 A 와 B 간에 구독을 다시 만듭니다. ( 데이터베이스 C 를 포함하는 구독은 이후 단계에서 처리됩니다.)

   1. 데이터베이스 B에서 게시를 다시 만듭니다. b단계로 이동합니다.

   2. 데이터베이스 B에서 데이터베이스 A의 게시에 대한 구독을 다시 만들고, 백업을 사용하여 구독을 초기화하도록 지정합니다(sp_addsubscription @sync_type 매개 변수에 대한 백업을 사용하여 초기화 값). c단계로 이동합니다.

   3. 데이터베이스 A에서 데이터베이스 B의 게시에 대한 구독을 다시 만들어 구독자에 이미 데이터가 있음을 지정합니다(sp_addsubscription @sync_type 매개 변수에 대해서만 복제 지원값). 8단계로 이동합니다.

8. 배포 에이전트를 실행하여 데이터베이스 A 및 B에서 구독을 동기화합니다. 게시된 테이블에 ID 열이 있는 경우 9단계로 이동합니다. 그렇지 않은 경우 10단계로 이동합니다.

9. 복원 후에는 데이터베이스 A의 각 테이블에 할당한 ID 범위도 데이터베이스 B에서 사용됩니다. 복원된 데이터베이스 B가 데이터베이스 A 및 데이터베이스 C로 전파된 실패한 데이터베이스 B에서 모든 변경 내용을 받았는지 확인합니다. 그런 다음 각 테이블의 ID 범위를 다시 지정했습니다.

   1. 데이터베이스 B에서 sp_requestpeerresponse 실행하고 출력 매개 변수 @request_id 검색합니다. b단계로 이동합니다.

   2. 기본적으로 배포 에이전트는 지속적으로 실행되도록 설정됩니다. 따라서 토큰은 모든 노드에 자동으로 전송되어야 합니다. 배포 에이전트가 연속 모드에서 실행되고 있지 않으면 에이전트를 실행합니다. 자세한 내용은 복제 에이전트 실행 파일 개념 또는 복제 에이전트 시작 및 중지(SQL Server Management Studio)를 참조하세요. c단계로 이동합니다.

   3. b단계에서 검색된 @request_id 값을 제공하여 sp_helppeerresponses 실행합니다. 모든 노드가 피어 요청을 수신했음을 나타낼 때까지 기다립니다. d단계로 이동합니다.

   4. DBCC CHECKIDENT를 사용하여 데이터베이스 B의 각 테이블을 다시 지정하여 적절한 범위가 사용되는지 확인합니다. 10단계로 이동합니다.

   ID 범위를 관리하는 방법에 대한 자세한 내용은 ID 열 복제의 "수동 ID 범위 관리를 위한 범위 할당" 섹션을 참조하세요.

10. 이 시점에서 데이터베이스 B 와 데이터베이스 C 는 직접 연결되지 않지만 데이터베이스 A를 통해 변경 내용을 받습니다. 토폴로지에서 SQL Server 2005를 실행하는 노드가 포함된 경우 11단계로 이동합니다. 그렇지 않으면 12단계로 이동합니다.

11. 시스템을 정지한 다음 데이터베이스 B 와 C 간에 구독을 다시 만듭니다. 시스템 정지에는 모든 노드에서 게시된 테이블에 대한 작업을 중지하고 각 노드가 다른 모든 노드에서 모든 변경 내용을 수신했는지 확인하는 작업이 포함됩니다.

    1. 피어 투 피어 토폴로지의 게시된 테이블에 대한 모든 작업을 중지합니다. b단계로 이동합니다.

    2. 데이터베이스 B에서 sp_requestpeerresponse 실행하고 출력 매개 변수 @request_id 검색합니다. c단계로 이동합니다.

    3. 기본적으로 배포 에이전트는 지속적으로 실행되도록 설정됩니다. 따라서 토큰은 모든 노드에 자동으로 전송되어야 합니다. 배포 에이전트가 연속 모드에서 실행되고 있지 않으면 에이전트를 실행합니다. d단계로 이동합니다.

    4. b단계에서 검색된 @request_id 값을 제공하여 sp_helppeerresponses 실행합니다. 모든 노드가 피어 요청을 수신했음을 나타낼 때까지 기다립니다. e단계로 이동합니다.

    5. 데이터베이스 C의 게시에 대한 구독을 데이터베이스 B에서 다시 생성하고, 구독자가 이미 데이터를 가지고 있음을 명시합니다. b단계로 이동합니다.

    6. 구독자가 이미 데이터를 가지고 있음을 명시하여, 데이터베이스 B의 게시에 대해 데이터베이스 C에 구독을 다시 생성하십시오. 13단계로 이동합니다.

12. 데이터베이스 B와 C 간에 구독을 다시 만듭니다.

    1. 데이터베이스 B에서 MSpeer_lsns 테이블을 쿼리하여 데이터베이스 B 가 데이터베이스 C에서 받은 가장 최근 트랜잭션의 LSN(로그 시퀀스 번호)을 검색합니다.

    2. 데이터베이스 B에서 데이터베이스 C의 게시에 대한 구독을 다시 만들고, 구독을 LSN(sp_addsubscription @sync_type 매개 변수의 lsn에서 초기화값)에 따라 초기화하도록 지정합니다. b단계로 이동합니다.

    3. 데이터베이스 B의 게시에 대한 구독을 데이터베이스 C에서 다시 생성하고, 구독자에게는 이미 데이터가 있음을 명시합니다. 13단계로 이동합니다.

13. 배포 에이전트를 실행하여 데이터베이스 B 및 C에서 구독을 동기화합니다. 복원이 완료되었습니다.

msdb 데이터베이스(게시자)

1. msdb 데이터베이스의 최신 백업을 복원합니다.

2. 복원된 백업이 완료되었고 up-to-date인가요? 모든 게시 및 구독에 대한 최신 구성이 포함되어 있나요? 그렇다면 복구가 완료됩니다. 없는 경우 3단계로 이동합니다.

3. 복제 스크립트에서 구독 정리 작업을 다시 만듭니다. 복구가 완료되었습니다.

마스터 데이터베이스 (Publisher)

1. master 데이터베이스의 최신 백업을 복원합니다.

2. 데이터베이스가 복제 구성 및 설정과 관련하여 게시 데이터베이스와 일치하는지 확인합니다.

배포자의 데이터베이스

배포 데이터베이스

1. 배포 데이터베이스의 최신 백업을 복원합니다.

2. 오류가 발생하기 전에 배포 데이터베이스에서 백업 설정과의 동기화 를 사용하도록 설정되었나요? 그렇다면 3단계로 이동합니다. 아니요이면 4단계로 이동합니다.

   설정을 사용하도록 설정하면 쿼리 SELECT DATABASEPROPERTYEX('<DistributionDatabaseName>', 'IsSyncWithBackup') 는 '1'을 반환합니다.

3. 복원된 백업이 제대로 완료되었으며 up-to이 최신 상태인가요? 모든 게시 및 구독에 대한 최신 구성이 포함되어 있나요? 그렇다면 복구가 완료됩니다. 없는 경우 4단계로 이동합니다.

4. 복원된 배포 데이터베이스의 구성 정보가 up-to없거나 백업과 동기화 옵션이 배포 데이터베이스에 설정되지 않았습니다. (복원 후 배포 데이터베이스에 게시자에서 커밋되었지만 아직 구독자에게 배달되지 않은 트랜잭션이 누락되었을 수 있습니다.) 복제를 삭제하고 다시 만든 다음 유효성 검사를 실행합니다.

   1. 게시자, 배포자 및 구독자에서 복제 구성을 제거한 다음 구성을 다시 만듭니다. 구독을 다시 만들 때 구독자에 이미 데이터가 있는지 지정합니다. b단계로 이동합니다.

      복제를 제거하는 방법에 대한 자세한 내용은 sp_removedbreplication(Transact-SQL)를 참조하세요.

      구독자에 이미 데이터가 있음을 지정하는 방법에 대한 자세한 내용은 수동으로 구독 초기화를 참조하세요.

   2. 유효성 검사를 위해 모든 게시를 표시합니다. 유효성 검사에 실패한 구독을 다시 초기화합니다. 복구가 완료되었습니다.

      유효성 검사에 대한 자세한 내용은 복제된 데이터 유효성 검사를 참조하세요. 다시 초기화에 대한 자세한 내용은 구독 다시 초기화를 참조하세요.

msdb 데이터베이스(배포자)

1. msdb 데이터베이스의 최신 백업을 복원합니다.

2. 복원된 백업이 완료된 상태이며 up-to-date인가요? 모든 게시 및 구독에 대한 최신 구성이 포함되어 있나요? 그렇다면 복구가 완료됩니다. 없는 경우 3단계로 이동합니다.

3. 게시자, 배포자 및 구독자에서 복제 구성을 제거한 다음 구성을 다시 만듭니다. 구독을 다시 만들 때 구독자에 이미 데이터가 있는지 지정합니다. 4단계로 이동합니다.

   복제를 제거하는 방법에 대한 자세한 내용은 sp_removedbreplication(Transact-SQL)를 참조하세요.

   구독자에 이미 데이터가 있음을 지정하는 방법에 대한 자세한 내용은 수동으로 구독 초기화를 참조하세요.

4. 유효성 검사를 위해 모든 게시를 표시합니다. 유효성 검사에 실패한 구독을 다시 초기화합니다. 복구가 완료되었습니다.

   유효성 검사에 대한 자세한 내용은 복제된 데이터 유효성 검사를 참조하세요. 다시 초기화에 대한 자세한 내용은 구독 다시 초기화를 참조하세요.

master Database(배포자)

1. master 데이터베이스의 최신 백업을 복원합니다.

2. 데이터베이스가 복제 구성 및 설정과 관련하여 게시 데이터베이스와 일치하는지 확인합니다.

구독자의 데이터베이스

구독 데이터베이스

1. 최신 구독 데이터베이스 백업이 배포 데이터베이스의 최소 배포 보존 설정보다 더 최근인가요? (이렇게 하면 배포자에 구독자 up-to-date를 가져오는 데 필요한 모든 명령이 여전히 있는지 여부가 결정됩니다.) 그렇다면 2단계로 이동합니다. 그렇지 않은 경우 구독을 다시 초기화합니다. 복구가 완료되었습니다.

   최대 배포 보존 설정을 확인하려면 sp_helpdistributiondb 실행하고 max_distretention 열에서 값을 검색합니다(이 값은 시간 단위).

   구독을 다시 초기화하는 방법에 대한 자세한 내용은 구독 다시 초기화를 참조하세요.

2. 최신 구독 데이터베이스 백업을 복원합니다. 3단계로 이동합니다.

3. 구독 데이터베이스에 밀어넣기 구독만 포함된 경우 4단계로 이동합니다. 구독 데이터베이스에 끌어오기 구독이 포함된 경우 다음 질문을 합니다. 구독 정보가 최신인가요? 데이터베이스에 실패 시 설정된 모든 테이블 및 옵션이 포함됩니까? 그렇다면 4단계로 이동합니다. 그렇지 않은 경우 구독을 다시 초기화합니다. 복구가 완료되었습니다.

4. 구독자를 동기화하려면 배포 에이전트를 실행합니다. 복구가 완료되었습니다.

   배포 에이전트를 실행하는 방법에 대한 자세한 내용은 복제 에이전트 시작 및 중지(SQL Server Management Studio) 및 복제 에이전트 실행 파일 개념을 참조하세요.

msdb 데이터베이스(구독자)

1. msdb 데이터베이스의 최신 백업을 복원합니다. 풀 구독은 이 구독자에서 사용됩니까? 그렇지 않으면 복원이 완료됩니다. 그렇다면 2단계로 이동합니다.

2. 복원된 백업이 완료되고 up-to-date인가요? 모든 끌어오기 구독에 대한 최신 구성이 포함되어 있나요? 그렇다면 복구가 완료됩니다. 없는 경우 3단계로 이동합니다.

3. 끌어오기 구독을 삭제하고 다시 만듭니다. 구독을 다시 만들 때 구독자에 이미 데이터가 있는지 지정합니다. 복원이 완료되었습니다.

   구독 삭제 방법에 대한 자세한 내용은 게시물 구독하기를 참조하세요.

   구독자에 이미 데이터가 있음을 지정하는 방법에 대한 자세한 내용은 수동으로 구독 초기화를 참조하세요.

master Database (구독자)

1. master 데이터베이스의 최신 백업을 복원합니다.

2. 데이터베이스가 복제 구성 및 설정과 관련하여 게시 데이터베이스와 일치하는지 확인합니다.

또한 참조하십시오

SQL Server 데이터베이스 백업 및 복원
복제된 데이터베이스 백업 및 복원
배포 구성
데이터 및 데이터베이스 개체 게시
게시 구독
구독을 초기화하기
데이터 동기화