Grooming ile ilişkili Stored Prosedürlerin hepsi diğer Stored Prosedürleri ve fonksiyonları çağırır, Çok sayıda Grooming ile ilişkili Job vardır. Bu yüzden bütün Grooming Job’ları derinlemesine incelemek yerine en yaygın olanını incelememiz makalemiz açısından da yerinde olacaktır J
Grooming’de en çok sorun yaşanan log tablosu EntityChangeLog
Table‘dır. Bu tablo kabaca History Retention ayarlarını alır ve Service Manager Entities’deki değişimleri takip eder. Entities Service Manager’daki CI,WI gibi Itemları Refer etme şeklidir.
EntityChangeLog ve RelatedEntityChange çeşitli nedenlerden dolayı büyüyebilir. Konsolda yüksek History Retention Settings kullanımı,Configuration Item’lardaki bir çok değişikliği takip etme zamanla büyümeye neden olabilir.
Service Manager konfigürasyonunuza bağlı olarak Grooming ile ilgili bir problem görmüş ya da görmemiş olabilirsiniz. Fakat düzenli olarak deployment’ınızın ne durumda olduğunu belirlemek için Grooming’i monitör etmeniz gerekir. (Monitör’den kastım belli aralıklarla bu prosedure’lerin çağırdığı satırların sayılarını kontrol etmek)
Örneğin 5,000 Configuration Items barındıran Incident, Change, and Service Management süreçlerini işleten ServiceManager ortamları için, Retention History Settings olarak 365gün normaldir.
Buna karşın ortamda 30000 Configuration Item varsa ve bunların değişimlerini tutuyorsanız, SLA/SLO, Incident Management, Change and Request Management gibi süreçleri işletiyorsanız, AD, SCCM gibi birden fazla Connector’ünüz varsa, o zaman History Retention Settings’ini 6 Ay yada 120 gün olarak ayarlamayı düşünebilirsiniz.
CMDB’de takip edilen tüm değişiklikler defalarca EntityChangeLog tablosuna yazılır. Çok sağlam bir SQL konfigürasyonunuz varsa ve EntityChangeLog tablonuz 25-30 milyon satır barındırıyorsa her hangi bir probleminiz yok demektir. Ancak genel olarak Service Manager mimarisinde ECL 10
milyondan fazla satır içeriyor ise o zaman orada bir Grooming sıkıntısı olabilir demektir. Aynı durum RelatedEntityChangeLog içinde geçerlidir.
ECL yada RECL tablosu 10 milyon Row’dan fazla satır barındırıyorsa ortamda her hangi bir Grooming hatası aramak gerekmez, Servis Manager performansı iyidir diyebiliriz. Ama kontrollü olmanız gerekir.
Bu tarz yoğunluktaki ECL ya da RECL tablolarında Random olarak yaşanan Grooming hataları için kaygılanmanıza gerek yok fakat devamlı olan hatalar pek iyi bir durumda olmadığınızı gösterir. Bu gibi durumları Service Manager üzerinde önceden sezmiş olmak ve performans problemi yaşamadan sorunları erken teşhis ile çözmek önemlidir.
EntityChangeLog 3 adet farklı Grooming Prosedürüne sahiptir.
- GroomChangeLogs
- GroomStagedChangeLogs
- GroomSubscriptionSpecificECLRows
GroomChangeLogs : History retention time değerini konsolu kullanıp aşağıdaki gibi öğrenebilir ve konfigüre edebilirsiniz. (Service Manager –> Administration –> Settings –> Data Retention Settings –> History)
Resim-1
Retention History gün sayısına bağlı olarak aşağıdaki sorguları kullanıp Grooming’e ihtiyaç duyan kayıt sayılarını görebilirsiniz. Bunlar örnek niteliğindedir.
Normalde bu değer 365 gün’dür. Ancak bu değeri sorgularda kullanırsak örnek sayı değerlerine ulaşamayabiliriz. Çünkü 365 günlük kayıtlar çoktan Groom edilmiştir. O yüzden 120 günlük kayıtları sorgulayıp Grooming bekleyen kayıtları görebilirsiniz. Zaten Grooming hatası aldığınız durumlarda default değeri kullandığınızda da eğer hata mevcutsa sorgular size değer dönecektir.
Script üzerindeki retention periodu 120 güne ayarlayıp devam edelim.
GroomChangeLogs üzerinde Groom edilmeyi bekleyen ne kadar ECL tabanlı entities olduğunu gösteren sorgu;
–declare variables
DECLARE @RetentionDateTime DateTime;
DECLARE @SubscriptionWatermark bigint;
DECLARE @RetentionPeriod int = 120; –<<<<< Bu kısmı 120 olarak ayarlayalım.
–Set variables
SELECT @SubscriptionWatermark = dbo.fn_GetEntityChangeLogGroomingWatermark();
SELECT @RetentionDateTime = DATEADD(d, -@RetentionPeriod, getutcdate())
–Count entities to be Groomed
SELECT count (1) EntityChangeLogId
FROM (SELECT EntityChangeLogId,
LastModified,
EntityTransactionLogId,
ROW_NUMBER() OVER (PARTITION BY EntityId, EntityTypeId ORDER BY EntityChangeLogId DESC) AS RowNum
FROM dbo.EntityChangeLog
WHERE RelatedEntityId IS NULL
AND SubscriptionSpecific = 0) AS D
WHERE D.RowNum > 1 AND
D.LastModified < @RetentionDateTime AND
D.EntityTransactionLogId <= @SubscriptionWatermark;
Resim-2
Şekilde görüldüğü gibi GroomChangeLog üzerinde 899 kayıt Groom edilmeyi bekliyor.
GroomChangeLogs üzerinde ne kadar Groom edilmesi gereken ECL tabanlı Relationship’in olduğunu gösteren sorgu
–declare variables
DECLARE @RetentionDateTime DateTime;
DECLARE @SubscriptionWatermark bigint;
DECLARE @RetentionPeriod int = 120; –<<<<< Retention period’nu 120 olarak ayarlayalım
–Set variables
SELECT @SubscriptionWatermark = dbo.fn_GetEntityChangeLogGroomingWatermark();
SELECT @RetentionDateTime = DATEADD(d, -@RetentionPeriod, getutcdate())
–Count Relationships to be Groomed
SELECT count (1) EntityChangeLogId
FROM dbo.EntityChangeLog
WHERE RelatedEntityId IS NOT NULL AND
LastModified < @RetentionDateTime AND
EntityTransactionLogId <= @SubscriptionWatermark;
Resim-3
Görüldüğü gibi ECL üzerindeki Relationship ile ilgili kayıtların sayısı 2609. Burada daha önceden de belirttiğim gibi 10000 kaydı aşmadıkça telaş edecek bir şey yok demektir.
Grooming ile alakalı diğer tablolar üzerindeki Groom edilmeyi bekleyen kayıtları da aşağıdaki gibi sorgulayabilirsiniz.
GroomStagedChangeLogs üzerinde Groom edilmesi gereken ne kadar ECL tabanlı entities olduğunu gösteren sorgu;
–declare variables
DECLARE @RetentionDateTime DateTime;
DECLARE @RetentionPeriod int = 120; –<<<<< This is where you set your retention days, 120 days in this example
–Set variables
SELECT @RetentionDateTime = DATEADD(d, -@RetentionPeriod, getutcdate())
–Count entities to be Groomed by GroomStagedChangeLogs
SELECT count (1) EntityChangeLogId
FROM EntityChangeLog ECL
WHERE ECL.ChangeType = 3 AND — 3:Staged
ECL.LastModified < @RetentionDateTime;
GroomSubscriptionSpecificECLRows. üzerinde Groom edilmesi gereken ne kadar ECL tabanlı entities olduğunu gösteren sorgu;
–Declare and set the subscription watermark
DECLARE @SubscriptionWatermark bigint = dbo.fn_GetEntityChangeLogGroomingWatermark();
SELECT count (1) EntityChangeLogId
FROM dbo.EntityChangeLog ECL
WHERE ECL.SubscriptionSpecific = 1
AND ECL.EntityTransactionLogId <= @SubscriptionWatermark;
Sorgular kaynak olarak gösterdiğim makaleye ait. Buradaki amaç Groom edilmeyi bekleyen kayıt sayılarını kontrol etmek.
GroomChangeLogsInternal Grooming’deki asıl işi yapar. GroomChangeLogsInternal managed type log tablolarından Grooming işlemi sırasında birbirine bağlı silme işleminin sonucu olan Database bütünlüğünü sağlar Silme işlemleri bu tarz Relationship kayıtlar söz konusu olduğunda yukarıdaki sorguların gösterdiği sonuç değerlerinden daha fazla olacaktır. Yani yukarıdaki Query’leri çalıştırdığınızda bir çok satır getirecektir fakat asıl sonuç bundan fazla olabilir. Bu genellikle EntitiyChangeLog satırlarının silinme işleminde doğrudur.
İzin verilen Grooming değerlerini bildikten sonra artık yapacağınız kontrolleri bu sayıları baz alarak yapabilirsiz. Bu işinizi kolaylaştırır. Eğer event loglarda GroomStagedChangeLogs ile ilgili bir event log görüreniz sayınız muhtemelen bu tabloda oldukça fazladır. Böyle bir durumda Stored Prosedür’ü manuel çalıştırmanız gerekir. Bunu yapmadan önce CMDB nin backupını almanızda fayda var. İşlem içinde yoğunluğun az olduğu bir vakti seçip, Management Server üzerindeki servisleri durdurmanız gerekir.
Aşağıdaki komutlar Grooming Job’larını manuel olarak çalıştırmanızı sağlar. Sadece ilk komut History Retention Settings’in gün değerini dakika cinsinden alır. Diğerleri 0 değerini kullanır.
Ilk parametre System.Entity, ,ikinci parametre dakika cinsinden retention time‘dır. ,üçüncü parametre bu işle ilgili olmadığı için boştur.(NULL), ve 4. parametre ise batch size‘dır.
GroomChangeLogs:
Exec dbo.p_GroomChangeLogs ‘55270A70-AC47-C853-C617-236B0CFF9B4C’, 172800, N”, 5000
GroomStagedChangeLogs:
Exec dbo.p_GroomStagedChangeLogs ‘55270A70-AC47-C853-C617-236B0CFF9B4C’, 0, N” , 5000
GroomSubscriptionSpecificECLRows:
Exec dbo.p_GroomSubscriptionSpecificECLRows ‘55270A70-AC47-C853-C617-236B0CFF9B4C’, 0, N”, 5000
RelatedEntityChangeLog kapalı olarak EntityChangeLog bağlandığında track Relationships çalışır, Buna ilişkin Prosedür aşağıdaki gibidir.
GroomSubscriptionSpecificRECLRows:
GroomSubscriptionSpecificRECLRows kriterine bağlı olarak RelatedEntityChangeLog tablosundan nekadar row silinmeli aşağıdaki sorgu ile elde edebiliriz.
–Declare and set the subscription watermark
DECLARE @SubscriptionWatermark bigint = dbo.fn_GetEntityChangeLogGroomingWatermark();
— Count rows that need to be Groomed from the RelatedEntityChangeLog
SELECT COUNT (1) RECL
FROM dbo.RelatedEntityChangeLog RECL
WHERE RECL.EntityTransactionLogId <= @SubscriptionWatermark
GroomSubscriptionSpecificRECLRows‘u mauel olarak çalıştırmak için,
Exec dbo.p_GroomSubscriptionSpecificRECLRows ‘55270A70-AC47-C853-C617-236B0CFF9B4C’, 0, N”,
Kesinlikle bu işlemler yapılmadan önce SCSM’ın backup’ının alınması gerekir. Herhangi bir sorun yaşandığında böylece hızlıca geri dönüş yapabilirsiniz.
Sorgular ve anlatılanların kaynağı aşağıdadır. Ben makalede anlatılanları açıklayıp anlatmak istedim. Umarım faydalı olmuştur.
Service Manager mimarisinde performans çok önemli ve performansa dayalı yaşanan sorunlarla karşılaşmanız da çok olağandır. Bu makale ile Grooming süreçlerinin performansa etkisini ve Grooming ile alakalı bir event log ya da Service Manager’da performans sorunları yaşarsanız kontrol etmeniz gereken yerleri ve Grooming Jobların’da sorun varsa bunları nasıl manuel olarak tetikleyeceğinizi aktarmış olduk.
Bir sonraki makalede görüşmek üzere.
Bu konuyla ilgili sorularınızı alt kısımda bulunan yorumlar alanını kullanarak sorabilirsiniz.
Referanslar
