BizTalk Server 데이터베이스 유지 관리 및 문제 해결

이 문서에서는 BizTalk Server 데이터베이스를 유지 관리하고 문제를 해결하는 방법에 대한 자세한 정보를 제공합니다.

원래 제품 버전: BizTalk Server 데이터베이스
원래 KB 번호: 952555

요약

성공적인 BizTalk Server 메시징 환경에서는 Microsoft BizTalk Server 데이터베이스의 상태가 중요합니다. 이 문서에서는 BizTalk Server 데이터베이스를 사용할 때 고려해야 할 중요한 사항에 대해 설명합니다. 이러한 고려 사항은 다음과 같습니다.

  • auto create statistics SQL Server 옵션을 사용하지 않도록 설정 auto update statistics 해야 합니다.
  • (MAXDOP) 옵션을 올바르게 설정 max degree of parallelism 해야 합니다.
  • BizTalk Server 인덱스를 다시 작성할 수 있는 시기를 결정합니다.
  • 잠금, 교착 상태 또는 차단이 발생할 수 있습니다.
  • 큰 데이터베이스 또는 테이블에 문제가 발생할 수 있습니다.
  • BizTalk SQL Server 에이전트 작업.
  • 서비스 인스턴스가 일시 중단될 수 있습니다.
  • SQL Server 및 BizTalk Server 성능 문제가 발생할 수 있습니다.
  • BizTalk Server 모범 사례를 따라야 합니다.

소개

이 문서에서는 BizTalk Server 데이터베이스를 유지하는 방법과 BizTalk Server 데이터베이스 문제를 해결하는 방법을 설명합니다.

자동 통계 만들기 및 통계 자동 업데이트 옵션을 사용하지 않도록 설정해야 합니다.

데이터베이스에서 auto create statisticsauto update statistics 옵션을 사용하지 않도록 BizTalkMsgBoxDb 설정해야 합니다. 이러한 설정을 사용하지 않도록 설정할지 여부를 확인하려면 SQL Server 다음 저장 프로시저를 실행합니다.

EXEC sp_dboption 'BizTalkMsgBoxDB', 'auto create statistics'
EXEC sp_dboption 'BizTalkMsgBoxDB', 'auto update statistics'

현재 설정을 off로 설정해야 합니다. 이 설정이 로 on설정된 경우 SQL Server 다음 저장 프로시저를 실행하여 해제합니다.

EXEC sp_dboption 'BizTalkMsgBoxDB', 'auto create statistics', 'off'
EXEC sp_dboption 'BizTalkMsgBoxDB', 'auto update statistics', 'off'

Max Degree of Parallelism 속성을 올바르게 설정해야 합니다.

SQL Server 실행하고 데이터베이스를 BizTalkMsgBoxDb 호스팅하는 컴퓨터에서 최대 병렬 처리 run_value 수준 및 config_value 속성을 값 1로 설정합니다. 이후 SQL 버전에서는 SQL instance 대신 데이터베이스당 이 설정을 지정할 수도 있습니다. 자세한 내용은 MAXDOP 설정을 참조하세요. 설정을 확인 max degree of parallelism 하려면 SQL Server Master 데이터베이스에 대해 다음 저장 프로시저를 실행합니다.

EXEC sp_configure 'show advanced options', 1;
GO
EXEC sp_configure 'max degree of parallelism'

config_value 속성이 run_value1로 설정되지 않은 경우 SQL Server 다음 저장 프로시저를 실행하여 1로 설정합니다.

EXEC sp_configure 'show advanced options', 1;
GO
RECONFIGURE WITH OVERRIDE;
GO
EXEC sp_configure 'max degree of parallelism', 1;
GO
RECONFIGURE WITH OVERRIDE;
GO

BizTalk Server 인덱스를 다시 작성할 수 있는 시기 결정

대부분의 BizTalk Server 인덱스는 클러스터형입니다(인덱스 ID: 1). SQL Server 문을 사용하여 DBCC SHOWCONTIG BizTalk Server 테이블에 대한 조각화 정보를 표시할 수 있습니다.

BizTalk Server 인덱스는 GUID 기반입니다. 따라서 조각화는 일반적으로 발생합니다. 문에서 반환 DBCC SHOWCONTIG 하는 스캔 밀도 값이 30% 미만이면 가동 중지 시간 동안 BizTalk Server 인덱스를 다시 작성할 수 있습니다.

