Makale Özeti

SQL Server 2000 hem uygulama geliştiriciler, hem de firmalar açısından çok önemli kazanımlar sağlayan, rdbms alanında dönüm noktası olarak kabul edebileceğimiz bir ürün olarak hayatımızda varoldu.. Açıksözlü olmak gerekirse 27 Ekim 2005 tarihinde MSDN Subscriber’lara RTM’i dağıtılmaya başlanan SQL Server 2005 ürününü incelediğimizde, SQL Server 2000’den 2005’e geçişin çok hızlı olacağını düşünmüyorum. Ancak ürünü detaylı olarak inceledikçe, SQL Server 2005’in uzun vadede Microsoft’un rdbms alanında liderliğini perçinleyecek bir ürün olacağı yönündeki düşünceme katılıyor olacağınızdan eminim. SQL Server 2005’in uygulama geliştirme alanında bize sunduğu artıları ele almadan önce altyapıda ne gibi değişikliklerin ve yeniliklerin olduğunu ele almakta fayda görüyorum. Dolayısıyla bu dokumanda SQL Server 2005 ile birlikte veritabanı yönetimi alanında gelen yenilikleri veritabanı mimarisi ve sotorage engine, veritabanı yönetim ve geliştirme araçları ve süreklilik ve veri güvenliği şeklinde üç ana başlık altında ele alıyor olacağız. 

Makale

Veritabanı Mimarisi ve Storage Engine
Microsoft SQL Server 7 ile geliştirdiği mimariyi sürekli olarak geliştirdi. Hepimizin bildiği ve doğruluğunu kabul ettiği kurala göre mevcut donanımların maliyeti düşerken, gücü ise her 18 ayda öncekine göre iki katına çıkıyor. SQL Server 2005 ile birlikte Microsoft’un öncelikli hedeflerinden biri, veritabanı motorunun mevcut donanım altyapısından ve geliştirilen Windows Server 2003 (ve sonrasında gelecek olan) işletim sisteminden mümkün olan en fazla oranda faydalanmasını sağlamak. SQL Server 2005 ile birlikte gelen yeni özellikler ve güncellemelerin diğer hedefleri ise kurumlar açısından yönetimi daha kolay ve şirkete daha çok değer katan bir veritabanı motoru oluşturmak. Bu bölümde SQL Server 2005 ile birlikte SQL Server mimarisindeki yenilik ve gelişmeleri, kurumumuza ve iş süreçlerimize ne gibi artılar katabileceklerini de ele alarak inceliyor olacağız.

Donanım Desteği
Donanım alanındaki gelişmeler ve hızla daha düşük seviyelere inan donanım maliyetleri, firmaların daha güçlü bilgisayar sistemlerine çok daha düşük maliyetlerle sahip olabilmesini mümkün kıldı. Özellikle sunucu alanında 32-bit sistemlerde yaşadığımız gelişmeler ve hızla yaygınlaşmaya başlayan ve donanım alanında bir dönüm noktası olarak nitelendirebileceğimiz 64-bit sistemler, donanım alanındaki sorunlarımızın neredeyse tamamını ortadan kaldırdı. Bellek, veritabanı performansında her zaman için en kritik unsurlardan biri olmuştur. 54-Bit platformunda UNIX tabanlı sistemler, non-clustered TPC-C performans testlerinde uzun süre liderliği elinde bulundurdu. Ancak SQL Server 2005, ilk 64-Bitlik sürümünde liderliği devraldı. Performans testlerine baktığımızda, 64-Bit SQL Server 2005’in, 64-Bit Windows Server 2003 üzerinde, Intel Itanium platformunda gerçekten çok çok başarılı sonuçlar sergilediğini görüyoruz.

