25 Ocak 2008 Cuma

SQL Server 2008: Declarative Management Framework

Yazarın Notu:
Bu makalenin daha okunaklısını buraya tıklayarak okuyabilirsiniz.


Merhaba arkadaşlar,


Bu yazımın konusu, SQL Server 2008 ile birlikte gelen Declarative Management Framework (DMF). Yazımın devamında, size ilk önce DMF' in kavramlarından ve bileşenlerinden bahsedeceğim, daha sonra da DMF' i ne gibi işlerde kullanabileceğimize dair iki örnek vereceğim ve adım adım resimlerle oluşturulmuş bir örnek yapıp yazımı tamamlayacağım.

Bu makalemi hazırlarken kullandığım SQL Server 2008, CTP5 versiyonudur. CTP versiyonlarını kesinlikle Production ortamınıza kurmanızı önermem. Microsoft' un kalbi olan Redmon' tan konuştuğum SQL Server ile çalışan insanlar bana SQL Server 2008' in Ağustos ayından önce çıkmayacağını söylediler. Yani RTM' e daha çok var. Bu makalemdeki örnekleri yapmak için Sanal Makine kullanmanızı tavsiye ederim.

Ben örneklerimi ve testlerimi MyDB isimli bir veritabanında oluşturuyorum. Hiç bir özelliği yok, alelade bir veritabanıdır kendisi ve arzu ederseniz aşağıdaki komutu kullanarak oluşturabilirsiniz.

=====================
CREATE DATABASE [MyDB]
=====================

Peki nedir bu DMF, ne işe yarar? DMF, kısaca Veritabanı Yöneticileri için gerçekten işe yarayacak, yönetimsel olarak istemediğimiz veya istediğimiz şeylerin bir veya birden çok SQL Server Instance' ında Policy tabanlı olarak uygulanışını denetleyecek, bu sayede de işlerimizi kolaylaştıracak bir yönetim sistemidir.

DMF bir kaç bileşenden oluşuyor. Bunlar:
- DMF Managed Target (Yönetilen Hedef),
- DMF Facet (Bu kelimenin tam karşılığını bilemiyorum ama sanırım 'Model' diyebiliriz),
- DMF Conditions (Koşul),
- DMF Policy (Politika),
- DMF Policy Category (Politika Kategorisi),
- DMF Execution Mode (Çalıştırma Modu), ve
- Effective Policy (Etkin Politika)' dir.

Resim-1

Gözünüzü korkutmasın sakın bu terimler. Ne kadar basit olduklarını verdiğim örneklerde ve kendiniz uygularken göreceksiniz. Basit derken yönetimsel olarak basit demek istedim, işlevleri ise çok işe yarar ve güçlü.

Şimdi size tek tek bu bileşenlerden bahsetmek istiyorum. Nedir bunlar? Ne işe yararlar? Bunları anlatacağım.

DMF Managed Target:
Bir SQL Server Database Engine örneği, bir veritabanı, bir tablo ya da bir dizin (Index) gibi DMF tarafından yönetilen varlıklara DMF Managed Target denir.

DMF Management Facet:
Belli bir Managed Target' ın davranış veya karakteristiğini modelleyen mantıksal özellikler bütünüdür. Özelliklerin sayısı ve karakteristikleri Facet içerisinde inşa edilmiştir ve sadece yapıcısı tarafından eklenip çıkarılabilirler. Bir hedef tipi bir veya daha fazla Facet içerebilir ve bir Facet de bir veya daha fazla hedef tipi tarafından içerilebilir.

DMF Condition:
Bir DMF Managed Target' ın izin verilen durumlarını Management Facet' e göre belirleyen bir Boolean beyandır.

DMF Policy:
Bir DMF Condition ve beklenen davranış biçimidir; örneğin, Execution Mode, Target Filters ve Schedule gibi. Bir Policy sadece bir Condition içerebilir. Policy' ler kullanılabilir veya kullanılamaz duruma getirilebilirler.

