특정 테이블의 스냅샷을 하루에 두 번씩 전달하는 잘 연결된 원격 사이트가 있습니다. 스냅샷 복제는 기본 애플리케이션의 스키마 제한을 기반으로 사용할 수 있는 유일한 방법입니다.
스냅샷은 UNC 경로와 FTP를 통해 게시되며 약 6MB로 상당히 작습니다. 실제로 FTP가 사용되는지 UNC가 사용되는지 100% 확신할 수 없습니다. 스냅샷이 snapshot.cab 파일로 압축된 후 복제 모니터에 적용된 첫 번째 스크립트가 표시될 때까지 약 5분 정도 소요되므로 그 간격을 전송 시간으로 가정합니다. FTP를 통해 3MB 연결을 통해 많은 데이터를 복사하는 데 시간이 훨씬 적게 걸린다는 점을 고려하면 UNC/SMB가 좋다고 생각합니다.
스냅샷을 로드하는 데 약 25분 정도 더 소요되는데, 이는 적당한 양의 데이터에 비해 많은 시간처럼 보입니다. 많은 행(여러 테이블에 100,000개의 행이 있음)이 있지만 실제 데이터 양은 매우 적습니다.
구독자는 3GB RAM을 갖춘 2.8GHz ProLiant에서 SQLExpress 2005를 실행 중이며 그렇지 않은 경우에는 사용하지 않습니다. 디스크 경합이 있는지 또는 다른 문제가 발생하는지 확인하기 위해 아직 광범위한 프로파일링을 수행하지 않았습니다.
여기에 가능한 속도 제한기가 무엇인지, 속도를 높일 수 있는 방법이 있는지 궁금합니다. 6MB의 압축 데이터를 복사하고 로드하는 데 30분은 긴 시간처럼 보입니다.
답변1
원격 측에 SQL Express가 있으므로 푸시 구독만 수행할 수 있으므로 옵션이 매우 제한됩니다.
복제가 작동하는 방식은 데이터가 이진 파일로 BCP되는 것입니다. 복제 에이전트는 스냅샷이 완료되었음을 확인하면 BCP를 사용하여 네트워크를 통해 구독자에게 데이터를 로드합니다. 네트워크를 통한 BCP는 지금까지 가장 빠른 프로세스는 아닙니다.