64-Bit Desteği
SQL Server 2005, Windows Server 2003 for 64-Bit Itanium systems üzerinde Intel Itanium ve Itanium2 mikroişlemcilerini desteklemektedir. Windows Server 2003 for 64-Bit Extended Systems üzerinde ise AMD’nin 64-Bit Opteron platformunu ve Intel’in “Xeon with Intel Extended Memory 64 technology (EMT64”  sistemlerini de desteklemektedir. SQL Server 2005, tüm ana bileşenleri (SQL Server Engine, Analysis Services, SQL Agent ve Reporting Services) için hem 32, hem 64-Bit platformları desteklemektedir. Veritabanı altyapımızı 64-Bit platformuna taşımanın bize sağlayacağı en önemli kazanım her ne kadar daha yüksek işlem gücü olarak görünse de gerçekte en önemli kazanım: artan adreslenebilir bellek oranıdır. Şekil 1:1’de SQL Server 2005’in 32-Bitlik ve 64-Bitlik sürümleri tarafından adreslenebilen bellek miktarlarının karşılaştırmasını görebilirsiniz.

 

Şekil 1:1 :: 32-Bit ve 64-Bit SQL Server 2005’in Bellek Adresleme Oranları

32-Bit mimarisi en fazla 4GB bellek adresleyebilmektedir. Windows altında bu oran işletim sistemi ve uygulamalar arasında paylaştırılır. Diğer bir deyişle 2GB işletim sistemi için rezerve edilirken kalan 2GB uygulamaların kullanımına tahsis edilmektedir. 32-Bit Windows üzerinde yer alan Advanced Windowing Extensions (AWE) desteğini kullanarak, 32-Bit SQL Server'ın 32GB'a kadar bellek adresleyebilmesini sağlayabilmekteyiz. Her ne kadar bahsettiğimiz artış yeterli gibi görünebilse de, yönetilebilen bellek sayfalarındaki limit değişmiş olmuyor. 64-Bit Platformu adreslenebilen bellek miktarını 32TB'a çekerek bu konudaki sıkıntıları uzun bir süre için ortadan kaldırıyor. Şu anda neredeyse hiç bir yerde bu oranda bellek kullanılmıyor olsa da, SQL Server 2005'in test edildiği en yüksek bellek miktarı 512GB'dır. Windows Server 2003 için gelecek bir sonraki Service Pack ile birlikte desteklenen en yüksek bellek miktarının 1TB'a çıkartılması hedefleniyor.

NUMA (Non-Uniform Memory Architecture) Desteği
Windows Server 2003'ü üstün kılan yeni özelliklerden biride Non-Uniform Memory Architecture (NUMA) desteğidir. NUMA, IBM ve Unisys gibi bazı sistem üreticileri tarafından kullanılan ve çok işlemcili sistemlerde işlemci ve bellek kullanımını SMP (Symmetric Multiprocessing) mimarisine göre çok daha etkin bir şekilde yöneten bir mimaridir. Standart SMP sistemlerde işlemcilerin hızı ve sayısı arttıkça, işlemciler arasında belleğe erişme amaçlı yaşanan rekabet gereksiz yoğunluğa neden olur. Bu da doğal olarak bazı gecikmelere neden olur. Bunun sonucunda SMP sistemler işlemci sayısının artışıyor orantılı olarak esneklik gösteremezler. NUMA mimarisi SMP sistemlerde yaşanan bu sorunları, işlemcilerin RAM üzerindeki verilere, RAM ve BUS'ın sağlayabileceğinden çok daha hızlı olarak erişmesine olanak tanıyarak ortadan kaldırmak amacıyla tasarlanmıştır. NUMA mimarisi işlemci ve belleği çoklu işlemcilerden oluşan yerel gruplara ayırır. Bu gruplar birbirlerine, gruplar arası veri trafiğinin aktarıldığı harici bus'lar ile bağlıdır. Bu grup sıralama mimarisi, belleğe erişmek için yarışacak işlemcilerin sayısını limitleyerek SMP sistemlerde yaşanan işlemciler arası rekabetin önünü kesmektedir. NUMA mimarisinin artılarından en fazla oranda faydalanmak için hem işletim sistemi, hem de uygulamalar gruplar arası veri trafiğini en aza indirgeyecek ve grup içi erişimi arttıracak, hızlandıracak şekilde tasarlanmalıdır. Eğer işletim sistemi ve uygulama doğru olarak tasarlanırsa, NUMA mimarisi işlemci sayısının artışına orantılı olarak esneklik sağlayacaktır. Windows Server 2003 ve SQL Server 2005 mimari gelişmeleri bünyelerinde birleştirerek işlemci ve bellekten en yüksek oranda faydalanmamızı sağlayacak şekilde tasarlanmışlardır.

Hyper-Threading Desteği
SQL Server 2005 aynı zamanda Microsoft'un Windows Server 2003'e eklediği hyper-threading desteği ile hyper-threading'in sunduğu avantajlardan da faydalanabilmektedir. Hyper-Threading, Intel tarafından geliştirilen ve sistem üzerindeki her bir fiziksel işlemci için iki mantıksal işlemci oluşturan bir teknolojidir. Her bir mantıksal işlemci eşzamanlı olarak farklı thread'leri işleyebilme yeteneğine sahiptir. Hyper-Threading'in asıl hedefi multithreading uygulanmış uygulamalarda veya aynı makina üzerinde çalışan birden çok sayıda uygulamaya daha iyi kaynak ayrımının daha verimli yapılmasını sağlamaktır.

SQL Server 2005, Windows Server 2003'ün Hyper-Threading desteğinden iki şekilde faydalanmaktadır. İlk olarak, Windows 2000'in aksine, Windows Server 2003 fiziksel işlemcileri sadece lisanslama amacıyla saymaktadır. Boylece hyper-threading kullanan bir işlemci, iki yerine bir işlemci olarak sayılıyor. Windows Server 2003, hyper-threading kullanan sistemlere yönelik gelişmiş thread scheduling desteği sunmaktadır. Bu değişiklikler SQL Server gibi multithread uygulamalarda çok daha iyi performans sonuçları alabilmemizi sağlıyor.

SQL Server Engine
İlk bölümde SQL Server 2005 ile gelen donanım desteğine biraz daha geniş açıdan baktık. Bu bölümde ise SQL Server veritabanı motorundaki yeniliklere daha detaylı bakıyor olacağız.

.NET Framework Entegrasyonu
SQL Server 2005 ile birlikte gelen en önemli yeniliklerin başında Microsoft .NET Framework entegrasyonu ve sağladığı avantajlar geliyor diyebiliriz. .NET Framework entegrasyonu SQL Server 2005'in esnekliğini stored procedure, user-defined function, trigger, aggregate ve user-defined type'ların, visual basic, c# veya j# gibi bir .NET dili ile geliştirilmesini mümkün kılarak arttırmaktadır. Sonraki bölümlerde bu entegasyonun çok daha derin ve detaylı olduğunu göreceğiz. 

Geliştirilmiş Çoklu Instance Desteği
SQL Server 2005 Enterprise Edition'da bulunan bir diğer yenilik ise aynı anda çalıştırılabilecek instance sayısının 50'ye kadar arttırılabiliyor olması. SQL Server 2000'de eşzamanlı instance desteği 16 ile sınırlıydı.

Yeni Veri Türleri
SQL Server 2005 pek çok yeni veri türünü desteklemektedir. .NET Framework entegrasyonu kullanıcı tanımlı türlerin geliştirilmesini sağlarken, varbinary(max) ve XML türünde yeni veri türlerini de desteklemektedir. Varbinary(max) beri türü SQL Server'da LOB'ların kullanımı için yeni bir metod sunmaktadır. Image ve Text veri türlerinin aksine varbinary(max) veri türü bir değişken olarak kullanılabilir ve daha kolay ve tutarlı işlem yapmak için daha küçük veri türleri gibi işlem yapılabilir.  

Yeni XML veri türü varbinary(max) veri türüne dayanmaktadır ve XML dokumanlarını veritabanında saklamamıza imkan verir. XML veri türü, XML formatındaki verilerin hızlı ve kolayca saklanması ve kullanılmasını sağlamak amacıyla geliştirilmiş ve XML dokumanlarının schema ile doğrulanmasına olanak vermektedir. SQL Server 2005'te yer alan XML ve diğer veri türlerini ileriki bölümlerde ele alıyor olacağız.

Database Snapshot'ları ve Mirroring
Database Mirroring veritabanı seviyesinde sunulan ve sürekliliği arttırmak, sağlamak için SQL Server 2005 tarafından desteklenen tüm donanımlar ile uyumlu çalışan bir özelliktir. Database Mirroring için primary server ve mirrored server arasında bir paylaşıma gereksinim ve herhangi bir uzaklık limiti bulunmamaktadır. Database Mirroring, transaction log'larını primary ve mirrored sunucu arasında ileterek çalışmaktadır, bu yapısından dolayı Database Mirroring özelliğini gerçek-zamanlı bir log-shipping uygulaması olarak kabul edebiliriz. Database Mirroring tek bir veritabanı ile kullanılabileceği gibi, çok sayıda veritabanı ile de kullanılabilir.  

Database Snapshot'ları veritabanının istenilen bir anına yönelik read-only fotoğrafını verirler. Database Snapshot'ları raporlama amaçlı bir veritabanının istenilen zamana ait bir kopyasını oluşturmak veya istenilen zamanda roll-back yapmak için belirli bir anda yedek almak amaçlı kullanılabilirler. Database Snapshot'ları, Database Mirroring ile bir arada kullanılarak mirrored server üzerindeki verilere dayanan bir reporting server oluşturmak için kullanabilmekteyiz. Mirrored sunucu üzerindeki veri, bu sunucunun her zaman recovery mode'da olmasından dolayı doğrudan erişşilebilir değildir ancak Mirrored database üzerinde bir Database Snapshot yaratarak bu verileri (read-only olarak) raporlama amacıyla kullanabiliriz.

Native HTTP Desteği
SQL Server 2005 ile birlikte gelen en önemli yeniliklerden biri de SQL Server Engine'e eklenen native HTTP desteğidir. SQL Server'ın gelen HTTP taleplerini işleyebilmesi, SQL Server'a stored procedure'leri ve SQL ifadelerini SOAP protokolünü kullanarak çalıştırabilmesi anlamına geliyor. Bu aynı zamanda SQL Server 2005'in, IIS olmadan web servis taleplerini karşılayabilmesi anlamına geliyor. SQL Server aynı zamanda endpointler için web servislerini WSDL olarak yayınlama yeteneğine sahiptir. SQL Server'ın HTTP özelliği hem Windows hem de SQL Server authentication'ı, SSL ile birlikte desteklemektedir. Bu özelliğin artılarını özellikle uygulama geliştiriciler için daha da arttırmak için stored procedure'ler sonuç kümelerini ADO.NET dataset'leri olarak döndürebilme imkanını sunmaktadır. 

Sunucu Olayları ve DDL Trigger'ları
SQL Server 2005 ile birlikte gelen Sunucu Olay ve Trigger özellikleri, sistemdeki değişikliklere karşı nasıl karşılık verileceğini programatik olarak belirlememizi mümkün kılmaktadır. Bu iki özellikte benzer işler yapıyor gibi görünse de, sunucu tarafında işlemleri farklı şekillerde gerçekleştiriyorlar. Standart DML trigger'larında olduğu gibi, DDL trigger'ları da stored procedure'leri çalıştıran senkronize olaylardır.  

Sunucu olayları ise asenkrondur. Sunucu olay modelinde sunucu SQL Server Broker Service'e bir olay gönderir. Olayla ilgilenen bu olaya sonradan bağımsız olarak erişebilir. Olay XML formatında kaydedilir. Bir olayı geri alma imkanı yoktur ancak kimsenin o olaya erişmemesi durumunda ignore edilir. Olay gerçekleştiğinde sizi olayın veya opsiyonel olarak bir kodun çalıştırıldığından haberdar edebilecek sistem olayı tetiklenir. Aşağıdaki kod bir event notification oluşturulurken kullanılacak söz dizimini örneklemektedir:

CREATE EVENT NOTIFICATION MyDDLEvents

ON SERVER FOR DDL_STATEMENTS TO SERVICE MyDDL_log 

Bu kod yeni bir event oluşturup "MyDDLEvents" şeklinde isimlendiriyor daha sonra oluşturduğu olayı DDL statement ile ilişkilendiriyor. TO SERVICE ifadesi MYDLL_log adlı SQL Server Broker Servisinin bu olayın alıcısı olduğunu belirtiyor. SQL Server Broker Servisini ilerleyen bölümlerde detaylı olarak ele alıyor olacağız.

Veritabanı Veri Dosyasındaki Yenilikler
SQL Server 2005, ALTER DATABASE komutu aracılığıyla veritabanının log ve veri dosyasının yerlerini değiştirme imkanı sunuyor. SQL Server 2000 tempdb veritabanı için dosyalarını taşımaya izin veriyordu ancak diğer veritabanları için izin verilmiyordu. Tahmin edebileceğiniz üzere SQL Server 2005 dosyaların taşınmasını sadece offline bir işlem olarak mümkün kılıyor. Aşağıdaki örnek, veritabanı dosyalarının yerini değiştirmeyi sağlayan ALTER DATABASE komutunun sözdizimini göstermektedir:

ALTER DATABASE <database_name>

  MODIFY FILE(name=<'veri_dosyasinin_adi'>, filename=<'yeni_veritabani_dosyasi_yolu'>)

Data Partitioning
SQL Server 2005'te yer alan bir diğer özellikse veri bölümlendirmedir. Veri bölümlendirme tablo veya index gibi tek bir veritabanı nesnesini birden çok bölüme ayırma imkanı vermektedir. Veri bölümlendirme özelliğinin öncelikli hedefi, çok büyük tablo ve indexleri yönetmeyi daha kolay hale getirmektir. Bölümlendirme, uygulamalar tarafından algılanamamaktadır. Uygulama çalışırken sadece tek bir tablo görmekte ve SQL Server tarafından yönetilen alt bölümlerden asla haberdar olmamaktadır. Bölümler, veritabanının sürekliliğini etkilemeden oluşturulabilir ve silinebilirler. Ek olarak partitioning verileri, bir uygulama tarafından kullanılırken dahi uygulamayı etkilemeden bölümlendirmenize olanak tanımaktadır. Şekil 1.1 bölümlendirmenin yapısını basitçe örneklemektedir. 


Şekil 1.1 :: Veri Bölümlendirme 

SQL Server 2005 tablolar, indexler ve indexlenmiş view'lar için veri bölümlendirmeyi desteklemektedir. Satır, veri bölümlendirmenin en temel elemanıdır. Bölümler, satırların alanlarında bulunan değerlere göre oluşturulabilir. Bu işlem, horizontal partitioning olarak adlandırılmaktadır. Örneğin bir tablo, her yıl için bir bölüm olacak şekilde tarihe göre bölümlendirilebilir.

Veri bölümlendirme çok büyük veritabanlarında (Very Large Databases - VLDBs) bazı önemli avantajlar sağlamaktadır. Veri bölümlendirme, verilerin yönetimini kolaylaştırmaktadır. Örneğin tarihe göre bölümlendirilmiş büyük bir tabloda önceki yılları hariç tutarak sadece bu yılın yedeğini almak isteyebilirsiniz. Bir diğer avantaj ise çok işlemcili sistemlerde daha yüksek performans için hangi bölümün, hangi işlemci tarafından işleneceğini belirtebilirsiniz.

Veri bölümlendirmeyi gerçekleştirmek için atmamız gereken iki basit adım vardır. İlk olarak hangi nesneyi, ne şekilde bölümlendireceğimizi belirlememiz gerekir. İkinci olarak her bir bölüm için fiziksel bir depolama lokasyonu belirtmemiz gerekir. Farklı bölümler, tek bir dosya grubuna atanabilir veya farklı dosya grupları tanımlanabilir.

Aşağıdaki örnek basit bir partition function oluşturmayı ve tabloyu bir Range Partition kullanarak bölümlendirmek üzere planlamayı örneklemektedir:

CREATE PARTITION FUNCTION MyPF

(int) AS RANGE LEFT FOR VALUES (50, 100)

GO

CREATE PARTITION SCHEME MyPS

 AS PARTITION MyPF TO (FileGroup1)

GO

CREATE TABLE MyTable (col1 int, col2 varchar(50))

  ON MyPS(col1)

GO

İlk satır MyPF adlı bir partition oluşturuyor. int, bölümlendirmenin int türünde tanımlanmış bir sütuna göre yapılacağını belirtiyor. RANGE keyword'u Range bölümlendirmenin uygulanacağını belirtiyor. LEFT keyword'u kesin olmayan değerlerin hangi partition'da saklanacağını belirtiyor. VALUES ifadesi bölümler için sınır değerleri belirtmek için kullanılıyor. Bu değerlerin sınır değerleri olduğunu ve bölümlendirilmediklerini unutmamakta fayda var. Bu komut 3 bölümün oluşması ile sonuçlanacaktır. İlk bölüm negatif değerleri ve 50'ye kadar olan pozitif değerleri, ikinci bölüm 51 ile 100 arasındaki değerleri, üçüncü bölüm ise 101'den büyük değerleri içerecektir.

İkinci satır, MyPS adlı bir bölüm şeması oluşturuyor. AS PARTITION ifadesi ise bu şema tarafından kullanılacak olan bölüm fonksiyonunu belirtmekte kullanılıyor. Bu örnek MyPF adlı bölüm fonksiyonunu kullanıyor. TO ifadesi bölümlerin kaydedileceği dosya grubunu veya gruplarını belirtmekte kullanılıyor. Bu örnek FileGroup1 adlı tek bir dosya grubunu kullanıyor.

Daha sonra, bölüm şemasının bölümlendirilecek tablo ile ilişkilendirilmeis gerekiyor. Bu örnek tablonun bölümlendirilmesine olanak tanıyan extended CREATE TABLE sözdizimini göstermektedir. CREATE TABL ifadesinin ilk bölümü aynı. Tablo adını (bu örnekte MyTable) ve sütunları belirtiyor. Örnek tablomuz col1 ve col2 adlı iki sütun içeriyor. Yeni gelen ON keywordu kullanılacak bölüm şemasını belirtmekte kullanılıyor. Bu örnekte az önce oluşturduğumuz MyPS şeması kullanılıyor. Bölümlendirme'de kullanılacak verileri içeren sütun parantez içinde yazılıyor. Bu örnekte kullandığımız sütun: col1. col1 sütununun veri türü int türünde. Seçilen sütunun veri türü, bölümlendirme fonksiyonunda belirtilen veri türü ile aynı olmalıdır.

Bölümlendirmede kullanılacak sütunların sahip olabileceği veri türleri konusunda bazı kısıtlamalar söz konusudur. Bu kısıtlamalar, index tanımlarken söz konusu kısıtlamalara oldukça benzemektedir. Text, ntext ve image veri türleri kullanılamıyor. Aynı şekilde timestamp sütunlarda partitioning key olarak belirtilemiyor. Sadece native T-SQL veri türleri partitioning key tanımlamalarında kullanılabilmektedir. Her bir tablo için 1000 bölüm üst sınırı ve tüm bölümlerin tek bir node üzerinde bulunması zorunluluğu mevcuttur.

Index Alanındaki Yenilikler
SQL Server 2005, indexlerde de pek çok yenilik getiriyor. İlk olarak, artık bir clustered index'in rebuild edilmesi, tüm non-clustered index'lerin rebuild edilmesini gerektirmiyor. SQL Server 2000'de, bir clustered index'i rebuild ettiğimiz zaman, tüm ilgili non-clustered index'ler de rebuild ediliyordu. SQL Server 2005, non-clustered index'lerin hasar görmesini engellediği için bu indexlerin rebuild edilmesi gerekmiyor.

İkinci olarak, yeni gelen "included columns" özelliği, non-key sütunların da bir index'e eklenmesine olanak tanıyor. Bu yeni özellik daha çok sorgunun index tarafından kapsanmasına ve böylece SQL Server Engine'in sorguyu tamamlamak için tabloya gitmesi ihtiyacını ortadan kaldırarak sorgu performansının ve hızının artmasına neden oluyor. Bu özelliğin en iyi yanlarından biride, index'e dahil edilen ve anahtarın bir bölümü olmayan sütunlar, hala 900 byte olan index üst sınırına dahil edilmiyor olması.

SQL Server 2005 ile gelen bir diğer yenilikse index'lerin disable edilebiliyor olması. Bir index'in disable edilmesi, bu index'in kullanılmasını ve SQL Server Engine tarafından işlemlerde dikkate alınmasını engelliyor. Bir index disable edildiğinde, SQL Server index için rezerve edilen alanı serbest bırakır ancak index'in metadata'sını saklar. Disable edilen index'in yeniden aktif duruma getirilebilmesi için, ALTER INDEX komutu ile rebuild edilmesi gerekir.

Online Index İşlemleri

SQL Server'ın önceki sürümleri, index'e rebuild sürecindeyken erişmeye imkan vermiyordu. Tablo'nun yeniden update edilebilir olması için rebuild sürecinin tamamlanmasını beklememiz gerekiyordu. SQL Server 2005'in online index işlemleri özelliği, uygulamaların index rebuild sürecindeyken, tablo üzerinde insert, update ve delete gibi işlemler yaparak index'e erişebilmelerine olanak tanıyor. Bu konuyu da ilerleyen bölümlerde detaylı olarak ele alıyor olacağız.

System Catalog ve Metadata Konularındaki Yenilikler
SQL Server 2000 ve daha önceki sürümlerde, sistem kataloğu ve metadata, master veritabanında her veritabanının bir parçası olarak saklanıyordu. SQL Server 2005 ile birlikte metadata sistem tarafından sys adında bir nesne olarak kaydedilen resource veritabanında saklanmaya başladı. SQL Server 2005 ile artık birlikte sistem veritabanlarına doğrudan erişemiyoruz. Bu değişiklik daha yüksek güvenlik ve daha hızlı sistem güncellemeleri sağlamak amacıyla getirildi. Catalog metadata'sının güvenliği row-level filtreler ile sağlanmıştır. SQL Server 2005'te Güvenlik alanındaki yenilik ve geliştirmeleri ilerleyen bölümlerde detaylı olarak ele alıyor olacağız.  

Yeni metadata, Microsoft tarafından dokumante edilmemiş olan ve kullanılmaması konusunda uyarıda bulunduğu sistem tablolarını kullanmadığınız sürece tamamen backward compatible'dır. SQL Server 2005'te sistem metadatası, çeşitli catalog view'ları tarafından sunulmaktadır. Catalog view'ları, ANSI INFORMATION_SCHEMA view'ları, property fonksiyonları ve built-in fonksiyonlar ile birlikte, sistem veritabanı ve tablolarına doğrudan erişim ihtiyacını tamamen ortadan kaldırmaktadır. Toplamda 250nin üzerinde catalog view'ı bulunmaktadır ve bu view'lar her kullanıcı veritabanının sys şemasından görüntülenebilir. Yeni sistem view'larını Microsoft SQL Server Manager Studio'da, Object Browser'ı açarak, ilgili veritabanına -> views -> system views node'una giderek bulabilirsiniz. Aynı zamanda yeni bir sorgu ekranı açarak aşağıdaki kod ile de görüntüleyebilirsiniz.

select * from sys.system_views

Multiple Active Results Sets (MARS)

SQL Server'ın önceki sürümleri her bir bağlantıda sadece bir sonuç kümesini destekliyordu. SQL server 2005 tek bir bağlantıda birden çok sonuç kümesini destekliyor. Bu özellik, veritabanına tek bir bağlantı açarak bir sorgu çalıştırma, sonuç kümesi üzerinde çalışma, sonrasında bir başka sorgu daha çalıştırarak sonuç kümesi üzerinde çalışmaya devam edebilme imkanı sağlıyor. Bunun uygulamalar açısından sunduğu avantaj ise, uygulamanın oluşan sonuç kümelerinin tümüne erişebiliyor ve işlem yapabiliyor olmasıdır.

Bulk Data Loading
SQL Server 2005 bulk data loading özelliğinde, önemli bir performans artışı ile birlikte pek çok yenilik sunuyor. Bulk Data Loading özelliği artık XML tabanlı bir dosya kullanarak Bulk Copy programlarının format dosyasının sağladığı tüm özellikleri sunuyor. Ek olarak BCP'nin XML formatında işlem yapması, dosyaların daha kolay okunabilmesini ve anlaşılabilmesini sağlıyor. Önceki uygulamalar ile uyumluluğu sağlamak için eski BCP formatı halen desteklenmektedir. 

SQL Server 2005'in bulk data loading prosesi artık hatalı satırların kaydını tutma özelliğini sağlamaktadır. Bu, yükleme işleminin hata ile karşılaşılması durumunda da devam edebilmesini sağlamaktadır. Hatalı olarak formatlanmış kayıtlar bir hata kayıt dosyasına kaydedilmektedir. Sınırlara uymayan satırlar ise hata durumuna bağlı olarak spesifik bir hata tablosuna yönlendirilirler.

Full-Text Search
SQL Server 2005'te Full-Text Search özelliği de geliştirilmiştir. SQL Server'ın Full-Text Search özelliği ile birlikte çalışabilmemiz için SQL Server 2005'e pek çok yeni DDL ifadesi eklenmiştir. Yeni DDL ifadelerine, CREATE FULLTEXT CATALOG ve CREATE FULLTEXT INDEX ifadelerini örnek olarak verebiliriz.

SQL Server 2005'te Full-Text Search özelliğinde gerçekleştirilen yenilikler, Full-Text Search kataloglarının ve indexlerin yedeklenebilmesi ve geri yüklenebilmesini, Full-text katalogların ilgili veritabanlarına attach ve detach edilebilmesini ve thesaurus kullanarak eş anlamlı kelimelerle yapılan aramaları bulma desteğini kapsamaktadır.

T-SQL Yenilikleri
SQL Server 2005 ile birlikte T-SQL'de de pek çok yenilik karşımıza çıkıyor. Bu yenilikler Common Table Expressions'ı, geliştirilmiş TOP ve WAITFOR ifadelerini, DML ifadeleri için OUTPUT ifadesini içermektedir. Bu yenilikleri ileriki aşamalarda SQL Server 2005'te T-SQL Alanındaki Yenilikler başlıklı bölümde detaylı olarak ele alıyor olacağız. 

SQL Server 2005’te Güvenlik Alanındaki Yenilikler
Güvenlik Microsoft açısından her zaman en öncelikli konular arasında yer almıştır. Microsoft'un Trustworthy Computing vizyonunun hedefi, tüm Microsoft uygulamalarının daha güvenli ve güvenilir olmasını sağlamaktır. Trustworthy Computing vizyonunun bir parçası olarak SQL Server 2005, güvenlik alanında çok önemli yenilik ve iyileştirmelerle birlikte gelmektedir. SQL Server 2005'in geliştirme grubu ürünün tasarımdan, dağıtıma, çok daha sağlam ve güvenli olmasına odaklanarak çalıştı. SQL Server 2005'in güvenlik tasarımında Microsoft bir kaç temel güvenlik kuralına bağlı kaldı. İlk olarak kurulum sırasında tüm standart ayarları sistemi en güvenli kılacak şekilde belirledi. Kullanıcılar daha az güvenli olan diğer seçenekleri ihtiyaçları doğrultusunda kullanabiliyor olsalar da, standart ayarlar, sistemin en yüksek güvenlik seviyesini yakalamasına odaklanmıştır. İkinci olarak sistem tasarımı en az yetki gerektirecek şekilde yapıldı. Son olarak Microsoft potansiyel risk alanını sadece gereksinim duyulan bileşenleri kurarak minimuma indirgemeyi hedeflemiştir. 

SQL Server 2005'te yer alan tüm güvenlik özellikleri, Microsoft'un 2002 yılının başlarında geliştirdiği güvenlik tekniklerinden etkilenmiştir. Bu bölümde ele alacağımız güvenlik özelliklerinden başlıcaları; kullanıcıların şemalardan ayrılmasını, yeni stored procedure çalıştırma konseptini, daha detaylı yetki kontrolünü, yeni password policy sistemini, row-level security'de yer alan yenilikleri ve kataloglar için geliştirilmiş güvenlik tekniklerini içermektedir.

Kullanıcı - Şema Ayrımı
SQL Server 2005'te gelen en önemli güvenlik değişikliklerin başında, kullanıcı-şema ayrımı gelmektedir. Bir kullanıcı veya daha doğru söylemek gerekirse bir principal, veritabanı nesnelerinin kendisine karşı korunduğu bir varlıktır. Principal bir windows kullanıcısı, SQL Server kullanıcısı, bir rol veya bir application role olabilir. SQL Server 2000 ile veritabanı nesneleri doğrudan kullanıcılara aitti ve bu kullanıcılar sys_users sistem tablosunda kayıtlı tutulmaktaydı. SQL Server 2005'te bu yapı tümüyle değiştirildi ve veritabanı nesnelerinin sahipliği şemalara verildi. Kullanıcılar ise artık doğrudan veritabanı nesnelerinin sahibi durumda değil, şemaların sahibi durumunda oluyorlar. SQL Server 2005 ile birlikte kullanıcılar ve diğer güvenlik principal'ları yeni sys.database_principals adlı view ile görüntülenebilmektedir. SQL Server 2005'in şema listesine ise sys.schemas view'ı ile erişilebilir.  

Şemayı çeşitli nesneler için bir container olarak düşünebiliriz. Şema, SQL Server tarafından kullanılan dört bölümlü isimlendirme yapısının üçüncü bölümü tarafından tanımlanmaktadır. Aşağıdaki örnek SQL Server 2005'in isimlendirme söz dizimini örneklemektedir.

sunucu_adi.veritabani_adi.schema_adi.nesne_adi

SQL Server'ın önceki tüm sürümlerinde schema ismi ve owner'ın ismi genellikle aynı olurdu. SQL Server 2005 ile birlikte owner, schema'dan ayrılmış durumdadır. SQL Server 2000 ve önceki sürümler nesne isimlerini çözümlerken SQL Server ilk olarak veritabani_adi.kullanici_adi.nesne_adi'na bakıyor ve çözümleme başarısız oluyordu, daha sonra ise veritabani_adi.nesne.adi'na bakıyordu.

SQL Server 2005'te kullanıcı ve şemanın ayrılmasının temel nedeni, bir kullanıcıya ait çok sayıda nesnenin ownership'liğini değiştirme ihtiyacıydı. Ek olarak, bir veritabanı nesnesinin isminin değişmesi aynı zamanda bir isim değişikliğine neden oluyordu. Örneğin MyDB veritabanında yer alan Tablo1'in ownerı KullanıcıA'dan KullanıcıB olarak değiştirildiğinde tablonun ismi MyDB.KullanıcıA.Tablo1'den MyDB.KullanıcıB.Tablo1'e dönüşmektedir. Bu problemi önlemek için çoğu kurum tüm veritabanı nesnelerinin dbo tarafından sahiplenilmesi şeklinde bir standart uygulama kullanmaya başladı.

SQL Server 2005'in veritabanı ownership zincirini şekil 1.2'de görebilirsiniz.

Şekil 1.2 :: SQL Server 2005, Veritabanı Ownership Zinciri

SQL Server 2005 ile birlikte veritabanı nesneleri şemalar içinde bulundurulmaya ve şemalar kullanıcılar tarafından own edilmeye başladı. Bu yeni soyutlama modeli veritabanı nesnelerinin sahibinin belirlenmesi ve değiştirilmesini kolaylaştırarak daha kolay yönetilebilir bir yapı oluşmasını sağladı. SQL Server 2005'te veritabanında herhangi bir nesnenin sahibi durumundaki bir kullanıcının silinmesi sadece DBA'in ilgili tüm nesnenin/nesnelerin ownerını değiştirmesi değil, sadece bu nesneleri içeren şemanın sahibinin değiştirilmesi anlamına geliyor. Bu DBA'in yapması gereken işlem ve müdahale edilmesi gereken nesne sayısını azaltarak, ilgili şemanın güncellenmesinden sonra ilgili kullanıcı accountunun drop edilerek işlerin çok daha hızlı tamamlanabilmesini sağlıyor. Ek olarak nesnenin / nesnelerin ismi değişmemiş oluyor.

Tabi bu değişikliklerle birlikte SQL Server'ın veritabanı nesnelerinin isimlerini çözümlemede kullandığı yöntem de değişiyor. Artık her kullanıcı için kullanıcı il ilişkilendirilmiş varsayılan bir şema mevcuttur ve SQL Server 2005 ilk olarak kullanıcının varsayılan şemasına bakar. Eğer başarısız olursa SQL Server nesneye dbo'nun şema ismine bakarak erişmeye çalışır. Örneğin KullanıcıA varsayılan şema olarak SchemaA ile ilişkilendirilmişse ve bu kullanıcı Tablo1 üzerinde bir sorgu çalıştırırsa, SQL Server ilk olarak SchemaA.Tablo1'i kullanarak isim çözümleme yapmaya çalışacak başarısız olursa dbo.Tablo1'e bakacaktır.

SQL Server 2000 veritabanlarının birden çok kullanıcı ve rol içerebildiği gibi SQL Server 2005 veritabanları da birden çok şema içerebilir. Her şema kendisine özgü bir kullanıcı veya rol olan principal'a sahiptir. İsim çözümleme işlemleri için her kullanıcı varsayılan bir şemaya sahiptir, veritabanı nesneleri ise şema içinde yer alır. Şema içinde yeni veritabanı nesneleri oluşturmak için ilgili nesne için CREATE, ilgili şema üzerinde ise ALTER veya CONTROL yetkileri olması gerekir. Ownership zinciri hala şemalara değil gerçek ownera dayanmaktadır.

SQL Server 2005 kullanıcı ve şema ayrımını desteklemek için USER, ROL ve SCHEMA nesneleri için CREATE, DROP, ALTER ifadelerinde pek çok DDL değişikliği ile gelmektedir.

Aşağıdaki kod, bir veritaanı şemasının nasıl oluşturulduğunu ve assign edildiğini örneklemektedir.

/* Yeni bir login oluştur */

CREATE LOGIN UserA WITH PASSWORD = 'ABC123#$'

GO

/* Oluşturulan login için bir kullanıcı oluştur. Şema varolmak zorunda değildir */

CREATE USER UserA FOR LOGIN UserA

  WITH DEFAULT_SCHEMA = MySchema

GO

/* Şemayı oluştur ve ownerı ile ilişkilendir */

CREATE SCHEMA MySchema AUTHORIZATION UserA

GO

/* Yeni şemanın içinde bir tablo oluştur */

CREATE TABLE MySchema.Table1 (col1 char (20))

GO

Örneğin ilk satırı UserA adlı yeni bir login oluşturuyor ve bir parola belirliyor. İkinci satır oluşturulan login için yeni bir kullanıcı oluşturuyor ve varsayılan şemayı belirtiyor. Bu aşamada belirtilen şemanın varolması gerekmemektedir. Yeni kullanıcı oluştururken varsayılan şemayı belirtmezseniz dbo ile aynı varsayılan şema kullanılacaktır. Sonraki adımda CREATE SCHEMA ifadesi ile MySchema adlı şema oluşturuluyor. AUTHORIZATION ifadesi şemanın ownerının UserA olduğunu belirtiyor ve şema içinde Table1 adlı bir tablo oluşturuluyor.

Stored Procedure Execution Context
Microsoft Stored Procedure Execution Context adlı bir özelliği deklare etmiş olsa da, bu özellik stored procedure'ler dışındaki modüller için de (fonksiyonlar veya assemblyler) geçerlidir. Bir modül için execution context belirtmek modülün içeridği tüm ifadelerin belirtilen execution context'e bağlı olarak yetki denetiminden geçirilmesine neden olacaktır. Diğer bir deyişle, bir modül için execution context'in belirtilmesi, modülün kapsadığı tüm ifadelerin, modülü çalıştıran kullanıcı yerine belirtilen kullanıcının ownershipliğinde çalıştırılması anlamına geliyor (İki kelime ile özetlemek gerekirse: identity impersonation diyebiliriz). Şekil 1.3 SQL Server 2005'in ownership mimarisini göstermektedir.

Şekil 1.4 :: SQL Server 2005 Ownership Mimarisi

UserA'nın dbo.Proc1'i çalıştırabilmesi için UserA'nın bu nesne üzerinde execute yetkisinin olması gerekiyor. Ancak dbo.Proc1, dbo.Table1'e eriştiğinde herhangi bir yetki denetimi yapılmıyor, çünkü dbo her iki nesneninde ownerı durumunda. Sonraki senaryoda, UsrA'nın UserB.Proc2'yi çalıştırabilmesi için, bu nesne üzerinde yetkiye gereksinimi var. Sonrasında UserB.Proc2, UserC.Table2 nesnesine erişmek istediğinde, UserA için SELECT yetkisi denetlenmek durumunda. Bu senaryoda, UserB.Proc2 ve UserC.Table2 farklı ownerlara sahip ve ownership zinciri kırılıyor.

SQL Server 2005 bu senaryoyu şekil 1.4'te görüldüğü üzere oldukça kolaylaştırıyor. Bu senaryoda UserA, UserB.Proc2'yi çalıştırmak istiyor ve SQL Serer UserA'nın UserB.Proc1 için Execute yetkisinin olup olmadığını denetliyor. Eğer UserB.Proc1 nesnesi, UserZ'nin contextinde çalıştırılacak şekilde oluşturulursa, UserB.Proc1 stored procedure'u UserC.Table1 nesnesine erişmeye çalıştığında SQL Server sadece işlemi gerçekleştiriyor olarak kabul edilecek kullanıcının, yani bu örnek için UserZ'nin yetkilerini denetleyecektir. İşlemi başlatan kullanıcı olan UserA için SELECT yetkisi aranmayacaktır.

Şekil 1.4 :: SQL Server 2005 execution context

Aşağıdaki kod MyProc1 adlı bir stored procedure'ın execution context'ini nasıl değiştirebileceğimizi örneklemektedir.

ALTER PROC MySchema.Proc1 WITH EXECUTE AS USER UserB

Bu ifade yeni WITH EXECUTE ifadesini kullanmaktadır. Burada MySchema içinde yer alan Proc1 adlı stored procedure UserB'nin context'inde çalıştırılmak üzere güncelleniyor. Bu işlemde bir kullanıcı adı belirtmemiz gerekiyor, bir rol ismi kullanamıyoruz. Execution Context'te yapılan değişiklikler sys.sql_modules view'ı aracılığıyla görüntülenebilmektedir.

Daha Detaylı Yetki Yönetimi
SQL Server 2005 önceki sürümlere göre çok daha detaylı yetkilendirme yapmamıza imkan veriyor. SQL Server 2005 ile birlikte pek çok farklı seviyede, farklı yetkilendirmeler yapılabiliyor. Yetkilendirmelerin uygulanabileceği seviyeler: sunucu, veritabanı, şema, nesne ve principal şeklindedir. SQL Server 2005'in gelişmiş yetkilendirme sisteminin arkasındaki fikir, DBA'in kime hangi yetkilerin verildiğini tam olarak kontrol edebilmesini ve mümkün olan en az yetki ile çalışmasını sağlamaktır. Yeni sistem, SQL Server'ın mevcut rollerini ortadan kaldırmıyor. SQL Server 2000'de yer alan tüm roller sorunsuz olarak yeni yetkilendirme sistemi ile bir arada çalışmayı sürdürüyor.

GRANT, DENY ve REVOKE gibi temel yetkilendirme ifadeleri geçerliliklerini halen korumakta. SQL Server 2005'te farklılık gösteren bir nokta, aynı yetkinin farklı seviyelerde uygulanabilmesi. Örneğin, eğer veritabanı seviyesinde bir yetkilendirme yapıyorsanız, yaptığınız yetkilendirme veritabanındaki tüm nesneleri etkileyecektir. Eğer yetkilendirmeyi şema seviyesinde yaparsanız, yetkilendirme şemanın içerdiği tüm nesneler için uygulanacaktır. Tablo 1.1 SQL Server 2005'te yer alan bazı önemli yetkilendirmeleri listelemektedir. Sunucu yetkilendirmeleri sys.server_permissions view'ı, veritabanı yetkilendirmeleri ise sys.database_permissions view'ı aracılığıyla görüntülenebilir.

Password Policy Sistemi
SQL Server 2005'te yer alan bir diğer önemli güvenlik özelliği ise password policy'ler. Yeni policy enforcement özelliği yerel Windows password policy'lerini izleyerek, kurumsal ölçekte sadece Windows Server sistemlerde değil, SQL Server sistemlerde de tutarlı bir security policy oluşturmanızı mümkün kılar. SQL Serer 2005 artık parola kompleksliği, geçerlilik süresi ve account lockout policy'lerini destekliyor. Bu özelliklerden, Windows 2000 serverda desteklenen parola kompleksliği dışında tamamı Windows Server 2003 tarafından desteklenmektedir. Tüm bu güvenlik önlemleri, varsayılan kurulumda aktif haldedir ancak kurulum sonrasında değiştirilebilmektedir. SQL Server 2005 password policy'leri sys.sql_logins katalog view'ında saklar. 

Katalog Güvenliği
Bu bölümde ele alacağımız son güvenlik yeniliği, catalog security özelliği. Farklı veritabanlarında ve master veritabanında saklanan SQL Server 2000 tarafından kullanılan sistem tabloları, SQL Server 2005'te catalog view'larında toplanmıştır. Bu view'lar tarafından sunulan metadata varsayılan olarak korunma altına alınmıştır ve çok kısıtlı public yetki söz konusudur. SQL Server 2005'in catalog view'ları, içerdikleri verilere sadece nesnelerin ownerı olmanız veya gerekli yetkilere sahip olmanız durumunda erişebilmenizi sağlayan, row-level security uygulamaktadır. Doğal olarak sa kullancısı bu durum için bir exception'dır. Sa accountu halen sunucu üzerindeki her nesneye tam erişim yetkisine sahip durumdadır.

Bir kullanıcı veya rolün metadata'ya erişmesini sağlamak için DBA'in VIEW DEFINITION yetkisini kullanması gerekir. VIEW DEFINITION yetkisi bir kullanıcıya, owner'ı olmadığı veya erişim hakkı olmayan bir nesne üzerinde, nesnenin metadata'sına erişme imkanı vermek amacıyla kullanılır. VIEW DEFINITION yetkisi sunucu, veritabanı, şema veya nesne seviyesinde uygulanabilir.

Bir sonraki bölümde SQL Server 2005’te veritabanı yönetimi ve programlaması alanlarındaki yenilikleri ele alıyor olacağız.

Kullanılan Kaynaklar;
         SQL Server 2005 Books Online
         SQL Server 2005 MSDN Site

Kadir Sümerkent
kadir@sumerkent.com
http://www.sumerkent.com