DMF Policy Category:
Policy' leri yönetmeye yardımcı olan ve kullanıcı tarafından belirlenmiş bir kategoridir. Kullanıcılar, Policy' leri değişik Policy kategorileriyle sınıflandırabilirler. Bir Policy sadece bir kategoriye ait olabilir. Veritabanı sahipleri bir veritabanını bir Policy kategorisine üye yapabilirler. Sadece kategorilerine üye olunmuş Policy' ler bir veritabanını yönetebilirler. Tüm veritabanları dolaylı olarak varsayılan Policy kategorisine üyedir.

DMF Execution Mode:
Bir Policy' nin nasıl çalıştırılacağını belirler. İstendiğinde çalıştırılan modlar Check ve Configure' dır. Otomatik çalışma modları ise:
- Changes are attempted, prevent out-of-compliance (Değişiklik yapılmak istendiğinde, kuraldışıysa önle)
- Changes are attempted, log out-of-compliance (Değişiklik yapılmak istendiğinde, kuraldışıysa kayıt tut)
- On Schedule, log out-of-compliance (Zaman ayarlı olarak, kuraldışıysa kayıt tut)

Effective Policy:
Bir hedefin Effective Policy' leri, bu hedefi yöneten Policy' lerdir. Bir hedef ile ilgili bir Policy, sadece aşağıdaki şartlar gerçekleştiğinde etkindir:

- Policy etkinleştirilmişse (Enabled)
- Hedef, Policy' nin hedeflerine aitse.
- Hedef veya hedeflerden bir tanesi bu Policy' yi içeren Policy grubuna üyeyse.



DMF' i nerelerde kullanabiliriz?
Aşağıdaki iki örneği inceleyin lütfen.

- Meselâ şirket politikanız Database Mil veya SQL Mail' in kullanılmasını yasaklıyor. Bu iki özelliğin kontrol edilmesi için bir Policy oluşturulur. Bir yönetici, mevcut ayarları ve Policy' yi karşılaştırır. Eğer ayarlar Policy kurallarına uymuyorsa, yönetici Configure modunu seçer ve Policy SQL Server ayarlarını Policy ile uyumlu hale getirir.

- AdventureWorkds veritabanınızdaki tüm Stored Procedure' larınının isimlerinin AW_ ile başlamasının gerektiğini farzedelim. Bu politikanın zorlanması için bir Policy oluşturulur. Bir yönetici bu Policy' yi test eder ve Policy kurallarına uymayan Stored Procedure' ların bir listesini hazırlar. Eğer gelecekteki Stored Procedure' lar bu isimlendirme standardına uymazlarsa, Stored Procedure' lar için kullanılan oluşturma komutları (CREATE PROC) hata verecektir.

Policy Yönetimi
Policy' ler SQL Server Management Studio kullanılarak oluşturulur ve yönetilirler. İşlemler aşağıdaki gibidir:

1. Yapılandırılacak özellikleri içeren bir DMF Facet seçin.
2. Management Facet' in durumunu belirleyen bir Condition tanımlayın.
3. Condition' ı, hedefleri süzen ek Condition' ları ve Execution Mode' ları içeren bir Policy tanımlayın.
4. Bir SQL Server Instance' ının Policy ile uyuşup uyuşmadığını kontrol edin.

Bir Policy' de hata oluştuğunda, SSMS' teki Object Explorer' da hedefin hemen yanında ve hedefin daha üstündeki düğümlerde kırmızı bir simge şeklinde kritik sağlık uyarısı görünür.

Policy' ler msdb sistem veritabanında tutulurlar. Bir Policy veya Condition değiştirildiğinde msdb veritabanı da yedeklenmelidir.

DMF' i yönetmek için msdb veritabanındaki PolicyAdministratorRole rolüne üye olunması gerekir. Bu rolün, sistem üzerindeki tüm Policy' lerde tam kontrolü vardır. Kontrol, Policy' lerin ve Condition' ların oluşturulması ve düzenlenmesi ve Policy' lerin kullanılabilir veya kullanılamaz yapılmasını kapsar.


DMF ile Adım Adım SP İsimlendirme Standardı Policy' si Oluşturma Örneği
Öncelikle iki adet DMF Condition oluşturacağız, daha sonra Policy' mizi de bu Condition' ları kullanarak oluşturacağız ve testlerimizi yapacağız.