많은 BizTalk Server 테이블에는 정의를 사용하는 DataType 열이 포함되어 있습니다. 이러한 열에서는 온라인 인덱싱을 수행할 수 없습니다. 따라서 BizTalk Server 데이터를 처리하는 동안 BizTalk Server 인덱스를 다시 빌드해서는 안 됩니다.

잠금, 교착 상태 또는 차단이 발생할 수 있습니다.

일반적으로 잠금 및 블록은 BizTalk Server 환경에서 발생합니다. 그러나 이러한 잠금 또는 블록은 장시간 유지되지 않습니다. 따라서 차단 및 교착 상태는 잠재적인 문제를 나타냅니다.

큰 데이터베이스 또는 테이블에 문제가 발생할 수 있습니다.

데이터베이스가 클 때 BizTalkMsgBoxDb 성능 문제가 발생할 수 있음을 확인했습니다. 이상적으로 데이터베이스는 BizTalkMsgBoxDb 데이터를 보유해서는 안 됩니다. BizTalkMsgBoxDb 데이터가 처리되거나 또는 BAM 데이터베이스로 이동할 때까지 데이터베이스는 버퍼로 BizTalkDTADb 간주되어야 합니다.

백 엔드에서 강력한 SQL Server 사용하고 많은 장기 실행 오케스트레이션을 사용하는 환경에는 5GB보다 큰 데이터베이스가 있을 BizTalkMsgBoxDb 수 있습니다. 장기 실행 오케스트레이션을 사용하지 않는 대용량 환경에는 5GB보다 훨씬 작은 데이터베이스가 있어야 합니다 BizTalkMsgBoxDb .

데이터베이스에 BizTalkDTADb 설정된 크기가 없습니다. 그러나 성능이 저하되면 데이터베이스가 너무 클 수 있습니다. 일부 고객의 경우 20GB가 너무 큰 것으로 간주될 수 있지만, 200GB가 있는 다른 고객의 경우 여러 CPU, 많은 메모리 및 빠른 네트워크 및 스토리지에서 실행되는 매우 강력한 SQL 서버에서 제대로 작동할 수 있습니다. 큰 BizTalk Server 데이터베이스가 있는 경우 다음과 같은 문제가 발생할 수 있습니다.

  • 데이터베이스는 BizTalkMsgBoxDb 계속 증가합니다. 그러나 로그 파일과 데이터 크기는 모두 큽니다.

  • BizTalk Server 간단한 메시지 흐름 시나리오도 처리하는 데 평소보다 시간이 오래 걸립니다.

  • BizTalk 관리 콘솔 또는 HAT(상태 및 활동 추적) 쿼리는 평소보다 시간이 오래 걸리며 시간이 초과할 수 있습니다.

  • 데이터베이스 로그 파일은 잘리지 않습니다.

  • BizTalk SQL Server 에이전트 작업은 평소보다 느리게 실행됩니다.

  • 일부 테이블은 일반적인 테이블 크기에 비해 더 크거나 행이 너무 많습니다.

데이터베이스는 여러 가지 이유로 커질 수 있습니다. 이러한 이유는 다음과 같습니다.

  • BizTalk SQL Server 에이전트 작업이 실행되고 있지 않음
  • 많은 수의 일시 중단된 인스턴스
  • 디스크 오류
  • 추적
  • 제한
  • SQL Server 성능
  • 네트워크 대기 시간

데이터 문제가 발생하는지 여부를 확인하려면 사용자 환경에서 예상되는 사항을 알고 있는지 확인합니다.

기본적으로 추적은 기본 호스트에서 사용하도록 설정됩니다. BizTalk를 사용하려면 단일 호스트에서 호스트 추적 허용 옵션을 선택해야 합니다. 추적을 사용하도록 설정하면 TDDS(추적 데이터 디코드 서비스)가 추적 이벤트 데이터를 데이터베이스에서 BizTalkMsgBoxDb 데이터베이스로 BizTalkDTADb 이동합니다. 추적 호스트가 중지되면 TDDS는 데이터를 데이터베이스로 BizTalkDTADb 이동하지 않으며 데이터베이스의 TrackingData_x_x 테이블이 BizTalkMsgBoxDb 증가합니다.

추적에 하나의 호스트를 바치는 것이 좋습니다. TDDS가 대용량 시나리오에서 새 추적 이벤트를 유지 관리할 수 있도록 하려면 단일 추적 호스트의 여러 인스턴스를 만듭니다. 둘 이상의 추적 호스트가 없어야 합니다.

