Raid Level ve SQL SERVER

RAID (redundant array of independent disks) levels olarak bilinen bu yapı farklı seviyelerden oluşur.Bunlar: RAID Level 1, RAID Level 2, RAID Level 3, RAID LEVEL 4, RAID Level 5 ve RAID Level 10'dur.

RAID LEVEL 0

Bu seviye disk striping olarak da bilinmektedir. Datalar bloklar haline bölünerek farklı fiziksel diskler üzerinde saklanırlar. Birden fazla fiziksel disk kullanımlarında RAID Level 0 iyi bir kullanım sunmaktadır. Bundan dolayı yüksek okuma ve yazma performansı sunar. Her ne kadar bu konuda organizasyonlara artı sağlasada oluşacak hata ve kusurlar söz konusu olduğu zaman bunları absorbe etme konusunda bu kadar başarılı bir yöntem olamamaktadır. Genellikle kurumlar SQL Server'ın data file'ları RAID LEVEL 0 düzeyinde saklama eğilimindedirler.

RAID LEVEL 1 

Raid Level 1 disk mirroring olarakta bilinmektedir. Dataların kopyaları farklı bir fiziksel disk'te daha tutulur. Bu açıdan RAID Level 1 oluşacak hatalar ve veri kayıplarını tolere etsede SQL Server'ın yazma performasını düşürecektir. Çünkü aşağıdaki resimde de gördüğünüz gibi ortada iki farklı fiziksel disc var ve bu iki farklı disc'ede aynı veriyi kayıt edecektir. Ama buna karşılık Raid Level 1 okuma performasını yükseltir. Raid Level 0 ' a göre daha pahalı bir seçenektir. Çünkü data'lar disc'lere iki kere yazıldığından dolayı daha fazla yer işgal etmekte bundan dolayıda daha fazla disc alanına ihtiyaç duymak zorunda kalabilirsiniz. Kurumlar genelde hatalara karşı toleransı daha yüksek olduğu için kullanmakta fakat kullanırken data file'ları saklamak yerine SQL SERVER Transaction log file'ları burada saklarlar.

RAID LEVEL 2 

Raid Level 2 data ve parity dataları çoklu fiziksel disk'lere böler. Raid Level 1 den biraz daha fazla okuma ve yazma perfromansı sunmaktadır. Parity dataları birden fazla fiziksel disc üzerinde saklar. Etkin şekilde disk alanı sunmamasından ve Raid Level 2 çok efektif bir yöntem olmamasından dolayı çok kullanılan ve tercih edilen bir yöntem değildir.

RAID LEVEL 3

Data striping methodu açısından Raid Level 2 ye benzemektedir. Fakat bu yöntemde daha iyi bir performans için parity data'lar tek bir disc üzerinde saklanırlar. Raid Level 2 ye göre biraz daha fazla performans artışı göstermektedir.

RAID LEVEL 4 

Raid Level 4, Raid Level 2 ve Raid Level 3 ile data striping açsından aynı metadolojiye sahip olmasına rağmen daha büyük disc blokları söz konusu olduğu için daha yüksek performans sağlamaktadır. Raid Level 3'teki gibi parity datalar aynı diskte saklanırlar. Aslında bakarsak Raid Level 2 ve Raid Level 3 ile aynı ailedendir. Fakat transaction tabalı işlemlerde çok verimli olduğu söylenemez.

RAID LEVEL 5 

Bu level aslında en çok tercih edilen raid stratejisidir. Yapı olarak Raid 4' e benzemektedir.  Çünkü burada da datalar dizi halindeki disklerde geniş bloklar içerisinde tutulurlar. Fakar Raid Level 5' te her bir fiziksel disk kendi içerisinde parity dataları saklar. Burada veri yedekleme stratejisi parity'ler tarafından sağlanmaktadır. Data ve parity bilgileri diskler içerisinde düzenlenmiştir. Bundan dolayı da paritiler farklı fiziksel diskler içerisnde saklanmaktadır. Bu yapıdan dolayı Raid Level 1' e göre performans açısından daha verimli çalışmaktadır. Fakat strip'lerden birisi bozulursa (disk'in fail olma durumu) okuma performansı düşecektir. Kurumlar genellikle bu stratejiyi SQL Server'ın data file'larını saklamak için kullanırlar.

RAID LEVEL 10 (1+0)