İlk oluşturacağımız Condition' da uygulayacağımız isimlendirme standardının hangi veritabanına uygulanacağını belirleyeceğiz. Bunun için aşağıdaki adımları uygulayın:

- SSMS' i açın ve çalışacağınız SQL Server Instance' ına bağlanın.
- Object Explorer' daki Management düğümünü genişletin. Conditions düğümünün üzerinde farenin sağ tuşuna basın ve açılan menüden "New Condition..." seçeneğine tıklayın. Daha sonra açılan Create New Condition penceresinde Resim-2' deki gibi bir Condition oluşturun.
- Seçeneğe bağlı olarak oluşturduğunuz Condition için bir Açıklama (Description) tanımlayabilirsiniz. Description' ı "Create New Condition" penceresinin sol tarafındaki "General" sekmesinin hemen altında görebilirsiniz.

Resim-2

Bu Condition ile Policy' mizi oluştururken göreceğiniz gibi isim standardının sadece MyDB veritabanındaki Stored Procedure' lere uygulanmasını sağlayacağız.

Şimdi ikinci Condition' ımız olan İsim Standardını belirleme Condition' ımızı oluşturalım.

- Zaten açık olduğunu varsaydığım Conditions düğümünün üzerinde farenin sağ tuşuna basın ve açılan menüden "New Condition..." seçeneğine tıklayın. Daha sonra açılan Create New Condition penceresinde Resim-3' deki gibi bir Condition oluşturun.

Resim-3

Bu ayarlarla, nesnemizin isminin ilk 4 karakterinin 'eko_' olmasını ağlayacağız, gerisi de bu nesneyi oluşturan kullanıcıya kalmış.

Artık Condition' larımızı oluşturmuş olduk, şimdi sıra Policy' de. Bunun için gene Object Explorer' daki Policy düğümünün üzerinde farenin sağ tuşuna tıklayın ve açılan menüden "New Policy..." seçeneğine tıklayın. Daha sonra açılan "Create New Policy" penceresinde Resim-4 ' teki gibi bir Policy oluşturun.

Resim-4

İsim standardımızın sadece Stored Procedure' lere uygulanması için "Against targets:" listesinde sadece StoredProcedure' ün solundaki seçim kutusunu işaretlemeniz gerekiyor. Bu işaret kutusunun sağındaki yazıları tercüme etmemiz gerekirse şöyle edebiliriz: "MyDB veritabanımdaki tüm Stored Procedure' leri belirlediğim isim standardına uydur." Dikkat ettiyseniz MyDB veritabanımız için oluşturduğumuz Condition' ı hemen "Every StoredProcedure" yazısının hemen altındaki "Isim Standarti Uygulanacak Veritabanim" olarak görürsünüz. "eko_" olarak belirlediğimiz isim standardımızı da "Check condition" açılır kutusunda görebilirsiniz.

Execute Mode olarak da "On Change - Prevent" i seçelim. Böylece, bundan sonra belirlediğimiz isim standardına uymadan oluşturulmaya çalışılacak tüm Stored Procedure' lerin oluşturulması engellenecektir.

Ayrıca "Create New Policy" penceresindeki "Enabled" seçim kutusunu sakın es geçmeyin. Çünkü eğer bu kutucuğu işaretlemezsek, Policy' miz etkin hale gelmeyecektir ve isim standardımız uygulanmayacaktır.

Seçeneğe bağlı olarak oluşturduğunuz Policy için de bir Açıklama (Description) tanımlayabilirsiniz. Description' ı "Create NewPolicy" penceresinin sol tarafındaki "General" sekmesinin hemen altında görebilirsiniz.

DMF Policy' mizi Test Edelim!
Peki eğer biz bu DMF Condition ve Policy' leri oluşturmadan önce isim standardımıza uymayan bir Stored Policy oluşturulmuşsa o zaman ne olacak? Policy' mize uymayan nesneleri en kısa yolla nasıl buluruz? Tabii ki Policy' mizi test ederek!