테이블에 행이 너무 많을 수 있습니다. 너무 많은 행 수가 설정되지 않았습니다. 또한 이 행 수는 테이블에 저장되는 데이터의 종류에 따라 달라집니다. 예를 들어 행이 dta_DebugTrace 100만 개 이상인 테이블에는 행이 너무 많을 수 있습니다. <HostName>Q_Suspended 행이 200,000개 이상인 테이블에는 행이 너무 많을 수 있습니다.

올바른 BizTalk SQL Server 에이전트 작업 사용

BizTalk SQL Server 에이전트 작업은 BizTalk Server 데이터베이스를 관리하고 고성능을 유지하는 데 중요합니다.

백업 BizTalk Server SQL Server 에이전트 작업은 SQL Server 에이전트 및 BizTalkServer 호스트 인스턴스가 시작될 때 BizTalk Server 데이터베이스를 백업하는 유일한 지원되는 방법입니다. 이 작업을 수행하려면 모든 BizTalk Server 데이터베이스에서 전체 복구 모델을 사용해야 합니다. 정상 BizTalk Server 환경에 대해 이 작업을 구성해야 합니다. SQL Server 메서드는 SQL Server 에이전트 중지되고 모든 BizTalk Server 호스트 인스턴스가 중지된 경우에만 BizTalk Server 데이터베이스를 백업하는 데 사용할 수 있습니다.

MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb SQL Server 에이전트 작업은 무한히 실행됩니다. 따라서 SQL Server 에이전트 작업 기록은 성공적인 완료를 표시하지 않습니다. 오류가 발생하면 작업이 1분 이내에 다시 시작되고 무한히 계속 실행됩니다. 따라서 오류를 무시해도 됩니다. 또한 작업 기록을 지울 수 있습니다. 작업 기록이 이 작업이 지속적으로 실패하고 다시 시작한다고 보고하는 경우에만 염려해야 합니다.

MessageBox_Message_Cleanup_BizTalkMsgBoxDb SQL Server 에이전트 작업은 SQL Server 에이전트 작업에서 시작 MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb 되므로 사용하도록 설정해서는 안 되는 유일한 BizTalk Server 작업입니다.

DTA 제거 및 보관 SQL Server 에이전트 작업은 추적된 메시지를 제거하고 보관하여 데이터베이스를 유지하는 BizTalkDTADb 데 도움이 됩니다. 이 작업은 테이블의 모든 행을 읽고 타임스탬프를 비교하여 레코드를 제거할지 여부를 결정합니다.

SQL Server 에이전트 작업을 제외한 MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb 모든 BizTalk SQL Server 에이전트 작업이 성공적으로 실행되어야 합니다.

서비스 인스턴스가 일시 중단될 수 있음

서비스 인스턴스는 일시 중단(다시 시작 가능) 또는 일시 중단(다시 시작할 수 없음)할 수 있습니다. 이러한 서비스 인스턴스는 메시징, 오케스트레이션 또는 포트일 수 있습니다.

이러한 서비스 인스턴스는 데이터베이스를 BizTalkMsgBoxDb 불필요하게 증가시키고 종료할 수 있습니다. 그룹 허브를 사용하여 메시지를 쿼리, 다시 시작 또는 종료할 수 있습니다. Terminate.vbs 스크립트 또는 BHM(BizTalk 상태 모니터) 도구를 사용하여 BizTalk 데이터베이스를 쿼리, 제거 및 유지 관리할 수도 있습니다. 경우에 따라 시스템에 분리되거나 좀비 메시지가 남아 있을 수 있습니다. BHM 도구는 이러한 상황을 해결하는 데 도움이 될 수 있습니다.

Terminate.vbs 스크립트에 대한 자세한 내용은 일시 중단된 서비스 인스턴스 제거를 참조하세요.

캐싱 인스턴스는 그룹 허브 페이지에 표시되지 않으며 일시 중단하거나 종료할 수 없습니다. 이 제한은 테이블 증가의 일반적인 원인입니다. BizTalk Server 2006에서 캐시 서비스 인스턴스에 대한 새 좀비 메시지를 방지하려면 Microsoft 기술 자료 문서 936536 핫픽스를 설치합니다. 이 문제는 BizTalk Server 2006 R2 이상 버전에서 해결되었습니다.

