HATA: Product: SQL Server System CLR Types -- SQL Server System CLR Types requires the .NET Framework version 2.0 or 3.0 or 3.5 or 4.0. Ensure that this requirement is fulfilled before installing SQL Server System CLR Types.
AÇIKLAMA:
SQL Server 2008 (SP1 + CU2) sunucularımızdan birine SP2 kurmaya çalışırken bu hatayı aldım. Sunucuda haliyle .Net kurulumu zaten vardı. Bu kurulumu onarmak istediğimde de başka bir hata alınca, en akıllıcasının sunucuyu yeniden başlatmak olduğunu düşündüm ve voila!
ÇÖZÜM:
Sunucuyu yeniden başlatınca bu sorun düzeliyor. Eğer olur da düzelmezse, .Net kurulumunu onarmayı denemenizi tavsiye edebilirim.
SQL Server 2008 etiketine sahip kayıtlar gösteriliyor. Tüm kayıtları göster
SQL Server 2008 etiketine sahip kayıtlar gösteriliyor. Tüm kayıtları göster
28 Eylül 2011 Çarşamba
5 Aralık 2008 Cuma
"See Object Explorer Details for objects in this folder"
BİLGİ:
"See Object Explorer Details for objects in this folder"
AÇIKLAMA:
SQL Server 2008' in SQL Server Management Studio aracını kullanarak, Object Explorer' daki 2500' den fazla öğe içeren herhangi bir düğümü\klasörü genişlettiğinizde bu mesaj ile karşılaşabilirsiniz.
Aslında bu bir hata değil, tasarımdan kaynaklanan bir sınırlama. Bu sınırlamanın nedeni ise Windows XP ve Windows Server 2003' teki Tree View kontrolündeki bir hata (BUG).
Bu sınırlamayı kaldıran herhangi bir yama veya çözüm şu anda yok.
Bununla birlikte, alternatif olarak (ilgili mesajda da belirtildiği üzere) Object Explorer yerine Object Explorer Details penceresini kullanabilirsiniz veya ilgilendiğiniz öğelerin listelenmesi için süzgeci kullanabilirsiniz.
Süzgeci kullanabilmek için, genişlettiğiniz düğümün üzerinde (misal olarak eğer tabloları genişletmek istiyorsanız bu düğümün adı "Tables" olacaktır) farenin sağ tuşuna tıklayın ve açılan menüden "Filter -> Filter Settins" öğesini seçin. Açılan süzgeç ayarları penceresinde ilgili süzme ayarlarını yapıp (2500 öğeyi geçmeyecek kadar) sadece ilgilendiğiniz öğeleri listeleyebilirsiniz.
Konuyla ilgili geribildirimi ve bu geribildirime Microsoft' tan gelen cevabı okumak için şu bağlantıyı takip edin:
https://connect.microsoft.com/SQLServer/feedback/Viewfeedback.aspx?FeedbackID=362453
"See Object Explorer Details for objects in this folder"
AÇIKLAMA:
SQL Server 2008' in SQL Server Management Studio aracını kullanarak, Object Explorer' daki 2500' den fazla öğe içeren herhangi bir düğümü\klasörü genişlettiğinizde bu mesaj ile karşılaşabilirsiniz.
Aslında bu bir hata değil, tasarımdan kaynaklanan bir sınırlama. Bu sınırlamanın nedeni ise Windows XP ve Windows Server 2003' teki Tree View kontrolündeki bir hata (BUG).
Bu sınırlamayı kaldıran herhangi bir yama veya çözüm şu anda yok.
Bununla birlikte, alternatif olarak (ilgili mesajda da belirtildiği üzere) Object Explorer yerine Object Explorer Details penceresini kullanabilirsiniz veya ilgilendiğiniz öğelerin listelenmesi için süzgeci kullanabilirsiniz.
Süzgeci kullanabilmek için, genişlettiğiniz düğümün üzerinde (misal olarak eğer tabloları genişletmek istiyorsanız bu düğümün adı "Tables" olacaktır) farenin sağ tuşuna tıklayın ve açılan menüden "Filter -> Filter Settins" öğesini seçin. Açılan süzgeç ayarları penceresinde ilgili süzme ayarlarını yapıp (2500 öğeyi geçmeyecek kadar) sadece ilgilendiğiniz öğeleri listeleyebilirsiniz.
Konuyla ilgili geribildirimi ve bu geribildirime Microsoft' tan gelen cevabı okumak için şu bağlantıyı takip edin:
https://connect.microsoft.com/SQLServer/feedback/Viewfeedback.aspx?FeedbackID=362453
5 Kasım 2008 Çarşamba
SQL Server 2008: Auditing
Merhaba arkadaşlar,
Bu özellik, kısmen de olsa SQL Server 2005' te SQL Trace gerçekleştirilebiliyordu. Kısmen diyorum, çünkü "hangi veritabanına kimler erişmiş?" gibi denetimleri SQL Trace ile yapamıyorduk. Bu tür denetimleri gerçekleştirmek için üçüncü parti programlar kullanılıyor veya alternatif yöntemlerle gerçekleştirilmeye çalışılıyordu. Fakat artık, bu tür denetimler de SQL Server 2008 ile gerek veritabanı, gerekse sunucu düzeylerinde yapabiliyor.
Denetim derken...?
Denetimden kasıt, "Veritabanımdaki bir tabloya\tablolara kim erişmiş?", "Kim yeni kayıt eklemiş veya silmiş veya değişiklik yapmış?", "Kim yeni bir Login oluşturmuş?" gibi sorulara ayrıntılı olarak cevap bulmanızdır. Sunucu veya veritabanı düzeyinde, çeşitli denetimleri SQL Server 2008' in bu özelliği ile takip edebilirsiniz. İleriki bölümlerde ayrıntılı örneklerini de göstereceğim.
Nasıl yapılır?
Önceki paragraflarda da belirttiğim gibi, denetim işlemi hem sunucu düzeyinde, hem de veritabanı düzeyinde gerçekleştirilebilir.
Bir denetim işlemini başlatmadan önce, bu denetim kayıtlarının nerede, nasıl ve hangi ayarlara göre saklanması gerektiğini ayarlamanız gerekiyor. Bunun için, ilk önce sunucu düzeyinde bir Audit oluşturmalısınız. Ardından, eğer denetimi sunucu düzeyinde yapmak istiyorsanız bir Server Audit Specification, eğer denetimi veritabanı düzeyinde oluşturmak istiyorsanız o zaman da bir Database Audit Specification oluşturmalısınız.
Bu elemanları ister T-SQL kullanarak, isterseniz de SQL Server 2008 ile birlikte gelen SQL Server Management Studio ile oluşturabilirsiniz. Örneklerimizde ben iki yöntemi de kullanacağım. Böylece iki yöntem hakkında da fikriniz olacak.
Şimdi, aşağıda da listelediğim bu üç denetim elemanını nasıl oluşturacağınızı, bunların ne olduğunu ve bu denetim sonucu oluşan raporu nasıl okuyacağınızı adım adım kendi başlıkları altında inceleyelim.
Audit : Denetim verilerinin saklanacağı konum ayarları.
Server Audit Specification: Sunucu düzeyinde belirlenecek denetim kuralları.
Database Audit Specification: Veritabanı düzeyinde belirlenecek denetim kuralları.
Log Viewer - Audit: Audit nesnesinde tanımladığımız raporun okunması.
Yapacağımız örneklerde bir senaryo üzerinden gidersek, konunun ve bu denetim mekanizmasına aşina olmayanların konuyu anlamasına yardımcı olacağını düşünüyorum. Senaryomuz şöyle: Şirketimizde, bilişim işleriyle ilgili taşeron bir firma var. Bu firmadan çalışanlar zaman zaman şirketimize geliyorlar ve SQL Server sunucumuzda bazı çalışmalar yapıyorlar. Ayrıca, bu arkadaşların SQL Server Instance' ımıza da erişim hakları var. SQL Server Instance' ımızdaki veriler bizim için çok kritik ve önemli. Taşeron firmadan gelen arkadaşların yetkileri yüksek, bu nedenle görmelerini istemediğimiz verilere erişme şansları var. Yaptığımız yazılı anlaşmalar neticesinde, böyle bir şeyin olmayacağını garanti ediyorlar. Ama herkesin malûmu, sonuçta ortada bir insan faktörü var ve biz veritabanı yöneticileri, güvenliği sıkı tutmalıyız. Aksi takdirde hesap sorulacakların en üst sıralarında bizim de isimlerimizin olduğunu çok iyi biliyoruz.
Özetle, şirketimize gelen taşeron firma çalışanlarının, "Muhasebe" isimli veritabanındaki tablolarımıza erişim erişmediklerini sıkı bir şekilde kontrol edeceğiz.
Audit
Audit' in nasıl oluşturulduğuna geçmeden önce, Audit' in üç farklı yere kaydedilebileceğini belirtmek istiyorum. Bunlar:
Windows Event Log: Application Log' a
Windows Event Log: Security Log' a
Dosya sisteminde bir dosyaya.
Not: Security Log' a kayıt işlemi Windows XP' de gerçekleştirilemiyor. Ayrıca, Security Log' a kayıt yaptırmak için ekstra ayarlar yapmanız gerekiyor. Bu ekstra ayarlar konusunda daha fazla bilgi için buraya tıklayın.
Biz örneğimizde, denetim verilerimizi bir dosyaya kaydedeceğiz.
T-SQL Yöntemiyle Audit Oluşturmak:
CREATE SERVER AUDIT [AuditTaseron] TO FILE
(FILEPATH = N'C:\Test\' ,
MAXSIZE = 500 MB ,
MAX_ROLLOVER_FILES = 5,
RESERVE_DISK_SPACE = OFF )
WITH
(QUEUE_DELAY = 1000 ,
ON_FAILURE = SHUTDOWN )
GO
Bir Audit nesnesi oluşturulduğunda, varsayılan olarak kullanılamaz (disabled) şekilde oluşturulur. (bkz. Resim - 3)
Dikkatinizi çektiyse, FILEPATH ile bir dosya adı değil, klasör yolu belirttim. Çünkü dosya adını, SQL Server kendi atayacak. MAXSIZE ise, denetim dosyasının ulaşabileceği en büyük dosya boyutu olacak. Bu ayarı yapmakta fayda var, çünkü zaten sunucunuzda bir çok kayıt dosyası sürekli doluyor ve büyüyor. Bu tür büyümeleri kontrol altında tutarsanız, bir gün "Diskinizde boş yer kalmadı!" gibi bir sürpriz ile karşılaşma olasılığınız azalır. MAX_ROLLOVER_FILES, kaç tane dosyanın kaydedileceği bilgisidir. 0 değeri sınırsız anlamına gelir. RESERVE_DISK_SPACE, MAXSIZE' da belirttiğiniz kadar alanı baştan ayırmak için kullanılır; eğer değeri ON ise, o zaman bu alan baştan ayrılır, eğer OFF ise, alan ihtiyaca göre ayrılır.
Audit işlemi, Service Broker temel alınarak yapılan bir işlemdir. İşlemler istenirse eşzamanlı (synchronous), istenirse de eşzamansız (asynchronous) olarak gerçekleştirilebilir. İşte bu ayar da QUEUE_DELAY ile belirtilir. Eğer bu ayarın değeri 0 ise, denetim sırasında toplanan veriler, kayıt yerine (Event Log' lara veya dosyaya) eşzamanlı olarak kaydedilir. Eğer bu değer 1000 ise (ki bu değerler milisaniye bazındadır ve asgari değer 1000' dir) o zaman biriktirilen denetim verileri, kayıt deposuna her bir saniyede bir yazılır. Burada dikkate alınması gereken şey ise, eşzamanlı veya çok kısa aralıklı yapılacak kayıt işlemlerinin belli bir oranda yük getirmesi olacaktır. Sisteminizin durumuna göre bu kayıt aralığını hesaplamalısınız. Ayrıca şunu da unutmamalısınız ki, eğer bu kayıt aralığını fazla uzun tutarsanız, kayıt deposuna kaydedilmemiş denetim verilerini bir elektrik kesintisi veya bir donanım arızası yüzünden kaybetme olasılığınız vardır.
ON_FAILURE ise iki değer alabilir, SHUTDOWN veya CONTINUE. Eğer kayıt dosyasında yer kalmadıysa veya diskinizde yer kalmadıysa yani özetle eğer denetim verileriniz kayıt deposuna kaydedilemiyorsa ve bu ayarın değeri de SHUTDOWN ise, o zaman SQL Server Instance' ınız böyle bir durumda kapanacaktır.
SQL Server Management Studio (SSMS) Kullanarak Audit Oluşturmak:
Denetimler, güvenlikle ilgili ve sunucu düzeyinde çalışan nesnelerdir. Bu nedenle yeni bir Audit oluşturmak istediğinizde, SSMS' teki Object Explorer penceresinden, Security->Audits bölümüne gidersiniz. (bkz Resim 1)
Resim - 1
Resim-1 de de görüldüğü gibi, Audits düğümünün üzerinde fare ile sağ tuşa tıkladığınızda "New Audit..." öğesini göreceksiniz. Bu öğeye tıklayın, "Create Audit" penceresi açılacaktır.
Resim - 2
Yine bu başlık altında, T-SQL kullanarak oluşturduğumuz Audit in aynısı, fakat bu sefer bu Audit' i SSMS kullanarak oluşturuyoruz. Resim - 2' de gördüğünüz tüm ayarları zaten yukarıda açıklamıştım, bu nedenle tekrar açıklamaya gerek yok. Biraz gözatarsanız zaten her şeyin aynı olduğunu göreceksiniz.
Daha önceden size yeni bir Audit nesnesi oluşturduğunuzda, bu nesnenin varsayılan olarak kullanılamaz şekilde oluşturulduğunu söylemiştim. Şimdi bunu tekrar belirtmemin nedeni ise, SSMS' te bu kullanılamazlığın görsel olarak da belirtilmesidir. Bunun için Resim -3' e bakın. Daha belirgin olması için kırmızı bir halka içine aldım.
Resim - 3
Bu nesneyi kullanılabilir hale getirmek için, üzerinde farenin sağ tuşuna tıklamanız ve "Enable Audit" öğesini seçmeniz gerekiyor. Bu noktada şunu da belirtmek istiyorum ki, daha sonraki başlıklarda oluşturacağımız Server Audit Specification ve Database Audit Specification nesneleri de varsayılan olarak kullanılamaz şekilde oluşturulur ve bu nesneler kullanılamaz durumdayken bu durum, Object Explorer' da aynen Resim - 3' teki gibi aşağı kırmızı bir ok ile görsel olarak belirtilir ve bu nesneleri kullanılabilir duruma getirmek için yine aynı şekilde bu nesnelerin üzerinde fare ile sağ tıklayıp "Enable ..." öğesini seçmeniz gerekir.
Bu noktada, artık Audit oluşturma konusunda bir sıkıntı kalmadığını varsayıyorum. Hadi, şimdi de Server Audit Specification nasıl oluşturulur onu inceleyelim!
Server Audit Specification
Bir Server Audit Specification nesnesi oluşturmadan önce, bu nesneyi oluştururken kullanmak üzere bir Audit nesnesinin önceki başlıkta da anlatıldığı gibi oluşturulması gerekiyor.
Bir Server Audit Specification nesnesi oluşturulduğunda, varsayılan olarak kullanılamaz (disabled) şekilde oluşturulur.
T-SQL Yöntemiyle Server Audit Specification Nesnesi Oluşturma
Bu örneğimizdeki Server Audit Specification nesnesine , 4 tane Action Type ekleyeceğim.
CREATE SERVER AUDIT SPECIFICATION [sasTaseron]
FOR SERVER AUDIT [AuditTaseron]
ADD (LOGIN_CHANGE_PASSWORD_GROUP),
ADD (SERVER_ROLE_MEMBER_CHANGE_GROUP),
ADD (SERVER_PRINCIPAL_CHANGE_GROUP),
ADD (DATABASE_CHANGE_GROUP)
GO
Bir Server Audit Specification nesnesini oluşturmak için öncelikle bir Audit nesnesine ihtiyacımız olduğunu önceden de söylemiştim. İşte bu örneğimizde de önceki Audit altbaşlığında oluşturmuş olduğumuz "AuditTaseron" nesnesini kullanıyoruz. Daha sonra da, aşağıda listelediğim Action Type' ları ekliyoruz:
LOGIN_CHANGE_PASSWORD_GROUP: Bu olay, sp_password veya ALTER LOGIN komutlarıyla bir Login' in şifresi değiştirildiğinde tetiklenir.
SERVER_ROLE_MEMBER_CHANGE_GROUP: Bu olay, bir Login, bir Server Fixed Role' e eklenip veya çıkarıldığında tetiklenir.
SERVER_PRINCIPAL_CHANGE_GROUP: Bu olay, örneğin bir Login' in silinmesi veya yeni bir Login' in eklenmesi veya bir Login üzerinde bir takım değişiklikler (örneğin Login' in varsayılan dilini değiştirdiğinizde) yaptığınızda tetiklenir.
DATABASE_CHANGE_GROUP: Bu olay, bir veritabanı silindiğinde, yeni bir veritabanı oluşturulduğunda veya varolan bir veritabanında değişiklik yapıldığında tetiklenir.
Biz örneğimizde sadece 4 tane Action Type kullandık, fakat bu Action Type' lardan başka daha bir çok Action Type vardır. Diğer Action Type' lar hakkında daha fazla bilgi almak için Books Online' a bakabilirsiniz: http://msdn.microsoft.com/en-us/library/cc280663.aspx
SQL Server Management Studio (SSMS) Kullanarak Server Audit Specification Oluşturmak:
Server Audit Specification nesnesi de Audit nesnesi gibi güvenlikle alâkalı bir nesne olduğu için, SSMS' teki Object Explorer' ın, Security düğümünün altında bulunur. (bkz Resim - 4)
Resim - 4
"New Server Audit Specification..." öğesine tıkladığınızda "Create Server Audit Specification" penceresi açılacaktır. (bkz Resim - 5)
Resim - 5
Bu pencerede temel olarak yapacağınız işlem, bu Server Audit Specification nesnesine bir isim vermek, önceden oluşturduğunuz Audit nesnesini, Audit aşağı açılır kutusundan belirlemek ve Audit Action Type listesindeki aşağı açılır kutulardan, ihtiyacınıza göre Action Type' lar eklemektir.
Aynı örneği yukarıda T-SQL ile yaparken size bir çok Action Type olduğunu söylemiştim. Bu Action Type' ların listesini de bu şekilde görmüş oldunuz. Bunların açıklamaları için yine yukarıda verdiğim Books Online adresinden yararlanabilirsiniz. Books Online' nın maalesef bir Türkçe versiyonunun olmadığını da bilmeyenler ve merak edenler için belirteyim.
Audit ve Server Audit Specifications açıklamalı ve adım adım uygulamış olduğumuz örneklerden sonra sıra şimdi de Database Audit Specifications konusunda!
Database Audit Specifications
Yine belirtmem gerekiyor ki, bir Database Audit Specification nesnesi oluşturmadan önce, bu nesneyi oluştururken kullanmak üzere bir Audit nesnesinin Audit başlığında da anlatıldığı gibi oluşturulması gerekiyor.
Ve yine belirtmekte fayda var ki, bir Database Audit Specification nesnesi oluşturulduğunda, varsayılan olarak kullanılamaz (disabled) şekilde oluşturulur.
Bu örnekte, öncelikle hayali taşeron firma için bir Login, "Test" isimli veritabanımızda, oluşturacağımız "TestLogin" isimli Login için "TestUser" isimli bir de User oluşturacağız. Daha sonra, hayali "Alacaklar" isimli tablomuzda, bu "TestUser" kullanıcısı tarafından bir SELECT, UPDATE, INSERT veya DELETE komutunun çalıştırılmasığını kontrol etmek için bir Database Audit Specification nesnesi oluşturacağız. Diğer örneklerimizde olduğu gibi, bu örneği de hem T-SQL ile, hem de SSMS kullanarak yapacağız.
T-SQL Yöntemiyle Database Audit Specification Nesnesi Oluşturma
Aşağıdaki T-SQL kodlarını çalıştırmadan önce, önceden oluşturmuş olduğumuz "AuditTaseron" isimli Audit nesnesini ve "sasTaseron" isimli Server Audit Specification nesnesini kullanılır (Enable) duruma getirdiğinizden emin olun. Nedenini daha sonra söyleyeceğim.
-- "TestLogin" isimli Login' in oluşturulması
USE [master]
GO
CREATE LOGIN TestLogin WITH PASSWORD = 'Pa$$w0rd'
GO
-- Test için kullanılacak, "Test" isimli veritabanının oluşturulması
USE [master]
GO
CREATE DATABASE [Test]
GO
-- Test için kullanılacak "Alacaklar" isimli veritabanının oluşturulması
USE [Test]
GO
CREATE TABLE [Alacaklar]
(id int)
GO
/* "Test" isimli veritabanında işlem yapabilmesi için, taşeron firma çalışanı tarafından kullanılacak "TestUser isimli kullanıcının oluşturulması */
USE [Test]
GO
CREATE USER [TestUser] FOR LOGIN [TestLogin]
WITH DEFAULT_SCHEMA=[dbo]
GO
-- "TestUser" isimli kullanıcının "db_owner" veritabanı rolüne eklenmesi
USE [test]
GO
EXEC sp_addrolemember N'db_owner', N'TestUser'
GO
/* "TestUser" isimli taşeron firma çalışanının "Alacaklar" tabloasuna karşı yapacağı erişimleri takip etmek için kullanılacak "dasAuditTaseron" isimli Database Audit Specification nesnesinin oluşturulması */
USE [Test]
GO
CREATE DATABASE AUDIT SPECIFICATION [dasAuditTaseron]
FOR SERVER AUDIT [AuditTaseron]
ADD (SELECT ON OBJECT::[dbo].[Alacaklar] BY [TestUser]),
ADD (DELETE ON OBJECT::[dbo].[Alacaklar] BY [TestUser]),
ADD (INSERT ON OBJECT::[dbo].[Alacaklar] BY [TestUser]),
ADD (UPDATE ON OBJECT::[dbo].[Alacaklar] BY [TestUser])
GO
Hemen bir önceki paragrafta örneğimizi anlattığım gibi, yukarıdaki T-SQL diliyle de bu örneği SQL Server' a anlatmış oldum.
Server Audit Specification' da olduğu gibi, Database Audit Specification' da da, bir çok Action Type bulunmaktadır. Bu Action Type' ların listesini bir sonraki SSMS örneğimizdeki "Create Database Audit Specification" isimli penceredeki Action Type aşağı açılır kutularında zaten göreceksiniz. Bu Action Type' ların açıklamaları için yine Books Online' dan yararlanabilirsiniz: http://msdn.microsoft.com/en-us/library/cc280663.aspx
SQL Server Management Studio (SSMS) Kullanarak Database Audit Specification Oluşturmak:
Evet! Tahmin edeceğiniz üzere yine aynı şeyi söyleyeceğim! Database Audit Specification nesnesi de elbette güvenlikle alâka bir nesne. Bu nedenle bu nesneler, SSMS' teki Object Explorer' ın Databases isimli düğümünün altındaki veritabanınızın içinde bulunan Security düğümündeki Database Audit Specifications içinde depolanıyor.
Kabul ediyorum, bu terimlere aşina olmayanlara biraz arapsaçı gibi görünmüş olabilir. Ama beni önceden takip edenler bilir, hem de buraya kadar sabredip okumuşsanız siz de görebilirsiniz ki, hiç üşenmeden resimlerle de örnek vermeyi çok severim ben. Hemen aşağıdaki resimde (Resim - 6) Database Audit Specification düğümünü görebilirsiniz.
Resim - 6
"New Database Audit Specification..." öğesine tıkladığınızda "Create Database Audit Specification" penceresi açılacaktır. (bkz Resim - 7)
Resim - 7
Eğer dikkatli bakarsanız, bu arayüzün de, "Create Server Audit Specification" penceresinin arayüzüyle aynı olduğunu görürsünüz ve eğer o penceredeki Object Class, Object, Object Name, Principal alanlarındaki kutucukları kurcaladıysanız, herhangi bir değişiklik yapamadığınızı görmüşsünüzdür. Tek arayüzde iki iş yaptırmaya çalışınca, böyle sonuçlar çıkabiliyor elbette. Neyse ki, bu alanları "Create Database Audit Specification" penceresinde kullanabiliyoruz.
Bildiğiniz üzere Audit Action Type alanında, ihtiyacınıza uygun Action Type' ı seçiyorsunuz. Object Class alanında, seçebileceğiniz üç tane seçenek var. Bunlar: Database, Object ve Schema. (Bu kavramların anlamları ise başka bir konu olduğu ve konumuzun kapsamında olmadığı için bunlara değinmiyorum.) Üzerinde denetim yapmak istediğiniz nesneye göre, Object Class' ını seçersiniz. Meselâ biz örneğimizde "Alacaklar" isimli tabloyu denetlemek istediğimiz için, Object Class olarak "Object" i seçtik. Eğer "Test" isimli veritabanımızdaki tüm tabloları denetlemek isteseydik, o zaman Object Class' ı "Database" olarak seçerdik, Object Name olarak da "Test" i seçerdik. Eğer belli bir kullanıcı veya rolü değil de, tüm kullanıcı ve rolleri denetlemek isteseydik, o zaman Principal alanında bir şey seçmezdik.
Audit, Server Audit Specification ve Database Audit Specification nesneleri için geçerli olan şu kuralı da unutmamalısınız, bu nesnelerden birinde bir değişiklik yapmadan önce, o nesneyi kullanılamaz (disable) duruma getirmeniz gerekir. Aksi takdirde şu hata ile karşılaşırsınız: "Changes to an audit specification must be done while the audit specification is disabled. (Microsoft SQL Server, Error: 33229)".
Log Viewer - Audit
Önceki konu başlıklarında bir Audit' in nasıl oluşturulacağını, bu Audit' in oluşturulmasının sebebi olan bir Server Audit Specification veya Database Audit Specification nesnesinin nasıl ve ne gibi amaçlar için oluşturulabileceğini anlattım. Şimdi sıra, yaptığımız bu otomatik denetim mekanizmasının ürettiği raporların nasıl okunabileceğine geldi.
Bir Audit dosyasının ürettiği kayıt dosyasını okuyabilmek için kullanabileceğiniz en pratik ve kısa yol, SSMS' teki Log Viewer' ı kullanmaktır. Bunun için, SSMS' i açtıktan sonra Resim - 1' de gösterilen Audits düğümü altında oluşturduğunuz Audit nesnesinin üzerinde farenin sağ tuşuna tıklayıp "View Audit Logs" öğesine tıklayın. Bu sayede, Log Viewer açılır ve ilgili Audit nesnenizin ürettiği kayıtları görebilirsiniz. Yukarıda yaptığımız örneklerde hatırlarsanız "TestLogin" adında bir Login oluşturmadan önce size "AuditTaseron" isimli Audit nesnesini ve "sasTaseron" isimli Server Audit Specification nesnesini kullanılabilir duruma getirin demiştim, bunun nedenini de daha sonra söyleyeceğim demiştim. İşte şimdi söylüyorum; bunun nedeni, CREATE LOGIN komutuyla birlikte sunucu düzeyinde bir işlem yapmamızdı. "Eee?" mi diyorsunuz? O zaman şunu da hatırlatayım, "sasTaseron" ismiyle oluşturduğumuz Server Audit Specification nesnesinin içine bir de SERVER_PRINCIPAL_CHANGE_GROUP Action Type' ı eklemiştik. Bu Action Type' ın takip ettiği olaylardan biri de neydi? Login oluşturulması! Yani eğer CREATE LOGIN komutuyla "TestLogin" Login' ini oluşturmadan önce "AuditTaseron" ve "sasTaseron" isimli nesneleri kullanılabilir duruma getirdiyseniz, "TestLogin" ismindeki Login' i oluşturduğunuz denetim kayıtlarına geçmiş demektir. Sizi bilmiyorum, ama ben nizami şekilde kendi dediklerimi uyguladım ve sonucunu görmek için Resim - 8' e bakabilirsiniz.
Resim - 8
Aslında kaydırma çubuğundan da anlaşılabileceği üzere, oldukça çok alan var ve bu kadar alanı bu kadar küçük bir resme sığdırmak imkânsız. Sığdırsam bile herhalde mikroskopla incelemeniz gerekirdi. Ama yine de bu resimde, elimden geldiğince çok veriyi size göstermeye çalıştım. Alanlardan anlatmaya başlarsak, örneğin, bu komutun çalıştırıldığı tarih ve saati görebilirsiniz. Hangi SQL Server Instance' ında gerçekleştiği (EKREM-PC), hangi komutun çalıştırıldığı (CREATE) ve bu komut ile hangi sınıf işlem yapıldığı (SQL LOGIN) ve daha bir çok bilgiyi görebilirsiniz. Aşağıdaki ayrıntılı bilgi alanına bakarsak, ilk göze çarpacak bilgilerden birisi, "CREATE LOGIN TestLogin WITH PASSWORD '*****'" tür sanırım. Hangi nesnenin hangi komutla oluşturulduğu bilgisi oldukça değerli olabilir. Ayrıca bu nesneyi hangi Login' in oluşturduğunu da görebilirsiniz (EKREM-PC\ekrem).
Bununla birlikte, yine Resim - 8' deki "File Name" bilgisi dikkatinizi çekti mi? Hatırlarsanız, "AuditTaseron" isimli Audit nesnesini oluştururken dosya adı değil, sadece dosya yolu belirtilir demiştim. Dosya adını ise, SQL Server, Audit nesnesinin adı olarak belirlediğiniz bir ad ile birlikte bir GUID (Globally Unique Identifier)' i birleştirerek ve uzantısını da ".sqlaudit" yaparak verir. Bu resimde, bir çok bilgiyle birlikte bu dosya adını da görebiliyorsunuz.
Ayrıca, test etmek için şimdi gidip, "dasTaseron" ismiyle oluşturduğumuz Database Audit Specification nesnesini de kullanılılabilir duruma getirebilirsiniz. Bu nesneye ait kayıtlara da, "sasTaseron" isimli Server Audit Specification nesnesinde olduğu gibi, o nesnenin bağlı olduğu Audit nesnesinin üzerinde farenin sağ tuşuna tıklayarak ve "View Audit Logs" öğesini seçerek ulaşabilirsiniz. "TestUser" isimli kullanıcının "Alacaklar" isimli tabloya yapacağı SELECT, UPDATE, DELETE ve INSERT (DML - Data Manipulation Language) işlemleri yine bu kayıt dosyasında, aynen CREATE LOGIN işlemindeki gibi kaydedilecektir. Fakat "dasTaseron" nesnesini test etmek için sunucuya "TestLogin" ile giriş yapmalı ve bu Login' in "Test" isimli tablodaki bağlı olduğu kullanıcı olan "TestUser" kullanıcısıyla "Alacaklar" tablosuna karşı bir DML işlemi yapmanız gerekiyor. Çünkü hatırlarsanız, Database Audit Specification nesnemizi bu kriterlere göre oluşturmuştuk. Eğer dediğim gibi "TestLogin" kullanıcısıyla bağlanıp "Alacaklar" tablosuna bir sorgu çekerseniz, göreceksiniz ki "AuditTaseron" isimli Audit kayıt dosyasınaki CREATE LOGIN komutunun üzerine bu yaptığınız işlemle ilgili başka bir kayıt daha eklenecektir.
Özet
Çok beklenen ve SQL Server 2008 ile birlikte gelen bir çok özellikten biri olan Auditing konusunu size anlatmaya çalıştım. Bu makaleye başlarken de dediğim gibi, bu gereksinim gerek bazı üçüncü parti yazılımlarla, gerekse SQL Trace ile giderilmeye çalışılıyordu. Fakat artık SQL Server 2008 ile birlikte, arayüz desteğiyle de (SQL Trace özelliği için arayüz desteği yoktu) bu iş oldukça kolaylaştırıldı.
Biz veritabanı yöneticilerinin ana sorumluluklarının başında güvenlik geliyor. "Kim, hangi bilgiye ne zaman erişmiş?" veya "Bu tablodaki değişikliği kim yapmış?" gibi sorulara her an yanıt verebilmeliyiz. Bu yeni Auditing özelliği sayesinde, bu konudaki işimiz daha kolaylaşacak. Umarım bir gün sizin de işinize yarar.
Ekrem Önsoy
Bu özellik, kısmen de olsa SQL Server 2005' te SQL Trace gerçekleştirilebiliyordu. Kısmen diyorum, çünkü "hangi veritabanına kimler erişmiş?" gibi denetimleri SQL Trace ile yapamıyorduk. Bu tür denetimleri gerçekleştirmek için üçüncü parti programlar kullanılıyor veya alternatif yöntemlerle gerçekleştirilmeye çalışılıyordu. Fakat artık, bu tür denetimler de SQL Server 2008 ile gerek veritabanı, gerekse sunucu düzeylerinde yapabiliyor.
Denetim derken...?
Denetimden kasıt, "Veritabanımdaki bir tabloya\tablolara kim erişmiş?", "Kim yeni kayıt eklemiş veya silmiş veya değişiklik yapmış?", "Kim yeni bir Login oluşturmuş?" gibi sorulara ayrıntılı olarak cevap bulmanızdır. Sunucu veya veritabanı düzeyinde, çeşitli denetimleri SQL Server 2008' in bu özelliği ile takip edebilirsiniz. İleriki bölümlerde ayrıntılı örneklerini de göstereceğim.
Nasıl yapılır?
Önceki paragraflarda da belirttiğim gibi, denetim işlemi hem sunucu düzeyinde, hem de veritabanı düzeyinde gerçekleştirilebilir.
Bir denetim işlemini başlatmadan önce, bu denetim kayıtlarının nerede, nasıl ve hangi ayarlara göre saklanması gerektiğini ayarlamanız gerekiyor. Bunun için, ilk önce sunucu düzeyinde bir Audit oluşturmalısınız. Ardından, eğer denetimi sunucu düzeyinde yapmak istiyorsanız bir Server Audit Specification, eğer denetimi veritabanı düzeyinde oluşturmak istiyorsanız o zaman da bir Database Audit Specification oluşturmalısınız.
Bu elemanları ister T-SQL kullanarak, isterseniz de SQL Server 2008 ile birlikte gelen SQL Server Management Studio ile oluşturabilirsiniz. Örneklerimizde ben iki yöntemi de kullanacağım. Böylece iki yöntem hakkında da fikriniz olacak.
Şimdi, aşağıda da listelediğim bu üç denetim elemanını nasıl oluşturacağınızı, bunların ne olduğunu ve bu denetim sonucu oluşan raporu nasıl okuyacağınızı adım adım kendi başlıkları altında inceleyelim.
Audit : Denetim verilerinin saklanacağı konum ayarları.
Server Audit Specification: Sunucu düzeyinde belirlenecek denetim kuralları.
Database Audit Specification: Veritabanı düzeyinde belirlenecek denetim kuralları.
Log Viewer - Audit: Audit nesnesinde tanımladığımız raporun okunması.
Yapacağımız örneklerde bir senaryo üzerinden gidersek, konunun ve bu denetim mekanizmasına aşina olmayanların konuyu anlamasına yardımcı olacağını düşünüyorum. Senaryomuz şöyle: Şirketimizde, bilişim işleriyle ilgili taşeron bir firma var. Bu firmadan çalışanlar zaman zaman şirketimize geliyorlar ve SQL Server sunucumuzda bazı çalışmalar yapıyorlar. Ayrıca, bu arkadaşların SQL Server Instance' ımıza da erişim hakları var. SQL Server Instance' ımızdaki veriler bizim için çok kritik ve önemli. Taşeron firmadan gelen arkadaşların yetkileri yüksek, bu nedenle görmelerini istemediğimiz verilere erişme şansları var. Yaptığımız yazılı anlaşmalar neticesinde, böyle bir şeyin olmayacağını garanti ediyorlar. Ama herkesin malûmu, sonuçta ortada bir insan faktörü var ve biz veritabanı yöneticileri, güvenliği sıkı tutmalıyız. Aksi takdirde hesap sorulacakların en üst sıralarında bizim de isimlerimizin olduğunu çok iyi biliyoruz.
Özetle, şirketimize gelen taşeron firma çalışanlarının, "Muhasebe" isimli veritabanındaki tablolarımıza erişim erişmediklerini sıkı bir şekilde kontrol edeceğiz.
Audit
Audit' in nasıl oluşturulduğuna geçmeden önce, Audit' in üç farklı yere kaydedilebileceğini belirtmek istiyorum. Bunlar:
Windows Event Log: Application Log' a
Windows Event Log: Security Log' a
Dosya sisteminde bir dosyaya.
Not: Security Log' a kayıt işlemi Windows XP' de gerçekleştirilemiyor. Ayrıca, Security Log' a kayıt yaptırmak için ekstra ayarlar yapmanız gerekiyor. Bu ekstra ayarlar konusunda daha fazla bilgi için buraya tıklayın.
Biz örneğimizde, denetim verilerimizi bir dosyaya kaydedeceğiz.
T-SQL Yöntemiyle Audit Oluşturmak:
CREATE SERVER AUDIT [AuditTaseron] TO FILE
(FILEPATH = N'C:\Test\' ,
MAXSIZE = 500 MB ,
MAX_ROLLOVER_FILES = 5,
RESERVE_DISK_SPACE = OFF )
WITH
(QUEUE_DELAY = 1000 ,
ON_FAILURE = SHUTDOWN )
GO
Bir Audit nesnesi oluşturulduğunda, varsayılan olarak kullanılamaz (disabled) şekilde oluşturulur. (bkz. Resim - 3)
Dikkatinizi çektiyse, FILEPATH ile bir dosya adı değil, klasör yolu belirttim. Çünkü dosya adını, SQL Server kendi atayacak. MAXSIZE ise, denetim dosyasının ulaşabileceği en büyük dosya boyutu olacak. Bu ayarı yapmakta fayda var, çünkü zaten sunucunuzda bir çok kayıt dosyası sürekli doluyor ve büyüyor. Bu tür büyümeleri kontrol altında tutarsanız, bir gün "Diskinizde boş yer kalmadı!" gibi bir sürpriz ile karşılaşma olasılığınız azalır. MAX_ROLLOVER_FILES, kaç tane dosyanın kaydedileceği bilgisidir. 0 değeri sınırsız anlamına gelir. RESERVE_DISK_SPACE, MAXSIZE' da belirttiğiniz kadar alanı baştan ayırmak için kullanılır; eğer değeri ON ise, o zaman bu alan baştan ayrılır, eğer OFF ise, alan ihtiyaca göre ayrılır.
Audit işlemi, Service Broker temel alınarak yapılan bir işlemdir. İşlemler istenirse eşzamanlı (synchronous), istenirse de eşzamansız (asynchronous) olarak gerçekleştirilebilir. İşte bu ayar da QUEUE_DELAY ile belirtilir. Eğer bu ayarın değeri 0 ise, denetim sırasında toplanan veriler, kayıt yerine (Event Log' lara veya dosyaya) eşzamanlı olarak kaydedilir. Eğer bu değer 1000 ise (ki bu değerler milisaniye bazındadır ve asgari değer 1000' dir) o zaman biriktirilen denetim verileri, kayıt deposuna her bir saniyede bir yazılır. Burada dikkate alınması gereken şey ise, eşzamanlı veya çok kısa aralıklı yapılacak kayıt işlemlerinin belli bir oranda yük getirmesi olacaktır. Sisteminizin durumuna göre bu kayıt aralığını hesaplamalısınız. Ayrıca şunu da unutmamalısınız ki, eğer bu kayıt aralığını fazla uzun tutarsanız, kayıt deposuna kaydedilmemiş denetim verilerini bir elektrik kesintisi veya bir donanım arızası yüzünden kaybetme olasılığınız vardır.
ON_FAILURE ise iki değer alabilir, SHUTDOWN veya CONTINUE. Eğer kayıt dosyasında yer kalmadıysa veya diskinizde yer kalmadıysa yani özetle eğer denetim verileriniz kayıt deposuna kaydedilemiyorsa ve bu ayarın değeri de SHUTDOWN ise, o zaman SQL Server Instance' ınız böyle bir durumda kapanacaktır.
SQL Server Management Studio (SSMS) Kullanarak Audit Oluşturmak:
Denetimler, güvenlikle ilgili ve sunucu düzeyinde çalışan nesnelerdir. Bu nedenle yeni bir Audit oluşturmak istediğinizde, SSMS' teki Object Explorer penceresinden, Security->Audits bölümüne gidersiniz. (bkz Resim 1)
Resim - 1Resim-1 de de görüldüğü gibi, Audits düğümünün üzerinde fare ile sağ tuşa tıkladığınızda "New Audit..." öğesini göreceksiniz. Bu öğeye tıklayın, "Create Audit" penceresi açılacaktır.
Resim - 2Yine bu başlık altında, T-SQL kullanarak oluşturduğumuz Audit in aynısı, fakat bu sefer bu Audit' i SSMS kullanarak oluşturuyoruz. Resim - 2' de gördüğünüz tüm ayarları zaten yukarıda açıklamıştım, bu nedenle tekrar açıklamaya gerek yok. Biraz gözatarsanız zaten her şeyin aynı olduğunu göreceksiniz.
Daha önceden size yeni bir Audit nesnesi oluşturduğunuzda, bu nesnenin varsayılan olarak kullanılamaz şekilde oluşturulduğunu söylemiştim. Şimdi bunu tekrar belirtmemin nedeni ise, SSMS' te bu kullanılamazlığın görsel olarak da belirtilmesidir. Bunun için Resim -3' e bakın. Daha belirgin olması için kırmızı bir halka içine aldım.
Resim - 3Bu nesneyi kullanılabilir hale getirmek için, üzerinde farenin sağ tuşuna tıklamanız ve "Enable Audit" öğesini seçmeniz gerekiyor. Bu noktada şunu da belirtmek istiyorum ki, daha sonraki başlıklarda oluşturacağımız Server Audit Specification ve Database Audit Specification nesneleri de varsayılan olarak kullanılamaz şekilde oluşturulur ve bu nesneler kullanılamaz durumdayken bu durum, Object Explorer' da aynen Resim - 3' teki gibi aşağı kırmızı bir ok ile görsel olarak belirtilir ve bu nesneleri kullanılabilir duruma getirmek için yine aynı şekilde bu nesnelerin üzerinde fare ile sağ tıklayıp "Enable ..." öğesini seçmeniz gerekir.
Bu noktada, artık Audit oluşturma konusunda bir sıkıntı kalmadığını varsayıyorum. Hadi, şimdi de Server Audit Specification nasıl oluşturulur onu inceleyelim!
Server Audit Specification
Bir Server Audit Specification nesnesi oluşturmadan önce, bu nesneyi oluştururken kullanmak üzere bir Audit nesnesinin önceki başlıkta da anlatıldığı gibi oluşturulması gerekiyor.
Bir Server Audit Specification nesnesi oluşturulduğunda, varsayılan olarak kullanılamaz (disabled) şekilde oluşturulur.
T-SQL Yöntemiyle Server Audit Specification Nesnesi Oluşturma
Bu örneğimizdeki Server Audit Specification nesnesine , 4 tane Action Type ekleyeceğim.
CREATE SERVER AUDIT SPECIFICATION [sasTaseron]
FOR SERVER AUDIT [AuditTaseron]
ADD (LOGIN_CHANGE_PASSWORD_GROUP),
ADD (SERVER_ROLE_MEMBER_CHANGE_GROUP),
ADD (SERVER_PRINCIPAL_CHANGE_GROUP),
ADD (DATABASE_CHANGE_GROUP)
GO
Bir Server Audit Specification nesnesini oluşturmak için öncelikle bir Audit nesnesine ihtiyacımız olduğunu önceden de söylemiştim. İşte bu örneğimizde de önceki Audit altbaşlığında oluşturmuş olduğumuz "AuditTaseron" nesnesini kullanıyoruz. Daha sonra da, aşağıda listelediğim Action Type' ları ekliyoruz:
LOGIN_CHANGE_PASSWORD_GROUP: Bu olay, sp_password veya ALTER LOGIN komutlarıyla bir Login' in şifresi değiştirildiğinde tetiklenir.
SERVER_ROLE_MEMBER_CHANGE_GROUP: Bu olay, bir Login, bir Server Fixed Role' e eklenip veya çıkarıldığında tetiklenir.
SERVER_PRINCIPAL_CHANGE_GROUP: Bu olay, örneğin bir Login' in silinmesi veya yeni bir Login' in eklenmesi veya bir Login üzerinde bir takım değişiklikler (örneğin Login' in varsayılan dilini değiştirdiğinizde) yaptığınızda tetiklenir.
DATABASE_CHANGE_GROUP: Bu olay, bir veritabanı silindiğinde, yeni bir veritabanı oluşturulduğunda veya varolan bir veritabanında değişiklik yapıldığında tetiklenir.
Biz örneğimizde sadece 4 tane Action Type kullandık, fakat bu Action Type' lardan başka daha bir çok Action Type vardır. Diğer Action Type' lar hakkında daha fazla bilgi almak için Books Online' a bakabilirsiniz: http://msdn.microsoft.com/en-us/library/cc280663.aspx
SQL Server Management Studio (SSMS) Kullanarak Server Audit Specification Oluşturmak:
Server Audit Specification nesnesi de Audit nesnesi gibi güvenlikle alâkalı bir nesne olduğu için, SSMS' teki Object Explorer' ın, Security düğümünün altında bulunur. (bkz Resim - 4)
Resim - 4"New Server Audit Specification..." öğesine tıkladığınızda "Create Server Audit Specification" penceresi açılacaktır. (bkz Resim - 5)
Resim - 5Bu pencerede temel olarak yapacağınız işlem, bu Server Audit Specification nesnesine bir isim vermek, önceden oluşturduğunuz Audit nesnesini, Audit aşağı açılır kutusundan belirlemek ve Audit Action Type listesindeki aşağı açılır kutulardan, ihtiyacınıza göre Action Type' lar eklemektir.
Aynı örneği yukarıda T-SQL ile yaparken size bir çok Action Type olduğunu söylemiştim. Bu Action Type' ların listesini de bu şekilde görmüş oldunuz. Bunların açıklamaları için yine yukarıda verdiğim Books Online adresinden yararlanabilirsiniz. Books Online' nın maalesef bir Türkçe versiyonunun olmadığını da bilmeyenler ve merak edenler için belirteyim.
Audit ve Server Audit Specifications açıklamalı ve adım adım uygulamış olduğumuz örneklerden sonra sıra şimdi de Database Audit Specifications konusunda!
Database Audit Specifications
Yine belirtmem gerekiyor ki, bir Database Audit Specification nesnesi oluşturmadan önce, bu nesneyi oluştururken kullanmak üzere bir Audit nesnesinin Audit başlığında da anlatıldığı gibi oluşturulması gerekiyor.
Ve yine belirtmekte fayda var ki, bir Database Audit Specification nesnesi oluşturulduğunda, varsayılan olarak kullanılamaz (disabled) şekilde oluşturulur.
Bu örnekte, öncelikle hayali taşeron firma için bir Login, "Test" isimli veritabanımızda, oluşturacağımız "TestLogin" isimli Login için "TestUser" isimli bir de User oluşturacağız. Daha sonra, hayali "Alacaklar" isimli tablomuzda, bu "TestUser" kullanıcısı tarafından bir SELECT, UPDATE, INSERT veya DELETE komutunun çalıştırılmasığını kontrol etmek için bir Database Audit Specification nesnesi oluşturacağız. Diğer örneklerimizde olduğu gibi, bu örneği de hem T-SQL ile, hem de SSMS kullanarak yapacağız.
T-SQL Yöntemiyle Database Audit Specification Nesnesi Oluşturma
Aşağıdaki T-SQL kodlarını çalıştırmadan önce, önceden oluşturmuş olduğumuz "AuditTaseron" isimli Audit nesnesini ve "sasTaseron" isimli Server Audit Specification nesnesini kullanılır (Enable) duruma getirdiğinizden emin olun. Nedenini daha sonra söyleyeceğim.
-- "TestLogin" isimli Login' in oluşturulması
USE [master]
GO
CREATE LOGIN TestLogin WITH PASSWORD = 'Pa$$w0rd'
GO
-- Test için kullanılacak, "Test" isimli veritabanının oluşturulması
USE [master]
GO
CREATE DATABASE [Test]
GO
-- Test için kullanılacak "Alacaklar" isimli veritabanının oluşturulması
USE [Test]
GO
CREATE TABLE [Alacaklar]
(id int)
GO
/* "Test" isimli veritabanında işlem yapabilmesi için, taşeron firma çalışanı tarafından kullanılacak "TestUser isimli kullanıcının oluşturulması */
USE [Test]
GO
CREATE USER [TestUser] FOR LOGIN [TestLogin]
WITH DEFAULT_SCHEMA=[dbo]
GO
-- "TestUser" isimli kullanıcının "db_owner" veritabanı rolüne eklenmesi
USE [test]
GO
EXEC sp_addrolemember N'db_owner', N'TestUser'
GO
/* "TestUser" isimli taşeron firma çalışanının "Alacaklar" tabloasuna karşı yapacağı erişimleri takip etmek için kullanılacak "dasAuditTaseron" isimli Database Audit Specification nesnesinin oluşturulması */
USE [Test]
GO
CREATE DATABASE AUDIT SPECIFICATION [dasAuditTaseron]
FOR SERVER AUDIT [AuditTaseron]
ADD (SELECT ON OBJECT::[dbo].[Alacaklar] BY [TestUser]),
ADD (DELETE ON OBJECT::[dbo].[Alacaklar] BY [TestUser]),
ADD (INSERT ON OBJECT::[dbo].[Alacaklar] BY [TestUser]),
ADD (UPDATE ON OBJECT::[dbo].[Alacaklar] BY [TestUser])
GO
Hemen bir önceki paragrafta örneğimizi anlattığım gibi, yukarıdaki T-SQL diliyle de bu örneği SQL Server' a anlatmış oldum.
Server Audit Specification' da olduğu gibi, Database Audit Specification' da da, bir çok Action Type bulunmaktadır. Bu Action Type' ların listesini bir sonraki SSMS örneğimizdeki "Create Database Audit Specification" isimli penceredeki Action Type aşağı açılır kutularında zaten göreceksiniz. Bu Action Type' ların açıklamaları için yine Books Online' dan yararlanabilirsiniz: http://msdn.microsoft.com/en-us/library/cc280663.aspx
SQL Server Management Studio (SSMS) Kullanarak Database Audit Specification Oluşturmak:
Evet! Tahmin edeceğiniz üzere yine aynı şeyi söyleyeceğim! Database Audit Specification nesnesi de elbette güvenlikle alâka bir nesne. Bu nedenle bu nesneler, SSMS' teki Object Explorer' ın Databases isimli düğümünün altındaki veritabanınızın içinde bulunan Security düğümündeki Database Audit Specifications içinde depolanıyor.
Kabul ediyorum, bu terimlere aşina olmayanlara biraz arapsaçı gibi görünmüş olabilir. Ama beni önceden takip edenler bilir, hem de buraya kadar sabredip okumuşsanız siz de görebilirsiniz ki, hiç üşenmeden resimlerle de örnek vermeyi çok severim ben. Hemen aşağıdaki resimde (Resim - 6) Database Audit Specification düğümünü görebilirsiniz.
Resim - 6"New Database Audit Specification..." öğesine tıkladığınızda "Create Database Audit Specification" penceresi açılacaktır. (bkz Resim - 7)
Resim - 7Eğer dikkatli bakarsanız, bu arayüzün de, "Create Server Audit Specification" penceresinin arayüzüyle aynı olduğunu görürsünüz ve eğer o penceredeki Object Class, Object, Object Name, Principal alanlarındaki kutucukları kurcaladıysanız, herhangi bir değişiklik yapamadığınızı görmüşsünüzdür. Tek arayüzde iki iş yaptırmaya çalışınca, böyle sonuçlar çıkabiliyor elbette. Neyse ki, bu alanları "Create Database Audit Specification" penceresinde kullanabiliyoruz.
Bildiğiniz üzere Audit Action Type alanında, ihtiyacınıza uygun Action Type' ı seçiyorsunuz. Object Class alanında, seçebileceğiniz üç tane seçenek var. Bunlar: Database, Object ve Schema. (Bu kavramların anlamları ise başka bir konu olduğu ve konumuzun kapsamında olmadığı için bunlara değinmiyorum.) Üzerinde denetim yapmak istediğiniz nesneye göre, Object Class' ını seçersiniz. Meselâ biz örneğimizde "Alacaklar" isimli tabloyu denetlemek istediğimiz için, Object Class olarak "Object" i seçtik. Eğer "Test" isimli veritabanımızdaki tüm tabloları denetlemek isteseydik, o zaman Object Class' ı "Database" olarak seçerdik, Object Name olarak da "Test" i seçerdik. Eğer belli bir kullanıcı veya rolü değil de, tüm kullanıcı ve rolleri denetlemek isteseydik, o zaman Principal alanında bir şey seçmezdik.
Audit, Server Audit Specification ve Database Audit Specification nesneleri için geçerli olan şu kuralı da unutmamalısınız, bu nesnelerden birinde bir değişiklik yapmadan önce, o nesneyi kullanılamaz (disable) duruma getirmeniz gerekir. Aksi takdirde şu hata ile karşılaşırsınız: "Changes to an audit specification must be done while the audit specification is disabled. (Microsoft SQL Server, Error: 33229)".
Log Viewer - Audit
Önceki konu başlıklarında bir Audit' in nasıl oluşturulacağını, bu Audit' in oluşturulmasının sebebi olan bir Server Audit Specification veya Database Audit Specification nesnesinin nasıl ve ne gibi amaçlar için oluşturulabileceğini anlattım. Şimdi sıra, yaptığımız bu otomatik denetim mekanizmasının ürettiği raporların nasıl okunabileceğine geldi.
Bir Audit dosyasının ürettiği kayıt dosyasını okuyabilmek için kullanabileceğiniz en pratik ve kısa yol, SSMS' teki Log Viewer' ı kullanmaktır. Bunun için, SSMS' i açtıktan sonra Resim - 1' de gösterilen Audits düğümü altında oluşturduğunuz Audit nesnesinin üzerinde farenin sağ tuşuna tıklayıp "View Audit Logs" öğesine tıklayın. Bu sayede, Log Viewer açılır ve ilgili Audit nesnenizin ürettiği kayıtları görebilirsiniz. Yukarıda yaptığımız örneklerde hatırlarsanız "TestLogin" adında bir Login oluşturmadan önce size "AuditTaseron" isimli Audit nesnesini ve "sasTaseron" isimli Server Audit Specification nesnesini kullanılabilir duruma getirin demiştim, bunun nedenini de daha sonra söyleyeceğim demiştim. İşte şimdi söylüyorum; bunun nedeni, CREATE LOGIN komutuyla birlikte sunucu düzeyinde bir işlem yapmamızdı. "Eee?" mi diyorsunuz? O zaman şunu da hatırlatayım, "sasTaseron" ismiyle oluşturduğumuz Server Audit Specification nesnesinin içine bir de SERVER_PRINCIPAL_CHANGE_GROUP Action Type' ı eklemiştik. Bu Action Type' ın takip ettiği olaylardan biri de neydi? Login oluşturulması! Yani eğer CREATE LOGIN komutuyla "TestLogin" Login' ini oluşturmadan önce "AuditTaseron" ve "sasTaseron" isimli nesneleri kullanılabilir duruma getirdiyseniz, "TestLogin" ismindeki Login' i oluşturduğunuz denetim kayıtlarına geçmiş demektir. Sizi bilmiyorum, ama ben nizami şekilde kendi dediklerimi uyguladım ve sonucunu görmek için Resim - 8' e bakabilirsiniz.
Resim - 8Aslında kaydırma çubuğundan da anlaşılabileceği üzere, oldukça çok alan var ve bu kadar alanı bu kadar küçük bir resme sığdırmak imkânsız. Sığdırsam bile herhalde mikroskopla incelemeniz gerekirdi. Ama yine de bu resimde, elimden geldiğince çok veriyi size göstermeye çalıştım. Alanlardan anlatmaya başlarsak, örneğin, bu komutun çalıştırıldığı tarih ve saati görebilirsiniz. Hangi SQL Server Instance' ında gerçekleştiği (EKREM-PC), hangi komutun çalıştırıldığı (CREATE) ve bu komut ile hangi sınıf işlem yapıldığı (SQL LOGIN) ve daha bir çok bilgiyi görebilirsiniz. Aşağıdaki ayrıntılı bilgi alanına bakarsak, ilk göze çarpacak bilgilerden birisi, "CREATE LOGIN TestLogin WITH PASSWORD '*****'" tür sanırım. Hangi nesnenin hangi komutla oluşturulduğu bilgisi oldukça değerli olabilir. Ayrıca bu nesneyi hangi Login' in oluşturduğunu da görebilirsiniz (EKREM-PC\ekrem).
Bununla birlikte, yine Resim - 8' deki "File Name" bilgisi dikkatinizi çekti mi? Hatırlarsanız, "AuditTaseron" isimli Audit nesnesini oluştururken dosya adı değil, sadece dosya yolu belirtilir demiştim. Dosya adını ise, SQL Server, Audit nesnesinin adı olarak belirlediğiniz bir ad ile birlikte bir GUID (Globally Unique Identifier)' i birleştirerek ve uzantısını da ".sqlaudit" yaparak verir. Bu resimde, bir çok bilgiyle birlikte bu dosya adını da görebiliyorsunuz.
Ayrıca, test etmek için şimdi gidip, "dasTaseron" ismiyle oluşturduğumuz Database Audit Specification nesnesini de kullanılılabilir duruma getirebilirsiniz. Bu nesneye ait kayıtlara da, "sasTaseron" isimli Server Audit Specification nesnesinde olduğu gibi, o nesnenin bağlı olduğu Audit nesnesinin üzerinde farenin sağ tuşuna tıklayarak ve "View Audit Logs" öğesini seçerek ulaşabilirsiniz. "TestUser" isimli kullanıcının "Alacaklar" isimli tabloya yapacağı SELECT, UPDATE, DELETE ve INSERT (DML - Data Manipulation Language) işlemleri yine bu kayıt dosyasında, aynen CREATE LOGIN işlemindeki gibi kaydedilecektir. Fakat "dasTaseron" nesnesini test etmek için sunucuya "TestLogin" ile giriş yapmalı ve bu Login' in "Test" isimli tablodaki bağlı olduğu kullanıcı olan "TestUser" kullanıcısıyla "Alacaklar" tablosuna karşı bir DML işlemi yapmanız gerekiyor. Çünkü hatırlarsanız, Database Audit Specification nesnemizi bu kriterlere göre oluşturmuştuk. Eğer dediğim gibi "TestLogin" kullanıcısıyla bağlanıp "Alacaklar" tablosuna bir sorgu çekerseniz, göreceksiniz ki "AuditTaseron" isimli Audit kayıt dosyasınaki CREATE LOGIN komutunun üzerine bu yaptığınız işlemle ilgili başka bir kayıt daha eklenecektir.
Özet
Çok beklenen ve SQL Server 2008 ile birlikte gelen bir çok özellikten biri olan Auditing konusunu size anlatmaya çalıştım. Bu makaleye başlarken de dediğim gibi, bu gereksinim gerek bazı üçüncü parti yazılımlarla, gerekse SQL Trace ile giderilmeye çalışılıyordu. Fakat artık SQL Server 2008 ile birlikte, arayüz desteğiyle de (SQL Trace özelliği için arayüz desteği yoktu) bu iş oldukça kolaylaştırıldı.
Biz veritabanı yöneticilerinin ana sorumluluklarının başında güvenlik geliyor. "Kim, hangi bilgiye ne zaman erişmiş?" veya "Bu tablodaki değişikliği kim yapmış?" gibi sorulara her an yanıt verebilmeliyiz. Bu yeni Auditing özelliği sayesinde, bu konudaki işimiz daha kolaylaşacak. Umarım bir gün sizin de işinize yarar.
Ekrem Önsoy
3 Ekim 2008 Cuma
SQL Server 2008: Sparse Columns
Merhaba,
Kısaca, eğer bir alan içerisindeki (sütun) verilerin çoğunluğunu NULL değeri oluşturuyorsa, o zaman bu alanda veri tasarrufu sağlamak için bu alanın "Sparse" özelliğini etkinleştirirsiniz. "Sparse" özelliği, bu alanda saklanacak olan NULL değerleri için diskte daha az yer harcanmasını sağlayacaktır.
Tabi bunun da bir bedeli vardır, NULL olmayan alanlardaki veriler için harcanacak yer fazlalaşacaktır. Bu yüzden "Sparse" ı kullanmak için aklınızda bulundurmanız gereken altın kural, bu özelliği kullanacağınız alandaki değerlerin büyük çoğunluğunun NULL olması gerektiğidir. Bu değerler hakkında fikir sahibi olmak için aşağıdaki örnekleri inceleyebilirsiniz.
Her alan ve veritipinin de "Sparse" özelliği kullanılamaz, buna aşağıdaki örnekten sonra değineceğim.
Nasıl Kullanılır?
Bir alanı "Sparse" olarak belirlemek için ise CREATE TABLE veya ALTER TABLE komutlarını kullanmalısınız. Bu komutların SQL Server 2008 versiyonları hakkında daha fazla bilgi için buraya tıklayın.
Misal olarak aşağıdaki örneği uygulayın:
CREATE TABLE SparseOlmayanTablo(a int, b int, c int, d int)
GO
CREATE TABLE SparseOlanTablo(a int, b int SPARSE, c int SPARSE, d int SPARSE)
GO
DECLARE @i int=0
WHILE @i < 100000
BEGIN
INSERT INTO SparseOlanTablo VALUES (@i,null,null,null)
INSERT INTO SparseOlmayanTablo VALUES (@i,null,null,null)
SET @i+=1
END
Yukarıdaki işlem tamamlandıktan sonra da, hangi tabloda ne kadar alan kullanıldığını belirlemek için aşağıdaki satırları çalıştırın:
exec sp_spaceused SparseOlmayanTablo
exec sp_spaceused SparseOlanTablo
Bu iki komutu da çalıştırdıktan sonra, aşağıdaki gibi bir sonuç görmeniz gerekiyor:
Resim 1
Gördüğünüz gibi, iki tablo aynı alanları içerse de, "Sparse" özelliğini kullandığımız tablo diğer tabloya nazaran diskte %50 daha az yer kaplıyor.
"Sparse" özelliğinin veri depolanmasını nasıl etkileyebileceğini daha ayrıntılı bir şekilde anlatabilmek için bir de şu örneğe bakın
Örnek: 2
Tablo isimlerinin sonunda "N" olan tablolara NULL değerler koyacağız, diğerlerine ise sırayla bir sayı kaydedilecek.
DROP TABLE SparseOlanTablo
GO
DROP TABLE SparseOlmayanTablo
GO
CREATE TABLE SparseOlanTablo(a int SPARSE)
GO
CREATE TABLE SparseOlanTabloN(a int SPARSE)
GO
CREATE TABLE SparseOlmayanTablo(a int)
GO
CREATE TABLE SparseOlmayanTabloN(a int)
GO
Yine bir önceki örnekteki WHILE döngüsünü 3 kere kullanın. Birinci seferde 1.000 kayıt girin. İkinci seferde 10.000 ve üçüncü seferde de 100.000 kayıt girin. (Not: Kendi yaptığım örnekte, her yeni bir döngüye başlamadan önce tabloların içini boşalttım.)
DECLARE @i int=0
WHILE @i < 1000
BEGIN
INSERT INTO SparseOlanTablo VALUES (@i)
INSERT INTO SparseOlanTabloN VALUES (null)
INSERT INTO SparseOlmayanTablo VALUES (@i)
INSERT INTO SparseOlmayanTabloN VALUES (null)
SET @i+=1
END
Bunların sonucu ise aldığım "data" alanının (yani verilerin diskte ne kadar yer kapladıkları) değerleri şöyle:
Satır Sayısı SparseOlanTablo SparseOlanTabloN SparseOlmayanTablo SparseOlmayanTabloN
1.000 24KB 16KB 16KB 16KB
10.000 232KB 120KB 136KB 136KB
100.000 2288KB 1144KB 1352KB 1352KB
Gördüğünüz gibi, "Sparse" özelliğini kullandığımızda eğer tabloda hiç NULL değer yoksa, o zaman bu bize kârdan çok zarar verecektir. 100.000 kayıt girildiğinde "Sparse" özelliğini kullandığımız SparseOlanTablo isimli tablonun diskte kapladığı alan 2.288KB, fakat "Sparse" özelliği kapalı olan tablo olan SparseOlmayanTablo isimli tablonun diskte kapladığı alan ise 1.352KB. İkisinde de aynı veriler var.
Şimdi başka bir örnek daha yapacağız. Bu örnekte ise, SparseOlanTablo' daki verilerin %90' ı NULL olacak, %10' u ise sayılardan ibaret olacak.
Örnek: 3
DROP TABLE SparseOlanTablo
GO
DROP TABLE SparseOlmayanTablo
GO
CREATE TABLE SparseOlanTablo(a int SPARSE)
GO
CREATE TABLE SparseOlmayanTablo(a int)
GO
DECLARE @i int=0
WHILE @i < 10000
BEGIN
INSERT INTO SparseOlanTablo VALUES (@i)
INSERT INTO SparseOlmayanTablo VALUES (@i)
SET @i+=1
END
Yukarıdaki döngüyle birlikte, tablolarımıza on bin kayıtlık sayı girmiş olduk. Şimdi de doksan bin kayıtlık NULL veri gireceğiz.
DECLARE @i int=0
WHILE @i < 90000
BEGIN
INSERT INTO SparseOlanTablo VALUES (null)
INSERT INTO SparseOlmayanTablo VALUES (null)
SET @i+=1
END
Satır Sayısı SparseOlanTablo SparseOlmayanTablo
10.000 (Sayı) 264KB 136KB
90.000 (NULL) + 10.000 (Sayı) 1264KB 1352KB
900.000 (NULL) + 100.000 (Sayı) 12576KB 13520KB
Bu örneklerde hep "int" veritipini kullandık. Unutmayın ki, "Sparse" özelliğinin kullanımı değişik veritiplerinin kullanımında değişik sonuçlar verecektir.
"Sparse" Özelliğine SQL Server Management Studio ile Ulaşmak
Bu özelliğe, SQL Server Instance' larının yönetilmesi amacıyla kullanılan SQL Server Management Studio (SSMS)' dan ulaşmak için aşağıdaki adımları izleyin:
- SSMS' i başlatın,
- Çalışma yapacağınız SQL Server Instance' ına bağlanın,
- Object Explorer' dan ilgili veritabanınızdaki tablonuzu bulun ve üzerinde farenin sağ tuşua tıklayarak "Design" seçeneğini seçin,
- "Sparse" özelliğini (bkz Resim 2) açılan penceredeki Column Properties' de bulacaksınız.
Resim 2
"Sparse" Kullanımının Tespiti
Bir tablodaki bir alanın "Sparse" özelliğinin kullanılıp kullanılmadığını anlamak için ise aşağıdaki komutu kullanabilirsiniz:
SELECT COLUMNPROPERTY(object_id('dbo.SparseOlanTablo'),'b','IsSparse')
Eğer sonuç olarak "1" dönüyorsa, o zaman sorguladığınız alanın "Sparse" özelliği kullanılıyordur.
"Sparse" Özelliğinin Kullanım Kısıtlamaları
Yukarıda değineceğimi söylediğim gibi, "Sparse" özelliği her zaman ve her veritipi için kullanılamaz. Meselâ şu veritipleri kullanılan alanlarda "Sparse" özelliği kullnılamaz: geography, geometry, image, ntext, text, timestamp, user-defined data type.
Bunlardan başka, "Sparse" özelliği açık olduğunda, bu alan için bir "Default" değer tanımlanamaz. Bu alan bir "Rule" e bağlanılamaz. Bir "Computed Column" un, "Sparse" özelliği etkinleştirilemez. "Sparse" özelliği açık olan bir alan, bir "Clustered Index" veya bir "Unique Primary Key Index" in parçası olamaz.
Bunlar gibi kısıtlamalar ve "Sparse" ın hangi SQL Server teknolojileri ile kullanılabileceği hakkında daha fazla bilgi için buraya yıklayın.
Ekrem Önsoy
Kısaca, eğer bir alan içerisindeki (sütun) verilerin çoğunluğunu NULL değeri oluşturuyorsa, o zaman bu alanda veri tasarrufu sağlamak için bu alanın "Sparse" özelliğini etkinleştirirsiniz. "Sparse" özelliği, bu alanda saklanacak olan NULL değerleri için diskte daha az yer harcanmasını sağlayacaktır.
Tabi bunun da bir bedeli vardır, NULL olmayan alanlardaki veriler için harcanacak yer fazlalaşacaktır. Bu yüzden "Sparse" ı kullanmak için aklınızda bulundurmanız gereken altın kural, bu özelliği kullanacağınız alandaki değerlerin büyük çoğunluğunun NULL olması gerektiğidir. Bu değerler hakkında fikir sahibi olmak için aşağıdaki örnekleri inceleyebilirsiniz.
Her alan ve veritipinin de "Sparse" özelliği kullanılamaz, buna aşağıdaki örnekten sonra değineceğim.
Nasıl Kullanılır?
Bir alanı "Sparse" olarak belirlemek için ise CREATE TABLE veya ALTER TABLE komutlarını kullanmalısınız. Bu komutların SQL Server 2008 versiyonları hakkında daha fazla bilgi için buraya tıklayın.
Misal olarak aşağıdaki örneği uygulayın:
CREATE TABLE SparseOlmayanTablo(a int, b int, c int, d int)
GO
CREATE TABLE SparseOlanTablo(a int, b int SPARSE, c int SPARSE, d int SPARSE)
GO
DECLARE @i int=0
WHILE @i < 100000
BEGIN
INSERT INTO SparseOlanTablo VALUES (@i,null,null,null)
INSERT INTO SparseOlmayanTablo VALUES (@i,null,null,null)
SET @i+=1
END
Yukarıdaki işlem tamamlandıktan sonra da, hangi tabloda ne kadar alan kullanıldığını belirlemek için aşağıdaki satırları çalıştırın:
exec sp_spaceused SparseOlmayanTablo
exec sp_spaceused SparseOlanTablo
Bu iki komutu da çalıştırdıktan sonra, aşağıdaki gibi bir sonuç görmeniz gerekiyor:
Resim 1
Gördüğünüz gibi, iki tablo aynı alanları içerse de, "Sparse" özelliğini kullandığımız tablo diğer tabloya nazaran diskte %50 daha az yer kaplıyor.
"Sparse" özelliğinin veri depolanmasını nasıl etkileyebileceğini daha ayrıntılı bir şekilde anlatabilmek için bir de şu örneğe bakın
Örnek: 2
Tablo isimlerinin sonunda "N" olan tablolara NULL değerler koyacağız, diğerlerine ise sırayla bir sayı kaydedilecek.
DROP TABLE SparseOlanTablo
GO
DROP TABLE SparseOlmayanTablo
GO
CREATE TABLE SparseOlanTablo(a int SPARSE)
GO
CREATE TABLE SparseOlanTabloN(a int SPARSE)
GO
CREATE TABLE SparseOlmayanTablo(a int)
GO
CREATE TABLE SparseOlmayanTabloN(a int)
GO
Yine bir önceki örnekteki WHILE döngüsünü 3 kere kullanın. Birinci seferde 1.000 kayıt girin. İkinci seferde 10.000 ve üçüncü seferde de 100.000 kayıt girin. (Not: Kendi yaptığım örnekte, her yeni bir döngüye başlamadan önce tabloların içini boşalttım.)
DECLARE @i int=0
WHILE @i < 1000
BEGIN
INSERT INTO SparseOlanTablo VALUES (@i)
INSERT INTO SparseOlanTabloN VALUES (null)
INSERT INTO SparseOlmayanTablo VALUES (@i)
INSERT INTO SparseOlmayanTabloN VALUES (null)
SET @i+=1
END
Bunların sonucu ise aldığım "data" alanının (yani verilerin diskte ne kadar yer kapladıkları) değerleri şöyle:
Satır Sayısı SparseOlanTablo SparseOlanTabloN SparseOlmayanTablo SparseOlmayanTabloN
1.000 24KB 16KB 16KB 16KB
10.000 232KB 120KB 136KB 136KB
100.000 2288KB 1144KB 1352KB 1352KB
Gördüğünüz gibi, "Sparse" özelliğini kullandığımızda eğer tabloda hiç NULL değer yoksa, o zaman bu bize kârdan çok zarar verecektir. 100.000 kayıt girildiğinde "Sparse" özelliğini kullandığımız SparseOlanTablo isimli tablonun diskte kapladığı alan 2.288KB, fakat "Sparse" özelliği kapalı olan tablo olan SparseOlmayanTablo isimli tablonun diskte kapladığı alan ise 1.352KB. İkisinde de aynı veriler var.
Şimdi başka bir örnek daha yapacağız. Bu örnekte ise, SparseOlanTablo' daki verilerin %90' ı NULL olacak, %10' u ise sayılardan ibaret olacak.
Örnek: 3
DROP TABLE SparseOlanTablo
GO
DROP TABLE SparseOlmayanTablo
GO
CREATE TABLE SparseOlanTablo(a int SPARSE)
GO
CREATE TABLE SparseOlmayanTablo(a int)
GO
DECLARE @i int=0
WHILE @i < 10000
BEGIN
INSERT INTO SparseOlanTablo VALUES (@i)
INSERT INTO SparseOlmayanTablo VALUES (@i)
SET @i+=1
END
Yukarıdaki döngüyle birlikte, tablolarımıza on bin kayıtlık sayı girmiş olduk. Şimdi de doksan bin kayıtlık NULL veri gireceğiz.
DECLARE @i int=0
WHILE @i < 90000
BEGIN
INSERT INTO SparseOlanTablo VALUES (null)
INSERT INTO SparseOlmayanTablo VALUES (null)
SET @i+=1
END
Satır Sayısı SparseOlanTablo SparseOlmayanTablo
10.000 (Sayı) 264KB 136KB
90.000 (NULL) + 10.000 (Sayı) 1264KB 1352KB
900.000 (NULL) + 100.000 (Sayı) 12576KB 13520KB
Bu örneklerde hep "int" veritipini kullandık. Unutmayın ki, "Sparse" özelliğinin kullanımı değişik veritiplerinin kullanımında değişik sonuçlar verecektir.
"Sparse" Özelliğine SQL Server Management Studio ile Ulaşmak
Bu özelliğe, SQL Server Instance' larının yönetilmesi amacıyla kullanılan SQL Server Management Studio (SSMS)' dan ulaşmak için aşağıdaki adımları izleyin:
- SSMS' i başlatın,
- Çalışma yapacağınız SQL Server Instance' ına bağlanın,
- Object Explorer' dan ilgili veritabanınızdaki tablonuzu bulun ve üzerinde farenin sağ tuşua tıklayarak "Design" seçeneğini seçin,
- "Sparse" özelliğini (bkz Resim 2) açılan penceredeki Column Properties' de bulacaksınız.
Resim 2
"Sparse" Kullanımının Tespiti
Bir tablodaki bir alanın "Sparse" özelliğinin kullanılıp kullanılmadığını anlamak için ise aşağıdaki komutu kullanabilirsiniz:
SELECT COLUMNPROPERTY(object_id('dbo.SparseOlanTablo'),'b','IsSparse')
Eğer sonuç olarak "1" dönüyorsa, o zaman sorguladığınız alanın "Sparse" özelliği kullanılıyordur.
"Sparse" Özelliğinin Kullanım Kısıtlamaları
Yukarıda değineceğimi söylediğim gibi, "Sparse" özelliği her zaman ve her veritipi için kullanılamaz. Meselâ şu veritipleri kullanılan alanlarda "Sparse" özelliği kullnılamaz: geography, geometry, image, ntext, text, timestamp, user-defined data type.
Bunlardan başka, "Sparse" özelliği açık olduğunda, bu alan için bir "Default" değer tanımlanamaz. Bu alan bir "Rule" e bağlanılamaz. Bir "Computed Column" un, "Sparse" özelliği etkinleştirilemez. "Sparse" özelliği açık olan bir alan, bir "Clustered Index" veya bir "Unique Primary Key Index" in parçası olamaz.
Bunlar gibi kısıtlamalar ve "Sparse" ın hangi SQL Server teknolojileri ile kullanılabileceği hakkında daha fazla bilgi için buraya yıklayın.
Ekrem Önsoy
3 Temmuz 2008 Perşembe
SQL Server 2008: Güvenlik ile ilgili değişiklikler
Son güncelleme tarihi: 02 Temmuz 2008
Merhaba arkadaşlar,
SQL Server 2008' in güvenlik ile ilgili politikalarının bazılarında, SQL Server' ın önceki versiyonlarına göre bazı değişiklikler oldu. Bu yazımda sizlere bu değişikliklerden bahsedeceğim.
Bildiğiniz gibi SQL Server 2005, önceki versiyonlarına göre çok daha güvenliydi. Gerek tasarım olarak, gerek kurulumda gerekse varsayılan ayarlarıyla. SQL Server 2008' de bu güvenlik tedbirleri daha da sıkılaştırılarak bir adım öteye gidilmiş. Çok ahım şahım değişiklikler değil bunlar, fakat bilmenizde ve yeri ve zamanı geldiğinde hesaba katmanızda yarar var. Bu arada, burada bahsedeceğim güvenlik ile ilgili olan değişiklikler, SQL Server' ın eski versiyonlarındaki özelliklere göre yapılan değişikliklerdir. SQL Server 2008' deki güvenlik ile ilgili yeni özelliklere, farklı makalelerde değineceğim.
Peki nedir bu değişiklikler?
- SQL Server 2008 Setup' ta yükleme veya sürüm yükseltme esnasında "sa" hesabının adını değiştirebilme.
- SQL Server' ın eski versiyonlarında BUILTIN\Administrators Windows Grubu, SQL Server System Administrators "sysadmin" sunucu sabit rolüne eklenirdi. SQL Server 2008' de böyle olmayacak, yani Windows Yöneticileri doğrudan SQL Server Sistem Yöneticileri olmayacak artık.
- SQL Server tarafından oluşturulan "SQLServer2005MSSQLUser$-BİLGİSAYARADI-$INSTANCEADI" gibi Windows Gruplarına artık doğrudan SQL Server' a erişim izinleri verilmeyecek. Bunun yerine bu haklar, SQL Server servislerini başlatmak için kullanılan Windows hesabına verilecek.
- Surface Area Configuration aracı SQL Server 2008' de yok, yani kaldırıldı. Bunun yerine İlke Temelli Yönetim (Policy-Based Management) özelliği ve Configuration Manager' daki değişiklikler kullanılabilecek.
- Kerberos desteği genişletildi. TCP\IP' nin yanında, artık Named Pipes ve Shared Memory' yi de kapsıyor.
SQL Server "sa" hesabının adının değiştirilmesi:
"sa" hesabı varsayılan SQL Login' idir. "sysadmin" üyesidir ve bu değiştirilemez. Bu role üye olan bir Login, içinde bulunduğu SQL Server Instance' ında tüm yetkilere sahiptir. Bunu bilen korsanlar, sisteminize girmeye çalışacağı zaman ilk önce "sa" hesabına saldırırlar. Bir çok saldırı durumunda daha sonra "admin" isimli bir hesap denediklerini gördüm. Aslında SQL Server' da varsayılan olarak "admin" isminde bir hesap yoktur. Ama bildiğiniz gibi alışkanlıklarımız, güvenlik konusuna gelince en kırılgan noktamızdır. İnsanlar alışkanlıktan dolayı genelde "admin" isminde bir Login oluştururlar ve bunu da "sysadmin" rolünün bir üyesi yaparlar. Bu nedenle de korsanlar, SQL Server Instance' ınıza saldırdıklarında ilk önce olduğunu varsaydıkları bu Login' leri kırmaya çalışırlar.
"sa" hesabının adını değiştirmeniz ve bu hesaba güçlü bir şifre vermeniz (ki güçlü şifre denirken kastedilen, şifrenin içinde büyük-küçük harflerin, rakamların ve işaretlerin kullanılmasıdır) korsanların sisteminize en güçlü Login' lerle girmelerini engelleyici tedbirlerden olacaktır.
Tabi ki bu değişiklikleri yapmadan önce sisteminizi, uygulamalarınızı, Function' ları, Script' leri, CLR Assembly' leri gibi şeyleri de tekrar gözden geçirmeniz gerekebilir. "sa" hesabına bağlı uygulamalarınız, bu hesap ismini değiştirdiğiniz için artık çalışmayabilirler. Bu nedenle gerekli değişiklikleri uygulamalarınızda da yapmanız gerekebilir.
Mümkün olan her zaman Windows Authentication kullanmanız önerilir, ama öyle durumlar olur ki SQL Authentication kullanmanız gerekebilir. İşte böyle durumlarda yukarıdaki paragraflarda değindiğim tedbirleri almanızda büyük yarar vardır.
"sa" hesabı hakkında daha fazla bilgi için buraya tıklayın.
Windows Yerel Gruplarındaki değişiklik:
SQL Server' ın kurulması esnasında bazı Windows yerel grupları oluşturulur. SQL Server' ın, SQL Server 2008' den önceki versiyonlarında SQL Server servislerinin başlatılması için kullanılan servis hesapları bu yerel gruplara ekleniyorlardı. Servis hesabı ve Windows yerel gruplarına, işletim sistemi dosyaları ve Windows sistemi üzerinde haklar veriliyordu. Bu hesap ve gruplara SQL Server' da da bazı haklar veriliyordu.
SQL Server' ın yüklenmesi veya sürüm yükseltmesi esnasında seçtiğiniz özelliklere göre oluşturulan Windows yerel grupları aşağıdakilerden oluşur:
- SQL Server 2000
- OLAP Administrators
- SQL Server 2005
- SQLServer2005DTSUser$BİLGİSAYARADI
- SQLServer2005MSFTEUser$BİLGİSAYARADI$INSTANCEADI
- SQLServer2005MSOLAPUser$BİLGİSAYARADI$INSTANCEADI
- SQLServer2005MSSQLServerADHelperUser$ BİLGİSAYARADI
- SQLServer2005MSSQLUser$ BİLGİSAYARADI$INSTANCEADI
- SQLServer2005NotificationServicesUser$BİLGİSAYARADI
- SQLServer2005ReportingServicesWebServiceUser$BİLGİSAYARADI$INSTANCEADI
- SQLServer2005ReportServerUser$ BİLGİSAYARADI$INSTANCEADI
- SQLServer2005SQLAgentUser$ BİLGİSAYARADI$INSTANCEADI
- SQLServer2005SQLBrowserUser$ BİLGİSAYARADI
SQL Server 2008' de de bu Windows yerel grupları oluşturulacak, ama artık bu gruplara SQL Server içinde haklar verilmeyecek. Sadece, doğru Erişim Kontrol Listesi (Access Control List), SQL Server Motoru ve diğer özellikler için işletim sistemi hakları etkinleştirmesi amacıyla kullanılacaklar. Ancak SQL Server Setup boyunca servis hesapları olarak seçilen hesaplara SQL Server' da haklar atanacak.
Bir başka deyişle, Windows yerel grupları artık sadece işletim sistemi görevleri için kullanılacaklar. SQL Server servisleri için seçilen hesaplar da SQL Server ve veritabanı işlemleri için kullanılacaklar. Bu konuda daha fazla bilgi için buraya tıklayın.
Surface Area Configuration aracı:
Bu araç SQL Server 2005 ile birlikte geldi ve bu aracı, SQL Server' ın bazı özelliklerini açmak ve kapatmak için kullanıyoruz.
SQL Server 2008' de ise Surface Area Configuration aracı kaldırıldı. Bunun yerine çok daha gelişmiş bir özellik olan Policy-Based Management özelliğini kullanacağız. Bu konuda SQL Server' ın sanırım Kasım CTP' sinde bir örnek yaparak bunu yayınlamıştım. Bu makalemi okumak için buraya tıklayın. Bu özellik kısaca size SQL Server bileşenleri için ilkeler tanımlamanızı ve ayrıntılı bir şekilde bu ilkeleri SQL Server içindeki Principal ve Rollere uygulamanızı sağlıyor. Bu konuda daha fazla bilgi için buraya tıklayın.
Surface Area Configuration aracındaki bağlantılarla ilgili ayarları da -SQL Server 2005' te de yapabildiğimiz gibi- SQL Server Configuration Manager' da yapabilirsiniz. Örnek vermek gerekirse, TCP\IP, Named Pipes vb. protokollerin etkinleştirilip kapatılması gibi...
Kerberos Authentication:
SQL Server 2008' den itibaren, Kerberos Authentication desteği Named Pipes ve Shared Memory protokollerini de kapsayacak şekilde genişletildi. Buna ek olarak Kerberos, Windows Active Directory olmadan da kullanılabilecek. Bu konuda daha fazla bilgi için buraya tıklayın.
Ekrem Önsoy
Kaynak: Bu yazıyı yayınlarken Books Online' dan yararlandım.
Son güncelleme tarihi: 02 Temmuz 2008
Merhaba arkadaşlar,
SQL Server 2008' in güvenlik ile ilgili politikalarının bazılarında, SQL Server' ın önceki versiyonlarına göre bazı değişiklikler oldu. Bu yazımda sizlere bu değişikliklerden bahsedeceğim.
Bildiğiniz gibi SQL Server 2005, önceki versiyonlarına göre çok daha güvenliydi. Gerek tasarım olarak, gerek kurulumda gerekse varsayılan ayarlarıyla. SQL Server 2008' de bu güvenlik tedbirleri daha da sıkılaştırılarak bir adım öteye gidilmiş. Çok ahım şahım değişiklikler değil bunlar, fakat bilmenizde ve yeri ve zamanı geldiğinde hesaba katmanızda yarar var. Bu arada, burada bahsedeceğim güvenlik ile ilgili olan değişiklikler, SQL Server' ın eski versiyonlarındaki özelliklere göre yapılan değişikliklerdir. SQL Server 2008' deki güvenlik ile ilgili yeni özelliklere, farklı makalelerde değineceğim.
Peki nedir bu değişiklikler?
- SQL Server 2008 Setup' ta yükleme veya sürüm yükseltme esnasında "sa" hesabının adını değiştirebilme.
- SQL Server' ın eski versiyonlarında BUILTIN\Administrators Windows Grubu, SQL Server System Administrators "sysadmin" sunucu sabit rolüne eklenirdi. SQL Server 2008' de böyle olmayacak, yani Windows Yöneticileri doğrudan SQL Server Sistem Yöneticileri olmayacak artık.
- SQL Server tarafından oluşturulan "SQLServer2005MSSQLUser$-BİLGİSAYARADI-$INSTANCEADI" gibi Windows Gruplarına artık doğrudan SQL Server' a erişim izinleri verilmeyecek. Bunun yerine bu haklar, SQL Server servislerini başlatmak için kullanılan Windows hesabına verilecek.
- Surface Area Configuration aracı SQL Server 2008' de yok, yani kaldırıldı. Bunun yerine İlke Temelli Yönetim (Policy-Based Management) özelliği ve Configuration Manager' daki değişiklikler kullanılabilecek.
- Kerberos desteği genişletildi. TCP\IP' nin yanında, artık Named Pipes ve Shared Memory' yi de kapsıyor.
SQL Server "sa" hesabının adının değiştirilmesi:
"sa" hesabı varsayılan SQL Login' idir. "sysadmin" üyesidir ve bu değiştirilemez. Bu role üye olan bir Login, içinde bulunduğu SQL Server Instance' ında tüm yetkilere sahiptir. Bunu bilen korsanlar, sisteminize girmeye çalışacağı zaman ilk önce "sa" hesabına saldırırlar. Bir çok saldırı durumunda daha sonra "admin" isimli bir hesap denediklerini gördüm. Aslında SQL Server' da varsayılan olarak "admin" isminde bir hesap yoktur. Ama bildiğiniz gibi alışkanlıklarımız, güvenlik konusuna gelince en kırılgan noktamızdır. İnsanlar alışkanlıktan dolayı genelde "admin" isminde bir Login oluştururlar ve bunu da "sysadmin" rolünün bir üyesi yaparlar. Bu nedenle de korsanlar, SQL Server Instance' ınıza saldırdıklarında ilk önce olduğunu varsaydıkları bu Login' leri kırmaya çalışırlar.
"sa" hesabının adını değiştirmeniz ve bu hesaba güçlü bir şifre vermeniz (ki güçlü şifre denirken kastedilen, şifrenin içinde büyük-küçük harflerin, rakamların ve işaretlerin kullanılmasıdır) korsanların sisteminize en güçlü Login' lerle girmelerini engelleyici tedbirlerden olacaktır.
Tabi ki bu değişiklikleri yapmadan önce sisteminizi, uygulamalarınızı, Function' ları, Script' leri, CLR Assembly' leri gibi şeyleri de tekrar gözden geçirmeniz gerekebilir. "sa" hesabına bağlı uygulamalarınız, bu hesap ismini değiştirdiğiniz için artık çalışmayabilirler. Bu nedenle gerekli değişiklikleri uygulamalarınızda da yapmanız gerekebilir.
Mümkün olan her zaman Windows Authentication kullanmanız önerilir, ama öyle durumlar olur ki SQL Authentication kullanmanız gerekebilir. İşte böyle durumlarda yukarıdaki paragraflarda değindiğim tedbirleri almanızda büyük yarar vardır.
"sa" hesabı hakkında daha fazla bilgi için buraya tıklayın.
Windows Yerel Gruplarındaki değişiklik:
SQL Server' ın kurulması esnasında bazı Windows yerel grupları oluşturulur. SQL Server' ın, SQL Server 2008' den önceki versiyonlarında SQL Server servislerinin başlatılması için kullanılan servis hesapları bu yerel gruplara ekleniyorlardı. Servis hesabı ve Windows yerel gruplarına, işletim sistemi dosyaları ve Windows sistemi üzerinde haklar veriliyordu. Bu hesap ve gruplara SQL Server' da da bazı haklar veriliyordu.
SQL Server' ın yüklenmesi veya sürüm yükseltmesi esnasında seçtiğiniz özelliklere göre oluşturulan Windows yerel grupları aşağıdakilerden oluşur:
- SQL Server 2000
- OLAP Administrators
- SQL Server 2005
- SQLServer2005DTSUser$BİLGİSAYARADI
- SQLServer2005MSFTEUser$BİLGİSAYARADI$INSTANCEADI
- SQLServer2005MSOLAPUser$BİLGİSAYARADI$INSTANCEADI
- SQLServer2005MSSQLServerADHelperUser$ BİLGİSAYARADI
- SQLServer2005MSSQLUser$ BİLGİSAYARADI$INSTANCEADI
- SQLServer2005NotificationServicesUser$BİLGİSAYARADI
- SQLServer2005ReportingServicesWebServiceUser$BİLGİSAYARADI$INSTANCEADI
- SQLServer2005ReportServerUser$ BİLGİSAYARADI$INSTANCEADI
- SQLServer2005SQLAgentUser$ BİLGİSAYARADI$INSTANCEADI
- SQLServer2005SQLBrowserUser$ BİLGİSAYARADI
SQL Server 2008' de de bu Windows yerel grupları oluşturulacak, ama artık bu gruplara SQL Server içinde haklar verilmeyecek. Sadece, doğru Erişim Kontrol Listesi (Access Control List), SQL Server Motoru ve diğer özellikler için işletim sistemi hakları etkinleştirmesi amacıyla kullanılacaklar. Ancak SQL Server Setup boyunca servis hesapları olarak seçilen hesaplara SQL Server' da haklar atanacak.
Bir başka deyişle, Windows yerel grupları artık sadece işletim sistemi görevleri için kullanılacaklar. SQL Server servisleri için seçilen hesaplar da SQL Server ve veritabanı işlemleri için kullanılacaklar. Bu konuda daha fazla bilgi için buraya tıklayın.
Surface Area Configuration aracı:
Bu araç SQL Server 2005 ile birlikte geldi ve bu aracı, SQL Server' ın bazı özelliklerini açmak ve kapatmak için kullanıyoruz.
SQL Server 2008' de ise Surface Area Configuration aracı kaldırıldı. Bunun yerine çok daha gelişmiş bir özellik olan Policy-Based Management özelliğini kullanacağız. Bu konuda SQL Server' ın sanırım Kasım CTP' sinde bir örnek yaparak bunu yayınlamıştım. Bu makalemi okumak için buraya tıklayın. Bu özellik kısaca size SQL Server bileşenleri için ilkeler tanımlamanızı ve ayrıntılı bir şekilde bu ilkeleri SQL Server içindeki Principal ve Rollere uygulamanızı sağlıyor. Bu konuda daha fazla bilgi için buraya tıklayın.
Surface Area Configuration aracındaki bağlantılarla ilgili ayarları da -SQL Server 2005' te de yapabildiğimiz gibi- SQL Server Configuration Manager' da yapabilirsiniz. Örnek vermek gerekirse, TCP\IP, Named Pipes vb. protokollerin etkinleştirilip kapatılması gibi...
Kerberos Authentication:
SQL Server 2008' den itibaren, Kerberos Authentication desteği Named Pipes ve Shared Memory protokollerini de kapsayacak şekilde genişletildi. Buna ek olarak Kerberos, Windows Active Directory olmadan da kullanılabilecek. Bu konuda daha fazla bilgi için buraya tıklayın.
Ekrem Önsoy
Kaynak: Bu yazıyı yayınlarken Books Online' dan yararlandım.
SQL Server 2008 Release Candidate 0
Merhaba Arkadaşlar!
SQL Server 2008' in ilk Release Candidate versiyonu artık indirilebilir!
SQL Server 2008 RC 0' ı indirmek için buraya yıklayın!
Not:
"Release Candidate" versiyon, üretim ortamında kullanılabilecek bir versiyon değildir. SQL Server 2008 henüz resmen piyasaya sürülmemiştir ve Ağustos-Eylül gibi piyasaya sürülmesi beklenmektedir.
SQL Server 2008 RC0 versiyonunu sadece test amaçlı kullanmanızı tavsiye ediyorum. Zaten 180 gün sonra otomatik olarak kullanılamaz hale gelecektir.
Kolay gelsin,
Ekrem Önsoy
SQL Server 2008' in ilk Release Candidate versiyonu artık indirilebilir!
SQL Server 2008 RC 0' ı indirmek için buraya yıklayın!
Not:
"Release Candidate" versiyon, üretim ortamında kullanılabilecek bir versiyon değildir. SQL Server 2008 henüz resmen piyasaya sürülmemiştir ve Ağustos-Eylül gibi piyasaya sürülmesi beklenmektedir.
SQL Server 2008 RC0 versiyonunu sadece test amaçlı kullanmanızı tavsiye ediyorum. Zaten 180 gün sonra otomatik olarak kullanılamaz hale gelecektir.
Kolay gelsin,
Ekrem Önsoy
29 Ocak 2008 Salı
SQL Server 2008: Table Valued Parameters
Son güncelleme tarihi: 10 Nisan 2023
Merhaba arkadaşlar,
"Tablo-değerli parametreler" SQL Server 2008 ile birlikte gelen bir yeniliktir. "Tablo-değerli parametreler", User-Defined Table Type (Kullanıcı Tanımlı Tablo Tipi) kullanılarak tanımlanır. "Tablo-değerli parametreler"ı Stored Procedure ya da Function' lara geçiçi tablo kullanmadan çoklu kayıt göndermek için kullanabilirsiniz.
Şunu da yazımın başında hemen söyleyeyim, bu yazıyı hazırlarken kullandığım SQL Server 2008 versiyonu CTP5 versiyonudur. RTM versiyonunda değişiklikler olabilir. Bunu şu anda bilmek imkânsız. Bu nedenle daha sonra SQL Server 2008 ile ilgili bu ve diğer yazdığım makaleler ile kullanacağınız SQL Server 2008 RTM versiyonu arasında uyuşmazlık olursa kızmayın bana =)
Konunun örneklerle ve deneyerek daha iyi anlaşılacağını düşündüğüm için yazıma bir örnekle devam etmek istiyorum. Meselâ SQL Server 2005 ve öncesinde bir Stored Procedure kullanarak bir kerede birden çok kayıt girmek istediğimizde ne yaptığımızı hatırlayalım. Örneği yapmak için aşağıdaki kodları SQL Server Query Editor \ Query Analyzer'a kopyalayıp yapıştırarak çalıştırın ve örneğimiz için gereken yapıyı oluşturmuş olun.
Örnek Veritabanı:
CREATE DATABASE DenemeDB
Örnek Tablo:
USE DenemeDB
GO
CREATE TABLE dbo.Personeller(PersonelID int NOT NULL, PersonelAdi nvarchar(100) NOT NULL, PersonelEposta nvarchar(100) NOT NULL)
Örnek Stored Procedure:
USE DenemeDB
GO
CREATE PROCEDURE YeniPersonel
( @PersonelID int,
@PersonelAdi nvarchar(100),
@PersonelEposta nvarchar(100) )
AS
BEGIN
INSERT INTO dbo.Personeller VALUES(@PersonelID, @PersonelAdi, @PersonelEposta)
END
Eğer yukarıda örnek kodları bulunan veritabanını, tabloyu ve Stored Procedure' ü oluşturduysanız, şimdi de tablomuzun içine Stored Procedure' ümüzü kullanarak bir kaç kayıt girelim.
Örnek Kayıtlar:
USE DenemeDB
GO
EXECUTE YeniPersonel 1,'Fatma Mutlu','fatmam@xxx.com'
EXECUTE YeniPersonel 2,'Ali Satılmış','alis@xxx.com'
EXECUTE YeniPersonel 3,'Yasemin Yeter','yaseminy@xxx.com'
Örnek Kayıtları Sorgula:
USE DenemeDB
GO
SELECT * FROM Personeller
İşte SQL Server 2008 öncesinde birden fazla kayıt girmemiz gerekdiğinde (genelde) yaptığımız şey buydu. Tablo-değerli parametreler ile karşılaştırıldığında bu yöntemin aşağıdaki gibi bazı eksileri var:
- Birden çok kere gidip gelme (Round Trip)
- Stored Procedure' ün birden fazla çalıştırılması
- Verimsiz kodlama
Aynı sonucu bir de Tablo-değerli parametreler kullanarak almayı deneyelim. Ama önce, yeni örneğimiz için de kullanacak olduğumuz "Personeller" isimli tablomuzdaki kayıtları aşağıdaki kodu kullanarak temizleyelim.
"Personeller" Tablosunu Temizle:
USE DenemeDB
GO
TRUNCATE TABLE dbo.Personeller
Şimdi temiz bir "Personeller" tablomuz var. Tablo-değerli parametrelerimizi bir User Defined Table Type tanımlayarak oluşturalım:
Used Defined Data Type:
CREATE TYPE PersonellerTableType AS TABLE (PersonelID INT, PersonelAdi nvarchar(100), PersonelEposta nvarchar(100));
GO
Bu kodu çalıştırdıktan sonra "DenemeDB" veritabanınız içerisindeki Programmability\Types\User-Defined Table Type içerisinde Resim-1' deki gibi "PersonellerTableType" adında bir User Defined Table Type göreceksiniz.
Resim-1
Şimdi "PersonellerTableType" adlı bu User Defined Table Type'ı kullanarak veri kaydedeceğimiz Stored Procedure' ümüzü oluşturalım. Yalnız şuna dikkatinizi çekmek istiyorum ki bu Stored Procedure' ün adını bir önceki örnekte oluşturduğumuz Stored Procedure ile karıştırılmasın diye özellikle "YeniPersonel08" yaptım. "YeniPersonel08" isimli Stored Procedure' ü oluşturmak için aşağıdaki kodu çalıştırın:
Örnek Stored Procedure:
USE DenemeDB
GO
CREATE PROCEDURE YeniPersonel08
( @PersonelBilgileri PersonellerTableType READONLY)
AS
BEGIN
INSERT INTO dbo.Personeller SELECT * FROM @PersonelBilgileri
END
Stored Procedure de oluşturulduktan sonra sıra veri girmede. Aşağıdaki kodu kullanarak ve tabii User Defined Table Type marifetiyle veri girişi yapmış olacağız:
Örnek Kayıt Girişi:
USE DenemeDB
GO
DECLARE @YeniPersonel PersonellerTableType
INSERT INTO @YeniPersonel VALUES(1,'Zeynep Yamalı','zeynepy@xxx.com')
INSERT INTO @YeniPersonel VALUES(2,'Zeydi Kaçar','zeydik@xxx.com')
INSERT INTO @YeniPersonel VALUES(3,'Mehmet Tanrıverdi','mehmett@xxx.com')
EXECUTE YeniPersonel08 @YeniPersonel
GO
"YeniPersonel" isminde bir değişken tanımladık ve veritipini de daha önceden oluşturmuş olduğumuz "PersonellerTableType" olarak verdik. Daha sonra tanımladığımız bu değişken içerisine eklemek istediğimiz kayıtları INSERT INTO komutunu kullanarak sunucuya tekrar tekrar gidip gelmeden ekledik. Daha sonra tek seferde bu üç kaydı da "YeniPersonel08" ismiyle oluşturmuş olduğumuz Stored Procedure' ü kullanarak tek seferde veritabanımıza kaydettik. Bunu söylemeye gerek var mı ya da yok mu tam bilemiyorum, ama komutun çalışması tamamlandıktan sonra değişkene atadığınız değerler otomatik olarak silinecektir.
Bunu daha önceden şu vey bu şekilde yapıyorduk zaten diyenleriniz olabilir. Fakat SQL Server ile bütünleşik şekilde ve bu kadar kolay bir şekilde böyle bir özellik yoktu. Oldukça kullanışlı olduğuna inandığım bir yenilik. Benim çok hoşuma gitti, umarım siz de beğenirsiniz.
Kaynaklar:
Bu makaleyi hazırlarken Microsoft Virtual Labs dökümanlarından yararlandım.
Ekrem Önsoy
Merhaba arkadaşlar,
"Tablo-değerli parametreler" SQL Server 2008 ile birlikte gelen bir yeniliktir. "Tablo-değerli parametreler", User-Defined Table Type (Kullanıcı Tanımlı Tablo Tipi) kullanılarak tanımlanır. "Tablo-değerli parametreler"ı Stored Procedure ya da Function' lara geçiçi tablo kullanmadan çoklu kayıt göndermek için kullanabilirsiniz.
Şunu da yazımın başında hemen söyleyeyim, bu yazıyı hazırlarken kullandığım SQL Server 2008 versiyonu CTP5 versiyonudur. RTM versiyonunda değişiklikler olabilir. Bunu şu anda bilmek imkânsız. Bu nedenle daha sonra SQL Server 2008 ile ilgili bu ve diğer yazdığım makaleler ile kullanacağınız SQL Server 2008 RTM versiyonu arasında uyuşmazlık olursa kızmayın bana =)
Konunun örneklerle ve deneyerek daha iyi anlaşılacağını düşündüğüm için yazıma bir örnekle devam etmek istiyorum. Meselâ SQL Server 2005 ve öncesinde bir Stored Procedure kullanarak bir kerede birden çok kayıt girmek istediğimizde ne yaptığımızı hatırlayalım. Örneği yapmak için aşağıdaki kodları SQL Server Query Editor \ Query Analyzer'a kopyalayıp yapıştırarak çalıştırın ve örneğimiz için gereken yapıyı oluşturmuş olun.
Örnek Veritabanı:
CREATE DATABASE DenemeDB
Örnek Tablo:
USE DenemeDB
GO
CREATE TABLE dbo.Personeller(PersonelID int NOT NULL, PersonelAdi nvarchar(100) NOT NULL, PersonelEposta nvarchar(100) NOT NULL)
Örnek Stored Procedure:
USE DenemeDB
GO
CREATE PROCEDURE YeniPersonel
( @PersonelID int,
@PersonelAdi nvarchar(100),
@PersonelEposta nvarchar(100) )
AS
BEGIN
INSERT INTO dbo.Personeller VALUES(@PersonelID, @PersonelAdi, @PersonelEposta)
END
Eğer yukarıda örnek kodları bulunan veritabanını, tabloyu ve Stored Procedure' ü oluşturduysanız, şimdi de tablomuzun içine Stored Procedure' ümüzü kullanarak bir kaç kayıt girelim.
Örnek Kayıtlar:
USE DenemeDB
GO
EXECUTE YeniPersonel 1,'Fatma Mutlu','fatmam@xxx.com'
EXECUTE YeniPersonel 2,'Ali Satılmış','alis@xxx.com'
EXECUTE YeniPersonel 3,'Yasemin Yeter','yaseminy@xxx.com'
Örnek Kayıtları Sorgula:
USE DenemeDB
GO
SELECT * FROM Personeller
İşte SQL Server 2008 öncesinde birden fazla kayıt girmemiz gerekdiğinde (genelde) yaptığımız şey buydu. Tablo-değerli parametreler ile karşılaştırıldığında bu yöntemin aşağıdaki gibi bazı eksileri var:
- Birden çok kere gidip gelme (Round Trip)
- Stored Procedure' ün birden fazla çalıştırılması
- Verimsiz kodlama
Aynı sonucu bir de Tablo-değerli parametreler kullanarak almayı deneyelim. Ama önce, yeni örneğimiz için de kullanacak olduğumuz "Personeller" isimli tablomuzdaki kayıtları aşağıdaki kodu kullanarak temizleyelim.
"Personeller" Tablosunu Temizle:
USE DenemeDB
GO
TRUNCATE TABLE dbo.Personeller
Şimdi temiz bir "Personeller" tablomuz var. Tablo-değerli parametrelerimizi bir User Defined Table Type tanımlayarak oluşturalım:
Used Defined Data Type:
CREATE TYPE PersonellerTableType AS TABLE (PersonelID INT, PersonelAdi nvarchar(100), PersonelEposta nvarchar(100));
GO
Bu kodu çalıştırdıktan sonra "DenemeDB" veritabanınız içerisindeki Programmability\Types\User-Defined Table Type içerisinde Resim-1' deki gibi "PersonellerTableType" adında bir User Defined Table Type göreceksiniz.
Resim-1Şimdi "PersonellerTableType" adlı bu User Defined Table Type'ı kullanarak veri kaydedeceğimiz Stored Procedure' ümüzü oluşturalım. Yalnız şuna dikkatinizi çekmek istiyorum ki bu Stored Procedure' ün adını bir önceki örnekte oluşturduğumuz Stored Procedure ile karıştırılmasın diye özellikle "YeniPersonel08" yaptım. "YeniPersonel08" isimli Stored Procedure' ü oluşturmak için aşağıdaki kodu çalıştırın:
Örnek Stored Procedure:
USE DenemeDB
GO
CREATE PROCEDURE YeniPersonel08
( @PersonelBilgileri PersonellerTableType READONLY)
AS
BEGIN
INSERT INTO dbo.Personeller SELECT * FROM @PersonelBilgileri
END
Stored Procedure de oluşturulduktan sonra sıra veri girmede. Aşağıdaki kodu kullanarak ve tabii User Defined Table Type marifetiyle veri girişi yapmış olacağız:
Örnek Kayıt Girişi:
USE DenemeDB
GO
DECLARE @YeniPersonel PersonellerTableType
INSERT INTO @YeniPersonel VALUES(1,'Zeynep Yamalı','zeynepy@xxx.com')
INSERT INTO @YeniPersonel VALUES(2,'Zeydi Kaçar','zeydik@xxx.com')
INSERT INTO @YeniPersonel VALUES(3,'Mehmet Tanrıverdi','mehmett@xxx.com')
EXECUTE YeniPersonel08 @YeniPersonel
GO
"YeniPersonel" isminde bir değişken tanımladık ve veritipini de daha önceden oluşturmuş olduğumuz "PersonellerTableType" olarak verdik. Daha sonra tanımladığımız bu değişken içerisine eklemek istediğimiz kayıtları INSERT INTO komutunu kullanarak sunucuya tekrar tekrar gidip gelmeden ekledik. Daha sonra tek seferde bu üç kaydı da "YeniPersonel08" ismiyle oluşturmuş olduğumuz Stored Procedure' ü kullanarak tek seferde veritabanımıza kaydettik. Bunu söylemeye gerek var mı ya da yok mu tam bilemiyorum, ama komutun çalışması tamamlandıktan sonra değişkene atadığınız değerler otomatik olarak silinecektir.
Bunu daha önceden şu vey bu şekilde yapıyorduk zaten diyenleriniz olabilir. Fakat SQL Server ile bütünleşik şekilde ve bu kadar kolay bir şekilde böyle bir özellik yoktu. Oldukça kullanışlı olduğuna inandığım bir yenilik. Benim çok hoşuma gitti, umarım siz de beğenirsiniz.
Kaynaklar:
Bu makaleyi hazırlarken Microsoft Virtual Labs dökümanlarından yararlandım.
Ekrem Önsoy
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
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-1Gö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-2Bu 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-3Bu 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-5Eğ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-6Bu 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-7Siz 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
23 Kasım 2007 Cuma
SQL SERVER 2008 : Yedek Sıkıştırma (Backup Compression) Özelliği
Merhaba arkadaşlar,
Bu makalemde sizlere SQL Server 2008 ile birlikte gelen Sıkıştırılmış Yedekleme (Compressed Backup) özelliğinden bahsedeceğim.
Bazılarınızın da bildiği gibi, bu sıkıştırılmış yedekleme özelliği gerçekten çok gerekiyordu. Veritabanı yöneticileri açısından veritabanları konusundaki en önemli şeyler güvenlik, verinin kullanılabilirliği ve performanstır. Yedekleme, veritabanı yöneticileri için hayati ve sürekli yapılması gereken bir işlemdir. Her zaman son yedeğiniz kadar güvendesinizdir.
SQL Server 2008' den önceki SQL Server versiyonlarında maalesef sıkıştırma özelliği yoktu. Bazı veritabanı yöneticileri bu ihtiyaçlarını üçüncü parti yazılımlar (Red-Gate Backup gibi) kullanarak gideriyordu.
Peki, sıkıştırma neden gerekiyor? Yukarıda da dediğim gibi, veritabanı yöneticilerinin sürekli yedek almaları gerekiyor. Diskler artık eskisi gibi pahalı değiller, çok daha kolay alabiliyoruz; fakat eğer doğru ve düzenli bir şekilde kullanılmazlarsa bir süre sonra disk yönetimi de sorun olmaya başlıyor. Örnek vermek gerekirse, SQL Server sunucularından sorumlu olduğum büyük bir firma, disklerini çok kötü kullanıyordu. Raporlarımda sürekli belirtmeme rağmen gelişi güzel yedekler alıp oraya buraya atıyorlardı ve sonunda ne oldu tahmin edin! Evet, patladılar =)
Eğer yedeklerimizi düzenli ve kontrollü bir şekilde alırsak, böyle sorunlarla karşılaşmayız. Neyse, çok dağıtmadan hemen sıkıştırmanın neden gerektiğine de bir vurgu yapıp hemen yeni özelliklerden bahsedeyim. Gerçi artık vurguya da gerek kalmadı, söylemek istediğim şeyi sanırım çoktan anlamışsınızdır... Bol yedek alacağımız için, disk alanlarından kazanmamız gerekiyor. Ayrıca, sıkıştırma yöntemi kullanacağımız için dosya boyutu daha küçük olacak, yani G\Ç (I\O) işlemleri de azalacak. Her şekilde kazanmış oluyoruz. Tek kayıp var, ondan da sırası gelince bahsedeceğim.
Sıkıştırılmış Yedek özelliği sadece SQL Server 2008' in Enterprise Sürümünde olacak arkadaşlar. Bununla birlikte, bir SQL Server 2008 Enterprise sürümüyle sıkıştırılmış veritabanı yedeği, başka bir SQL Server 2008 sürümüyle (meselâ Standard veya Express) açılabilecek; fakat diğer sürümler maalesef sıkıştırılmış yedek alamayacaklar. Ayrıca, SQL Server' ın eski versiyonları (90, 80, 70...) SQL Server 2008 ile alınan sıkıştırılmış yedekleri açamayacaklar.
Sıkıştırılmış bir yedek ile sıkıştırılmamış bir yedek aynı medya-set' inde saklanamaz.
Her şeyin ama her şeyin bir bedeli olduğuna inanırım; evet, bunun da bir bedeli var! Fiyatı hariç =) Bedeli şu: İşlemci. Evet arkadaşlar, sıkıştırma işlemi, işlemcinizi yoracak. Bununla birlikte, yukarıda da bahsettiğim gibi yedek alma süresini düşüreceği için G\Ç' dan ("Girdi\Çıktı" Bu terimden, fiziksel disklere yapılan yazma ve okumalar kastediliyor.) kâr edeceksiniz.
Bu sıkıştırma işinin gördüğünüz gibi bazı maliyetleri olacağı için, bu işe kalkışmadan önce gerekli performans testlerini yapmanızı tavsiye ederim. Ve de yedeklerinizi iş saatleri dışında almanızı tavsiye ederim. İşlemci o zamanlar daha az kullanılıyor olacaktır. Ayrıca, sıkıştırılmış yedek alacağınız zaman iş saatlerinde işlemcinize ekstra yük bindirmemiş olursunuz. Performans testlerini Yönetimsel Araçlar' daki Sistem Monitörü ile yapabilirsiniz.
Sıkıştırılmış veritabanı yedeği özelliği hem sunucu düzeyinde varsayılan olarak ayarlanabilir, hem de yedek alırken T-SQL komutunun içerisinde siz de belirleyebilirsiniz. Ve tabii ki, SSMS' te yedekleme işlemi için menüleri kullanarak da belirlenebilir.
Bu yöntemlere dair bir kaç tane örnek ve resim de göstermek istiyorum sizlere.
Sunucu düzeyinde ayar yapmak için:
- sp_configure Transact-SQL komutunu kullanabilirsiniz,
veya
- SSMS arayüzünü kullanarak, aşağıdaki resimde de gösterdiğim yerden varsayılan ayar değişikliğini yapabilirsiniz.
Sunucu düzeyinde yapılan varsayılan sıkıştırılmış yedek alma ayarından farklı bir yedek almak için ise aşağıdaki yöntemleri kullanabilirsiniz:
- BACKUP DATABASE \ LOG komutu ile birlikte WITH NO_COMPRESSION veya WITH COMPRESSION anahtarlarını kullanabilirsiniz.
veya
- SSMS kullanarak aldığınız yedeğin Seçenekler menüsünden "Compress backup" veya "Do not commpress backup" seçeneklerini kullanarak ihtiyacınıza göre yedek alabilirsiniz. Ayarı nereden yapacağınıza dair de bir resim ekliyorum aşağıya.
Tabii bir de veritabanlarının neye göre ve ne kadar sıkıştırılacağı konusu var. Bu konuda da aşağıdaki bilgileri dikkate alın. Veritabanlarınızın yedekleri, bu kriterlere göre çok veya az sıkıştırılacaktır.
- Verinin tipi: Her zaman olduğu gibi (Winzip veya Winrar vb. programlarda) karakterler daha çok sıkıştırılır.
- Sayfa (Page)' lardaki satırların veri bütünlüğü: Tipik olarak, bir sayfadaki satırlarda bulunan verriler aynı değerleri içeriyorsa önemli bir miktarda sıkıştırma oranı yakalayabilirsiniz. Tam tersi bir senaryoda ise, yani eğer her sayfada büyük ve sadece bir satır varsa veya veritabanınızda hep farklı farklı, birbirine benzemeyen veriler varsa o zaman sıkıştırılmış veritabanı yedeğinizin boyutu, hiç sıkıştırılma işlemine uğramamış veritabanı yedeğiyle aynı olacaktır büyük ihtimalle.
- Verilerinizi şifreli olup olmadığı (Encrypted): Sıkıştırılmış veritabanı yedeğiniz, şifrelenmemiş benzerlerine göre çok daha az sıkıştırılacaktır.
- Veritabanınızın sıkıştırılmış olup olmadığı: Bu durumda sıkıştırılmış veritabanı yedeğiniz neredeyse hiç bir boyut azalmasına neden olmayacaktır.
Not: Bu son öğede lütfen yanlış anlaşılma olmasın. SQL Server 2008' de, veritabanını da sıkıştırabiliyorsunuz. Yani veritabanını sıkıştırmak başka bir işlem, sıkıştırılmış veritabanı yedeği almak başka bir işlem.
Özet:
Size bu makalemde SQL Server 2008 Enterprise Edition ile birlikte gelecek olan Yedek Sıkıştırma (Backup Compression) özelliğini anlatmaya çalıştım. Umarım yararlı olmuştur.
Ekrem Önsoy
Bu makalemde sizlere SQL Server 2008 ile birlikte gelen Sıkıştırılmış Yedekleme (Compressed Backup) özelliğinden bahsedeceğim.
Bazılarınızın da bildiği gibi, bu sıkıştırılmış yedekleme özelliği gerçekten çok gerekiyordu. Veritabanı yöneticileri açısından veritabanları konusundaki en önemli şeyler güvenlik, verinin kullanılabilirliği ve performanstır. Yedekleme, veritabanı yöneticileri için hayati ve sürekli yapılması gereken bir işlemdir. Her zaman son yedeğiniz kadar güvendesinizdir.
SQL Server 2008' den önceki SQL Server versiyonlarında maalesef sıkıştırma özelliği yoktu. Bazı veritabanı yöneticileri bu ihtiyaçlarını üçüncü parti yazılımlar (Red-Gate Backup gibi) kullanarak gideriyordu.
Peki, sıkıştırma neden gerekiyor? Yukarıda da dediğim gibi, veritabanı yöneticilerinin sürekli yedek almaları gerekiyor. Diskler artık eskisi gibi pahalı değiller, çok daha kolay alabiliyoruz; fakat eğer doğru ve düzenli bir şekilde kullanılmazlarsa bir süre sonra disk yönetimi de sorun olmaya başlıyor. Örnek vermek gerekirse, SQL Server sunucularından sorumlu olduğum büyük bir firma, disklerini çok kötü kullanıyordu. Raporlarımda sürekli belirtmeme rağmen gelişi güzel yedekler alıp oraya buraya atıyorlardı ve sonunda ne oldu tahmin edin! Evet, patladılar =)
Eğer yedeklerimizi düzenli ve kontrollü bir şekilde alırsak, böyle sorunlarla karşılaşmayız. Neyse, çok dağıtmadan hemen sıkıştırmanın neden gerektiğine de bir vurgu yapıp hemen yeni özelliklerden bahsedeyim. Gerçi artık vurguya da gerek kalmadı, söylemek istediğim şeyi sanırım çoktan anlamışsınızdır... Bol yedek alacağımız için, disk alanlarından kazanmamız gerekiyor. Ayrıca, sıkıştırma yöntemi kullanacağımız için dosya boyutu daha küçük olacak, yani G\Ç (I\O) işlemleri de azalacak. Her şekilde kazanmış oluyoruz. Tek kayıp var, ondan da sırası gelince bahsedeceğim.
Sıkıştırılmış Yedek özelliği sadece SQL Server 2008' in Enterprise Sürümünde olacak arkadaşlar. Bununla birlikte, bir SQL Server 2008 Enterprise sürümüyle sıkıştırılmış veritabanı yedeği, başka bir SQL Server 2008 sürümüyle (meselâ Standard veya Express) açılabilecek; fakat diğer sürümler maalesef sıkıştırılmış yedek alamayacaklar. Ayrıca, SQL Server' ın eski versiyonları (90, 80, 70...) SQL Server 2008 ile alınan sıkıştırılmış yedekleri açamayacaklar.
Sıkıştırılmış bir yedek ile sıkıştırılmamış bir yedek aynı medya-set' inde saklanamaz.
Her şeyin ama her şeyin bir bedeli olduğuna inanırım; evet, bunun da bir bedeli var! Fiyatı hariç =) Bedeli şu: İşlemci. Evet arkadaşlar, sıkıştırma işlemi, işlemcinizi yoracak. Bununla birlikte, yukarıda da bahsettiğim gibi yedek alma süresini düşüreceği için G\Ç' dan ("Girdi\Çıktı" Bu terimden, fiziksel disklere yapılan yazma ve okumalar kastediliyor.) kâr edeceksiniz.
Bu sıkıştırma işinin gördüğünüz gibi bazı maliyetleri olacağı için, bu işe kalkışmadan önce gerekli performans testlerini yapmanızı tavsiye ederim. Ve de yedeklerinizi iş saatleri dışında almanızı tavsiye ederim. İşlemci o zamanlar daha az kullanılıyor olacaktır. Ayrıca, sıkıştırılmış yedek alacağınız zaman iş saatlerinde işlemcinize ekstra yük bindirmemiş olursunuz. Performans testlerini Yönetimsel Araçlar' daki Sistem Monitörü ile yapabilirsiniz.
Sıkıştırılmış veritabanı yedeği özelliği hem sunucu düzeyinde varsayılan olarak ayarlanabilir, hem de yedek alırken T-SQL komutunun içerisinde siz de belirleyebilirsiniz. Ve tabii ki, SSMS' te yedekleme işlemi için menüleri kullanarak da belirlenebilir.
Bu yöntemlere dair bir kaç tane örnek ve resim de göstermek istiyorum sizlere.
Sunucu düzeyinde ayar yapmak için:
- sp_configure Transact-SQL komutunu kullanabilirsiniz,
veya
- SSMS arayüzünü kullanarak, aşağıdaki resimde de gösterdiğim yerden varsayılan ayar değişikliğini yapabilirsiniz.
Sunucu düzeyinde yapılan varsayılan sıkıştırılmış yedek alma ayarından farklı bir yedek almak için ise aşağıdaki yöntemleri kullanabilirsiniz:
- BACKUP DATABASE \ LOG komutu ile birlikte WITH NO_COMPRESSION veya WITH COMPRESSION anahtarlarını kullanabilirsiniz.
veya
- SSMS kullanarak aldığınız yedeğin Seçenekler menüsünden "Compress backup" veya "Do not commpress backup" seçeneklerini kullanarak ihtiyacınıza göre yedek alabilirsiniz. Ayarı nereden yapacağınıza dair de bir resim ekliyorum aşağıya.
Tabii bir de veritabanlarının neye göre ve ne kadar sıkıştırılacağı konusu var. Bu konuda da aşağıdaki bilgileri dikkate alın. Veritabanlarınızın yedekleri, bu kriterlere göre çok veya az sıkıştırılacaktır.
- Verinin tipi: Her zaman olduğu gibi (Winzip veya Winrar vb. programlarda) karakterler daha çok sıkıştırılır.
- Sayfa (Page)' lardaki satırların veri bütünlüğü: Tipik olarak, bir sayfadaki satırlarda bulunan verriler aynı değerleri içeriyorsa önemli bir miktarda sıkıştırma oranı yakalayabilirsiniz. Tam tersi bir senaryoda ise, yani eğer her sayfada büyük ve sadece bir satır varsa veya veritabanınızda hep farklı farklı, birbirine benzemeyen veriler varsa o zaman sıkıştırılmış veritabanı yedeğinizin boyutu, hiç sıkıştırılma işlemine uğramamış veritabanı yedeğiyle aynı olacaktır büyük ihtimalle.
- Verilerinizi şifreli olup olmadığı (Encrypted): Sıkıştırılmış veritabanı yedeğiniz, şifrelenmemiş benzerlerine göre çok daha az sıkıştırılacaktır.
- Veritabanınızın sıkıştırılmış olup olmadığı: Bu durumda sıkıştırılmış veritabanı yedeğiniz neredeyse hiç bir boyut azalmasına neden olmayacaktır.
Not: Bu son öğede lütfen yanlış anlaşılma olmasın. SQL Server 2008' de, veritabanını da sıkıştırabiliyorsunuz. Yani veritabanını sıkıştırmak başka bir işlem, sıkıştırılmış veritabanı yedeği almak başka bir işlem.
Özet:
Size bu makalemde SQL Server 2008 Enterprise Edition ile birlikte gelecek olan Yedek Sıkıştırma (Backup Compression) özelliğini anlatmaya çalıştım. Umarım yararlı olmuştur.
Ekrem Önsoy
22 Kasım 2007 Perşembe
Microsoft SQL Server 2008 November CTP artık indirilebilir!
Merhaba Arkadaşlar!
Bugün Microsoft' tan gelen bir haber ile SQL Server 2008 Kasım CTP' sinin indirilebileceğini öğrendim.
SQL Server 2008 Kasım CTP' sini aşağıdaki adresten indirebilirsiniz!
http://www.microsoft.com/downloads/details.aspx?FamilyId=3BF4C5CA-B905-4EBC-8901-1D4C1D1DA884&displaylang=en
Not:
Tam deneme sürümlerinin yanısıra, bir de Express Edition da yayınlanmış!
Ekrem Önsoy
Bugün Microsoft' tan gelen bir haber ile SQL Server 2008 Kasım CTP' sinin indirilebileceğini öğrendim.
SQL Server 2008 Kasım CTP' sini aşağıdaki adresten indirebilirsiniz!
http://www.microsoft.com/downloads/details.aspx?FamilyId=3BF4C5CA-B905-4EBC-8901-1D4C1D1DA884&displaylang=en
Not:
Tam deneme sürümlerinin yanısıra, bir de Express Edition da yayınlanmış!
Ekrem Önsoy
Kaydol:
Kayıtlar (Atom)