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

"Failed to install and configure assemblies C:\Program Files\Microsoft SQL Server\90\DTS\Tasks\Microsoft.SqlServer.MSMQTask.dll in the COM+ catalog. E

HATA MESAJI:
"Failed to install and configure assemblies C:\Program Files\Microsoft SQL Server\90\DTS\Tasks\Microsoft.SqlServer.MSMQTask.dll in the COM+ catalog. Error: -2146233087 Error message: Unknown error 0x80131501 Error description: One or more of the components being installed are already registered in the target application. You must install the 64 bit versions of the components being installed in a different COM+ application, or delete the existing 32 bit versions of the components being installed from the target COM+ application prior to attempting install of the 64 bit versions. COM+ applications cannot contain bit neutral components."

AÇIKLAMA:
64 Bit bir Windows işletim sistemi üzerinde SQL Server 2005' i kurarken kurulum esnasında böyle bir hata mesajıyla kurulum duraklatılabilir.

Bu hatayı almanızın nedeni ise, sisteminizdeki MSMQTask COM+ bileşeninin önceden 32 bit olarak kurulu bulunmasıdır.

ÇÖZÜM:
Ben bu sorunla karşılaştığımda, sorunu çözmek için Component Services MMC' sindeki MSMQTask COM+ bileşenini kaldırdım ve SQL Server Setup' ın verdiği hata mesajı penceresindeki "Retry" düğmesine tıkladım ve kurulum sorunsuz şekilde devam edip başarıyla tamamlandı.

MSMQTask COM+ Bileşeni Nasıl Silinir?
- Start\Programs\Administrative Tools\Components Services' i açın,
- "Component Services" -> "My Computer" -> "COM+ Applications" düğümlerini genişletin,
- "Microsoft.SqlServer.MSMQTask" bileşenini göreceksiniz. Bu bileşen üzerinde farenin sağ tuşuna tıklayıp "Delete" öğesini seçerek bu bileşeni silin.
- SQL Server Setup' a geri dönün ve hata mesajı penceresindeki "Retry" düğmesine tıklayın.

"ASP.Net Version Registration Requirement (Warning)"

HATA MESAJI:
"ASP.Net Version Registration Requirement (Warning)"

AÇIKLAMA:
64 Bit bir Windows işletim sistemi üzerinde SQL Server 2005' i kurarken, "System Configuration Check" penceresinde böyle bir uyarı mesajıyla karşılaşabilirsiniz.

Bu hatayı almanızın nedeni ise, 64Bit sisteminizde 32Bit uygulamaların çalıştırılmasının varsayılan olarak etkinleştirilmemesidir.

ÇÖZÜM:
Aşağıdaki kodu çalıştırdığınızda, bu hata mesajını bir daha SQL Server Setup' ını çalıştırdığınızda almayacaksınız.

cscript %SystemDrive%\inetpub\AdminScripts\adsutil.vbs set w3svc/AppPools/Enable32bitAppOnWin64 1

SQL Server 2008: Integrated Full-Text Index Catalog

SQL Server' ın önceki versiyonlarında Full-Text Catalog, IN PATH seçeneği kullanılarak ayrı bir klasörde tutulabiliyordu. SQL Server 2008' de ise Catalog ayrı bir klasörde tutulamıyor. Bunun yerine bir FileGroup' ta, veritabanının bir parçası olarak saklanıyor.

"IN PATH" seçeneği SQL Server 2008' de geriye dönük destek için hâlâ kullanılabiliyor, fakat yeni uygulamalarınızda bu seçeneği kullanmamanızı tavsiye ediyorum. Çünkü SQL Server 2008' den itibaren bu seçenek "ileriki versiyonlarda kaldırılacak özellikler" listesine girdi (Yani "Depricated" oldu).

Ayrıca, eğer mümkünse Full-Text Catalog için ayrı bir FileGroup oluşturun.

SQL Server 2008: Resource Veritabanı

SQL Server 2005' te, "master" sistem veritabanını varsayılan yerinden başka bir yere taşımanız gerektiğinde "resource" sistem veritabanını da "master" veritabanını taşıyacağınız yere taşımalıydınız.

SQL Server 2008' de bu zorunluluk kaldırıldı. Artık ikisini de farklı yerlerde tutabilirsiniz. SQL Server 2008' de, "resource" veritabanının varsayılan yeri şöyle:

"-sürücü-:\Program Files\Microsoft SQL Server\MSSQL-instance_no-.-instance_adı-\Binn\".