Raid Level 1 ve Raid Level 0 'ın ortak kullanımıdır diyebiliriz. Disc strip'lerinden biri, bir diğerinin kopyasıdır. Raid Level 10 en yüksek okuma ve yazma performansı sağlayan yapıdır. Aynı zamanda fail durumlarına karşıda yüksek tolerans sağlar.  Fakat çok daha fazla disk kullanımına ihtiyaç duyulduğu için aralarında ki uygulanması en pahalı strateji denilebilir. 

Where Clause da Performance Tuning

Sql server'ın bir çok yararlı fonksiyonu bulunmakta. Hatta bu fonksiyonlar sayesinde çok karmaşık kodları gayet kolay bir şekilde yazılabilirliği arttırır. Aynı zamanda Sql Server içerisinde kullanıcı tanımlı fonksiyonlar oluşturabiliriz. Select cümleleri içerisinde kullanılan uppercase, substring gibi fonksiyonlar Sql Server performansına çok fazla etki etmese bile where cümlesinin hatalı kullanımı performansı oldukça kötü bir şekilde etkileyebilir. Select cümlesi içerisinde bir fonksiyon kullandığınız zaman datalar hazır bir şekilde döndürülür. Tabii ki eğer siz dataları filtrelemeye ihtiyaç duymuyorsanız çünkü bu şekilde karşınıza veritabanınızın boyutuna göre yüzbinlerce satır dönebilir. Eğer böyle kalabalık bir sql çıktısından ziyade filtre edilmiş verilere ihtiyacınız varsa bu noktada Where clause kullanmanız gerekmektedir. Bu noktada Sql Server index seek yapmak yerine table scan ve index scan yaparak  (tabloda eğer kullnaılmış bir index varsa) doğru sonuçları gösterecektir. Bu sebeple dataların belirlenen her bir satırları sizin kriterlerinizle eşleşip döndürülecektir. Bazı basit sorgularla where clause kullanımının etiklerini size göstermeye çalıştım. Execution plan sayesinde query'lerin ne şekilde çalıştığını anlamış olacağız.

Örnek1:
İlk örnekte left fonk. kullanarak ilk iki karakteri email adreslerden alıyoruz. Eğer 'As' kriteri mevcutsa her bir satır incelenir ve var olanlar döndürülürler. (Email adreste index kullanılmıştır.)

SELECT EmailAddress from person.contact
Where left(EmailAddress,2) = 'As'

Aşağıdaki query planına göre Sql Server’ın index taraması yaptığını görüyoruz. Yani sonuçlar dönmeden önce bütün satırlar gözden geçirilmiştir. Query’de kullanılan Left fonksiyonu yüzünden bu şekilde bir çıktı almış oluyoruz.

Şimdi yukarıda yazmış olduğumuz query’nin bir diğer versiyonunu inceleyelim. Burada left fonksiyonu yerine like clause kullanacağız. Burada amacımız yukarıda olduğu gibi bütün datalar içerisinde ‘AS’ ile başlayanları listelemek olacak. İndex’leme EmailAdress üzerinde oluşturulmuştur ve bundan dolayı yukarıda olduğu gibi index scan yerine like clause kullanıldığı için index seek Sql Server tarafından kullanılmıştır.

SELECT EmailAddress from person.contact

Where EmailAddress like ‘As%’

Query planında da görüldüğü gibi index seek, index scan’ e göre daha verimli olduğu açıkça görülmektedir.

Örnek 2

Şimdiki örneğimizde ise Upper clause kullanarak EmailAddress kolonu üzerindeki datalar üzerinde değişiklikler yapacağız.

SELECT EmailAddress From  person.Contact

Where Upper(EmailAddress) like ‘As%’

SELECT EmailAddress from person.Contact

Where EmailAddress like ‘%As’

Yukarıdaki execution planlar incelendiğinde görüldüğü gibi index scan ve index seek arasındaki fark açıkça görülmekte ayrıca upper kullanıldığı zamanki performans düşüşü de gayet net şekilde gözükmektedir.

Örnek 3:

Şimdi ki yazacağımız query’ de Where clause’da  DateDiff fonksiyonunu kullanalım. Aşağıda yazdığımız query’de ModifiedDate ve getdate() arasındaki farkın sıfırdan büyük olduğu durumları listeleyecektir. ModifiedDate alanında index bulunmaktadır.

SELECT ModifiedDate from person.contact

Where datediff(minute,ModifiedDate, getdate())>0

Yukarıda ki query’de fonksiyon kullandığı için Sql Server index scan yapmıştır.