참고

좀비 메시지는 라우팅되었지만 소비되지 않은 메시지입니다.

좀비 메시지에 대한 설명은 다음 MSDN 웹 사이트 BizTalk Core 엔진의 WebLog를 참조하세요.

SQL Server 및 BizTalk Server 성능 문제가 발생할 수 있습니다.

BizTalk Server 1분 내에 수백 개의 짧고 빠른 트랜잭션을 SQL Server. SQL Server 이 활동을 유지할 수 없는 경우 BizTalk Server 성능 문제가 발생할 수 있습니다. 성능 모니터 PhysicalDisk 성능 개체에서 Avg. Disk sec/Read, Avg. Disk sec/TransferAvg. Disk sec/Write 성능 모니터 카운터를 모니터링합니다. 최적 값은 10ms(밀리초) 미만입니다. 20ms 이상의 값은 성능 저하로 간주됩니다.

BizTalk Server 모범 사례

SQL Server SQL Server 에이전트 시작합니다. SQL Server 에이전트 중지되면 데이터베이스 유지 관리를 담당하는 기본 제공 BizTalk SQL Server 에이전트 작업을 실행할 수 없습니다. 이 동작으로 인해 데이터베이스가 증가하면 성능 문제가 발생할 수 있습니다.

SQL Server LDF(로그 데이터베이스 파일) 및 MDF(주 데이터베이스 파일) 파일을 별도의 드라이브에 배치합니다. 및 BizTalkDTADb 데이터베이스에 대한 BizTalkMsgBoxDb LDF 및 MDF 파일이 동일한 드라이브에 있는 경우 디스크 경합이 발생할 수 있습니다.

메시지 본문 추적의 이점이 없는 경우 이 기능을 사용하도록 설정하지 마세요. 그러나 솔루션을 개발하고 문제를 해결하는 동안 메시지 본문 추적을 사용하도록 설정하는 것이 좋습니다. 이 작업을 수행하는 경우 완료되면 메시지 본문 추적을 사용하지 않도록 설정해야 합니다. 메시지 본문 추적을 사용하도록 설정하면 BizTalk Server 데이터베이스가 증가합니다. 메시지 본문 추적을 사용하도록 설정해야 하는 비즈니스 요구 사항이 있는 경우 및 DTA 제거 및 보관 SQL Server 에이전트 작업이 성공적으로 실행되고 있는지 TrackedMessages_Copy_BizTalkMsgBoxDb 확인합니다.

일반적으로 트랜잭션 로그가 작을수록 성능이 향상됩니다. 트랜잭션 로그를 더 작게 유지하려면 백업 BizTalk Server SQL Server 에이전트 작업을 더 자주 실행하도록 구성합니다.

sp_ForceFullBackup 데이터베이스의 저장 프로시저를 BizTalkMgmtDb 사용하여 데이터 및 로그 파일의 임시 전체 백업을 수행할 수도 있습니다. 저장 프로시저는 테이블을 값 1로 업데이트합니다 adm_ForceFullBackup . 다음에 Backup BizTalk Server 작업이 실행되면 전체 데이터베이스 백업 집합이 만들어집니다.

BHM(BizTalk 상태 모니터) 도구를 사용하여 기존 BizTalk Server 배포를 평가할 수 있습니다. BHM은 수많은 데이터베이스 관련 검사를 수행합니다.

문제 해결

BizTalk Server SQL Server 데이터베이스에 대한 최상의 문제 해결 단계는 차단 또는 교착 상태와 같은 데이터베이스 문제의 종류에 따라 달라집니다. BizTalk Server 데이터베이스 문제를 해결하려면 다음 단계를 수행합니다.

1단계: 필요한 모든 BizTalk SQL Server 에이전트 작업 사용 및 실행

작업을 제외한 MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb 모든 BizTalk SQL Server 에이전트 작업을 사용하도록 설정하고 성공적으로 실행해야 합니다. 다른 작업을 사용하지 않도록 설정하지 마세요.

오류가 발생하는 경우 SQL Server 기록 보기 옵션을 사용하여 오류 정보를 확인한 다음 그에 따라 오류를 해결합니다. MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb SQL Server 에이전트 작업은 무한히 실행됩니다. 따라서 작업 기록이 작업이 지속적으로 실패하고 다시 시작된다는 것을 보고하는 경우에만 염려해야 합니다.