Öncelikle Policy' mizin çalışıp çalışmadığını bir test edelim. Bunun için yeni bir Query açın ve Query Editor penceresinde aşağıdaki kodu çalıştırın.

=====================
USE MyDB
GO
CREATE PROCEDURE Test
AS
SELECT * FROM MyDB
=====================

Bu komutu çalıştırdıktan sonra eğer Conditon ve Policy' leriniz sorunsuz çalışıyorsa Query Editor' deki "Messages" penceresinde aşağıdaki hatayı almanız gerekiyor.

=====================
TEST1(TEST1\lab): Policy 'Isim Standardi' has been violated by 'Server/Database[@Name='MyDB']/StoredProcedure[@Name='test' and @Schema='dbo']'. This transaction will be rolled back. Policy description: '' Additional help: '' : ''. TEST1(TEST1\lab): Msg 3609, Level 16, State 1, Procedure sp_syspolicy_dispatch_event, Line 50 The transaction ended in the trigger. The batch has been aborted.
=====================

Eğer bu hatayı aldıysanız her şey yolunda demektir. Hatayı şöyle tercüme edebiliriz: "test" isimli bir Stored Procedure oluşturmaya çalıştığınız için "Isim Standardi" isimli Policy' yi ihlal ettiniz. Yapılan işlem geri alınacaktır.