Aşağıda yazılan kodda direk olarak ModifiedDate ile getdate() karşılaştırması yapılmıştır.

SELECT ModifiedDate from person.contact

Where ModifiedDate < getdate()

Bu query de fonksiyon yazılmadan sorgu yapıldığı için index seek kullanılmıştır.

            Sorgular boyut olarak küçük olan AdventureWorks üzerinde yazılmıştır. Yapay bir sistem üzerinde çalışıldığı için performans kaybı veya artışı çok hissedilebilir değildir. Eğer çok daha büyük sistemlerde çalışırsanız buradaki farklılıklar daha göze batar durumda olacaktır. Where clause lar da fonksiyon kullanımından kaçınırsanız oldukça yüksek performans sağlayabilirsiniz. Fonksiyon kullanmak yerine daha farklı alternatifler kullanarak başarılı bir performance tuning çalışması yapmış olursunuz.

Attunity Kullanarak MS SQL Server'dan Oracle'a Migraiton

  Veri transferinde kullanılan Attunity’i bu yazımda ele alacağım. Attunity'i tanıtırkende aynı zamanda MS SQL SERVER 2014 ve ORACLE arasında migration işlemi nasıl gerçekleşir bunu da resimleyerek anlatmaya çalıştım. Öncelikle Attunity'nin desteği sadece MS SQL Server ya da Oracle ile sınırlı kalmıyor; IBM Informix, MYSQL, Sybase gibi farklı firmalarında veritabanlarına destek vermekte.

Resim1.1

Benim anlatacağım örnekte SQL Server'dan Oracle, Northwind database'ni Oracle'da tanımlamış olduğum yasin şemasının içerisine aktaracağım. Öncelikle bu işlemi yapabilmek için Attunity ' de task oluşturmanız gerekmektedir. Bunun için resim1.1 de sol üstte bulunan new task'i tıklıyoruz. 

Resim1.2

Karşımıza gelen bu ekranda aslında task'in ne amaçla oluşturduğumuzu belirtiyoruz. Gördüğünüz gibi 3 farklı seçeneğimiz mevcut:

 Full load seçeneğinde aslında adında anlaşılacağı üzere kaynak tablodan verileri alıp hedefe tamamını göndermekte ve işlem bittiğinde de task kapanmaktadır.

Apply change'i seçerseniz bu noktada ise öncelikle full load'ı kullanmış olmanız gerekmektedir. Amaç kaynak tablonun birebir kopyasını hedef tarafta oluşturmak ve her yapılan değişiklikleri uygulayarak kaynak ile hedefin bire bir kalmasını sağlamak. Bundan dolayı arka planda Attunity çalışarak sürekli olarak kaynak ile hedefi eşitlemeye çalışır.

Store Changes ise apply changes den farklı olarak kaynak ile hedefin eşitlenmesine ihtiyaç duymaz. Sadece siz task'i oluşturduktan sonra kaynak tabloda yapılan değişiklikleri hedef tabloya yansıtmaya başlar, task çalıştırılmadan önceki veriler hedef tabloda bulunmaz.

Bu üç farklı seçenekten ihtiyacınıza uygun olanı belirledikten sonra task'e bir isim ve ihtiyaç duyarsanız description kısmına açıklama yazabilirisniz. Arından tamam diyerek task'i oluşturmuş oluyoruz.

Resim1.3

Task oluştuktan sonra karşınıza resim 1.3'deki gibi bir ekran gelecektir. Bu noktada artık bizim veritabanlarımızı tanımlamamız gerekmektedir. Bunun içinde ekranın üst orta kısmında bulunan manage database'i tıklıyoruz.

Resim1.4

Karşımıza gelen ekranda name kısmında tanımlamak istediğimiz databas’e istediğimiz herhangi bir isim verebiliriz. Description kısmında ise task'i bize daha sonra hatırlatacak bir açıklama yazabilirsiniz. ROLE kısmında seçeceğiniz database'in kaynak mı yoksa hedef database olduğunu belirtmeniz gerekmektedir. TYPE kısmında kullanacağınız database'i seçmeniz gerekmektedir. Ben yukarıda MS SQL Server'ı kaynak database olarak tanımladım tavsiye olarak SQL SERVER authentication olarak bağlanmanızı tavsiye ediyorum. Çünkü Windows Aut. bir kaç kez denememde hatalar aldım. Bundan sonra belirtmiş olduğunuz kullanıcının şifresini de yazarak hemen altında ilgili database'i (ki ben Northwind'i seçtim) belirterek bu kısımdaki işi en son olarak ekreanın sol alt köşesinde bulunan test butonu ile bağlantıyı kontrol ederek eğer başarılı yazısını alıyorsak noktalayabiliriz.

