BizTalk Service들이 제대로 동작하지 않을 때 체크할 일

안녕하세요. 김현수입니다.

BizTalk 관리자가 어느 날 고객으로부터 다음과 같은 내용의 전화를 받습니다.

메시지 보낸지 한참되었는데 진행이 안되고 있어요. 비즈톡에 걸려있는지 확인해주세요.

메시지가 잘못되었거나, 일시적으로 타겟 시스템과의 연결이 안되고 있거나.. 흔히 발생할 수 있는 상황이라 생각하고 느긋하게 BizTalk Admin Tool로 진행상태를 확인해보니 한 두 개 인터페이스가 아니라 진행중인 모든 메시지들이 Active 된 상태로 벌써 몇 십분간이나 멈춰있습니다. 다른 인터페이스를 담당하는 고객들로부터도 전화가 걸려오기 시작합니다.

메시지 보낸지 한참되었는데 진행이 안되고 있어요. 비즈톡에 걸려있는지 확인해주세요.

자 이게 어찌된 노릇일까요?

일단 뭔가 문제가 있을 때는 먼저 EventViewer를 체크해봐야겠죠?
서둘러 EventViewer를 확인하니 특정 시점부터 다음과 같은 에러 메시지들이 반복되고 있습니다.

아하! SSO 관련 에러군요. SSO Service가 제대로 동작하지 못할 경우는 긴장하셔야 합니다. 왜냐하면 모든 BizTalk Service들이 SSO에 dependant하기 때문이죠. 그럼 왜 SSO database에 접속하지 못하고 있을까요? 먼저 해당 SSO database에 접속해야겠지요?

1. Regedit 실행
2. HKEY_LOCAL_MACHINE/SOFTWARE/MICROSOFT/ENTSSO/SQL 확인

에 있는 Database와 Server value를 확인해서 연결에 이상이 없는지 체크해봅니다.
만약 이상이 없다면 Database 서버의 Event Viewer를 확인합니다.


오~노우~~~!! SSODB의 Log 파일을 Autogrow 하려다가 실패를 반복했군요. 시각으로 미루어봐도 이게 문제의 원인임이 틀림없어 보입니다. 계속해서 Autogrow를 시도하면서 Lock이 걸려 App서버에서 DB서버로 Access 실패를 번복하고 있는 것이죠. 그나저나 30015 milliseconds면 30초 정도인데 대체 얼마나 큰 용량을 늘리려다 저런 결과가 나왔을 까요? DB 관리가 제대로 이루어지고 있는지 확인해봐야겠지요?

먼저 MSFT가 제안하는 BizTalk Database들의 초기 사이즈 및 Autogrowth 사이즈를 알아볼까요?(.ldf only)

Database	File Name	Initial Size (MB)	Growth Increment (MB)
BizTalkMsgBoxDb	BizTalkMsgBoxDb.ldf	40000	100
BizTalkDTADb	BizTalkDTADb.ldf	25000	100
SSODB	SSODB.ldf	1	1
BizTalkRuleEngineDb	BizTalkRuleEngineDb.ldf	10	1
BizTalkHwsDb	BizTalkHwsDb.ldf	10	1
BizTalkEDIDb	BizTalkEDIDb.ldf	10	1
BizTalkTPMDb	BizTalkTPMDb.ldf	10	1
BizTalkAnalysisDb *	BizTalkAnalysisDb.ldf	100	10
BizTalkMgmtDb	BizTalkMgmtDb.ldf	100	10
BAMPrimaryImport	BAMPrimaryImport.ldf	5000	10
BAMStarSchema	BAMStarSchema.ldf	100	10
BAMArchive	BAMArchive.ldf	5000	10

*SQL Server 2K only

보다 자세한 내용은 BizTalk Server Database Optimization 확인하시고,
다음 문제가 발생한 DB 서버의 설정을 확인해보면..

헉!!! SSODB_log 의 Initial Size가 무려 13기가, Autogrowth 사이즈가 무려 10 percent나 잡혀있군요. Guide가 제시하는 것과는 전혀 틀립니다. Guide를 눈여겨 보시면 일괄적으로 Autogrow 하는 단위가 MB로 되어 있는데 이것은 문제가 발생한 서버의 예처럼 Percentage로 잡을 경우, DB 사이즈가 커지면 커질수록 늘리는 사이즈도 계속 늘어나기 때문입니다. 더구나 사이즈를 늘릴때 Lock이 걸리므로 이 시간을 최소화하기 위해서는 Autogrowth 사이즈를 최소로 유지해주는 것이지요.

위 이슈는 그래서 Autogrowth 단위를 1MB로 바꿔주는 것으로 간단히 해결되었습니다. log 파일 사이즈가 자동 증가되면서 App Server의 SSO Service도 문제없이 동작하고, 이에 dependant한 BizTalk Service들도 다시 정상 작동하게 된 것이지요.

혹시나 해서 문제가 발생한 Database 서버의 다른 BizTalk DB들을 확인해보니 SSODB의 경우와는 달리 주기적으로 Truncate 해줘 log 사이즈가 날렵하게 유지되고 있었습니다. SSODB의 경우, 실수로 빼놓은 것이지요. 그럼 이렇게 모든 BizTalk Database들의 로그 파일 사이즈를 주기적으로 일일이 Truncate해주는 것이 옳은 방법일까요? 그렇지 않습니다. Database들을 정기적으로 백업해주는 것이 DB들의 로그를 날렵하게 유지해주기 위해 보다 우아한 방법입니다. 백업한 Database 파일들을 삭제하는 것은 Policy를 세워야 겠지요. BizTalk에는 Backup BizTalk Server (BizTalkMgmtDb)라고 하는 Job이 있는데 이 Job이 BizTalk Database들을 일괄적으로 백업해주는 역할을 합니다. 따라서 이 Job도 적절한 세팅과 함께 Enable 해줄 것을 권장합니다. 이 때 BAM, BAS 또는 BAS EDI 어댑터 사용시 위 Job만 가지고는 올바른 Backup을 할 수 없습니다. 설정을 위한 보다 자세한 내용은 아래를 참고하시기 바랍니다.

Backing Up and Restoring the BizTalk Server Databases

감사합니다.

=> BizTalk 관련 국내 최고 KB가 되겠습니다. 구독 신청해주세요~!!

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.