다음을 통해 공유


변경 내용 추적 및 데이터 복원

동기화가 필요한 응용 프로그램에서는 변경 내용 추적이 설정된 데이터베이스를 이전 버전의 데이터로 되돌리는 경우를 고려해야 합니다. 이런 경우는 백업에서 데이터베이스가 복원된 후, 비동기 데이터베이스 미러링에 장애 조치가 있는 경우 또는 로그 전달을 사용할 때 실패한 경우에 발생할 수 있습니다. 다음 시나리오에서는 이러한 문제를 보여 줍니다.

  1. 테이블 T1은 변경 내용이 추적되고 테이블의 유효한 최소 버전 50입니다.

  2. 클라이언트 응용 프로그램은 버전 100에서 데이터를 동기화하고 버전 50과 100 사이의 모든 변경 사항에 대한 정보를 가져옵니다.

  3. 버전 100 이후 추가 변경 내용이 테이블 T1에 적용됩니다.

  4. 버전 120에서 오류가 발생하고 데이터베이스 관리자는 데이터베이스를 복원하지만 데이터 손실이 있습니다. 복원 작업 후 테이블에는 버전 70까지 데이터가 포함되고 동기화된 최소 버전은 여전히 50입니다.

    즉, 동기화된 데이터 저장소에는 주 데이터 저장소에 더 이상 존재하지 않는 데이터가 있습니다.

  5. T1은 여러 번 업데이트되어서 현재 버전은 130입니다.

  6. 클라이언트 응용 프로그램은 다시 동기화하고 마지막으로 동기화된 버전인 100을 제공합니다. 100은 50보다 크기 때문에 클라이언트는 성공적으로 이 번호의 유효성을 검사합니다.

    클라이언트는 버전 100과 130 사이의 변경 내용을 가져옵니다. 이 지점에서 클라이언트는 이전과 다른 70과 100 사이의 변경 내용을 인식하지 못합니다. 클라이언트와 서버의 데이터는 동기화되지 않았습니다.

데이터베이스가 버전 100 이후 지점으로 복구되면 동기화에 아무 문제가 없습니다. 클라이언트와 서버는 다음 동기화 간격 동안 데이터를 올바르게 동기화합니다.

변경 내용 추적은 데이터 손실의 복구를 지원하지 않지만 이러한 세 가지 유형의 동기화 문제를 감지할 수 있는 다음 두 가지 옵션을 가지고 있습니다.

  • 데이터베이스 버전 ID를 서버에 저장하고 데이터베이스가 복구될 때마다 이 값을 업데이트합니다. 그렇지 않으면 데이터가 손실됩니다. 데이터를 동기화할 때 각 클라이언트 응용 프로그램은 ID를 저장하고 각 클라이언트는 이 ID의 유효성을 검사해야 합니다. 데이터 손실이 발생하면 ID가 일치하지 않고 클라이언트가 다시 초기화됩니다. 한 가지 단점은 데이터 손실이 마지막으로 동기화된 경계에 교차되지 않은 경우에 클라이언트가 불필요하게 다시 초기화해야 할 수도 있다는 점입니다.

  • 클라이언트가 변경 내용에 대해 쿼리할 때 서버의 각 클라이언트에 대한 마지막 동기화 버전을 기록합니다. 데이터에 문제가 있으면 마지막으로 동기화된 버전 번호가 일치하지 않습니다. 이것은 다시 동기화해야 한다는 것을 나타냅니다.