Biztalk MessageBox Veritabanı yapısı ve temel tablolar

Merhabalar,

Diğer yazılarımızda Biztalk sunucularında oluşacak problemlerin analizi ve entegrasyon problemlerinin çözülmesi için kullanılabilecek ‘Biztalk Terminator’ ve ‘MessageBox Viewer’ araçlarından bahsetmiştim. Bugün ise Biztalk veritabanı mimarisi hakkında bilgi vermeye çalışacağım.

Bildiğimiz üzere Biztalk, Publish / Subscribe mekanizması ile çalışan bir mesajlaşma sistemidir. Bu model, bilgiyi gönderen (‘publish’ eden) taraf ile bilgiyi alan (‘subscribe’ olan) taraf arasında gerçekleşen ve ölçülebilirlik açısından avantaj sağlayan bir modeldir. Biztalk mesajlaşma modelinde gelen mesajların tipi ne olursa olsun ‘XML’ formatına çevirilerek ‘MessageBox’ veritabanına kaydedilir ve aynı formatta veritabanından çekilir. MessageBox veritabanındaki entegrasyon problemlerinin çoğu bu mesajlaşma işlemleri sırasında kullanılan veritabanı tablolarında gerçekleşir. Bu blog'da temel olarak ‘MessageBox’ veritabanında hangi tabloların bulunduğu ve bu tabloların görevleri hakkında bilgi vereceğim. Bu tablolar oluşabilecek performans problemlerinde, kafamızdaki hesaplamalara sıklıkla dahil edeceğimiz tablolar olacaklar.

Biztalk Yönetim panelinden, Biztalk uygulamalarını çalıştırmak üzere yeni bir host instance oluşturduğumuzda, veritabanında <HostName>Q, <HostName>Q_Suspended, InstanceStateMessageReferences_<HostName> gibi yeni tabloların oluştuğunu görebilirsiniz. Host Instance Process’i (BTSNTSvc.exe) bu tabloları birer çalışma kuyruğu olarak kullanır.

<HostName>Q – Biztalk host instance’ı bu tablodan ilgili çalışma isteğini ‘dequeue’ ederek alır. Burada birçok mesajın ‘Host instance’ tarafından işlenmek üzere beklediğini görüyorsak;

• ilgili servis (host instance) kapalı durumda olabilir.
• ‘Host instance’ a ait ‘process’ yoğun stress altında olduğu için burada birikme yaşanıyordur.
• Bir ‘service window’ (dtStartWindow,dtEndWindow) başlamıştır. Yada bu mesajları , örneğin bir send port’ a göndermeye çalışıp başarısız oluyorsak, birikiyor olabilir. ‘Retry’ yaptıkça bunların üzerine bir miktar gecikme eklenir (nRetryCount)

Bu tablonun boyutunun artması, host instance’ın çalışmasını engellemeyecektir, fakat bu yapılacak bir çok işin belirli sebeplerden birikiyor olduğunu gösterir. Örn. Server’in kapalı olması, işlerin bir şekilde fail etmesi ve tekrar denenmeleri gibi.

<HostName>Q_Suspended – Bu tablo askıya alınmış olan mesajların bir listesini içerir. Bu tabloda bir büyüme yaşanıyorsa büyük olasılıkla mesajın dahil olduğu ‘Instance’ da askıya alınmış ve yapılan işlemler başarısız oluyor demektir. Bu durumda bunun sebebinin incelenmesi gerekir .

Spool – Bu tablo sistemdeki tüm mesajların bir listesini tutar. Diğer tüm tablolarda, mesajlara tutulan referanslar bu tabloyu işaret ederler. Bu tablonun anormal derecede büyüdüğünü görüyorsanız SQL server Agent görevini
yerine getirmiyor olabilir. Çünkü ‘SQL Agent Job’ ları bu tablo üzerinde ‘Garbage Collection’ gerçekleştirir. Bu Job’lar çalışmıyorsa ‘Spool’ tablosu küçülmez ve buda sisteminizde sorunlara yol açar.

Instances – Bu tabloda Biztalk Sistemine mesaj akışı olduğunda oluşturulan tüm servis nesneleri (Receive portları, Orchestration’lar ve send portları) tutulmaktadır. Bu nesneler aşağıdaki durumlarda bulunabilirler:

• 'In Breakpoint’ : Sadece Orchestration’lar için geçerli bir durumdur. Bir ‘orchestration’ breakpoint sebebi ile durduğu zaman bu duruma gelir.
• ‘Ready to run’ : Bir servis nesnesi aktive edilmiş fakat henüz çalışmaya başlamamış ise bu durumdadır.
• ‘Active’ : An itibari ile çalışmakta olan (BTSNTSvc.exe içerisinde) servis nesnesini gösterir.
• ‘Dehydrated’ : Servis nesnesi ‘MessageBox’ veritabanına daha sonra üzerinde çalışılmak üzere kaydedilmiştir.
• ‘Completed with discarded messages’ : Servis nesnesi tamamlanmıştır, fakat servis nesnesinin almamış (consume) olduğu olan mesajlar da vardır.
• ‘Suspended (resumable)’: Servis nesnesi askıya alınmıştır. Bu nesneyi çalışmasına devam etmek üzere devam (‘resume’) ettirebilirsiniz. Not olarak; Bir servis nesnesini once askıya alıp (‘suspend’) sonra devam (‘resume’) ettirirseniz , servis nesnesi ‘dehydrated’ duruma geçer.
• Suspended (not-resumable): Servis nesnesi askıya alınmıştır ama devam ettirelemez. Bu servis nesnesine ait mesajları tespit edip bunları terminate etmeniz gerekebilir.
• Pending suspend/Pending terminate: Bu diğer durumlardan bağımsız bir durumdur. (Diğer durumlarla birarada da olabilir). Görevini tamamlamış bir servis nesnesine bir suspend / terminate komutu gelmiştir ve fakat bu komut nesne tarafından henüz alınmamıştır.

‘Instances’ tablosundaki büyüme çoğunlukla bir problem teşkil etmez. Örneğin bir binlerce 'orchestration' 'suspended' durumda uzunca bir süredir bekliyor olabilir. Diğer tablolardaki büyümeler performans açısından daha net birer belirleyici olabilirler.

InstanceStateMessageReferences_<HostName> -- Bu tabloda servis nesneleri tarafından kullanılmakta olan yada kullanılacak olan mesaj referansları tutulur. Örneğin bir ‘orchestration’ bir mesajı alıp, işlemeye başlayıp sonrasında kullanılmak üzere bu tablodaya koyar. Bu genelde pek sorun yaratmayan bir tablodur, fakat bazı durumlarda, örneğin MSMQt adapter’ında non-acknowledged mesajların referanslarının burada tutulması sebebi ile örneğin bu tabloda bir şişme yaşanabilir.

 Yukarıda belirttiğim tablolar Biztalk veritabanı içerisinde bulunan Temel tablolar, bunlar harcinde daha birçok tablo birbirleri ile ilişkili şekilde bulunmaktalar. Fakat Temel işleyişi anlayabilmek açısından bence yukarıdaki tablolar diğerlerine nazaran daha kritik tablolar diyebiliriz. Aşağıda oluşturduğum şemada örnek olarak bu tablolar arasınraki ilişkiyi görsel olarak da göstermeye çalıştım:

 

 

Yukarıda görüldüğü gibi her yeni Host instance için oluturulan tablolar o host instance’ın ismini taşımaktalar ve aşağıdaki sorgu ile ‘Applications’ tablosundan getiriliyorlar:

SELECT nvcApplicationName FROM [BiztalkMsgboxDb].. [Applications]

 @nvcAppName + ‘Q’ isimli iş kuyruk tablosu üzerinde bulunan uidClassID alanına bağlı olarak ‘uidServiceID’ alanı ‘Sendport’ yada ‘Orchestration’ tablolarını gösterebiliyor. Aşağıda belirttiğim sorguda ise örnek olarak tip ve durumlarına gore ‘Instance’ toplam sayılarını getiren bir sorguyu görebilirsiniz:

               
SELECT COUNT(*) as Count, CASE i. uidClassIDWHEN '226FC6B9-0416-47A4-A8E8-4721F1DB1A1B' THEN 'Orchestration'                
WHEN '59F295B0-3123-416E-966B-A2C6D65FF8E6' THEN 'Messaging'               
WHEN '683AEDF1-027D-4006-AE9A-443D1A5746FC' THEN 'Isolated'               
WHEN '3D7A3F58-4BFB-4593-B99E-C2A5DC35A3B2' THEN 'MSMQT'               
WHEN 'EAF8EEA9-366A-4CDE-8DD3-57A4C39BF8E5' THEN 'RFR'               
WHEN 'BB3A1470-F5C4-47C3-B71F-EAABC260FBD0' THEN 'Caching'               
ELSE 'Other' END as Type,               

CASE i.nState               
WHEN 1 THEN 'Ready To Run'               
WHEN 2 THEN 'Active'               
WHEN 4 THEN 'Suspended Resumable'               
WHEN 8 THEN 'Dehydrated'               
WHEN 16 THEN 'Completed With Discarded Messages'               
WHEN 32 THEN 'Suspended Non-Resumable'               
END as State                
FROM Instances AS i WITH (NOLOCK)               
GROUP BY i.nState, i.uidClassID               
ORDER BY Count desc

 

İyi çalışmalar,

Mert Öztürk