다음을 통해 공유

MessageBox 데이터베이스에서 병목 상태를 식별하는 방법

  • 아티클

MessageBox 데이터베이스의 병목 상태를 확인하려면 먼저 SQL Server 에이전트 서비스가 시작되었는지 확인합니다. 서버를 다시 시작하면 서비스가 자동으로 다시 시작되도록 서비스 시작 상태를 수동에서 자동으로 변경합니다.

기본적으로 BizTalk 서비스는 스풀, TrackingData 또는 ApplicationQ 테이블이 증가하는 경우 제한됩니다. 이러한 테이블은 SQL-Agent 작업에 의해 정리되며, 실행되지 않으면 스풀이 증가하여 제한이 시작되고 추가 압력으로부터 데이터베이스를 보호합니다. 다음 성능 카운터의 상태를 확인합니다.

스풀 테이블 증가

스풀은 여러 이유로 증가될 수 있습니다. 스풀이 증가하는 한 가지 이유는 애플리케이션 큐가 증가하는 경우입니다. 다운스트림 병목 상태 및/또는 리소스 경합과 같은 이유로 인해 증가할 수 있습니다.

애플리케이션 큐가 작고 스풀이 여전히 큰 경우 제거 작업이 유지되는지 확인합니다. SQL 에이전트 서비스가 실행되고 있는지, 다음 작업이 성공적으로 완료되고 있는지 확인합니다.

  • MessageBox_Message_Cleanup_BizTalkMessageBoxDb

  • MessageBox_Parts_Cleanup_BizTalkMessageBoxDb

    MessageZeroSum 테이블이 크면 메시지가 처리되었음을 나타냅니다. 즉, DeQueue가 애플리케이션 큐 테이블에서 데이터를 성공적으로 완료하고 삭제했으며 행은 삭제 플래그가 지정되었습니다. 제거 작업이 미처 데이터를 삭제하지 못하고 있음을 알 수 있습니다. 이 문제는 SQL Server 실행하는 컴퓨터에서 CPU 경합이 심하여 CPU 부족으로 인해 제거 작업이 계속 수행되는 기능에 영향을 주는 경우에 발생할 수 있습니다.

애플리케이션 큐 테이블 증가

애플리케이션 큐는 처리되면 DeQueue에서 정리되는 진행 중인 전환 데이터를 호스트합니다.

이러한 메시지가 처리되면 스풀 테이블(이러한 행에 대한 참조 보유)을 정리할 수 있습니다.

예를 들어 RxHostQ는 오케스트레이션 PxHostQ에 데이터를 게시합니다. 이 큐는 각각 스풀 테이블의 행을 참조하는 전송 TxHostQ에 데이터를 게시합니다. 특정 HostQ에 대한 메시지가 시스템을 통해 성공적으로 처리되면 이러한 행은 DeQueue에 의해 삭제됩니다. 행이 삭제되고 나면 제거 작업에서 더 이상 이러한 행이 참조하지 않는 스풀을 정리할 수 있습니다.

애플리케이션 큐 증가는 애플리케이션 큐를 드레이닝하는 호스트 인스턴스가 들어오는 속도를 따라잡을 수 없음을 나타냅니다.

예를 들어 오케스트레이션 처리를 담당하는 서버가 CPU 제약으로 인해 더 빨리 처리할 수 없어서 오케스트레이션 애플리케이션 큐(PxHostQ)가 증가할 수 있습니다. 그러나 수신 서버가 빠르면 오케스트레이션 서버가 처리할 수 있는 것보다 빠르게 게시되어 애플리케이션 큐가 증가합니다.

오케스트레이션 큐 증가의 또 다른 이유는 메모리 경합 때문일 수 있습니다. 많은 장기 실행 오케스트레이션 인스턴스가 메모리에서 동시에 인스턴스화되는 경우 메모리 bloat은 간접적으로 제한으로 인해 메모리 압력이 완화될 때까지 스레드 풀을 축소합니다.

송신 애플리케이션 큐가 증가할 수 있는 이유는 다운스트림 시스템에서 메시지를 충분히 빨리 받을 수 없는 경우(BizTalk Server) 때문입니다. 따라서 메시지가 BizTalk 시스템 내에 계속 상주하여 애플리케이션 큐가 증가합니다. 이로 인해 제한이 시작되고 시스템의 전체 처리량에 영향을 주는 수신 속도를 줄일 수 있습니다.

TrackingData 테이블 증가

MessageBox 데이터베이스의 TrackingData 테이블은 인터셉터가 HAT(상태 및 활동) 및 BAM(비즈니스 활동 모니터링) 추적 모두에 대한 추적 데이터를 쓰는 전환 테이블입니다. 추적이 해제된 경우 이 테이블은 비어 있어야 합니다. 기본적으로 HAT 추적은 파이프라인 및 오케스트레이션 In/Out 이벤트에 대해 사용하도록 설정됩니다.

메시지 본문 추적을 사용하도록 설정하면 MessageBox 데이터베이스 서버(즉, "호스트 추적 허용"이 있는 호스트)가 실행 중인지 확인합니다. 호스트가 MessageBox 데이터베이스의 TrackingData 테이블에서 BizTalk 추적 데이터베이스 테이블로 데이터를 이동할 때 "호스트 추적 허용"이 실행 중인지 확인하면 병목 현상이 발생할 가능성이 줄어듭니다.

예를 들어 승격된 속성 및 메시지 본문 추적에서 사용자 지정 HAT 추적을 사용하도록 설정하여 사용자 지정 이벤트를 추적할 수 있습니다. HAT 추적 데이터 외에도 BAM 데이터는 TrackingData 테이블에 기록됩니다. 추적이 사용되는 호스트 instance 실행되는 TDDS(추적 데이터 디코딩 서비스)는 이 데이터를 MessageBox 데이터베이스에서 BizTalk 추적 및 BAM 기본 가져오기 데이터베이스로 이동하는 작업을 담당합니다. 그런 다음 데이터가 성공적으로 이동되면 TDDS에서 이 데이터를 삭제합니다. 메시지 본문 추적 데이터는 SQL 에이전트 작업 TrackedMessages_Copy_BizTalkMsgBoxDb에 의해 별도로 이동됩니다.

TDDS가 인터셉터가 TrackingData 테이블에 데이터를 쓰는 속도를 따라갈 수 없는 경우 이 테이블이 증가하여 제한이 시작됩니다. 이는 지속 가능한 처리량에 영향을 줍니다. 이 문제를 줄이려면 추적을 사용하도록 설정된 호스트가 하나 이상 실행되고 있는지 확인합니다.

데이터가 계속 빌드되는 경우 BizTalk 추적 데이터베이스가 통제 불능 상태가 되지 않는지 확인합니다. 또한 보관 및 제거 작업이 실행 중이고 데이터가 도착하는 속도를 따라갈 수 있는지 확인합니다.

참고

기본적으로 제거 작업은 이 데이터가 보관될 때까지 BizTalk 추적 데이터베이스 테이블에서 데이터를 삭제할 수 없습니다. 추적 데이터를 보관할 필요가 없는 경우 BizTalk 추적 데이터베이스에서 데이터를 제거하는 방법(https://go.microsoft.com/fwlink/?LinkID=153817)의 단계에 따라 보관하지 않고 BizTalk 추적 데이터베이스를 제거하도록 작업을 수정할 수 있습니다.

참고 항목

데이터베이스 계층의 병목 상태