Biztalk veritabanı boyutlarının büyümesi ve ilgili problemler
Merhabalar,
Biztalk üzerine önceki yazılarımızda, MessageBox Viewer tool’u nu kullanmayı ver birtakım integrasyon problemlerini çözümlemek için terminator tool’u ile nasıl çalışacağımızı yazmıştık. Daha önce karşılaştığım birçok problemde, Biztalk veritabanlarının bulunduğu ‘SQL Server’ üzerinde yüksek CPU kullanımı gibi performans sorunlarının temel nedenlerinden birinin, veritabanı boyutunun oldukça büyümesi olduğunu görmüştüm. Bu yazımda bunun nasıl saptanabileceği, nedenlerini ve bunu düzeltmek için neler yapabiliriz, bu konulara değineceğim.
Öncelikle SQL Server veritabanı dosyalarındaki büyümeyi anlamanın birçok yolu olduğunu söyleyebiliriz. Örneğin; bunlardan iki tanesi sp_helpdb, sp_spaceused komutlarıdır. Ama bu yazımda 'Message box viewer' raporu (MBV) üzerinden gidiyor olacağız. Böyle bir durumda MBV raporunda ilk bakılacak yer, 'IMPORTANT' kategorisi altındaki ‘Biztalk – All Biztalk Db’s: Dbs Space’ sekmesi. Bu alan temel olarak 'SQL server’ın kullanmakta olduğu veri ve log dosyaların büyüklüklerini raporluyor. Örneğin aşağıdaki örnekte, ‘BiztalkMsgBoxDb’ veritabanın da kullanılan alanın oldukça küçük olmasına rağmen, Toplam alanın oldukça büyük olduğu görünmekte. Bu tip bir semptom’a rastlarsanız veritabanı dosyanız fragmante olmuş demektir.
Fragmantasyon durumunda yapılabilecek iki şey mevcut:
#1 . İlgili veritabanı’nın özelliklerinde ‘auto-shrink’ seçeneğinin disabled durumda olup olmadığına bakmalıyız, eğer disabled durumda ise enabled yapmalıyız:
Bunun yanısıra bir veritabanı dosyası DBCC SHRINKFILE komutu ile de manuel olarak küçültülebilir.
#2 . Biztalk Server arka planda veritabanına büyük oranlarda ‘insert’ ve ‘delete’ operasyonları uyguladığı için uzun vadede veri dosyaları fragmante oluyor. Bu noktada bir servis kesintisine gidip (tüm biztak hostları, servisler ve Sql agent job’ları durdurulacak) re-index stored prosedürü çalıştırılabilir.
Yani özetle, önce 're-index' çalıştırılıp sonrasında veritabanı dosyası 'Shrink' edilebilir.
Fakat yukarıdaki MBV örneğinde durumun DTA veritabanı için 'MsgBox' veritabanına göre farklılık gösterdiğini görebilirsiniz. ‘Used Space’ 10 GB seviyelerinde. Bu sefer fragmentation’ın yanısıra yoğun bir kullanım da söz konusu. Böyle bir durumla karşı karşıya isek bu durumda, bu kullanımın hangi tablolardan kaynaklandığını incelemek faydalı olabilir. Örneğin; yukarıdaki tabloda DTA veritabanın da hangi tabloların en çok yer kapladığını görebilmek için MBV raporunda gine IMPORTANT kategorisi alınrdaki ‘Biztalk – Dta Db: DTA Tables Size order by Table Size’ kısmına gitmeliyiz:
<Benzer problem ‘Tracking’ veritabanında değil de ‘Msgbox’ veritabanında olsaydı be sefer IMPORTANT kategorisi altında ki ‘BizTalk - All MsgBox Dbs : MsgBox Tables Size sorted by Table Size’ sekmesine bakabilirdik.>
Yukarıdaki örnekte ‘Tracking’ veritabanındaki en büyük tabloların ‘dta_MessageInOutEvents’ ve ‘dta_ServiceInstances’ tabloları olduğu görülüyor. Bu saptamayı yaptıktan sonra öncelikle Biztalk veritabanı sunucusundaki ‘SQL Server Agent Job’larını incelememiz faydalı olur. Çünkü bu ‘job’ lar 'Biztalk' veritabanlarında zamanla oluşan tarihsel veriyi temizlemek / arşivlemek ve veritabanlarının sağlıklı bir şekilde çalışmaya devam etmesini sağlamaktan sorumludurlar. Bu iki tablonun milyon mertebesinde kayıt tutuyor olması ‘DTA Purge and Archive (BizTalkDTADb)’ SQL Agent job’ına bakmamız gerektiğini gösteriyor. Çünkü bu ‘Agent Job’ı geriye dönük olarak bu tabloda tutulan verinin belirli bir zamandan daha eski olanlarının silinmesini sağlıyor. Bunun için örneğin; aşağıdaki resimdeki gibi '@nHardDeleteDays' parametresi ile kaç günden önceki verilerin silinmesi gerektiğini belirtebiliriz.
Bunun servis haricinde diğer Job'larında önemli görevleri mevcut. Daha detaylı bilgi için bu makaleyi inceleyebilirsiniz.
'Biztalk Tracking' veritabanındaki büyümenin diğer bir sebebi de veriyi ne kadar süre ile değil, ne kadar kanaldan aldığınızla da ilgili olabilir. Yani ne kadar biztalk nesnesi için 'tracking' diğer bir deyişle takip işlemi yapmaktayız, bunu gözden geçirmekte fayda var. İhtiyacımız yoksa, ilgili 'Biztalk' nesnesini 'track' etmeyedebiliriz. Aşağıdaki örnekte de gösterdiğim gibi herbir 'Biztalk' nesnesi için ayrı ayrı bu tanımlamaları yapabiliriz.
'Tracking' veritabanının dışında 'MsgBox' veritabanında yoğun bir kullanım görüyor isek bunun sebebi, Yetim ('Orphaned') yada askıya alınmış ('suspended') veritabanı nesneleri olabilir. Tüm veritabanı problemlerinde, her türlü 'Orphaned' yada 'suspended' nesneleri tespit edip bunlarıda temizlememiz gerekir. Çünkü bu nesneler veritabanında diğer birçok nesneye olan bağlantıları nedeni ile büyümeye neden olurlar. Bu tip problemlerde MBV raporu üzerinde, özellikle 'Critical Warnings' bölümünde raporlanmaktadır:
Bu tip sorunların çözümünde 'Biztalk terminator' kullanarak veritabanını temizlemek için bu makaleyi takip edebilirsiniz.
İyi çalışmalar,
Mert