SQL Server 2008’de policy based management


SQL Server’ın Türkçe sürümü olmadığı için arayüzde kullanacağınız unsurlarla ilgili kavramların İngilizce isimlerini kullanıyorum.

2008’in getirdiği önemli bir yenilikte policy based management.

Policy based management’ın üç önemli faydası var:

– Bir kuralı baştan belirleyip buna aykırı bir eylemin gerçekleşmesini en baştan engelleyebilirsiniz.
– Gözetim amaçlı kullanabilirsiniz. Yani yasaklamazsınız, ama belirli aralıklarla kural dışı uygulama olup olmadığını hızlı bir şekilde inceleyebilirsiniz.
– Engelleme ya da gözetim işlerini merkezi olarak birden fazla sunucu üzerinde yapabilirsiniz.

Policy’leri anlamak için öncelikle üç temel nesneyi kavramamız gerekiyor: Facet, Condition ve Target.

Facet sadece bir özellikler demeti. Birbiriyle ilişkili olan özellikler bir facet altında guruplanıyor. Ama tek başına facet bu özelliklerin değerlerine ilişkin hiçbir şey ifade etmiyor.

Condition belirli bir facet altındaki bir ya da birkaç özelliğin hangi değerlerde olmasını istediğinizi ayarladığınız nesne.

Target ise policy’i hangi nesnelere uygulayacağınızı belirliyor.

Bir policy, bir condition’ın belirlenen target’ta bir evaluation mode’u ile uygulanması anlamına geliyor. Target alanında filtreleme yapabiliyorsunuz. Ayrıca policy’lerin category’leri de olabiliyor. Policy’leri enable ya da disable etmeniz mümkün.

Öncelikle evaluation mode’dan bahsedelim. Bu ayar, policy’nin çalışma şekliyle ilgili dört seçenek sunuyor:

– On demand: Bu durumda policy ile ilgili bir otomasyon yok. Değerlendirilmesini istediğiniz zaman elle tetikliyorsunuz.

– On schedule: Bir SQL Server Agent job’ı ile zamanlanarak policy kontrol edilir.

– On change log only: Bu seçenek event notifications altyapısını kullanır. Değişiklik durumunda sadece loglama yapılır.

– On change prevent: Bu seçenekse DDL triggerlarını kullanır. Değişiklik yapılmak istenen transaction roll back edilir ve policy ile ilgili bir hata mesajı verilir. Bunu kullanabilmeniz için sunucu seçeneklerinden olan nested triggers’ın enabled durumda olması gerekir. (Zaten varsayılan değeri budur.)

Policy’lere category atayabileceğinizden bahsetmiştik. Bunun en temel faydası, category bazında Mandate Database Subscriptions seçeneğini enable ya da disable edebilmenizdir. Mandate etmiş durumdaysanız, targettaki veritabanları zorunlu olarak bu policy’e abone olur. Aksi durumda veritabanı yönetimi seviyesinde politikaya abone olunabilir ya da abone olunmayabilir.

Policy based management, özellikle güvenlik bölümlerinin SQL Serverlarla ilgili belirledikleri kuralların uygulanmasını denetleyebilmeleri açısından büyük fayda sağlayacaktır.

Bu yazı SQL Server 2008 içinde yayınlandı. Kalıcı bağlantıyı yer imlerinize ekleyin.

4 Responses to SQL Server 2008’de policy based management

  1. Mustafa bey merhaba;varoan çok büyük bir database yapımız var. ve bu yapıda herhangi bir client dan select * from table gibi bir sorgunun çaışmasını istemiyoruz.yani sorgu where koşulu olmadan çalışamasın.bunu policy lerle yapabilir miyiz acaba ?

  2. Mustafa Acungil dedi ki:

    MerhabalarFacet'lere bakmak lazım. Çünkü condition'larda falan facet'lerdeki property'leri kullanıyoruz.Query diye bir facet yok. Stored Procedure, trigger gibi facetlere baktım. Onlarda da statement'ın kendisi değil mesela insert triggerı mı gibi konular var.Sanırım policy yoluyla yapmanız mümkün değil.

  3. Dün biraz daha araştırdım ; query governor diye bir olay var ama o da bizim işimizi görecek gibi görünmüyor. Orada da Cpu veya memory kullanımı şu kadar olan sorgular çalışmasın gibi bir durum söz konusu. Yazılım firmasının kodlarını tekrar düzenlemesi en kolay çözüm olacak sanırım 🙂

  4. Mustafa Acungil dedi ki:

    O yöne yönelirseniz iki seçenek var.Yani eğer amacınız belirli bir maliyetten yüksek sorguların engellenmesi ise:1. Timeout. Kötü bir mekanizmadır. Çünkü timeout zamanı dolana kadar sorgu çalışır. Belki de 3-5 saniye sonra bitecek olan bir sorgu da timeout yiyebilir.Ama yine de diyelim gerçekte çalışmasına izin vermek istediğiniz en uzun sorgu on dakika sürüyorsa, 20 dakikalık bir timeout ayarlamak belirli ölçüde iş görebilir.Kötü olan, sorgu o kadar süre boyunca gereksiz yere sistemi meşgul edecektir ve beklenmedik yoğunluk anlarında normal sorgularınız da bu limiti yiyecek kadar uzayabilirler. (Bazı önemli ve uzun süren raporlarınızı düşünün mesela…)2. Query Governor Cost Limit. Bu timeout'tan iyidir. Çünkü cost tahmini eğer limitin üzerindeyse sorguyu hiç başlatmaz.Ama bu da tam olarak çözüm değildir. Ya sisteminizde bir tane çok uzun süren ve gerçekten yapılabilecek bir şey olmayan bir sorgunuz varsa, ve çalışmasını istemediğiniz sorgular bundan kısa sürüyorsa? Bu durumda query governor cost limiti yüksek ayarlasanız, istemediğiniz sorgulara etki etmez; düşük ayarlasınız, çalışması gereken sorgunuz da çalışmaz.Doğru çözüm, çalışmakta olan sorguları sağlanan çok çeşitli imkanlarla (ve bunlar epeyce de kolay kullanılabiliyor) inceleyip sorun olanları bulmak ve bunların iyileştirilmesini sağlamaktır.

Bir Cevap Yazın

Aşağıya bilgilerinizi girin veya oturum açmak için bir simgeye tıklayın:

WordPress.com Logosu

WordPress.com hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap /  Değiştir )

Google fotoğrafı

Google hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap /  Değiştir )

Twitter resmi

Twitter hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap /  Değiştir )

Facebook fotoğrafı

Facebook hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap /  Değiştir )

Connecting to %s