Eğer bu hatayı almadıysanız ve "test" isimli SP oluşturulduysa, Policy' nizin etkin olduğundan emin olun. Bunun için Policy' nizi Object Explorer' daki Policies isimli düğümün altında bulabilir ve üzerinde sağ tuşa tıklayabilir ve "Enabled" olduğundan emin olabilirsiniz ya da Policy' nizin özelliklerinden (üzerinde sağ tuş ve açılan menüden Properties' e tıklayarak) "Enabled" seçim kutusunun seçili olduğundan emin olabilirsiniz. Eğer "Enabled" ise ve gene de isimlendirme kuralı işlemiyorsa, o zaman oluşturduğunuz Condition' ları tekrar gözden geçirmenizi tavsiye ederim.

Ayrıca Policy' nizin etkin veya etkin olmadığını simgesinden de anlayabilirsiniz. Eğer Policy' nizin simgesinin sağ alt köşesinde aşağı giden kırmızı bir ok resmi varsa o zaman Policy' niz kullanılmıyor durumundadır.

Şimdi biz Policy' mizi oluşturmadan önceki Stored Procedure' lerle ilgilenebiliriz! Yalnız bu bölümü daha anlaşılabilir yapmak için bir planım var. Umarım "amma uzattın sen de!" demiyorsunuzdur.

Bunun için sizden Policy' nizi yukarıda anlattığım yöntemle kullanılmıyor yapmanızı yani "Disable" etmenizi isteyeceğim. Haklı nedenlerim var! Çünkü isim standardı politikamızı çiğneyen bir Stored Procedure oluşturmamızın tek yolu bu. Böyle bir SP oluşturalım ki, konuyu daha iyi anlamamıza yardımcı olsun.

"Isim Standardi" isimli Policy' yi "Disable" ettikten sonra aşağıdaki kodu kullanarak bir SP oluşturun.

=====================
USE MyDB
GO
CREATE PROCEDURE Test
AS
SELECT * FROM MyDB
=====================

Evet, böylece kuralı çiğneyen bir SP oluşturabildik en sonunda! Şimdi lütfen şu Policy' yi tekrar "Enable" edin. Biliyorum biliyorum, çok masraflıyım!

Şimdi bir de isim politikamıza uyan bir SP oluşturalım. Lütfen aşağıdaki kodu çalıştırın.

=====================
USE MyDB
GO
CREATE PROCEDURE eko_Test
AS
SELECT * FROM MyDB
=====================

Şimdi biri "Test" diğeri de "eko_Test" isimli iki tane SP' miz oldu. Hayırlı olsun. Biri isimlendirme standardımıza uyuyor, diğeri ise uymuyor. Şimdi bunu Policy' mize nasıl otomatik olarak bulduracağımızı göreceğiz.

Bunun için SSMS' teki Object Explorer' da bulunan Management\Policies düğümü altındaki "Isim Standardi" isimli Policy' nizi bulun ve üzerinde farenin sağ tuşuna tıklayın. Açılan menüden "Test Policy..." seçeneğine tıklayın. Aşağıda bulunan Resim-5' e benzer bir pencerenin açılması gerekiyor.

Resim-5

Eğer "Run Now - Isim Standardi" isimli pencereye bakarsanız yukarıda oluşturduğumuz iki SP' yi göreceksiniz. Birisi "Isim Standardi" isimli Policy' ye uyuyor, diğeri ise uymuyor. Aynı penceredeki "Target" isimli sütunda sorunun nedeni yazıyor. Eğer "Details" sütununda bulunan "View..." bağlantısına tıklarsanız karşınıza Resim-6' dakine tıpatıp benzer bir pencere çıkması lâzım.

Resim-6

Bu pencerede hatanın nedenini çok daha kolay görebilirsiniz. Bu pencere, bir önceki Resim-5' teki pencerede bulunan ve Target sütununda yazan ve karmaşık görünen hata mesajının biçimlendirilmiş şeklidir. "Expected Value" sütunu girilmesi umulan değerdir, "Actual Value" sütunu ise girilen değerdir. Belirlediğimiz isimlendirme standardı Policy' mizin sonucu olarak, SP' lerin adlarının ilk dört karakterinin "eko_" olması gerekiyor, fakat bu SP' nin adı böyle değil. İşte bu nedenle bu SP hata veriyor.

Eğer değer True\False gibi bir değer olsaydı Resim-5' teki "Run Now" isimli pencerede bulunan "Configure" etiketli düğmeye tıklayarak gerekli ayarların otomatik olarak yapılmasını sağlayabilirdik. Fakat bu ayar otomatik olarak yapılamaz. Bu nedenle gidip elle "Test" isimli SP' nin adını "eko_Test2" yaparsanız tekrar Policy' yi test ettiğinizde buir hata ile karşılaşmadığınızı göreceksiniz.

Bu değişikliği yapmadan önce Resim-7' ye de bir gözatmanızı istiyorum. Size bu yazımın önceki bölümlerinden biri olan Policy Yönetimi isimli bölümde şöyle demiştim: "Bir Policy' de hata oluştuğunda, SSMS' teki Object Explorer' da hedefin hemen yanında ve hedefin daha üstündeki düğümlerde kırmızı bir simge şeklinde kritik sağlık uyarısı görünür.". İşte Resim-7' de bunu görüyorsunuz. SSMS' teki Object Explorer otomatik olarak Refresh yapmıyor, bu nedenle göremiyor olabilirsiniz, F5' i kullanarak veya Object Explorer' daki Refresh düğmesini kullanarak düğümleri yenileyebilirsiniz. Resim-7' nin sağ tarafındaki "Object Explorer Details" penceresindeki "Policy Health State" e de dikkat edin, "Critical" yazıyor.

Resim-7

Siz de daha değişik Facet' leri ve Condition' ları kullanarak değişik Policy' ler oluşturabilirsiniz, ki oluşturmanızı da tavsiye ederim.

Özetle, size bu makalemde SQL Server 2008 ile birlikte gelecek ve yönetim işlerinde biz Veritabanı Yöneticilerinin çok işine yarayacağını düşündüğüm Declarative Management Framework' ü size anlatmaya çalıştım. Umarım yararı dokunmuştur.


Ekrem Önsoy

1 yorum:

mf_tunc@hotmail.com dedi ki...

Ekrem bey merhaba;değerli deneyimleriniz için teşekkür ederim. Şöyle bir durumda uygulayabileceğimiz bir policy var mıdır merak ediyorum ?

Büyük bir database var ve bu db üzerinde where koşulu olmayan sorguların çalışmasını istemiyoruz.

Select * from table gibi sorgu çalışmasın istiyoruz

Uzun süredir arştırmama rağmen bir sonuca ulaşabilmiş değilim.Bu konuda yapılabilecek herhangi bir şey var mıdır acaba ?