2단계: BHM(BizTalk 상태 모니터)/MsgBoxViewer 도구 사용

문제를 재현하는 동안 BHM 보고서를 수집합니다.

BHM 도구는 테이블 크기 및 행 수에 대한 자세한 정보가 포함된 HTML 보고서를 제공하기 때문에 문제 해결에 유용합니다. 또한 보고서는 BizTalk Server 제한되는지 여부를 확인하는 데 도움이 될 수 있습니다. 또한 이 도구는 BizTalk Server 데이터베이스 및 BizTalk Server 구성에 대한 스냅샷 보기를 제공합니다.

BizTalk Server 제한에 대한 자세한 내용은 BizTalk Server 호스트 제한을 구현하는 방법을 참조하세요.

BizTalk Server 평소보다 느리게 실행되는 경우 BHM 도구를 실행한 다음 생성된 HTML 보고서를 검토하여 문제를 확인합니다. 요약 섹션에는 노란색 경고와 잠재적인 문제가 빨간색으로 나열되어 있습니다.

또한 BHM 도구 출력을 사용하여 가장 크고 레코드가 가장 많은 테이블을 확인할 수 있습니다. 다음 표에서는 일반적으로 가장 큰 BizTalk Server 테이블을 나열합니다. 이 데이터를 사용하여 잠재적인 문제가 있을 수 있는 위치를 확인할 수 있습니다.

설명
<HostName>Q_Suspended 이 테이블에는 특정 호스트에 Spool 대해 일시 중단된 인스턴스와 연결된 테이블의 메시지에 대한 참조가 포함되어 있습니다. 이 테이블은 데이터베이스에 있습니다 BizTalkMsgBoxDb .
<HostName>Q 이 테이블에는 특정 호스트와 연결되고 일시 중단되지 않은 테이블에 있는 메시지에 Spool 대한 참조가 포함되어 있습니다. 이 테이블은 데이터베이스에 있습니다 BizTalkMsgBoxDb .
Spool

Parts

Fragments
이러한 테이블은 데이터베이스에 실제 메시지 데이터를 저장합니다 BizTalkMsgBoxDb .
Instances 이 표에서는 모든 인스턴스와 현재 상태 데이터베이스에 BizTalkMsgBoxDb 저장합니다.
TrackingData_0_x 이 4개의 테이블은 TDDS가 BizTalkMsgBoxDb 이벤트를 데이터베이스로 이동하기 위해 BAM(Business Activity Monitoring) 추적 이벤트를 데이터베이스에 BAMPrimaryImport 저장합니다.
TrackingData_1_x 이 네 개의 테이블은 추적된 이벤트를 데이터베이스에 BizTalkMsgBoxDb 저장하여 TDDS가 이벤트를 데이터베이스로 이동할 수 있도록 BizTalkDTADB 합니다.
Tracking_Fragmentsx
Tracking_Partsx
Tracking_Spoolx
이러한 각 테이블은 및 BizTalkDTADb 데이터베이스에 BizTalkMsgBoxDb 있습니다. 하나는 온라인이고 다른 하나는 오프라인입니다.

BizTalk Server 2004 SP2 이상 버전 TrackedMessages_Copy_BizTalkMsgBoxDb 에서는 SQL Server 에이전트 작업이 추적된 메시지 본문을 데이터베이스의 BizTalkDTADb 이러한 테이블로 직접 이동합니다.

BizTalk Server 2004 SP1(서비스 팩 1) 및 이전 버전의 BizTalk Server 2004 TrackedMessages_Copy_BizTalkMsgBoxDb 에서 SQL Server 에이전트 작업은 추적된 메시지 본문을 데이터베이스의 BizTalkMsgBoxDb 이러한 테이블에 복사합니다. TrackingSpool_Cleanup_BizTalkMsgBoxDb SQL Server 에이전트 작업은 오프라인 테이블을 제거하고 온라인 테이블을 온라인으로 만드는 반면 작업은 온라인 테이블을 오프라인으로 전환합니다.
dta_ServiceInstances 이 표에서는 데이터베이스의 BizTalkDTADb 서비스 인스턴스에 대해 추적된 이벤트를 저장합니다. 이 테이블이 크면 데이터베이스가 BizTalkDTADb 클 수 있습니다.
dta_DebugTrace 이 표에서는 오케스트레이션 디버거 이벤트를 BizTalkDTADb 데이터베이스에 저장합니다.
dta_MessageInOutEvents 이 표에서는 추적된 이벤트 메시지를 데이터베이스에 저장합니다 BizTalkDTADb . 이러한 추적된 이벤트 메시지에는 메시지 컨텍스트 정보가 포함됩니다.
dta_ServiceInstanceExceptions 이 표에서는 데이터베이스에 일시 중단된 서비스 instance BizTalkDTADb 대한 오류 정보를 저장합니다.