Resim1.5

Resim1.5 de ise hedef veritabanını düzenliyoruz. Burada da aslında mantık yukarıda yaptığımız işlem ile tamamen aynı. Hedef olarak ben Oracle'ı seçtim Oracle' da yasin isimli şemamı ve şema şifresi ile birlikte yazarak tanımlamış oldum. Burada dikkat edilmesi gereken bir diğer husus ise şemanızın ilgili yetkilere sahip olmasına dikkat edin yoksa bağlantıyı test ettiğiniz zaman hata alacaksınızdır. Eğer ilgili yetkiler şemaya tanımlanmazsa Attunity'nin Oracle bağlanması mümkün olmayacaktır.  Connect session ve resource yetkilerini vermek bağlanma tarafında herhangi bir sıkıntı çıkarmamaktadır. Ama daha sonra yapacağınız işlemler doğrultusunda vermeniz gereken yetkiler de bu doğrultuda değişiklik gösterecektir. 

Resim1.6

Resim1.6 da gördüğünüz gibi sol tarafta tanımladığımız iki database de gözükmekte. Bu noktada yapmamız gereken işlem ise hedef veritabanını ve kaynak veritabanını ortada bulunan alana sürükleyip bırakmak. Ekranın sağ bölümünde table selection kısmında tablo seçimini yapmak için tıklıyoruz.

Resim1.7

Schema kısmında bu alana schema'nızın ismini yazıyoruz Northwind'in şema ismi dbo olduğu için ben bunu yazdım. Daha sonra eğer table kısmını herhangi bir şey yazmadan search'ü tıklarsanız database içinde bulunan tablolar listenecektir. Bu noktada istediğiniz tabloları seçip ekleyebilirsiniz. Ayrıca yukarıda include butonuna tıklayarak şemanızıda dâhil etmeniz gerekmektedir.

Resim1.8

Resim 1.6 ekranın sağ üst köşesinde bulunan global transformations butonuna tıklayarak yukarıdaki ekrana ulaşırsınız burada schma, table ve kolonları tekrardan isimlendirebilir, kolon ekleyebilir yada silebilir veya veriler kaynaktan hedefe aktarılmadan önce veri tipleri üzerinde çeşitli manipülasyonlar uygulayabilirsiniz. Bu noktada Attunity oldukça işlevsel ve basit bir arayüzle kullanıcının işini oldukça kolaylaştırmakta ve çeşitli inisiyatifler sunarak kaynaktan tablolar gönderilmeden ihtiyaçlar doğrultusunda çeşitli değişikliklere uğratılmasını sağlamaktadır.

Resim1.9

Resim 1.6 da ekranın sol üst köşede bulunan task butonuna basarak server'ı seçtiğmizde karşımıza gelen ekranda Notification bölümünde bildirim ayarlarını düzenleyebiliriz bu sayade task tamamlandığı zaman ya da çalışmadığı zaman mail yolu ile bilgilendirilirmiş oluruz. Bu ekrandan lisans ayarlamaları, hata düzenlemeleri log'lanma seçenekleri ve zamanlama ile ilgili ayarlamalar yapılabilir..

Resim1.10

Yukarıdaki resimdeki seçeneklerde task çalıştırma, task'i durdurma ya da tekrardan hedef tabloya yönlendirme yaptırılabilinir.  Aşağıda görüldüğü gibi aslında Sql Server'da job'lara alışkın olan kişilerin yabancılık çekmiyeceği bir yapı var çeşitli zaman aralıkları tanımlayarak zamanlama yapılabilmekte.

Not:  Attunity çalışırken MS SQL Server (diğer database lerde de bu durum söz konusu olabilir.) log kayıtlarını yapmamaktadır. Çünkü Attunity kayıtları log dosyasına erişip buradan almakta ve bundan dolayı log'lanma durumunda kesintiye sebebiyet vermektedir. Eğer veri kaybı tahammülünün hiç olmadığı bir sistem üzerinde çalışıyorsanız dikkatli olmanız gerekmektedir. Konu ile ilgili daha ayrıntılı çalışma yaptığım zaman buradan sizinle paylaşıyor olacağım.