(2 업데이트를 2012년 12월 6일에서 - 새로운 프로토콜하는 sligtly 다른보기)SQL 서비스 브로커 : 데이터 수집은 - 플러그 - 인 시나리오 분석
문제는이 솔루션은 아래 타당 여부를 (SQL Server Service Broker를 처음 사용하는 경우) ...
SQL Service Broker: Collecting data from distributed sources에 제시된 문제의 분석을 계속하고 싶습니다. 필자는 위성 SQL 서버에서 데이터를 수집 할 때 사용할 프로토콜 문제에 중점을두고 자합니다. SQL Server Service Broker의 사용법은 필수 항목입니다. 여기에 제시되지 않은 다른 이유들로 인해 결정됩니다. 그럼, 제발, 완전히 다른 대안을 제안하지 마십시오.
내가 수행해야 어떤 내용과 방법 정확한 문제에 대한 (최상의 방법) 자연스럽게 서비스 브로커를 사용하는 방법에 초점을하고 싶습니다. 전반적인 목표는 was presented in the above mentioned question입니다. 첫번째 사진 :
이제 자세한 내용은
은 플러그인 아키텍처
기계가 실제 물리적 인 생산 라인에 관련된 위성를 원 ... 생각합니다. 그것은 몇 가지 기계 기술 과정에 추가되었는지, 어떤 기계가 어떤 기계가이 같은 생산 라인 식별을 사용하는 의미에서 교체 할 수 있습니다 사라질 수 일어날 수 있지만, 물리적으로 다른 - 자사의 SQL 서버가 다른 즉, 예. 그것에서 첫 번째 메시지를 때까지
중앙 서버는 위성에 대해 아무것도 모른다. 위성 서버의 중앙 데이터베이스가 없습니다. 시스템에 포함될 위성 SQL Server의 수와 수에 대한 지식이 없습니다. 그것은 항상 위성 사이트에서 결정됩니다.
데이터 수집에 관련된 모든 활동
은 위성 기계에 의해 생성 된 이벤트에 의해 시작되어야한다.중요 : 목표는 새로 생성 된 모든 데이터 (센서에서)를 지속적으로 전송하고 드롭 아웃을 발견하여 해결할 수 있습니다.
(노란색) 3 호선에 의해 확인 된 기계가 최근 환경에 추가되었습니다
당신에게 구체적인 예를 제공합니다. SQL Server Express가 시작되어 센서 데이터 (타사 솔루션, 특수 구조가있는 전용 테이블)를 수집하기 시작했습니다. 기계가 아직 중앙 서버에 연결되지 않았습니다.유일한 구성 점은 생산 라인 (여기서는 3)의 신뢰성 할당 된 고정 식별하고, 모든이 켜지지 세부 사항은 중앙 SQL 서버에 연결할 수 있습니다. 그러나 중앙 SQL 서버는 정보를 알지 못합니다. 센터는 새로운 souce의 데이터를 수용 할 준비가되었지만 언제 알 수 없습니다. (이미 SQL Service Broker — one central SQL and more satelite SQL…이라는 질문에 한 기계 using the approach suggested by Remus Rusanu answer에 대해 테스트를 마쳤습니다.)
SQL 소프트웨어는 컴퓨터 3에 약간 배포됩니다. 그것은 중앙과 이야기하기 시작합니다. 위성 부분 벙어리 아니지만 자체 활성 새로운 레코드가 센서 데이터 테이블 (위의 포인트 1 참조)에 삽입 될 때마다, 센서 데이터를 전송한다.레코드에서 UTC 시간이 독점 형식에서 계산되면 한 레코드의 여러 센서 데이터가 같은 수의 정규화 된 레코드 (하나의 XML 메시지로 포맷 됨)로 변환되어 중앙 SQL 서버로 전송됩니다.
중앙 장치는 위성 시스템에서 보낸 센서 데이터가있는 메시지로 활성화됩니다. 물리적 연결의 실패는 Service Broker 큐에 의해 가려집니다.
합리적인 간격 (여기서는 1 시간) 후에 중앙 서버는 지금까지 수집 된 데이터를 처리해야하는지 여부를 확인합니다. 생산 시간이 걸리는 작업 단위가 있으며 데이터는 처리되어 장치의 문서에 추가되어야합니다. 처리는 장치가 완료되었을 때에 만 이루어져야합니다.
또한 중앙에서는 유닛에 대한 모든 데이터가 있는지 여부도 확인합니다. 센서 샘플링은 알려진 일정한 간격 (약 1 분)으로 수행되므로 중앙에서는 드롭 아웃이 있는지 확인할 수 있습니다. 위성이 SSB를 통해 중앙에 연결되지 않은 시간 간격에 대한 초기 "드롭 아웃"도 있습니다. 메커니즘은 어떤 상황에서도 회복되어야합니다. 또한 센서가 고장난 곳이나 데이터가 수집되지 않을 수도 있습니다. 중앙에서 감지 된 드롭 아웃은 실제로 중앙에서 묻는 의미 일 수 있습니다. "이 시간 간격 동안 사용자로부터받은 데이터가 없습니다. 존재하는 경우 그 중 일부를 보내거나 존재하지 않는다고 말해주십시오."
위성은 샘플링 시간 사이에 보낼 수있는 많은 양의 데이터 만 보내야합니다. 탈락에서의 회복은 다소 느릴 수 있습니다. 중앙 서버에서의 데이터 처리 지연은 중요하지 않습니다. 그러나 중앙에서 데이터가 준비되었는지 (또는 감지 된 시간 간격 동안 존재하지 않는지) 알아야합니다.
일부 사진 더 솔루션의 자세한 사항
내가 위성과 중앙 사이의 통신을위한 기본 프레임 워크로 "Recycling conversations" by Remus Rusanu을 선택했습니다. 대화 처리 핸들을 버려야하고 새 대화 핸들을 사용해야 함을 알리기 위해 EndOfStream 메시지 유형을 정의합니다. 수명은 Service Broker 타이머에 의해 생성 된 위에서 언급 한 1 시간 간격으로 제한됩니다.
메시지는 데이터 처리 활성화를 위해 중앙 서버에서 (잘못) 사용됩니다. 거의 동시에 중앙 부서는 탈락을 확인합니다. 중앙에서는 드롭 아웃이 이미 체크 된 곳보다 아래의 시간을 유지합니다. 이렇게하면 처리 할 준비가 된 데이터를 알 수 있습니다.
시나리오가 합리적이라고 생각하십니까? 문제가 생길 수 있습니까?
당신의 시간과 경험에 대한감사합니다 (I은. 당신의 제안을 반영하기 위해 질문을 수정하기 위하여려고하고있다), 그리고 좋은 하루 되세요.
페트르