Microsoft, bu veritabanının yerinin değiştirilmemesini iki nedenle öneriyor, bunlar: 1-SQL Server servis paketleri veya "hotfix" ler bu veritabanını \Binn klasöründe oluşturuyor.
2-Failover Cluster' lı bir SQL Server ortamında "resource" veritabanınının yerinin Cluster olmayan bir yerle değiştirilmesi, Failover Cluster çalışmamasına neden olacaktır.

SQL Server 2008: Replace Fonksiyonu

SQL Server 2005' te, Replace fonksiyonunu kullandığınızda, bu fonksiyonun aldığı üç parametrenin sağındaki boşluklar otomatik olarak siliniyordu (RTRIM). Fakat SQL Server 2008' deki Replace fonksiyonunda bu boşluklar otomatik olarak silinmiyor. Bu işlemin aynen SQL Server 2005' teki gibi olmasını isteyenler Replace fonksiyonunu şu şekilde kullanabilirler:

REPLACE(RTRIM(parametre1), RTRIM(parametre2), RTRIM(parametre3)).

SQL Server' da noktalı virgül kullanımı

SQL Server' ın sıradaki değil (yani muhtemelen 2011' de çıkacak versiyon değil), ama ondan sonraki SQL Server versiyonunda (muhtemelen SQL Server 2014) T-SQL komutlarının sonuna noktalı virgül koyulması zorunlu olacak.

Bunu şimdiden sizinle paylaşıyorum ki, ileriye dönük projeleriniz için noktalı virgül kullanımına şimdiden başlayın. Aksi takdirde, gelecekteki SQL Server' da uygulamanızı çalıştırırken sorun yaşarsınız. Muhtemelen "daha çook var" diyorsunuzdur, zaten benim de "ileriye dönük" ibaresini vurgulamamın nedeni buydu.

SQL Command (SQLCMD)

SQLCMD aracı vasıtasıyla çalıştırdığınız Script' lerde veya komut satırlarında değişkenler kullanabileceğinizi biliyor muydunuz?

Örneğin, "yedek_al.sql" isimli Script' inizin içinde şöyle bir yedek alma komutu olsun:

"BACKUP DATABASE $(Veritabanim) TO DISK=N'D:\SQLYedekler\$(Veritabanim).bak'"

Gördüğünüz gibi, buradaki değişken adı "Veritabanim". Bu değişkene atanacak değer ise, SQLCMD komutuyla "yedek_al.sql" Script dosyası çağırılırken "-v" parametresi ile atanıyor.

Örnek: SQLCMD -E -i yedek_al.sql -v Veritabanim="Muhasebe".

SQL Command (SQLCMD)

ISQL ve OSQL, SQL Server 2005' ten önce SQL Server Instance' larında Komut İstemcisinden işlem yapmak için kullanılan Komut İstemcisi araçlarıydı. SQL Server 2005 ile birlikte, tamamen yeniden yazılan SQL Command (SQLCMD) Komut İstemci aracı geliştirildi ve OSQL da tedavülden kalkma sürecine girdi ("Deprecated" oldu).

SQLCMD' den önceki araçlar SQL Server Instance' larına ODBC ile bağlanıyorlar ve bu yüzden bir seferde bir Instance' a bağlanabiliyorlardı. Fakat SQLCMD aracı bağlantı için OLE DB kullanıyor ve bu sayede değişik SQL Server Instance' larına bir Script' te birden fazla bağlantı kurabiliyor.

Örnek vermek gerekirse, ODBC ile bağlandığınızda bir Script içerisinde iki farklı SQL Server Instance' ından iki farklı veritabanının yedeğini alamazsınız. Fakat aynı işlem için SQLCMD kullanarak ve Script' inizde de

":CONNECT SQLServerInstanceAdı -E"

komutunu da kullanarak farklı Instance' larda işlem yapabilirsiniz.

SQL Server Agent

SQL Server 2005 ve 2008' de, bir kullanıcıyı "sysadmin" yapmadan, bu kullanıcıya iş (Job) oluşturma ve bunu yönetme hakkı verebileceğinizi biliyor muydunuz?

Bunun için, bahsi geçen kullanıcıyı MSDB veritabanındaki üç rolden birine atamanız yeterli.

Rolleri, yetkileri en kısıtlı olandan itibaren yazıyorum:
1) SQLAgentUserRole,
2) SQLAgent ReaderRole,
3) SQLAgentOperatorRole.

Roller hakkında daha fazla bilgi için Books Online' a bakabilirsiniz: http://msdn.microsoft.com/en-us/library/ms188283.aspx