다음 시나리오를 고려하세요.

  • <HostName>Q_Suspended 테이블

    테이블에 레코드가 <HostName>Q_Suspended 많은 경우 테이블은 그룹 허브 또는 HAT에 표시되는 유효한 일시 중단된 인스턴스일 수 있습니다. 이러한 인스턴스는 종료할 수 있습니다. 이러한 인스턴스가 그룹 허브 또는 HAT에 표시되지 않는 경우 인스턴스는 인스턴스를 캐싱하거나 분리된 라우팅 실패 보고서일 수 있습니다. 일시 중단된 인스턴스가 종료되면 이 테이블의 항목과 및 Instances 테이블의 Spool 연결된 행이 정리됩니다.

    이 시나리오에서는 일시 중단된 인스턴스를 다시 열거나 종료하여 처리합니다. BHM 도구를 사용할 수도 있습니다.

  • <HostName>Q 테이블

    테이블에 레코드가 <HostName>Q 많은 경우 다음과 같은 종류의 인스턴스가 있을 수 있습니다.

    • 즉시 실행 가능한 인스턴스
    • 활성 인스턴스
    • 탈수 인스턴스 BizTalk Server 인스턴스를 "따라잡기"하고 처리하는 데 시간이 필요합니다.

    이 테이블은 들어오는 처리 속도가 나가는 처리 속도를 능가할 때 증가할 수 있습니다. 이 시나리오는 큰 BizTalkDTADb 데이터베이스 또는 SQL Server 디스크 지연과 같은 다른 문제가 발생할 때 발생할 수 있습니다.

  • Spool, PartsFragments 테이블

    Spool, PartsFragments 테이블에 많은 레코드가 있는 경우 많은 메시지가 현재 활성 상태이거나 탈수되거나 일시 중단됩니다. 이러한 테이블의 크기, 부분 수 및 조각화 설정에 따라 단일 메시지가 이러한 모든 테이블을 생성할 수 있습니다. 각 메시지에는 테이블에 정확히 하나의 행과 Spool 테이블에 하나 이상의 행이 Parts 있습니다.

  • Instances 테이블

    BizTalk 관리자는 많은 일시 중단된 인스턴스를 테이블에 유지 Instances 하도록 허용해서는 안 됩니다. 탈수 인스턴스는 비즈니스 논리에 장기 실행 오케스트레이션이 필요한 경우에만 유지되어야 합니다. 하나의 서비스 instance 테이블의 Spool 많은 메시지와 연결할 수 있습니다.

  • TrackingData_x_x 테이블

    테이블이 TrackingData_x_x 크면 TDDS(추적 호스트)가 성공적으로 실행되지 않습니다. 추적 호스트 instance 실행 중인 경우 이벤트 로그 및 데이터베이스의 TDDS_FailedTrackingData 테이블을 BizTalkDTADb 검토하여 오류 정보를 확인합니다. BizTalk가 6(큰 데이터베이스) 상태로 제한되는 경우 데이터가 필요하지 않은 경우 BizTalk 종결자 도구를 사용하여 이러한 테이블을 잘라낼 수도 있습니다.

    테이블의 시퀀스 번호 BizTalkMsgBoxDbTrackingData_x_xBAMPrimaryImport 또는 BizTalkDTADbTDDS_StreamStatus 테이블 사이에 큰 차이가 있는 경우 TDDS는 데이터베이스에서 BizTalkMsgBoxDb 데이터를 이동하지 않을 수 있습니다. 이 문제를 해결하려면 BHM 도구를 사용하여 이러한 테이블을 제거하고 시퀀스 번호를 다시 설정합니다.

  • dta_DebugTracedta_MessageInOutEvents 테이블

    dta_DebugTrace 셰이프 시작 및 종료가 오케스트레이션에서 사용하도록 설정되면 테이블이 채워집니다. 테이블에 많은 레코드가 dta_DebugTrace 있는 경우 이러한 오케스트레이션 디버깅 이벤트가 사용 중이거나 사용되고 있습니다. 일반 작업에 오케스트레이션 디버깅이 필요하지 않은 경우 오케스트레이션 속성에서 셰이프 시작 및 끝 검사 상자를 선택 취소합니다.

    dta_MessageInOutEvents 오케스트레이션 및/또는 파이프라인에서 메시지 보내기 및 수신을 사용하도록 설정하면 테이블이 채워집니다. 이러한 추적 이벤트가 필요하지 않은 경우 오케스트레이션 및/또는 파이프라인 속성에서 이 옵션에 대한 검사 상자를 선택 취소합니다.

    이러한 추적 이벤트를 사용하지 않도록 설정하거나 데이터베이스에 백로그가 있는 BizTalkMsgBoxDb 경우 TDDS가 이 데이터를 이러한 테이블로 계속 이동하므로 이러한 테이블은 계속 증가할 수 있습니다.

    기본적으로 전역 추적은 사용하도록 설정됩니다. 전역 추적이 필요하지 않은 경우 사용하지 않도록 설정할 수 있습니다. 자세한 내용은 전역 추적을 끄는 방법을 참조하세요.

    데이터베이스의 dta_DebugTrace 테이블 및/또는 dta_messageInOutEvents 테이블 BizTalkDTADb 이 너무 큰 경우 추적 호스트를 중지한 후 테이블을 수동으로 잘라낼 수 있습니다. BHM 도구는 이 기능도 제공합니다.

    데이터베이스의 BizTalkMsgBoxDb 모든 추적 테이블을 자르려면 BHM 도구를 사용합니다. BHM 도구는 Microsoft 다운로드 센터에서 외부에서 사용할 수 있습니다.

    데이터베이스 크기 조정 지침 추적에 대한 자세한 내용은 MSDN 웹 사이트: 데이터베이스 크기 조정 지침 추적을 참조하세요.

  • dta_ServiceInstanceExceptions 테이블

    일반적으로 테이블은 dta_ServiceInstanceExceptions 정기적으로 일시 중단된 인스턴스가 있는 환경에서 커집니다.

