Service Manager 2012 R2 – Grooming – Part 3

By | 20 January 2016

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 :)

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 managerdaki 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, ozaman 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 porbleminiz yok demektir. Ancak genel olarak Service Manager mimarisinde ECL 10 milyondan fazla satır içeriyor ise ozaman orada bir grooming sıkıntısı olabilir demektir. Aynı durum RelatedEntityChangeLog içinde geçerlidir.

ECL yada RECL tablosu 10 milyon rowdan 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)

Res1

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;

 

res2

Ş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;

res3

Görüldüğü gibi ECL üzerindeki relationship ile ilgili kayıtların sayısı 2609. Burada daha önceden de belirttiğim gibi 10000 kayıtı 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 relationsip kayıtlar söz konusu olduğunda yukarıdaki sorguların göösterdiği sonuç değerlerinden daha fazla olacaktır. Yani yukarıdaki queryleri ç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ğıdak 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’nin backup’ının alınması gerekir. Herhangibir 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ı olmş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.

FIRAT

Leave a Reply