3단계: 교착 상태 시나리오 조사

교착 상태 시나리오에서는 교착 상태 정보가 SQLERROR 로그에 기록되도록 SQL Server DBCC 추적을 사용하도록 설정합니다.

SQL Server 2005 이상 버전에서 다음 문을 실행합니다.

DBCC TRACEON (1222,-1)

SQL Server 2000에서 다음 문을 실행합니다.

DBCC TRACEON (1204)

또한 PSSDiag 유틸리티를 사용하여 이벤트 및 Lock:Deadlock Chain 이벤트에 대한 Lock:Deadlock 데이터를 수집합니다.

데이터베이스는 BizTalkMsgBoxDB 대용량 및 대용량 OLTP(온라인 트랜잭션 처리) 데이터베이스입니다. 일부 교착 상태가 예상되며 이 교착 상태는 BizTalk Server 엔진에서 내부적으로 처리됩니다. 이 동작이 발생하면 오류 로그에 오류가 나열되지 않습니다. 교착 상태 시나리오를 조사할 때 출력에서 조사 중인 교착 상태는 이벤트 로그의 교착 상태 오류와 상관 관계가 있어야 합니다.

큐에서 제거 명령과 일부 SQL Server 에이전트 작업이 교착 상태에 빠질 것으로 예상됩니다. 일반적으로 이러한 작업은 교착 상태 피해자로 선택됩니다. 이러한 작업은 교착 상태 추적에 표시됩니다. 그러나 이벤트 로그에는 오류가 나열되지 않습니다. 따라서 이 교착 상태가 예상되며 이러한 작업과의 교착 상태를 무시해도 됩니다.

빈 교착 상태가 교착 상태 추적에 표시되고 이벤트 로그에 상관 관계 오류가 나열되면 교착 상태가 발생할 수 있습니다.

4단계: 차단된 프로세스 찾기

SQL Server 활동 모니터를 사용하여 잠금 시스템 프로세스의 SPID(서버 프로세스 식별자)를 가져옵니다. 그런 다음, SQL Profiler를 실행하여 잠금 SPID에서 실행되는 SQL 문을 확인합니다.

SQL Server 잠금 및 차단 문제를 해결하려면 PSSDiag for SQL 유틸리티를 사용하여 차단 스크립트가 사용하도록 설정된 모든 Transact-SQL 이벤트를 캡처합니다.

SQL Server 2005 이상 버전에서는 차단된 프로세스 임계값 설정을 지정하여 지정한 임계값보다 더 오래 차단되는 SPID 또는 SPID를 확인할 수 있습니다.

차단된 프로세스 임계값 설정에 대한 자세한 내용은 차단된 프로세스 임계값 서버 구성 옵션을 참조하세요.

참고

SQL Server 잠금 또는 차단 문제가 발생하는 경우 Microsoft 고객 지원 서비스에 문의하는 것이 좋습니다. Microsoft 고객 지원 서비스는 올바른 PSSDiag 유틸리티 옵션을 구성하는 데 도움이 될 수 있습니다.

5단계: 최신 BizTalk Server 서비스 팩 및 누적 업데이트 설치

BizTalk Server 이후 버전이 CU(누적 업데이트) 모델로 이동되었습니다. 누적 업데이트에는 최신 수정 사항이 포함됩니다.

모든 데이터 삭제

데이터베이스가 너무 크거나 기본 설정 방법이 모든 데이터를 삭제하는 경우 모든 데이터를 삭제할 수 있습니다.

주의

데이터가 중요 비즈니스용이거나 데이터가 필요한 경우 어떤 환경에서도 이 메서드를 사용하지 마세요.

BizTalkMsgBoxDb 데이터베이스 제거 단계

데이터베이스의 BizTalkMsgBoxDb 모든 데이터를 삭제하려면 BHM(BizTalk 상태 모니터) 도구를 사용합니다.

BizTalkDTADb 데이터베이스 제거 옵션

데이터베이스에서 BizTalkDTADb 모든 데이터를 삭제하려면 BHM(BizTalk 상태 모니터) 도구를 사용합니다. 그렇지 않으면 다음 메서드 중 하나를 사용합니다.

참고

두 메서드 모두 모든 메시지를 삭제하지만 메서드 2는 더 빠릅니다.

  • 메서드 1:

    1. 모든 BizTalk Server 데이터베이스를 백업합니다.

    2. 저장 프로시저를 dtasp_PurgeAllCompletedTrackingData 실행합니다. 저장 프로시저에 dtasp_PurgeAllCompletedTrackingData 대한 자세한 내용은 BizTalk 추적 데이터베이스에서 수동으로 데이터를 제거하는 방법을 참조하세요.

      참고

      이 작업은 완료된 모든 메시지를 삭제합니다.

  • 메서드 2:

    1. 모든 BizTalk 데이터베이스를 백업합니다.

    2. 저장 프로시저를 dtasp_CleanHMData 실행합니다. 데이터베이스에 BizTalkDTADb 제거해야 하는 불완전한 인스턴스가 많은 경우에만 이 옵션을 사용합니다.

      이렇게 하려면 다음과 같이 하십시오.

      1. 모든 BizTalk 호스트, 서비스 및 사용자 지정 격리 어댑터를 중지합니다. HTTP 또는 SOAP 어댑터를 사용하는 경우 IIS 서비스를 다시 시작합니다.
      2. 데이터베이스에서 dtasp_CleanHMData 저장 프로시저를 실행합니다 BizTalkDTADb .
      3. 모든 호스트 및 BizTalk Server 서비스를 다시 시작합니다.

BizTalk Server 2004 전용 단계

참고

추적 데이터가 있어야 하는 경우 데이터베이스를 BizTalkDTADb 백업하고 데이터베이스를 다른 SQL Server 복원한 다음 원래 BizTalkDTADb 데이터베이스를 제거합니다.

BHM 데이터 또는 PSSDiag 출력을 분석하는 데 도움이 필요한 경우 Microsoft 고객 지원 서비스에 문의하세요. 고객 지원 서비스 전화 번호 및 지원 비용에 대한 전체 목록은 Microsoft 지원 문의를 참조하세요.

참고

고객 지원 서비스에 문의하기 전에 BHM 보고서 데이터, PSSDiag 출력 및 업데이트된 이벤트 로그(.evt 파일)를 압축합니다. 이러한 파일을 BizTalk Server 지원 엔지니어에게 보내야 할 수 있습니다.

적용 대상

  • BizTalk Server 2009
  • BizTalk Server 2010
  • BizTalk Server 2013
  • BizTalk Server 2013 R2
  • BizTalk Server 2016
  • BizTalk Server 2020