Deadlock, ölümcül kilit. Her sistem yöneticisinin veya Sql Adminin başına gelen bir olaydır deadlock. Deadlock hatasını alan bir kullanıcı bu hatanın düzeltilemez olduğunu düşünür ve programı kapatır açar. Aslında düzelen hiçbir şey olmamıştır. Sql üzerindeki transactionların (proseslerin) kilitlenmesine kısaca deadlock diyebiliriz.

Bir örnek vermek gerekirse; veritabanlarımızda bir güncelleme (update) işlemi yaptığımızda, güncelleme bitene kadar sql server ilgili tabloyu kilitler. Aynı sırada farklı bir transaction (işlem) tabloda bir güncelleme yapmak istediğinde bekletmeye alınır, timeout (zaman aşımı) süresi kadar kilidin açılmasını bekler. Bu süre içerisinde ilk transaction’ın bitmesini veya roll back (geri alınmasını) bekler. Bu iki transaction birbirini beklemeye başladığı sırada deadlock dediğimiz olay meydana gelir. Özetlersek, iki farklı kaynak birbirine erişmek istiyor fakat ikisi de birbirlerinin üzerindeki işlerin bitmesini bekliyor.

Deadlock’ın kesin ve net bir çözümü yok. Şunu şunu yaparsan çözümü budur diyemeyiz. Deadlock oluşmasını önleyici bir takım tedbirler ve analizler yapılabilir. Birçok deadlock’ı veritabanı dizaynı ve indeksleme sayesinde giderebiliriz. Ayrıca hata yakalama yöntemleri ile de deadlocklar önlenebilir. Bu makalemizde örnekler ile deadlock izleme ve tespit etmek için neler yapabiliriz bunları göreceğiz.

Bu makale 4 bölümden oluşmaktadır:

1- Deadlock Tespit Edilmesi

2- Deadlock İle İlgili Bigl Toplama Süreci

3- Deadlock Analizi

4- Deadlock Tipleri

Makalemizde kullanacağımız terimlere göz atalım;

Transaction – Veritabanında çalışan bir birim iş.

Kilit (lock) – Birden fazla eşzamanlı çalışan transactionları, senkronizasyon mekanizması kullanarak birbirleri arasında koruma sağlaması.

Lock mode – Transactionların kilitlendiğindeki erişim seviyesi.

Kilitlenme (blocking) – Bir transaction işlemi çalışmaya başladığında kilit talebinde bulunuyor ise, çakışan diğer diğer transactionların beklemesi ve ilk transaction bitene kadar diğerlerine izin vermemesi.

Deadlock – İki transaction birbirlerini blokladığında, her biri kaynakları üzerindeki kilidi açmaya çalışır, bu sırada transactionlar çatışma moduna düşer (conflicting mode) deadlock meydana gelir.

Bu makaleyi okumadan önce Transaction Locking ile ilgili Technet’teki makaleyi incelemenizde fayda var; http://technet.microsoft.com/en-us/library/jj856598.aspx

Deadlock Hakkındaki Yanılgılar – Yanlış Bilinenler

- Deadlocklar Sql Server’ın açığıdır.

Sql 2005 ile ortaya atılan bir söylemdir, tam anlamıyla doğru değildir. Kodlama sonuçları yüzünden oluşan bir durumdur.

- Deadlocklar önlenemez.

Evet yüzde 100 önlenemez ama önlenemez diye de çözüm arayışları bırakılmamalıdır. Deadlockları önlemek için yöntemler mevcuttur. Veritabanının tasarımını değiştirmek, T-Sql kod değişiklikleri, transactionları farklı bir sırayla veya ayrı bir şekilde çalıştırmak, deadlock önlemede en önemli faktörlerdendir.

- Select ifadesinde NOLOCK kullanımı deadlockların oluşmasını engellemede en iyi yoldur.

En sık karşılaşılan yanılgılardan biri de budur. NOLOCK kullanmak o anda işinizi görür, sorgunuzu çalıştırır, kilitlenmede olmaz. Ama değişiklikler sorgu sonucuna yansımaz, o sırada ilgili tablolarda, bir update, delete veya insert işlemi yapılıyorsa bunlar sonuçları sizin sonuçlarınıza yansımaz. Uygunsuz bir çözümsüzdür. Sadece anlık sorgularda sürekli alışkanlık haline getirenler vardır, anlık sorgu NOLOCK’ın kullanılması çokta sıkıntılı bir durum değildir.

- Her sorguyu indekslemek deadlock oluşmasını engeller.

NOLOCK ile aynı kapsamdadır. Deadlock oluşmasını büyük ölçüde azaltır fakat gereksiz yere indeksleme yapmak veritabanı boyutunu ciddi derecede arttırır. İndeksleme sorgu performansı için yapılır ama gereksiz indeksleme de performans kaybına yol açar. Bilinmeden yapılan indekslemeler kesinlikle tavsiye edilmez.

Kilitlenme birimleri

Kilitlenme sırasında karşımıza çıkacak olan temel ana birimler şunlardır;

- RID: Ram’in heap kısmında duran, satır üzerindeki kimlik no’sudur

- KEY: Satırın indeks anahtarıdır.

- PAGE: Veritabanının kilitledği herbir sayfaya page denir.

- HOBT: Heap veya indeks bölümünün kilitlenmesi.

- TABLE: Tablonun kilitlenmesi.

- METADATA: Tablo şema açıklamasının kilitlenmesi.

Birden çok birim aynı anda kilitlenmeye maruz kalabilir. Bunun amacı da, en düşük kaynak seviyesinde, tam bir koruma sağlanmak istenmesidir. Kilitlenmeler tepeden aşağıda doğru hiyerarşik şekilde olur, önce tablolar sonra satırlar.

Delete ifadesinde, tablo içinde önce 1 satır silme ile başlar. Bu sırada tablo için kilitlenme isteği oluşturulur, ardından her satır için değiştirilmeye karşı bu kilitlenme geçerli olur.

Update ifadesinde, hiçbir kayıtta güncelleme yapılmasına izin vermez. Select ile sorgular yapmaya izin verir.

1. Deadlock Tespit Edilmesi

Sql server periyodik olarak deadlock tespiti için arama işlemi başlatır. Varsayılan olarak bu periyodik monitörleme işlemi 5 saniye aralıkla yapılmaktadır. Sql server’da deadlock tespit edildiğinde bu zaman 100ms’ye kadar düşer ve deadlock lar tamamen bitene kadar 100ms periyodu ile taramaya devam eder, deadlock’lar tamamen bittikten sonra arama periyodu 5 saniyeye tekrardan çıkar.

Deadlock araması sırasında, bloke olan işlemler tespit edilir, hangi kaynağın bloke koyduğu bulunur ve bu işlem yinelemeli olarak devam eder.

Deadlock tespit edildiğinde, deadlock gören işlemlerden birisi sonlandırılır ve işlem geri alınır (roll back transaction). Kullanıcı 1205 no’lu hatayı alır. http://technet.microsoft.com/en-us/library/aa258770(v=SQL.80).aspx Roll back yapılan işlemde ilk önce Deadlock_Priority (deadlock önceliği) seviyesi düşük mü yok sa yüksek mi diye bakılır. Buna bakılması için, çalışan işlemin içinde deadlock_priority nin tanımlı olması gerekmektedir. Eğer priority ayarları default olarak bırakılmış ise (genelde bu ayar yapılmaz) hangi işlemin (transaction) roll back yapması daha hızlı ve daha kolay olacaksa, o işlem deadlock victim (deadlock kurbanı) seçilir ve roll back olur.

2. Deadlock ile İlgili Bilgi Toplama Süreci

Deadlock ile ilgili bilgileri toplarken Trace Flag’leri kullanacağız. Trace flaglar ilk önce Sql Server 2005’te kullanılmaya başlandı. Dbcc Traceon komutu ile kullanılırlar.

Dcc Traceon: http://technet.microsoft.com/en-us/library/ms187329.aspx

Trace Flaglar: http://technet.microsoft.com/en-us/library/ms188396.aspx

Dbcc Traceon komutu -1 parametresi kullanıldığında tüm oturumları kapsayacak şekilde çalışır.

Deadlocklar yakalamamız için trace flaglardan 1204 ve 1222’yi takip etmemiz gerekecektir. Aynı zamanda hatalog larına da bu kayıtların gelmesi için gerekli ayarları yapmamız gerekecektir. Aşağıda bununla ilgili örnekleri yapacağız.

Trace flag 1222’yi nasıl aktif hale getireceğimize bakalım;

Sql Server Management Studio’yu açıyoruz.

New Query diyerek, yeni bir sorgu ekranı açıyoruz.

1222 Trace flag için aşağıdaki Dbcc kodunu yazıp Execute diyoruz,

1222 flag’imiz etkin oldu, şimdi durumuna bakalım,

Status 1 oldu, ama sadece bu oturum (Session) için geçerli.

Trace flag’imizi iptal etmek içinde aşağıdaki kodu yazıyoruz.

Trace flag’in genel olarak (Global) açılması için -1 parametresini kullanıyoruz,

Status kontrolü yaptığımzda global seçeneği 1 oldu,

Trace flag için yaptığımız bu ayarlar geçici olmuş oldu. Kalıcı olarak sürekli trace flagleri izlemek istiyor isek, Sql server’ın açılışına –T parametresini girerek, sürekli açık kalmasını sağlayabiliriz.

Bunun için Sql Server Configuration Manager’ı açıyoruz.

Sql Server Services – Sql Server (instance adı) sağ tıklayıp “Properties” bölümünü açıyoruz.

“Startup Parameters” sekmesine gelip, -T1222 parametresini yazıp Add ile ekleme işlememizi tamamlıyoruz.

Apply dedikten sonra Sql server hizmetinin yeniden başlatılması gerektiğini belirten bir uyarı çıkıyor.

Sql Profiler ile İzleme Yapılması

Sql Server Profiler, xml formatında bize deadlock’ların bir grafiğini sunabiliyor. Bilgi toplama sürecinde, Deadlock’lara sebep olan sorunları bu grafiksel arayüz sayesinde daha rahat bakabiliyoruz. Xml dosyalarından deadlockları okumak ve analiz etmek daha hızlı olmakla beraber, zaman kazandıran bir özellik gibi de düşünebiliriz.

Sql Server Profiler’ı, Management Studio’da Tools bölümünden açıyoruz.

Şablon olarak boş seçiyoruz.

R10

Events selection kısmında da “Locks” kısmından deadlock graph ı işaretliyoruz.

R11

Deadlock Graph’ı seçtikten sonra, yan tarafta “Events Extraction Settings” yani olayımızla ilgili sonuçları kaydedebileceğimiz seçenekler çıktı.

Bu kısımda Deadlock XML’i işaretliyoruz. Deadlock ile ilgili tüm olayları xml formatında masaüstüme kaydedecek şekilde ayarladım.

R12

Deadlock izlememiz başlamış durumda, deadlocklar oluştuğu zaman aşağıdaki ekrana gelmeye başlayacak.

R13

Olay Bildirimleri – Event Notifications

Trace olaylarını yakalayıp bunları olay olduğunda otomatik olarak bildimelerini sağlayan yapıya Event Notifications yani Olay Bildirimleri denmektedir. Bir bildirim ve bilgi mesajı içeriğiden olabilirler. Windows event logtaki warning ve info mesajları gibi.

Olay bildirimlerini alabilmek için, olay mesajlarını bir kuyrukta yakalamak gerekmektedir. Bu yakalanan verilerin nereye yönlendireceğini ve bunu bir servis gibi çalıştırmaya şimdi bakacağız.

Deadlock durumlarını yakalamak için msdb veritananında önce bir Queue yani kuyruk oluştuyoruz.

R14

Yeni bir servis Broker Service oluşturuyoruz. Detaylar için: http://technet.microsoft.com/en-us/library/ms190332.aspx

R15

Servisten sonra Olay Bildirimi için Event Notification’ı oluşturmamız gerekiyor. Detaylar için: http://technet.microsoft.com/en-us/library/ms189453.aspx

R16

Bakalım bildirim ayarlarımız olmuş mu, aşağıdaki sorguyu çalıştırıyoruz.

Servis adımızda atanmış durumda. İzleme servisimiz başarıyla oluşmuş gözüküyor.

R17

Deadlock bilgilerini toplamak bizlere deadlockların sebepleri hakkında çok önemli bilgiler vermektedir. Bu yüzden bilgi toplama aşaması önemlidir. Görüldüğü gibi, Sql Server varsayılan olarak bize deadlockların bilgilerini sunmuyor. Şu aşamaya kadar bilgi toplama nasıl yapılır bunları gördük, şimdi bu bilgileri nasıl analiz edeceğimize bakacağız.

3. Deadlock Analizi

Deadlock analizinde, ilk bakılacak nokta, deadlock olan proseslerin hangisinin roll back olduğudur. Bunu tespit edebilmek için, proseslere – id, bekleme zamanı, öncelik v.b. ve kaynağına yani neden olan sebepleri inceleyeceğiz.

Hata logları Sql üzerinde xp_readerrorlog üzerinde tutulmaktadır, buraya 1222 nolu trace flag’imiz ile ilgili hatalarda buraya da gelecektir.

R18

İlk olarak xml formatında deadlock isminde tanım yapıyoruz, ardından da her defasında 5 mesaj yakalayacak şekilde kodumuzu yazıyoruz.

R19

Şu anda bir deadlock olmadığı için NULL geldi, deadlock lar olduğunda burada xml formatının linkini verecek ve bu link üzerinden hangi sorgularda deadlock olduğunu görebileceğiz.

4. Deadlock Tipleri

4.1 Update Durumundaki Kilitlenmeler

Aynı anda çalışmaya başlayan Update komutlu iki prosesimiz olsun. Proses A Tablo A’ya, Proses B de Tablo B’ye Update komutu ile işleme başlasın. Bu durumda Tabla A ve Tablo B’yi bu iki proses kitleyecektir. Proses A Tablo B’de işlem yapamaz, Proses B’de Tablo A’da işlem yapamaz.

R20

Proses A ve B, her iki tabloyada Update yapmak istediğinde, Tablo A’nın daha büyük tablo olduğunu varsayarsak, bu esnada Proses B deadlock victim olacak ve roll back transaction yapılarak, yaptığı işlemler geri alınacaktır. Proses A hem Tablo A ya hem de Tablo B üzerinde update işlemini gerçekleştirecektir.

R21

Sql üzerinde bir örnek ile anlatmaya çalışalım;

Deadlock isminde bir veritabanı oluşturuyoruz,

R22

Olşturduğumuz veritabanımızda, TabloA isminde bir tablo ekleyelim.

R23

TabloA’nın içine Insert into ile rastgele veriler kaydedelim,

R24

Kolon 1 de Clustered Index’de oluşturalım,

R25

Bakalım verilerimiz gelmiş mi, görüldüğü gibi rastgele veriler tabloma kayıt olmuş gözüküyor.

R26

Daha sonra deadlock ta kullanmak için 2 satırı siliyorum,

R27

Bir tane stored prosedür olan bir tablo daha oluşturalım, tablonun adına TabloB diyorum, tabloma ilk tablomda olduğu gibi rastgele veriler ekliyorum. Bu sefer non clustered indeksini c2’de oluşturuyorum.

R28

Tablo A için basit bir Select sorgusu içeren Stored Procedure hazırlıyorum,

R29

Bir de TabloA için basit bir Update Stored Procedure hazırlıyorum,

R30

Veritabanlarımızı, tablolarımızı ve stored prosedürlerimizi hazırladık. Şimdi deadlock örneğimiz ile devam edelim.

Tablo A’da c2 kolonunda güncelleme işlemi yapıyorum. Begin trasaction diyerek, işlemi başlatıyor ve açık tutuyorum.

R31

Şimdi de Tablo B ve Tablo A da update işlemini başlatıyorum,

Evet sürekli Executing query dönüp durmaya başladı, diğer transaction tarafından prosesimiz bloklandı.

R32

Tablo B de c2 sutünunda güncelleme işlemi yapalım,

R33

İkinci kere güncelleme yapmama izin vermedi ve 2. Prosesimizde deadlock hatamızı verdi, bakalım ilk proseste ne olmuş, ilk proseste Executing query sürekli çalışır halde bloklanmış durumdaydı.

R34

Görüldüğü gibi, 2. Prosesi deadlock victim (kurban) yaparak ilk prosesimizin tamamlanmasını sağladı. Eğer bunu yapmamış olsaydı, bu işlemler biz durdurana kadar sürekli bekleyecek ve hiçbir iş yapmayacaklardı.

4.2 Insert Durumundaki Kilitlenmeler

Arda arda seri bir şekilde kayıt olan verilerde, veri kontrolü esnasında, iki veri arasında olmayan veri sorgulanmaya başlandığında, eş zamanlı olarak bir select sorgusu çalışıtı. Eksik olan verileri insert komutu ile veritabanına kayıt etmek isterken, 2 sorgudan biri deadlock victim olur ve rollback ile yaptığı işlemler geri alınır. Sql kodlarımızda bu tarz kontroller koyabiliriz, eksik olan bilgi eğer yok ise insert ile girişini yap gibi örnekler karşımıza çıkmaktadır.

İki select sorgusu ve eksik olan veriler insert edilmeye başlandığında Deadlock oluşuyor

R35

Bu sırada ikinci proses deadlock victim olur, transaction geri alınır ve 304 nolu kayıt insert edilir.

R36

4.3 Silme Durumundaki Kilitlenmeler

Sql Server üzerindeki bölünmüş tablolar yani partitioned tables, üzerinde oluşan deadlocklardır. Örnek olarak bölünmüş bir tabloda silme işlemini ele alalım. Partition table’ımız iki kısım olsun ve ilk kısımdan bir satır silmek istediğimizde sadece partition level kısmı kadar kilitler, yani tüm partition table’a ait tabloları kilitlemez. Ama bu silme işlemi, eş zamanlı olarak, hem birinci hem de ikinci bölümdeki alandan veri silmek istediğinde deadlock gerçekleşmiş olur.

Partition edilmiş bir tablodan eş zamanlı olarak veri silme işlemini aşağıdaki şeklimizde gösterelim,

R37

Bu makalede sizlere, deadlock nasıl tespit edilir ve nasıl izlenmesi gerektiği hakkında bilgiler aktarmaya çalıştım. Deadlocklar her zaman olacaktır, tam anlamıyla engellenecek bir durum değildir, aynı tablo üzerinde birden fazla kişinin çalışması önlenemez bir durumdur. Deadlockları azaltmak ve/veya önlemek için T-Sql kodunda kontroller koyabiliriz, veritabanımızın mimarisine göre özelleştirilmiş önlemler alınmalıdır.

Bu makalemde sizlere SQL Server 2008 R2 Express Edition kurulumu sunucularınız üzerinde SQL Management Studio yönetim arabirimi yok ise bu yönetim ara yüzünü yükleyip SQL Database dosyalarınızı nasıl yönetebilirsiniz bunları anlatmaya çalışacağım.

Bu makalemde test ortamımda çalışan sunucumuz üzerinde SQL Server Express 2008 R2 versiyonu yüklüdür, fakat Management Studio yazılımı bulunmamaktadır.

Benim bu sunucumda yüklü SQL Server Database dosyaları üzerinde bazı işlemler yapmam gerekiyor, ama SQL yönetim konsolu olmadığı için herhangi bir işlem yapamıyorum. Internetten SQL Management Studio yazılımını içeren kurulum dosyasını indirip sunucunuza kurduktan sonra database yönetim işlemlerimi yapabileceğim.

Aşağıdaki link’deki SQL Server 2008 R2 Express Management Studio kurulum dosyasını indirebilirsiniz.

http://www.microsoft.com/en-us/download/details.aspx?id=22985

Kurulum dosyası aşağıdaki gibidir.

Bu kurulum dosyasını çalıştırdığınızda sıfırdan kurulum yapıyormuş gibi New installation or add feture an existing installation seçeneği ile kurulumu başlatınız.

Sonraki ekranda Installation Type bölümünden New Installation or add shared features bölümünü seçmeniz gerekiyor, bu bölümde alttaki seçenek ile devam ederseniz yani bu sunucunuzda kurulu mevcut SQL Instance’i seçerek devam ederseniz managament studio kurulum seçeneği karşınıza gelmeyecektir.

Not: Buradaki ekranda gözüken instance name’i not alınız. SQL Server’a bağlanırken bu isme ihtiyacınız olacaktır. Bizim test ortamında yüklü Instance Name VIM_SQLEXP bunu not ediyorum.

Microsoft Lisans sözleşmeyi onaylayınız.

Karşınıza gelecek olan Feature Selection bölümün altındaki Management Tools – Basic modulü seçeneğini işaretleyip kuruluma devam ederseniz SQL Server Management Tools bilgisayarınıza kurulacaktır.

Kurulum sorunsuz biterse aşağıdaki ekranı görmeniz gerekiyor.

Microsoft SQL Server 2008 R2 altında SQL Server Management Studio kısayolunu kullanarak SQL Server yönetim ekranınızı açabilirsiniz.

Mevcut yüklü SQL Instance’a erişebilmek için aşağıdaki resimdeki gibi erişim bilgileri yazmalısınız. Yukarıda biz bu sunucuda yüklü Instance Name’I not almıştık. Server Name kısmına sunucumuzun adını ve SQL instance name’ini aşağıdaki gibi yazdıktan sonra sunucunuza bağlanabilirsiniz.

Sunucu Adı\SQL Instance Name
VCENTER55\VIM_SQLEXP

Mevcut yüklü çalışan SQL Database dosyalarını aşağıdaki gibi görebilirsiniz artık.

Faydası olması dileklerimle.

Birçok işletmede kullanılan Erp ve muhasebe programlarının kendilerine özgü raporlama araçları vardır. Çoğu Erp programlarında kendi raporumuzu yapacak araçlar mevcuttur. Programa özgü olan bu araçların izin verdiği sınırlar içerisinde raporlar yapılır. Farklı programların farklı veri tabanları ile rapor yapmak istediğimizde ise bu araçların yetersiz kaldığını, sadece kendi veri tabanlarındaki veriler ile rapor yapmamıza müsade ettiğini görmekteyiz. Bu konuyla ilgili farklı firmaların çözümleri mevcuttur. Bu makalemizde Sql Server ile beraber gelen, ek bir maliyet gerektirmeyen Reporting Services konusunu işleyeceğiz.

Makalemin ilk bölümüne aşağıdaki link üzerinden erişebilirsiniz.

http://www.cozumpark.com/blogs/sql/archive/2014/08/17/sql-server-reporting-services-bolum-1.aspx

4 - RAPOR OLUŞTURMA (SiHiRBAZSIZ):

Sihirbaz ile ne kadar kolay raporlar oluşturulduğunu gördük. Bu aşamadan sonra sihirbaz olmadan, rapordaki tüm parçaları nasıl oluştururuz ve nasıl değiştirebiliriz bunlara bakacağız. Visual Studio Data Tools’u açıp, New Project diyoruz. Burada bir hatırlatma yapmak istiyorum; VS Data Tools 2010 ve 2012 kullanmanız pek bir şey fark ettirmiyor, hatta 2008 bile kullanabilirsiniz. Sql Server 2012 Reporting Service için bu makalede VS Data Tools 2010 kullanıyorum, VS Data Tools 2012 kullansak pek fark olmayacak.

Report Server Project’I seçiyoruz, projemize isim veriyoruz. Kayıt yerleri önemli, genelde C veya farklı ana dizin altında kaydetmeye çalışın.

SSRS-97

Boş bir VS sayfası geliyor. Sağ tarafta bulunan Solution Explorer’daki Reports klasörüne sağ tıklayıp Add – New Item’e tıklıyoruz.

SSRS-98

Add New Item ekranında Report’u seçiyoruz, burada anlamlı bir isim vermek önemli. Bir projede birden çok rapor veya alt raporlar olabilir, raporların karışmaması için anlamlı bir isim veriyoruz.

SSRS-99

Raporumuz oluştu. Sol tarafa Report Data alanı geldi, eğer gelmez ise, View – Report Data (Ctrl + Alt + D) ile açabilirsiniz.

SSRS-100

4 – 1 DATA SOURCE (Veri kaynağı) OLUŞTURMA:

Yeni raporumuza ilk önce bir veri kaynağı (Data Sources) eklememiz gerekiyor. Verileri nereden alacağız, local bilgisayarımızdan mı, farklı bir Sql serverdan mı, ODBC driver’I ile farklı veritabanlarından veriler alacağımız gibi, bir excel sayfasından da veri alıp bunu rapor yapabiliriz. Report Data – Data Sources üzerinde sağ tıklayarak Add New DataSource diyoruz.

SSRS-101

Birden çok veri kaynağı kullanacak isek, anlamlı isimler vermek faydalı olacaktır. Daha önce paylaşılmış bir veri kaynağı var ise “Use Shared Source Reference” kısmından seçilebilir. Sürekli aynı veritabanında çalışıyor iseniz, paylaşılan bir veri kaynağı oluşturarak, her raporda seçebilirsiniz.

SSRS-102

Connection String’I oluşturmak için Edit’e tıklıyoruz. Server name, ister Sql serverın ip adresini istersekte, listeden adını seçebiliriz. Windows auth. Veya Sql auth. Ile Sql server bağlantı tipini seçebiliriz. Temel raporlama bölümünde de bahsetmiştim, tekrar etmekte fayda var, rapor alırken Sql’e bağlanacak kullanıcı adı ve şifresini sormasını istemiyorsanız “Save my password” seçeneğini işaretlemelisiniz. Windows auth. da ise Sql server’ın güvenlik ayarlarının mixed mod da ve, raporları oluşturan kullanıcınında Sql serverda yetkisi olan bir kullanıcı olması gerekmektedir. Veritabanını da seçtikten sonra, Test Connection diyerek bağlantıyı kontrol ediyoruz.

SSRS-103

Connection string alanine bağlantı cümlem geldi, bağlantı cümlesinin buraya gelmesi gerekiyor, eğer bu alan boş ise, hata verecektir.

SSRS-104

4 – 2 DATASET (Veri Seti) OLUŞTURMA:

Veri kaynağımızı oluşturduk. Şimdi sıra veri setimizi oluşturmaya geldi. Report Data – Datasets üzerinde sağ tıklayarak, Add Dataset diyoruz.

SSRS-105

Satışlar ile ilgili Adventurkworks veritabanındaki Satış ana tablosu Sales.SalesOrderHeader, Sales.SalesOrderDetail vSatış detay tablosu ve Customer tablosundaki satış bedeli, satış tarihi, sevkiyat tarihi, müşteri adı gibi bilgileri içeren bir rapor hazırlayacağız. İlk raporları yaparken hazır bir view seçmiştik. Şimdi ise bu 3 farklı ama birbirleri ile ilişkisi bulunan (relationships) tablolardan oluşan bir sorgu hazırlayacağız.

Name kısmına anlaşılır bir isim veriyoruz.

DataSource kısmında, oluşturduğumuz veri kaynağını seçiyoruz. Ardından Query Designer ekranını açıyoruz.

SSRS-106

Query designer ekranında en üsttteki boşlukta sağ tıklayarak Add Table diyoruz.

SSRS-107

Tables kısmında SalesOrderHeader, SalesOrderDetail, Customer(sales), Store(sales) tablolarını seçip Add diyoruz. (Customer tablosu yukarılarda, ekran görüntüsüne sığmadığı için gözükmemektedir.)

SSRS-108

Tabloları ekleyince, aralarında ilişki olduğundan otomatik olarak Join bağlantıları geldi. Eğer ilişki bulunmayan tablolar olsa idi, bu bağlatıları sürükle bırak ile bizim yapmamız gerekirdi.

SSRS-109

Sıra geldi, raporda gözükmesini istediğim alanların seçilmesine. SalesOrderHeader tablosundan;
OrderData, ShipDate, Subtotal, TaxAmt, Freigt, TotalDue

SalesOrderDetail tablosundan;

OrderQty, UnitPrice

Store(Sales) tablosundan;

Name

Alanlarını seçiyoruz, alanları seçtiktek sonra gruplama yapması için sağ tıklayıp Add Group By’a tıklıyoruz.

SSRS-110

Seçtiğimiz alanlar Criteria Pane dediğimiz kriter alanina geliyor. Bu alanda, Alias kısmında tablo adına bir takma isim verebiliriz. Daha anlaşılır olması için aşağıdaki Şekil 111 deki gibi Alias kısımlarına takma isimleri girdim.

SSRS-111

Ok ile Query Designer ekranını kapatıyoruz. Sorgumuz Dataset Properties ekranına geldi.

SSRS-112

Dataset Properties’in diğer sekmelerini inceleyelim
Fields: Görüldüğü gibi Alias ta yazdığımız takma isimler alan adı olarak geliyor. Add seçeneğiyle ilave olarak viewde veya sorgudaki veritabanlarından alanlar eklenebilir.

SSRS-113

Options:

- Collation: Dil ayarlarına göre sıralama yapılmasını sağlar

- Case Sensivity: Veri sağlayıcının (data provider) büyük-küçük harf hassaslığını buradan açıp kapatabilirsiniz. Varsayılan olarak Auto gelir.

- Accent Sensitivity: İsim ve soyisimlerde genelde karşılaşılan, farklı harflerin hassaslığının açık olup olmamasın buradan ayarlayabilirsiniz. Örnek olarak HELEN ismini HÉLÈN olarak farklı bir dilde görebilirsinizi, eğer bu özellik açık olursa, HELEN ve HÉLÈN farklı iki isim olarak algılayacaktır, kapalı olursa tek olarak algılar. Varsayılan olarak Auto olarak gelir.

- Kanatype Sensitivity: Uzakdoğu dilleri için hassassızlı ayarı.

- Widht Sensitivity: Kare üssü gibi ifadelerin hassasiyet ayarı için kullanılır.

- Subtotals: Otomatik olarak sayısal alanları toplamlarını getirir. SUM olarak otomatik olarak ekleme yapar.

SSRS-114

Filters: Rapor alanlarına filtre uygulandığı alandır. Örnek olarak SiparisTarihi, tarih aralığı veya farklı operatörlerde seçilebilir.

SSRS-115

Parameters: Raporu alırken hangi parametrelere göre alacağımızı bu ekrandan ayarlayabiliriz, birden fazla parametre olabilir. Parametreler aynı zamanda Query Design ekranında WHERE operatörü içerisine yazılarak ayarlanabilir.

SSRS-116

Dataset özelliklerini ayarladıktan sonra Ok ile ekranı kapatıyoruz. Datasetimiz Report Data altında Datasets klasörüne, alanlar ile birlikte gelmiş oldu.

SSRS-117

5 - RAPOR BİLEŞENLERİ:

5 – 1 TABLO (Table):

Datasets altına gelen alanları rapora getirmek için 3 farklı yöntemimiz var, Table, Matrix veya direk sürükle bırak ile rapor içerisine alanları getirebiliriz. Sihirbaz ile oluşturulmayan bir raporda nasıl tablolar yapılıyor buna bakalım. Desing ekranında sağ tıklayarak, Insert – Table diyoruz.

SSRS-118

Table’ın herhangi bir hücresine tıklayarak, kenardaki menüler aktifleştiriyoruz, daha sonra kenarlıkların herhangi bir yerinde sağ tıklayarak “Tablix Properties”I açıyoruz.

SSRS-119

Tablix Properties ekranını detaylı olarak inceleyelim;

General: Name, tablonun adı.

ToolTip, rapor arayüzünde tablonun üzerine fare ile gelindiğinde bilgi kutusunda yazacak metini buraya yazıyoruz.

Dataset name, tabloya hangi verisetinden veri geleceğinin seçildiği alandır. Birden çok veriseti olan bir raporda mutlaka Dataset name’den veriseti seçilmelidir. Veri seti olmayan Tablix tablolar olursa eğer, rapor çalışınca hata verecektir.

Page Break Options, her sayfa sonu öncesi veya sonrası ara verilmesini sağlar.

Row Headers, rapor birden fazla sayfadan oluşur ise, her sayfanın başında satır başlıklarının getirilmesini sağlar.

Column headers, birden fazla sayfadan oluşan raporlarda, her sayfanın başına kolon başlıklarının gelmesini sağlar.

SSRS-120

Visibility: Bazı tabloların raporda gözükmemesini isteyebiliriz. Örnek olarak, bir hesaplamada kullanacağımız bir tabloyu Visibility’den gizleyerek raporda gözükmesini engelleyebiliriz, böylelikle görüntü kalabalığı yapmamış olur. Varsayılan olarak her tablix ve matrix tablosu Show olarak gelir.

SSRS-121

Filters: Tablomuza filtreler ekleyebileceğimiz bir alandır. Tsql tarafında Where operatöründe yapabileceğimiz tüm işlemleri yapabiliriz. Örnek olarak Expression olarak SiparisTarihi alanını seçtim, veri tipini Datatime olarak seçti ve kilitledi, veri tipini değiştirmeye müsade etmiyor. Operatör olarak Between (iki tarih arasında) seçiyorum. Value kısmına da otomatik olarak başlangıç ve bitiş tarihini getiriyor.

İstenilen sayıda filtre eklenebilir. Bir tane de, Birimfiyatı filtresi ekleyelim. Birim fiyatı 20 den yüksek olanları getirsin.

SSRS-122

Sorting: Tablodaki verilerin hangi alana göre sıralanacağını belirleyeceğimiz alandır. Tsql deki Order by operatörünün yaptığı işi yapar.

SSRS-123

Table’ı gördükten sonra, matrix tablolarını inceleyelim.

5 – 2 Matrix Table: Raporun boş bir yerinde sağ tıklayıp, Insert – Matrix diyelim.

SSRS-124

Matrix tablolarda kolonlar, satırlar ve data alanı mevcut. Kolon veya satırlara gelecek alanları seçtikten sonra, hangi verilerin detay olarak geleceğini seçebiliriz.

SSRS-125

Rows kısmına Müşteri adı, Columns kısmına Birim Fiyatı ve veriler kısmına da Sipariş Adedi alanları seçiyoruz. Alanları seçmek için her hücrenin sağ tarafına mouse ile gelince mavi bir buton aktif oluyor, bu butona basarak veri setindeki tanımla alanlar otomatik olarak gelmektedir.

SSRS-126

Satır ve sütunlardaki verilerin daha düzgün gözükmesi için zemin rengini değiştirelim. İlgi hücre seçildikten sonra, Background Color’dan istediğimiz rengi seçerek zemin rengini değiştirebiliriz.

SSRS-127

Preview sekmesine geçerek raporun son haline bakalım.

SSRS-128

Görüldüğü gibi firma adı ve birim fiyatlarına göre matrix satış adedi raporumuz hazırlanmış oldu. İlerki bölümlerde alt toplam, rapor başlığı konularına değineceğiz. Bileşenlerden Textbox ile devam ediyoruz.

5 – 3 Textbox: Rapor body kısmında boş bir yerde sağ tıklayarak Insert – Textbox diyoruz.

SSRS-129

Textbox lara ister sabir bir yazı yazabilir, istersek te Expression kısmından formül veya bir hesaplama yaptırabiliriz.

İki tane text box ekliyorum, ilkine Alt Toplam yazıyorum, diğerine de expression ile veri setindeki Alttoplam alanını getiriyorum.

SSRS-130

SSRS-131

Textbox’ın içinde «Expr» şeklinde bir ifade yazdı, bunun anlamı bu textbox’ta bir expression kullanılmasıdır.

SSRS-132

Preview ile raporu alıyoruz. Alt toplam gelmiş durumda.

SSRS-133

Table veya matrix eklemeden, verisetinden bir alanı bağımsız bir textbox da nasıl tanımlanacağını görmüş olduk.

Insert – Rectangle ile alanların çevresine çerçeve ekleyebilirsiniz. Alt toplam alanına bir çerçeve ekleyelim.

Rectangle:

SSRS-134

Çerçevemiz ilk oluştuğu şekilde raporda gözükmeyecektir. Çerçevenin kenarından sağ tıklayıp Rectangel Properties’e giriyoruz.

General, Visibility, Fill, Border sekmeleri geldi.

General, sayfa öncesi veya sonrası otomatik olarak eklenmesini sağlar. Bu ekranda rectangle farklı bir isim de verebiliriz.

Visibility, görünürlük ayarlarını buradan yapıyoruz. İsteğe bağlı olarak bir şart yazarak, şarta bağlı olarak gözükmesini sağlayabiliriz.

Fill, rectangle’ın içini istediğiniz bir renk ile veya bir resim ile doldurabilirsiniz.

Border, en çok işimize yarayacak kısımdır, yeni bir rectangle oluşturduğumuzda mutlaka kenar çizgilerini belirtmek için bu sekmeye gelip ayarlamaları yapmamız gerekmektedir.

Outline’a tıklayarak rectangelın tüm kenarlarına otomatik olarak kenarlıkları atıyor. Color kısmından çerçeve rengi seçilebilir.

İstemediğimiz bir kenar var ise, Preview kısmından o kenarın üzerine basarak kaldırabiliriz.

SSRS-135

Rectangle hakkında bilgi verdikten sonra, raporumuzdaki Alt Toplam: alanının çevresine rectangle’ı yerleştiriyoruz.

Insert – Line ile de Alt Toplam ile sonuç arasına bir çizgi çekiyoruz.

SSRS-136

Önizleme ile kontrol edelim.

SSRS-137

5 – 4 List: Liste olarak hızlı tablolar eklemek kullanacağımız bir bileşendir. Rapor design ekranında sağ tıklayarak, Insert – Line diyerek rapora eklenmektedir.

SSRS-138

Boş bir kutu olarak list geldi, içine bir kere tıklayarak, sol ve üst taraftaki menülerin çıkmasını sağlayan kenarları aktif hale getiriyoruz. Üst teki kenara sağ tıklayıp iki kolon daha oluşturalım.

SSRS-139

Bir list olsada, aslında tablix mantığında çalışıyor. Bu list’e hangi verisetinden veri gelmesini istiyor ise, kenar çubuklarında sağ tıklayıp, Tablix Properties – General bölümünden ilgili veri setimizi seçiyoruz.

SSRS-140

Müşteri adı ve sipariş adetlerini seçerek, basit bir rapor yapıyoruz.

SSRS-141

Preview ile rapora bakalım, gruplama yapmadığımız için her siparişi ayrı ayrı göstermiş olduk.

SSRS-142

5 – 5 Image: Rapora bir resim veya logo eklemek için kullanılır. Resim dosyasının proje klasöründe olması, rapor projesinin taşınması ve yedeklenmesi gibi durumlarda, image dosyalarının kaybolmasını ve dosya yolunun aynı kalmasını sağlar.

Insert – Image diyerek Image properties sayfası açılıyor. General sekmesindeki Import butonu ile image’ı seçiyoruz.

SSRS-143

Logoyu en üste koyarak, bir önizleme alalım.

SSRS-144

Insert bölümündeki diğer bileşenler kendi başlarına bir konu olduğundan daha sonra inceleyeceğiz.

6 – FONKSİYONLAR:

Sql serverdaki veriyi işlemek için, Reporting Server tarafında fonksiyonlar kullanılmaktadır. Toplam, ortalama, say, minimum, maksimum, ilk değer, son değer v.b. Bu tarz hesaplamaları Sql tarafında hazırlayıp getirmek yerine, Rep. Server’ın VS Data Tools veya Report Builder programları ile yapmak daha kolaydır.

Haftalık tüm satışlar, geçen yılki ortalama birim fiyatlar, en yüksek veya en düşük fiyatlı satışlar gibi spesifik değerleri fonksiyonlar (functions) sayesinde elde edebiliriz.

Yeni bir rapor ekliyoruz, yeni rapor nasıl oluşturulur artık biliyorsunuz, SSRS-34’ten itibaren başlayabilirsiniz. Adventureworks veritabanındaki SalesOrderHeader tablosunu kullanarak fonksiyonlara örnek yapacağız.

TotalDue ve SalesOrderNumber alanlarını query ekranında seçtikten sonra devam ediyoruz.

SSRS-145

Report Type’ı table olarak seçiyoruz.

İki alanıda Details kısmına atıyoruz.

SSRS-146

Rapor ismi veriyoruz. Görsel seçip devam ediyoruz.

SSRS-147

Raporumuz oluştu, alias kısmına yazdığımız isimler design alanına otomatik olarak geldi.

SSRS-148

Satış toplamı, ortalama satış değeri, en yüksek satış ve en düşük satışı bulmak için, Tablix’in üzerinde sağ tıklayarak, Insert Row – Outside Group below’a tıklıyoruz, bu işlemi 3 defa daha yapıyoruz.

SSRS-149

Grup dışına satırı ekledikten sonra, hücrenin içinde sağ tarafta çıkan veri kutusuna tıklıyoruz ve Satis_Toplamı nı seçiyoruz.

SSRS-150

Görüldüğü gibi SUM(Satış_Toplamı)nı otomatik olarak getirdi.

SSRS-151

Sağ tıklayarak Insert Row – Below diyerek bir satır daha ekleyelim. Veri kutusundan yine Satış_Toplamını seçersek, bize SUM değerini getirecektir. Boş hücre içinde sağ tıklayarak Expression kısmına geliyoruz.

SSRS-152

Karşımıza gelen pencere expression penceresidir, birçok hesaplama ve özelliği bu expressionlar (ifadeler) sayesinde yapabiliriz. Ham veriyi işlemek için report service’da expressionlar çok sık kullanılmaktadır.

Satışların ortamalasını bulacağız, Common Functions – Aggregate – Avg ifadesini kullanacağız. İfadeleri ister menüden seçebilir, ilerki zamanda da alıştığınız zaman Value penceresine kendiniz yazabilirsiniz.

Not: Her İfadeyi seçtiğinizde sağ alt tarafta ifadeyle alakalı örnek bir kullanım göstermiştir. İfadelerin detaylı anlatımları Msdn kütüphanesinde mevcuttur, ayrıca VS Data Tools ve Report Builder’ın help kısımlarında detaylı anlatımları bulunmaktadır. Makalemizde yeri geldiğinde ve daha sonraki makalelerde İfadeleri sık sık anlatmaya çalışacağız.

Avg ile ortalama değerimizi bulalım. Avg ifadesine çift tıklayarak Value ekranına gelmesini sağlıyoruz.

SSRS-153

Avg ifadesini ekledikten sonra, hangi alanın ortalamasını almak istiyorsak, Datasets kısmından ilgili alanı seçeceğiz. Birden fazla Dataset olduğu zaman, ilgili dataseti seçmemiz gerekiyor.

Satış_Toplamını burada SUM olarak getiriyor, Reporting Service datasetleri, eğer numerik bir alan ise varsayılan olarak SUM, alfanumerik alanları ise varsayılan olarak FIRST yani ilk değerlerini otomatik olarak seçmemizi sağlıyor. Eğer burada SUM(Satış_Toplamı)na çift tıklayıp Value alanına atarsak, rapor hata verecektir. Hatayı görmek için deneyelim.

SSRS-154

Preview diyerek raporu almaya çalışalım.

Görüldüğü gibi iç kapsamdaki toplamlar alınamaz anlamında bir hata verdi, yani toplam bir değerin ortalaması olmaz. Value kısmından SUM ifadesini kaldırarak doğru olan değeri yazalım.

SSRS-156

Doğru ifade yukarıdaki gibi olmalıdır.

Satışlarımızdan en yüksek ve en düşük değerleri bulmak içinde MAX ve MIN ifadelerini kullanacağız.

En yüksek satış için ifade;

SSRS-157

En düşük değerli satış için ifade;

SSRS-158

Satış adedini bulmak içinde Count ifadesini kullanacağız, burada satış adedini Siparis_Numarasını sayarak bulabiliriz.

SSRS-159

Raporumuzu önizleme yapmadan önce şekil SSRS-48 olduğu gibi beş alanımızıda da binlik ayraç ile ayırıyoruz ve virgülden sonra tek hane gelecek şekilde ayarlıyoruz.

SSRS-160

Alanları düzenledikten sonra preview kısmından raporu çalıştırıyoruz. İfadeleri görmek için raporun son sayfasına gidiyoruz.

SSRS-161

Toplam satış tutarını SUM, satış ortalamasını AVG, en yüksek satışı MAX, en düşük satışı MIN, satış adedini de COUNT ifadeleri ile bulduk.

Makalemin ikinci bölümünün sonuna geldik. Bir sonraki bölümde görüşmek dileği ile.

Makalemin ilk bölümlerine aşağıdaki linklerden ulaşabilirsiniz.

http://www.cozumpark.com/blogs/sql/archive/2014/08/17/sql-server-reporting-services-bolum-1.aspx

http://www.cozumpark.com/blogs/sql/archive/2014/08/17/sql-server-reporting-services-bolum-2.aspx

7 – PARAMETRELER:

Şu ana kadar oluşturduğumuz raporlarda parametre belirtmeden yaptık. Çoğu zaman raporlar için parametre diğer bir deyişle koşullar belirterek raporu almamız gerekecektir. Reporting Service de parametreler nasıl oluşturulur bunlara değineceğiz.

Parametreler, metin, sayı ve tarih gibi kriterlere göre belirlenebilir. Bir veya birden fazla parametreyi raporumuza ekleyebiliriz. Örnek olarak, x malzemesini 2005 yılının Ocak ve Mart aylarında kaç tane ve toplam satış tutarını seçebileceğimiz parametreler olabilir.

Parametleri VS Data Tools ile eklerken Query ekranında WHERE koşulu kullanacağız. Report Builder ile biraz daha son kullanıcıya hitap eden, filter alanından parametreleri ekleyeceğiz. Her iki arayzüz için örnek vereceğiz.

Yeni bir rapor oluşturuyoruz. Solution Explorer – Reports – Add New Reports

Data Source ekranında Edit diyerek, AdventureWorks2012 veritabanını seçiyoruz.

Design the query ekranında Query Builder’ı açıyoruz.

Üst kısımdaki boşlukta sağ tıklayarak Add Table diyoruz.

Product (Production) tablosunu ekliyoruz.

SSRS-162

ProductID, Name, Color ve ListPrice alanlarını seçelim. Aliasları aşağıdaki şekildeki yazıyoruz.

SSRS-163

Tabular seçili olarak kalıyor, devam ediyoruz.

Desing the table ekranında tüm alanları details kısmına ekleyip devam ediyoruz.

SSRS-164

Herhangi bir stil seçiyoruz.

Rapor adı yazıp, Finish ile tasarım ekranına geliyoruz.

Raporumuz oluştu, Datasets altında Dataset1’e sağ tıklayıp Query penceresini açıyoruz.

SSRS-165

Sorgu kutusuna FROM bölümünün altına WHERE koşulunu yazacağız. ProductID numarasına göre parametre vermek istediğimiz için ilk önce parametre verilecek alan adı, sonra parametre koşulu ( =, <, >, LIKE v.b.), en sona da parametre ismini yazacağız (@Parametreadi).

SSRS-166

Sorguyu kontrol etmek için Execute dediğimizde karşımıza parametre soran bir ekran getirecektir.

SSRS-167

Ok diyerek Query desinger ekranını kapatıyoruz.

Parameters kısmına baktığımızda, oluşturduğumuz parametrenin geldiğini görüyoruz.

SSRS-168

Raporu çaıştırdığımızda, parametre kutusu gelmektedir, bu alana parametreyi yazarak istediğimiz Urun ID yi yazarak çalıştırıyoruz.

SSRS-169

7 – 1 Çoktan Seçmeli Parametreler:

Bu şekilde parametreli olarak rapor almak için, Urun ID sini ezbere bilmemiz veya bir listeden bakmak gerekiyor. Çoktan seçmeli olarak parametreleri ayarlayabiliriz. Bunun için bir dataset daha ekliyoruz, bu dataset te ProductId ve İsimleri bulunacak.

Datasets – New Dataset

Dataset ismine KategoriveNo diyoruz. Eğer dataset isimlerine anlamlı bir isim vermez iseniz, daha sonradan birden çok datasetle çalıştığınızda karmaşıklık olacaktır.

DataSource1’i seçiyoruz.

SSRS-170

Query Designer’ı açıp, en üstteki alanda sağ tıklıyoruz, Add table’dan, ProductCategory (Production) tablosunu ekliyoruz.

SSRS-171

ProductCategoryID ve Name alanları seçip, Ok ile devam ediyoruz.

SSRS-172

Dataset Properties ekranında Ok ile çıkıyoruz. Datasets altına diğer dataset KategoriveNo geldi. Şimdi parametremizin özelliklerine gidip, sorgudan parametre çekme işlemini yapacağız.

SSRS-173

Report Parameter Properties – Available Values sekmesinde Get Values From a Query’i seçiyoıruz.

Dataset olarak KategoriveNo

Value Field ProductCategoryID

Label Filed olarak ta Name’i seçiyoruz.

Burada label field kısmına Name (isim) seçmemizdeki amaç, ID nolarına göre değil de, kategori isimlerine göre parametreleri seçmek istememizdir, daha öncede belirtiğimiz gibi, Id numaralarını ezberlemek veya farklı bir yerden bakmak yerine, akılda kalıcı olan isimleri parametre olarak kullanmak daha mantıklı olacaktır.

SSRS-174

Preview ile raporumuzu aldığımızda, parametre olarak kategori id leri yerine kategori isimleri geldi.

SSRS-175

7-2 Tarih Aralıklı Parametreler:

En çok gereken parametrelerden biridir, tarih aralığı raporlarda en fazla istenen parametredir.

Yapacağımız örnekte, 3 farklı tablodan veriler getirip, bu verileri tarih parametresi ile rapora nasıl yansıtacağımızı göreceğiz.

Solution Explorer- Reports – Add New report, hoşgeldin ekranını geçiyoruz.

Datasource’u ayarlıyoruz, yukarıda verisetlerinin detaylı anlatımı olduğundan her defasında detaya girmiyorum.

SSRS-176

Desing The Query – Query Builder

Üstteki alanda Add Table kısmından; SalesOrderHeader (Sales) – SalesOrderDetail (Sales) ve Product (Production) tablolarını ekliyoruz. SalesOrderID alanları otomatik olarak eşleşti, Product tablosu ile de ProductID alanı eşleşti.

SalesOrderHeader tablosundan, SalesOrderNumber, OrderData, ShipDate ve TotalDue alanlarını,

SalesOrderDetail tablosundan, OrderQty ve ProductID alanlarını,

Product tablosundan da, Name ve ProductNumber alanlarını seçiyoruz.

Alias takma isimleri aşağıdaki gibi düzenliyoruz ki raporda sütun başlıkları anlaşılır bir şekilde gelsin.

SSRS-177

Report Type’ı tabular seçiyoruz.

Design The Table ekranında, UrunNo’ya göre gruplama yapalım, geri kalan alanları Details bölümüne yerleştiriyoruz.

SSRS-178

Table Layout stepped olarak bırakalım.

Herhangi bir style seçip devam ediyoruz.

Rapora bir isim verip Finish ile sonlandırıyoruz.

Raporumuz UrunNo gruplu bir şekilde oluştu. Preview diyerek çalışıp çalışmadığını kontrol edelim.

SSRS-179

Tarih aralıklı parametremizi atamadan önce Sipariş ve Sevk Tarihini kendi bölgemizde kullandığımız şekilde, Gün/Ay/Yıl olarak ayarlayalım. Bunun için Tarih alanının üzerinde sağ tıklayarak Text Box Properties ekranını açıyoruz.

SSRS-180

Sayısal olarak istediğimiz Gün/Ay/Yıl formatı gözükmüyor. 01/31/2000 tipini seçiyoruz, daha sonra Category kısmındaki Custom’a tıklıyoruz. Aşağıdaki şekilde gösterdiği gibi, MM ile dd nin yerlerini değiştirecek şekilde düzenlemeyi yapıyoruz.

SSRS-181

Aynı işlemi Sevk Tarihi içinde yapıyoruz. Preview yaptığınızda tarihlerin gün-ay-yıl olarak geldiğini göreceksiniz.

Tarih parametresi eklemek için Dataset – Dataset üzerinde sağ tıklayarak Query penceresini açıyoruz.

SSRS-182

Sorgunun FROM kısmından sonra WHERE koşulu yazarak tarih parametresi ekleyeceğiz.

WHERE (Sales.SalesOrderHeader.ShipDate BETWEEN @BasTarih AND @BitisTarih) Where koşulunu sorgu alanına ekledikten sonra, kontrol amaçlı sağ tıklayarak Execute SQL diyoruz.

SSRS-183

Koşulu yanlış yazsaydık eğer hata verecekti, Query Parameters ekranı açıldı. 2005 yılına ait satışları sorgulamak için BasTarih’e 1.1.2005 BitisTarih’e de 31.12.2005 yazalım.

SSRS-184

Sonuç ekranına 2005 yılına ait satışlar geldi, parametrelerimiz ve sorgumuz düzgün çalışıyor.

SSRS-185

Şimdi desing ekranına gelelim, preview ile raporu çalıştıralım. Görüldüğü gibi, tarih alanları text olarak geldi, bu şekilde tarih yazmak uzun sürecektir.

SSRS-186

Takvim üzerinden tarihi seçmeli yapmak, hem görsel açıdan hem de kullanım açısından daha iyi olacaktır. Parameters alanından BasTarih parametresinin özelliklerine giriyoruz.General sekmesinde aşağıdaki şekildeki gibi Data Type’ı Date/Time seçiyoruz.

Raporda gözüken isminide Prompt kısmından değiştiriyoruz.

SSRS-187

Aynı işlemi BitisTarihi parametresi içinde yapıp, preview ile raporu çalıştırıyoruz.

Parametrelerin yanına takvim butonları otomatik olarak eklendi, takvim ekranları sayesinde istediğimiz tarihi kolay seçebiliyoruz.

Ocak – Aralık 2007 arası tarihi seçtikten sonra raporu çalıştıyoruz.

SSRS-188

7 – 3 Report Builder’da Parametre Ekleme:

Report Builder’da nasıl parametre eklenir buna bakacağız. Boş bir rapor açıyoruz. Datasource’u Adventureworks2012 olarak ayarladıktan sonra, Dataset’i aşağıdaki şekildeki ayarlıyoruz. Product ve ProductInventory alanlarından istediğimiz alanları seçiyoruz.

SSRS-189

Relationships sekmesi en sağdaki aşağı bakan oklara basarak genişlettiğimizde, her iki alanda da ProductID alanı ortak alan olduğundan ve AutoDetect seçili durumda olduğu için, iki tabloyu otomatik olarak birleştirdi, eğer ortak bir alan olmaz ise bu işlemi kendimiz yapmalıyız.

SSRS-190

Parametre atama işlemini Applied filters kısmından yapıyoruz. Filtre ikonuna tıkladığımızda otomatik olarak algıladığı ortak anahtar alanını filtre olarak bizlere getirecek.

SSRS-191

Bu alanda en sağda Parameter kutusunu işaretlediğimizde, bu filtre artık parametre olarak çalışacaktır. Value kısmında da istersek varsayılan bir değer atayabiliriz. Raporu her aldığımızda ilk önce bu varsayılan değere göre rapor alır, daha sonra istediğimiz parametre girerek yeniden View Report dediğimizde istenen değere göre verileri getirir. Örnek verirsek, varsayılan olarak geçen senenin raporu ilk önce gelsin diye bir istek gelebilir, Value kısmına 2013 yazarak ilk önce geçen senenin verilerinin getirilmesini sağlayabilirsiniz.

SSRS-192

Dataseti oluşturduk, boş rapor ekranında, Insert menüsünden Table Wizard ekliyoruz.

SSRS-193

Choose a Dataset ekranında oluşturduğumuz Dataset1’i seçip devam ediyorız.

Details kısmına alanları aşağıdaki ekleyip devam ediyoruz.

SSRS-194

Choose a layout ekranında seçenekler pasif geldi, çünkü satır veya kolon tarafında bir gruplama yapmadık.

Herhangi bir style seçip devam ediyoruz. Rapor oluştu, parameters klasörünü altına parametremiz geldi.

SSRS-195

8 – VERİLERİ SIRALAMA – İNTERAKTİF SIRALAMA:

Raporların daha okunabilir olması için verilerin büyükten küçüğe veya küçükten büyüğe sıralanması gerekmektedir. Reporting service’te veriler ister Query ekranında Order by koşulu ile, istersek de Tablo özelliklerinden Sorting bölümünden sıralmasını yapabiliriz. Ayrıca rapor çalıştıktan sonra da interaktif olarak rapor başlıklarına atanan butonlar ile interaktif sıralama yapabiliriz.

8 – 1 Tablo İçerisindeki Verileri Sıralama:

Tablo içindeki verileri sıralamak için ilk önce AdventureWorks veritabanındaki Person tablosundan isim ve soyisimleri kapsayan basit bir rapor hazırlayalım.

Yeni rapor dedikten sonra, Query ekranında Person (Person) tablosunu ekleyerek alanları aşağıdaki gibi ayarlıyoruz.

SSRS-196

Tabular rapor olarak seçip devam ediyoruz, Desing the table ekranında üç alanıda detail bölgesine getiriyoruz. Rapora isim verip, tasarım ekranına geliyoruz.

Preview yaptığımızda isimlerin karışık bir şekilde geldiğini görüyoruz.

SSRS-197

Tablix özelliklerini açmak için, tablonun üzerine bir kere tıkladıktan sonra, sol ve üst tarafta açılan kenarların köşesinden sağ tıklayıp, Tablix Properties penceresini açıyoruz.

SSRS-198

Sorting sekmesine gelip, Add ile boş bir alan ekliyoruz. Hangi alana göre sıralama yapılacak ise Sort by kısmından ilgili alanı seçiyoruz. Sıralamanın büyükten küçüğe olması için Order kısmında Z-A olarak, küçükten büyüğe olacak ise A-Z olarak seçiyoruz.

SSRS-199

İsime göre küçükten büyüğe sıralamayı oluşturduk.

SSRS-200

8 – 2 İnteraktif Sıralama:

İnteraktif sıralama, raporu çalıştırdıktan sonra veri kolonlarını sıralamayı sağlayan rapor içi çalışan bir özelliktir. Üst tarafta oluşturduğumuz personel isimleri raporu üzerinde interaktif sıralamayı görelim.

Reporting Service’te tablixlerin içindeki hücrelere bir kere tıkladığınız da Textbox’ı seçer, ikinciye tıkladığınızda da Selected Text yani hücre içindeki yazıları seçer. İnteraktif sıralama yapmak için, bir kere tıklayarak Textbox’ı seçmemiz ve sağ tıklayarak Text Box Properties özellikler penceresini açmamız gerekmektedir. HÜcreye yanlışlıkla iki kere tıkladıktan sonra sağ tıklama menüsü değişir.

Name Text box’ına sağ tıklayarak Text box Properties özellikler ekranını açıyoruz.

SSRS-201

Interactive sorting sekmesinde, Enable interactive sorting on this textbox seçeneğini işaretliyoruz. Sort by kısmından da ilgili alanı seçiyoruz. Bu sıralamanın diğer tablo ve verisetlerini de kapsamasını istiyorsak aşağıdaki Apply this sorting to all groups and data regions in seçeneğinden ayarlamamız gerekiyor.

SSRS-202

Aynı işlemi soyadı alanı içinde yapıyoruz.

Preview ile raporu çalıştıralım, ad ve soyad alanlarının yanında yukarı ve aşağı doğru sıralama butonları geldi. İsime göre büyükten küçüğe sıralama yapalım.

SSRS-203

Soyadına göre küçükten büyüğe sıralama yapmak için Soyad’ın yanındaki butona tıklıyoruz.

SSRS-204

9 – BAĞLANTILI RAPOR OLUŞTURMA:

Reporting Service raporlarında bir rapordan diğerine bağlantı vererek, raporlar arası geçiş yapılabilmektedir. Özet bir tablo üzerindeki satırlardan, her bir satırdaki verinin bağlı olduğu detaylı rapora ulaşmak mümkündür. Text box özelliklerinden Action menüsündeki Go to Report seçeneği kullanılarak diğer rapor geçiş sunmaktadır. Bir örnek ile daha detaylı anlamaya çalışalım.

Solution Explorer – Reports – Add new reports.

Dataset olarak Adventureworks veritabanını seçiyoruz.

Query Designer – Add Table ProductCategory (Production) tablosunu ekleyip, ProductCategoryID ve Name alanlarını seçiyoruz.

SSRS-205

Report Type – Tabular

Design the table – Sadece name kısmını detail bölümüne getirip devam ediyoruz.

Table Style – Generic seçiyoruz

Rapor ismi veriyoruz – Finish

Kategoriler raporu olarak ana ürün kategorileri raporunu oluşturduk.

SSRS-206

Preview ile raporu çalıştırıp, kontrol edelim.

SSRS-207

Name alanına sağ tıklayıp, Text box özelliklerini açıyoruz. Action sekmesinden “Go to Report” seçeneğini seçip, daha yapmış olduğumuz Parametreli Raporu seçiyoruz.

SSRS-208

Use the parameters to run the report bölümünde Add diyerek, yeni bir parametre ekliyoruz. Eğer burada parametre eklemez isek, bağlantılar çalışmayacaktır. Bu parametrelere göre ikinci rapor bağlantıları çalışacaktır. Name kısmında UrunID, parameter kısmında ise ProductCategoryID yi seçiyoruz.

SSRS-209

Raporu preview ile çalıştırdığımızda, görünüşte bir fark olmadı. Kategorilerin üzerine gelince tıklanabilir özelliği aktif oldu. Kategoriler tıkladığımızda karşılık gelen parametreli rapor otomatik olarak açılıyor.

SSRS-210

Kategorilerin tıklabilir olduğunu daha iyi gösterebilmek için, web Url görünümünde, karakter rengini mavi ve alt çizgili olarak ayarlıyoruz.

SSRS-211

Kategorilerin son halini görmek için previewi çalıştırıyoruz.

SSRS-212

10 – REPORT PARTS:

Report partlara rapor parçaları da diyebiliriz. Oluşturduğumuz raporlardaki tablo, rectangle, parametreleri v.b. publish (yayınla) yöntemi ile, farklı raporlarda da kullanabilmemizi sağlayan bir özelliktir.

Örnek olarak, fatura üzerinde adres bilgisi içeren bir textbox’ı irsaliye ve diğer raporlarda da kullanabilmeniz için, bu adres textbox’ını report parts’a publish ederek diğer tüm raporlarınıza çağırıp kullanabilirsiniz. Daha önce oluşturduğunuz bir tabloyu farklı bir raporda da kullanmak için, tabloyu tekrardan kullanmanıza gerek kalmadan report part’tan kullanabilirsiniz.

Birbirine benzer raporlar yapmaya başladığınızda çok sık kullanacağınız bir özelliktir. Rapor oluşturma sürecinde sizi hata yapmaktan ve zaman kaybından kurtaracaktır.

Report part’tan eklediğiniz bir nesnenin, datasource ve dataset’i otomatik olarak oluşur, tekrardan datasource ve dataset eklemenize gerek kalmaz.

Report partlar, Reporting Service’in Report Manager dediğimiz web arayüzünden açılan, “Report Builder” programı ile açılır, makalenin başında Report Builder ile örnekler vermiştik. Report partlarda Report Builder programı ile oluşturulduğu için Report partlar nasıl oluşturulur, nasıl kullanılır örneklerle anlatmaya çalışalım.

Report Builder programını açıyoruz. Şekil SSRS-58.

Daha önce oluşturduğumuz parametreli raporu open ile açıyoruz.

SSRS-213

SSRS-214

Raporun sağ tarafına adres bilgisi içiren bir textbox ekliyoruz.

SSRS-215

Menü butonuna tıklayarak, Publish Report Parts’ı açıyoruz.

SSRS-216

Karşımıza iki seçenek geliyor, “Publish all report parts with default settings” tüm rapor bölümlerini varsayılan ayar kullnarak yayınla. Diğer seçenek, “Review and modify report parts before publishing” rapor bölümlerini gözden geçirip ve düzenleyip yayınla seçeneği geliyor. İkinci seçenek ile devam edeceğiz, hangi bölümleri alacağımıza karar verip daha sonra yayınla diyeceğiz.

SSRS-217

Yayınlanacak bölümler ekrana geliyor, fakat burada adres textbox’ı gelmedi. Textbox’lar tek başlarına report part olamazlar. Report olabilmeleri için Rectangle içinde Insert – Textbox diyerek oluşturulmaları gerekmektedir.

SSRS-218

Adres alanında gelmesi için Close diyerek Report parts ekranını kapatıyoruz. Insert – Rectangle diyoruz, rectangle’ın içinde sağ tıklayarak Insert – Textbox diyerek adres alanını bu textboxın içine yazıyoruz.

SSRS-219

Tekrardan publish report parts – review and modify parts bölümüne gidiyoruz. Adres textbox’ı report parts olarak geldi.

SSRS-220

Report part isimlerinin yanında oka tıklayarak açıklama bölümünü ve report partı hangi klasöre kaydeceğimizi seçebileceğimiz ekranı açıyoruz. Report part hakkında bir açıklama yazarak daha sonra hatırlamansı kolay olacaktır.

SSRS-221

Publish diyerek report partları servera yüklüyoruz. Sorunsuz bir şekilde publish edildi, report partların ikonları değişti, puzzle parça ikonuna benzer bir ikon eklendi.

SSRS-222

Report partları yükledik, şimdi report partları nasıl kullanırız bunu görelim. Sol üstteki menü butonuna tıklıyoruz,New diyerek yeni bir blank-boş rapor oluşturalım.

SSRS-223

Insert sekmesine gelerek, Report Parts’a tıklıyoruz. Yan tarafta Report Part Gallery açıldı.

SSRS-224

Çok fazla report part olacağı düşünülerek, arama kutusu konulmuş, Report Part Gallery ilk açtığımızda daha önce kaydettiğimiz report partlar gelmiyor. Tüm report partları görmek istiyorsak arama butonuna tıklayarak hepsini getirebiliriz veya aradığımız report partın adını girersek ilgili report part gelecektır. Arama butonuna tıklayarak tüm report partları getirelim.

SSRS-225

Tüm report partlar geldi, table1 ve Rectangle3-adres nesnesini sürükleyip raporun içine bırakıyoruz.

SSRS-226

Table report partını sürükleyince, otomatik olarak Datasource ve Dataset oluşmuş oldu. Run’a tıkladığınızda raporun çalıştığını göreceksiniz. Report parttaki nesnelerde bu bilgiler olduğu için, tekrardan oluşturmaya gerek kalmıyor. Report partlar benzer rapor oluşturmada veya benzer nesnelerin kullanıldığı raporlarda kullanıcılara zaman kazantırmakla beraber hata yapma olasılığını da en aza indirgemektedir.

11 – SUBREPORTS:

Subreports alt rapor anlamına gelmektedir. Rapor içine daha önce oluşturulmuş bir raporu ekleyebilmenize imkan verir. Daha önce yapılmış bir raporu, yeniden oluşturmak yerine subreport seçeneği ile yeni rapora dahil edip kolaylık sağlamaktadır.

Subreport nasıl eklenir, nasıl kullanılır açıklmaya çalışalım.

Yeni bir blank report oluşturuyoruz.

SSRS-227

AdventureWorks data source’unu oluşturuyoruz.

SSRS-228

Dataset olarak Production – ProductCategory tablosundan ProductCategoryID ve Name alanlarını ekliyoruz. Kontrol amaçlı Run Query’e tıklayıp, sonuçları aşağıda görmemiz gerekiyor.

SSRS-229

Insert menüsüne gelerek rapora bir List ekliyoruz. List bulunduğu bölgedeki verileri sürekli olara sunan bir yapıya sahiptir, veri listeside diyebiliriz. List in alanını bir sayfa kadar geniş bırakırsak eğer her sayfaya bir kayıt gelecek şekilde ayarlar.

SSRS-230

Name alanını list içine sürükleyip bırakıyoruz. Yazı boyutunu biraz büyütüp, Bold yapıyoruz.

SSRS-231

Run diyerek, kategorilerin sayfada nasıl durduğuna bakıyoruz.

SSRS-232

Kategoriler arasında eşit seviyede aralık oluşturmuş olduk, bu boşluk kısma şimdi subreport ekleyeceğiz. Insert Subreport butonuna tıklıyoruz. Buton rengi turuncu oldu, Name alanının altına subreportu genişleterek ekliyoruz.

SSRS-233

Subreport alanını belirttik, önceden oluşturulmuş olan bir raporu subreport olarak belirtmemiz gerekiyor. Reporting service’te subreport mantığı bu şekilde çalışmaktadır. Eş zamanlı rapor oluşturup, birini subreport olarak ayarlanmasına izin vermiyor.

Subreport üzerinde sağ tıklayarak Subreport Properties – özellikler ekranını açıyoruz.

SSRS-234

Name kısmından subreport’a isim verebilirsiniz, birden çok subreport kullanılacak ise anlamlı bir isim vermek önemlidir.

“Use this report as a subreport” bölümünde “Browse”a tıklayarak, ekleyeceğimiz subreport’u seçiyoruz.

Daha önce kategorilerin olduğu parametreli raporu subreport olarak ekliyoruz.

SSRS-235

Daha önceden oluşturduğumuz parametreli raporu seçiyoruz.

SSRS-236

Properties ekranında Parameters sekmesine gelip, subreport’u çalıştıracak parametreyi ilişkilendiriyoruz. Ana rapor ile subreport arasında bir ilişki yok ise subreport çalışmayacaktır.

SSRS-237

Run diyerek raporu çalıştıralım.

SSRS-238

Rapor ana kategoriler üstte olmak üzere, altında da subreport gelmiş gözüküyor. Subreportlar daha önce hazır olan raporları kullandığından bizlere hız ve kolaylık sağlamaktadır, ayrıca karmaşık raporlarda tablo karışıklığının da önüne geçilmiş olur.

Makalemin üçüncü bölümünün sonuna geldik, bir sonraki bölümde görüşmek üzere.

Makalemin ilk bölümlerine aşağıdaki linklerden ulaşabilirsiniz.

http://www.cozumpark.com/blogs/sql/archive/2014/08/17/sql-server-reporting-services-bolum-1.aspx

http://www.cozumpark.com/blogs/sql/archive/2014/08/17/sql-server-reporting-services-bolum-2.aspx

http://www.cozumpark.com/blogs/sql/archive/2014/08/17/sql-server-reporting-services-bolum-3.aspx

12 – RAPOR BAŞLIK VE ALT BAŞLIKLARI – HEADERS FOOTERS

Raporların daha anlaşılır ve rahat okunabilirliği için başlık ve alt başlıklar kullanılmaktadır. Başlık – Header kısmına genelde raporun adı yazılır, ilave olarak da firma logosu v.b. yerleştirilebilir.. Alt Başlık – Footer kısmına ise, rapor çalışma saati, sayfa numaraları v.b. nesneler yerleştirilebilir.

Report Builder da New – Blank Report oluşturduğunuzda otomatik olarak başlık ve page footer’ı atama yapar. Page header’ı başlığı atama yapmaz. Page footer’da execution time – rapor çalıştırma saatini otomatik olarak getirir.

SSRS-239

Page footer ve header da genellikle Report Data da bulunan “Built-in fields” alanları kullanılır. Bu alanlar;

- Execution Time – Rapor çalıştırma zamanı

- Language – Yerel dil

- Overall Page Number – Toplam sayfalar içindeki sayfa numarası

- Overall Total Pages – Toplam sayfa sayısı

- Page Name – Belirtilinen sayfa adı

- Page Number – Sayfa numarası

- Render format IsInteractive – Rapor görüntüleme formatının interaktif olup olmadığını true-false olarak döndürür.

- Render Format Name – Görüntüleme formatı bilgisini verir

- Report Folder – Raporun sunucu da hangi klasörde tutulduğu bilgisi

- Report Name – Raporun tekil olarak isim bilgisini içerir

- Report Server Url – Rapor sunucusunun web adresi bilgisi

- Total Pages – Toplam rapor sayfası bilgisi

- User ID – Raporu çalıştıran kullanıcının domain ve kullanıcı adının bilgisini verir

SSRS-240

Raporda sayfa numaraları ile ilgili bir örnek yapalım, hangi sayfada olduğumuzu gösteren built-in alanını aşağıdaki yazmamız gerekiyor. Sayfa 5 – 10, toplam 10 sayfa 5. Sayfadasın gibi.

Page footer’a bir textbox ekleyelim.

Textbox’a sağ tıklayıp expression alanına aşağıdaki kodu yazıyoruz.

SSRS-241

Sayfa numaralarını görmek için, report parts’dan daha önce oluşturduğumuz tabloyu raporumuza ekleyelim.

SSRS-242

Home – Run diyerek raporu çalıştırıyoruz.

Raporuın sayfa sonlarına baktığımızda hangi sayfada olduğumuzu ve toplam kaç sayfa olduğunu gösteriyor.

SSRS-243

13 – RAPOR YAZDIRMA – SAYFA YAPISI – DIŞA AKTRAMA (EXPORTING) – RAPOR ÖZELLİKLERİ:

Raporların oluşturduktan sonra, bazı raporların yazıcıdan çıktı alınmadan önce ayarlarının yapılması gerekir, sayfa ayarlarını kontrol etmeden hazırladığınız raporlar yazıcıdan çıkarken birçok sayfaya yazılacaktır. Sayfa ayarları ve dışa aktarma seçenekleri reporting service’te nasıl olur, bunları inceleyelim.

Raporlar dışa aktarıldığında, o andaki ekranda rapor nasıl gözüküyor ise o şekilde aktarılmış olur. Drillthrough raporlarda satırlar genişletilmiş halde export edilse ise, satılar açık gözükür, aktarım yapıldıktan sonra interaktif seçenekler haliyle devre dışı kalmaktadır.

13 – 1 Dışa aktarma (Exporting):

Report manager web site’dan sıralamalı raporu çalıştıralım.

SSRS-244

Raporu çalıştırıyoruz. Raporları report managerdan export etmek için, alt tarafında yeşil ok olan mavi disket ikonuna tıklamamız gerekiyor.

SSRS-245

Pdf seçip export ediyoruz. Pdf dosyasını açtığımızda, interaktif sıralamaların olmadığı ve raporun son hali nasılsa o şekilde aktarildığı gözükmekte.

SSRS-246

Report manager web site üzerinde 7 farklı formatta export işlemleri yapılabilmektedir, bunlar;

- XML file with report data – Rapor verileri ile birlikte xml dosyası

- CSV

- PDF

- MHTML

- Excel

- TIFF File

- Word

Şekil SSRS-245 te üstteki menülerden mavi disket ikonuna tıklayıp rapor export seçenekleri çıkmaktadır.

13 – 2 Sayfa Yapısı – Rapor Özellikleri:

Raporları yazdırmak istediğimizde, reporting service varsayılan olaran sayfa boşlukları bırakmaktadır. Bu sayfa boşlukları raporun gerekisiz yere bir veya birden fazla sayfaya çıkmasına sebep olmaktadır. Rapor sayfa ayarlarını açmak için, rapor sayfasının dışındaki alanda sağ tıklayarak, “Report Properties” ekranını açıyoruz.

SSRS-247

Report Properties ekranlarını tanıyalım;

- Page Setup: Sayfa ayarları ekranında, ölçü birimleri inç ve cm, sayfa düzeni yatay-dikey, sayfa boyutu, ve kenar boşlukları-margins ayarları bulunmaktadır. Varsayılan olarak sayfa düzeni Portrait ve marginler 2cm olarak gelmektedir. Export edilen raporlar eğer büyük ise ve sayfaya tam oturmuyor ise, bu ekrandan Paper size ve marginler düzenlenerek raporun bir sayfaya veya daha düzgün görüntülenmesini sağlayabiliriz. Bir raporu publish (yayınlamak) etmeden önce mutlaka Page Setup ayarlarını değiştirmemiz gerekmektedir.

SSRS-248

- Code: Reporting service, custom code desteklemektedir, örnek olarak hesaplama yapılan alanlarda genel toplam almak istediğinizde reporting service hata verecektir, bu gibi hataların önüne geçmek için custom-özelleştirilimiş kod kullanmamız gerekmektedir. Custom code konusuna daha sonraki makalelerde değineceğiz.

SSRS-249

- References: Referans olarak assembly dll dosyalarını ve kullanılmak istenen class’ları bu ekrandan ekleyebilmekteyiz. Farklı yazılım çözümlerinin entegresinde kullanılmaktadır.

SSRS-250

- Variables: Değişken atayabileceğimiz bölümdür.

14 – SHARED DATA SOURCES – PAYLAŞILAN VERİ KAYNAKLARI:

Aynı Sql serverdaki veritabanını kullanarak birden fazla rapor yapılmaya başlandığında, her yeni raporu oluştururken mutlaka Data Source – Veri kaynağını tanımalamak zorundayız. Her defasında bu zahmete katlanmak yerine, sürekli kullanacağımız veri kaynağını Shared Data Source yaparsak, bir sonraki raporlarda hazır bir şekilde veri kaynağını seçebiliriz.

Report Builder tarafında data sourcelar shared yapılamamaktadır. Shared data source yapmanın iki yöntemi vardır;

- Report Manager – New Data Source

- VS Data Tools – Datasets – Convert to shared data souce

Report Manager web sitesini açıyoruz. Üst menüde bulunan “New Data Source”a tıklıyoruz.

SSRS-251

Açılan ekranda Data source’a bir isim veriyoruz, açıklama alanına daha sonra hatırlanması kolay bir açıklama yazılabilir.

Data Source Type varsayılan olarak Sql Server olarak gelmektedir.

SSRS-252

Connection string bölümünü elle yazmamız gerekiyor. Hata yapmamak için, daha önce oluşturduğumuz bir data source’daki connection string cümlesini kopyalayıp buraya yapıştırıyoruz.

SSRS-253

Connection string alanına yapıştırıyoruz.

SSRS-254

Data source için yetkilendirmeyi de yaptıktan sonra “Test Connection” ile kontrol ediyoruz.

SSRS-255

Ana ekrana shared data source’umuz geldi. Shared data sourcelar için bir klasör oluşturulup, bu klasörde tutulamaları daha iyi olacaktır.

SSRS-256

Report builder’da Shared Data Source’u nasıl kullanacağız buna bakalım. Report Manager’daki Report Builder kısayoluna tıklıyoruz.

New Report diyerek yeni bir rapor oluşturalım.

Create a new dataset diyerek ilk ekranı geçelim.

Data Source Connections ekranında New diyerek yeni bir data source oluşturuyorduk, şimdi “Browse” diyerek Shared Data Source’umuzu seçeceğiz. Browse butonuna tıklıyoruz.

SSRS-257

OrtakVeriKaynagi adındaki data source’umuzu seçip Ok diyoruz. Shared data source nasıl kullanılır görmüş olduk.

SSRS-258

VS Data Tools tarafında ise, Datasource altındaki veri kaynağının üzerinde sağ tıklayarak Convert To Shared Data Source dediğimizde, dataseti Shared Data Set’e çevirebilmek mümkündür.

SSRS-259

Shared datasource un Solution Explorer’da “Shared Data Sources” klasörüne otomatik olarak eklenmektedir.

SSRS-260

15 – SHARED DATA SETS – PAYLAŞILAN VERİ SETLERİ:

Reporting Service üzerinde veri kaynakları paylaşıldığı gibi, veri setleri de paylaşılabilmektedir. Daha önce oluşturduğunuz bir verisetini, sonradan da kullanmak isteyebilirsiniz, özellikle karmaşık sorgular içeren veri setlerinin tekrar oluşturulması büyük bir vakit kaybına sebep olacaktır. Tekrardan karmaşık bir veriseti hazırlanmasında oluşabilecek hataların önüne Shared Datasets lle geçebilirsiniz.

Shared Datasetler nasıl oluşturulur, nasıl kullanılır inceleyelim.

İlk önce Shared datasetlerimiz için Report Manager’da bir klasör oluştralım, adına da Paylaşılan Verisetleri diyelim. Report Manager üst menüde “New Folder”a tıklıyoruz.

SSRS-261

Paylaşılan Verisetleri diye klasöre isim veriyoruz.

SSRS-262

Klasörü oluşturduktan sonra, Report Manager – Report Builder programını açıyoruz.

New Report’un altında “New Dataset”e tıklıyoruz. Daha önceden oluşturduğumuz Shared Data Source otomatik olarak gelmiş durumda. Create diyerek devam ediyoruz.

SSRS-263

Query ekranında Product ve ProductCategory tablolarından alanları aşağıdaki şekildeki seçtikten sonra, Run Query ile sorguyu çalıştırıp kontrol ediyoruz.

SSRS-264

Sorguyu kontrol ettikten sonra, verisetini Paylaşılan Verisetleri klasörüne kaydediyoruz.

SSRS-265

Kaydettikten sonra Report Builder’ı kapatıyoruz. Shared Dataseti oluşturduk. Şimdi Report Builder’ı açıyoruz, yeni bir rapor oluşturacağız.

New Report – Table or Matrix Wizard

Choose a dataset ekranında “Choose an existing dataset in this report or a shared dataset” seçeneğini işaretleyip “Browse” butonuna tıklıyoruz.

SSRS-266

Açılan pencerede Paylaşılan Verisetleri klasörüne gidiyoruz ve Shared Datasetimiz olan “UrunKategoriVeriseti”ni seçiyoruz.

SSRS-267

Verisetinin ikonunun yanında yukarı doğru bakan bir ok işareti oluştu, bunun anlamı bu verisetinin paylaşılan bir veriseti olduğunu belirtmektedir. Next ile devam ediyoruz.

SSRS-268

Alanları aşağıdaki gibi düzenledikten sonra, Next ile devam ediyoruz.

SSRS-269

Choose a layout kısmını olduğu gibi bırakıyoruz.

Choose a style’den herhangi bir tasarımı seçip Finish ile sihirbazı tamamlıyoruz.

Rapor hazırlandı, Shared Dataset olan UrunKategoriVeriseti geldi. Shared Dataset’in içinde datasource gömülü olduğundan, report data – Datasource kısmına veri kaynağını eklemeye gerek kalmadı.

SSRS-270

VS Data Tools ile Shared Dataset ise Datasets klasöründe ilgili dataset’e sağ tıklayıp, Convert to shared dataset seçeneği ile olmaktadır.

SSRS-271

Shared dataset, Solution Explorer’da Shared Datasets klasöründe otomatik olarak oluştu, projeyi build – deploy ettiğimizde Report manager tarafına da otomatik olarak yüklenmiş olacaktır.

SSRS-272

Bir raporun birden çok versiyonları yapılacak ise Shared Dataset ile ne kadar kolay olacağını görmüş olduk.

16 – REPORT MANAGER WEB SITE YÖNETİMİ:

Reporting Service’in görsel olarak sunulduğu yer Report Manager Web Site’dır. Kurulumda otomatik olarak kurulan, sadece configuration manager’dan linkini öğrenip kullanmaya başlıyoruz. Şekil SSRS-18’de Report Manager Url’sine nasıl bakılır görmüştük. Report Manager nasıl yönetilir, Report Manager’da neler yapabiliriz, şimdi bunlara bakacağız.

16 – 1 Raporların Düzenlenmesi:

Report manager da klasörler açabilir, bu klasörlerin içlerini de istediğiniz kadar klasör açıp düzenleyebilirsiniz. Klasörler halinde çalışmak departmanlar arası görmelerini istemediğiniz bölümlerin raporlarını rahatlıkla yönetebilme imkanı sunar.

New Folder’dan yeni bir klasör oluştuyoruz.

SSRS-273

Departmanlar arasında yetkiler vereceğimden, klasörlere departman isimlerini örnek olarak veriyoruz.

SSRS-274

Pazarlama isminde bir klasör daha açıyoruz.

Mevcut bir raporu bu klasörlere taşıyabiliriz. Bunun için raporun üzerine geldiğimizde Open Menu penceresi aktif olacak. Menüye tıklayarak “Move” diyoruz.

SSRS-275

Gelen ekranda hangi klasöre taşıyacağımı belirtip Ok diyoruz.

SSRS-276

Pazarlama klasörüne gidip kontrol ediyoruz.

SSRS-277

Satış raporu Pazarlama klasörünün altına kopyalanmış oldu.

16 – 2 Report Manager Güvenliği:

Reporting Service’in güzel taraflarından biride Active Directory ve Exchange uyumlu olmasıdır. Microsoft’un kendi programları arasındaki uyumluluk burada da kendini göstermekte. İlk Report Manager’ı açtığınızda lokal bir notebooka kurduğunuzdan sadece BUILTIN\Administrators kullanıcılarını ekler. Site Settings – Securty kısmında sadece bu kullanıcının yani bu grubu görürsünüz.

Hatta ilk Report Manager ana ekranında Report Builder gözükmez, size full yetkiler vermez. Lokal admin olarak kendi kullanıcınıza yetki verebilmeniz için Site settings – Security kısmından lokaldeki kullanıcı adınızı System Administrator olarak eklemelisiniz.

SSRS-278

Raporlara kimlerin erişmesini istiyorsanız, Open Menu seçeneğinden Security kısmından kullanıcıları seçebilirsiniz. Fakat bu zor olan yöntemdir. Her rapor için tek tek uğraşmanız gerekir. Departman bazında klasörler yapmıştık, klasör bazında yetkilendirme verirseniz, daha az zaman harcamış olursunuz. Tek tek her rapor yetkisi uğraşmak yerine bir ana klasörün yetkisiyle uğraşmak daha kolaydır.

Report Manager’ın ana sayfasına kullanıcıların erişmesi için ilk önce Home konumundayken “Folder Settings”e gelip istenen kullanıcıya yetki vermemiz gerekiyor, aksi takdirde kullanıcı Report Manager’a girdiğinde hata alır. Direk ilgili klasöre de yetki verdiğiniz zaman, son kullanıcıya o klasörün linkini tam olarak göndermeniz gerekmektedir.

SSRS-279

Kendi kullanıcımda full yetkiler var, sadece raporları görüntülemesini istediğiniz kullanıcılara “Browser” yetkisi verip kullanıcı açmanız gerekmektedir. “New Role Assignment” ile yeni kullanıcıya yetki veriyoruz. Not: Yeni kullanıcı açmıyoruz, domain veya lokaldeki mevcut kullanıcıya yetki verilmektedir. Reporting Service yeni bir kullanıcı açmaz.

SSRS-280

Role Assigment ekranında ister kullanıcı ister grup ismini verebilirsiniz. Active Directory bulunan bir ortamda, kullanıcı isimlerini ve grupları kendisi algılamaktadır.

Lokal bir pc de, daha önceden oluşturulmuş bir kullanıcı olması gerekmektedir. Rapor isminde bir kullanıcıya Browser yetkisi vererek oluşturmaya çalışalım.

SSRS-281

Ok dediğimizde aşağıdaki hatayı verecektir, çünkü bu pc de böyle bir kullanıcı mevcut değildir.

SSRS-282

Bilgisayarın yönet kısmından, Rapor isminde lokal bir kullanıcı açarak tekrar deniyoruz.

SSRS-283

Lokalde önceden açtığım kullanıcıyı kabul etti. Domain ortamında da varolmayan bir kullanıcı veya grubu kabul etmeyecektir.

16 – 3 Rol Atamaları:

Rol atamaları tüm klasörlerin ve ana klasörün Folder Settings kısmında bulunmaktadır. Ana klasördeki ilk yetkiler ne ise, daha sonra açılan klasördeki yetkilerde aynısı olur. Yani üstten – alta yetki ataması olmaktadır.

Yeni rol ataması dediğimizde karşımıza 5 farklı rol çıkıyor, kısaca bunları tanıyalım;

- Browser: En sık kullanacağınız roldür, sadece raporu görüntüleme yetkisi verir. Bu role sahip bir kullanıcı rapora müdahale edemez.

- Content Manager: En kapsamlı roldür, bu role sahip kullanıcı Report Manager’ı yönetmek yetkisine sahip oluır.

- My Reports: My Reports klasörü altında kendi raporlarını oluşturup ve yönetebilme yetkisine sahip olan bir roldür, departmanlar içinde rapor oluşturmayı öğrenen kullanıcılara verilebilecek bir roldür.

- Publisher: Report serverda raporları yayınlama hakkına sahip olan roldür.

- Report Builder: Rapor oluşturma ve açıklamaları görme yetkisine sahip kullanıcıdır.

SSRS-284

Reporting Service’te yetkilendirme konusuna değindik, özetlersek, istediğimiz bir grubu veya kullanıcıya yetki verebiliyoruz. Raporlara erişecek kişi veya grupları tek tek yönetmek yerine, benzer raporları örnek olarak departman bazlı raporları bir klasörde toplayarak, o klasörün yetkilerini ayarlayarak, tek tek herbir raporun yetkisi ile uğraşmamıza gerek kalmayacak.

17 – BİLDİRİMLER – SUBSCRIPTIONS:

Raporların sunumu için, web arayüzünden görüntüleme, export edebilme ve subscriptions, tam olarak abonelikler olarak çevirisi olsada, bildirimler demek doğru olacaktır. Hazırladığınız bir raporu istenen tarih ve istenen parametlerle, son kullanıcılara mail olarak veya dosya paylaşımı olarak bildirim yapmasına subscription denmektedir.

Mail bildirimi ile gönderim yapabilmek için, öncelikle Reporting Service kurulumunda anlattığımız şekil SSRS-19 daki Configuration Manager – E-mail Settings bölümündeki gibi ayarları tamamlamış olmamız gerekmektedir. Bir smtp sunucusuna ihtiyaç duymaktadır. Reporting Service Microsoft Exchange sürümleri ile sorunsuz çalışmaktadır.

Çoğu zaman periyodik raporlara kullanıcılar bakmayacaktır, sürekli aynı raporu almak zor geleceğinden, belli bir süre sonra Report manager web site arayüzü unutulur. Mail bildirimleri mailin gövde kısmına gömülü olarak geldiğinden, mail açan kişinin maili görmeme gibi bir şansı yoktur. Bu yüzden mail bildirimleri çok kullanacağınız bir özellik olacaktır.

Bir rapor mail olarak nasıl gönderilir, şimdi buna bakalım.

Raporun menü kısmından Subscription bölümüne giriyoruz.

SSRS-285

Karşımıza mail sayfası gibi bir ekran geliyor. Delivered by kısmında bu raporu mail mi yoksa File Share – Dosya paylaşımı olarak gönderilmesini belirttiğimiz alan.

To – Cc –Bcc, mail programlarından bildiğiniz alanlar. Kime ve bilgi alanlarını dolduruyoruz.

Reply-To – gelen bu maili reply dediğimizde hangi adreslere reply edilmesini istiyorsak ilgili mail adreslerini bu alana yazıyoruz.

Subject – Konu kısmında @ReportName – Rapor adını otomatik olarak getiri ve @ExecutionTime – Rapor alınma saatini konu başlığına varsayılan olarak getirmektedir. Konu kısmı isteğe değiştirilebilir ve parametre alabilmektedir.

Piority – Raporun önceliği var ise, önemli bir rapor ise piority high yapılabilir.

Comment – Bu kısma yazacağınız açıklamalar, raporun üzerinde blgi olarak gelecektir.

SSRS-286

Mailin ne zaman ve hangi periyodlarla gideceğini belirlemek için Select Schedule butonuna tıklıyoruz.

Report Manager Home sayfasında bir shared schedule oluştursaydık, On a shared schedule olarak seçilebilecekti.

Schedule Details ekranında, Saatlik, günlük, haftalık, aylık ve bir kereliğine mail gönderimi için takvimleme oluşturabilirsiniz.

Haftanın her günü saat 08:00’de raporu mail olarak göndermesini ayarlayarak, Ok’e basıyoruz.

SSRS-287

Tekrardan Report Delivery Options’a geldiğimizde, eğer raporda bir veya birden fazla parametre var ise, mailin hangi parametreye göre gideceğini belirtmemiz gerekmektedir.

SSRS-288

Parametreyide belirttikten sonra Ok ile aboneliği kaydediyoruz. Kayıt edilen bildirimler, Report Manager ana sayfasında “My Subscriptions” bölümünde tutulmaktadır. Buraya giderek, mail bildirimlerininb son durumuna bakabilir ve bildirimleri tekrardan düzenleyebilirsiniz.

SSRS-289

Mail gidecek olan raporlar listelenmiş durumda.

SSRS-290

Not: Subscriptionlar kullanıcı bazlıdır. Hangi kullanıcı yeni bir tanım yaptı ise sadece onun “My Subscription” kısmında görülür. Subscribe yetkisi olan kullanıcılar mail tanımları yaptıkları zaman, bu tanımlar diğer kullanıcılar etkilemez.

Bu makalede Reporting Service’in kurulum aşamalarından, raporların hazırlanması, görüntülenmesi ve daha birçok konuyu incelemiş olduk. Genel olarak raporlamalar excel programınd yapılmakta ve raporların hazırlanması saatler sürmektedir, ham veriyi excelde işlemek ciddi anlamda işçilik gerektirdiğinden, her defasında aynı işlemler yapılmaktadır. Reporting Service ile rapor hazırlama süreci biraz uzun sürsede, daha sonra size sağlayacağı fayda çok daha fazladır.

Makale biraz uzun sürdüğünden bazı konulara değinemedik, daha sonraki Reporting Service makalelerinde; Custom kod kullanımı, grafikler, sparklinelar, databarlar, indikatörler ve göstergeleri işleyeceğiz. Sorularınız olması durumunda benimle irtibata geçebilirsiniz.

Raporların son kullanıcıya ulaşmasındaki en önemli yöntemlerden biri de mail ile gönderimdir. Sql Server Reporting Service ile raporlar mail ile son kullanıcılara ulaştırabilmektedir. Reporting Service ile Exchange Server sorunsuz bir şekilde haberleşebilmekte ve sadece Exchange’in ip adresini SSRS – Configuration Manager’a yazmamız yeterli olmaktadır.

Yapısında Exchange Server olmayan, fakat raporların mail ile gönderilmesini isteyenler oldukça uğraşmaktadır. Bu makalede Gmail ile SSRS üzerinden nasıl mail bildirimleri gönderilir anlatmaya çalışacağım.

Makaledeki lab ortamı, Vmware üzerinde, Server 2012 R2 üzerine kurulu Sql Server 2012 versiyonudur. Sql Server 2014 ile de aynı şekilde uygulayabilirsiniz.

İlk olarak Server 2012 üzerine SMTP Server kurulumu yapacağız, ardından SMTP ayarlarını SSRS Configuration Manager’da yapılandıracağız, son olarak örnek bir raporu mail ile gönderip test edeceğiz.

Smtp kurulumu ile başlıyoruz. Server Manager – Add Roles and Features

SSRS-1

Before You Begin ekranını Next ile geçiyoruz.

Installation Type – Role-based or feature-based installation olarak seçip Next ile devam ediyoruz.

SSRS-2

Server Selection ekranını Next ile geçiyoruz.

Server Roles ekranında seçim yapmadan devam ediyoruz.

Features bölümünde “SMTP Server”ı seçip, açılan ekranda Add Feature’a tıklıyoruz.

SSRS-3

SMTP Server’ın check box’ı işaretlendi, Next ile devam ediyoruz.

Web Service Role IIS ekranını geçtikten sonra, Role Services ekranında varsayılan olarak seçilen servisleri değiştirmeden Next ile devam ediyoruz.

SSRS-4

Otomatik olarak restart etmesi için üstteki kutuyu işaretleyip Install ile Smtp Server kurulumunu başlatıyoruz.

SSRS-5

Results ekranına kurulacak servisler geliyor. Kurulum tamamlandıktan sonra, Administrative Tools – IIS 6.0 Manager’ı açıyoruz.

SSRS-6

(Start menüsü için Classic shell programı kullanılmıştır)

SMTP Virtual Server karşımıza geliyor. SMTP Virtual Server üzerinde sağ klik Properties ekranını açıyoruz.

SSRS-7

General sekmesinde sunucun ip adresini seçiyoruz.

SSRS-8

Access sekmesinde Relay butonuna tıklıyoruz.

SSRS-9

Relay Restrictions ekranında All except the list below seçeneğini seçip Ok ile devam ediyoruz

SSRS-10

Delivery sekmesinde Outbound Security’i açıyoruz.

SSRS-11

Basic authentication seçip Gmail kullanıcı adı ve şifremizi giriyoruz. Aşağıdaki TLS encryption kutusunu işaretleyip Ok ile devam ediyoruz.

SSRS-12

Outbound Connections’a tıklayıp açılan pencerede, TCP portuna 587 yazıyoruz.

SSRS-13

Advanced butonuna basıp, açılan ekranda

SSRS-14

Ok diyerek SMTP properties pencerelerini kapatıyoruz. Smtp server tarafında ayarları tamamlamış bulunuyoruz.

SSRS – Configuration Manager’ı açarak E-Mail Setting sekmesine Smtp server adresini ve gmail adresimizi giriyoruz.

SSRS-15

E-Mail Settings ekranında mail ve Smtp server’ı girdikten sonra Apply ile ayarları kaydediyoruz.

SSRS-16

Mail ayarlarını tamamaladıktan sonra, basit bir rapor yapalım ve bu raporu mail olarak gönderelim.

SSRS – Conf. Manager daki, Report Manager URL ile Report Web ekranımızı açıyoruz.

SSRS-17

Web site üzerinde Report Builder kısayoluna tıklayarak rapor tasarım aracımızı açıyoruz.

SSRS-18

Gelen uyarıyı Run diyerek geçiyoruz.

Örnek bir rapor yapacağımız için Table – Matrix Wizard ile devam edelim.

Create a Dataset’i seçip Next ile ilerliyoruz.

Datasource bağlantısını Adventureworks olarak ayarlıyoruz.

SSRS-19

Desing a Query ekranında Production – Views – vProductCatalog view ını seçip devam edelim.

SSRS-20

Aşağıdaki alanları seçip devam edelim.

SSRS-21

Choose a layout bölümünü Expand/Collapse seçeneğini işaretlemeden devam edelim. Raporu mail ile göndereceğimizden collapse şeklinde gelir ise rapor, mail ile gelen raporda da kapalı olarak gelecektir.

SSRS-22

Choose a stlye kısmında herhangi bir tasarım seçip devam ediyoruz.

Finish ile raporu tamamlıyoruz.

Run diyerek raporun çalışıp çalışmadığını kontrol ettikten sonra, raporu kaydediyoruz.

Raporun report manager url’e kaydedildiğinden emin oluyoruz.

SSRS-23

Raporumuz Reporting Service web site’ına geldi. Raporun üzerine gelince sağ tarafta beliren, aşağı ok işaretine tıklıyoruz. Açılan menüde Subscribe’a tıklıyoruz.

SSRS-24

Report Delivery Options ekranında mail kimlere gidecek ise mail adreslerini yazıyoruz, zamanlamasını ayarlıyoruz.

SSRS-25

Ok ile bu ekrandan çıkıyoruz. Raporun gidip gitmediğini kontrol etmek için, anasayfadaki My Subscriptions bölümünden takip edebiliriz.

SSRS-26

Mail başarılı bir şekilde gönderildi.

SSRS-27

Yahoo mailine de bilgi olarak göndermiştim, aşağıdaki gibi yahoo mailede rapor gelmiş durumda.

SSRS-28

Sql Server Reporting Service’te oluşturulan raporların Gmail ile mail olarak gönderilmesini görmüş olduk. SSRS kurulu olan her yapıda Exchange server veya smtp server kurulu olmayabilir, Smtp server kurup, Gmail ayarlarımızı tanımladıktan sonra SSRS ile sorunsuz bir şekilde çalıştığını gördük.

Sql Server güvenlik konusu son zamanlardaki hızla artan hacking olaylarından sonra iyice önem kazanmıştır. Sql Server Windows işletim sistemleri üzerinde bir servis olarak çalışmaktadır. Kullanıcılar yetkileri ve onlara atanmış olan haklar çerçevesinde SQL Server üzerinde sunulan veritabanı ve diğer yönetim başlıklarında değişiklik yapabilirler. Bu sebepten ötürü SQL Server güvenlik konusu ele alındığında sadece sunucu komponentlerinin güncel olması yeterli olmaz buna ek olarak kullanıcı hareketlerinin denetlenmesi ve yeterli miktarda saklanması da önemlidir. Bu başlık altında tabi ki SQL Server’ın tüm hizmetleri sunmak üzere kurulu olduğu Windows sunucularına ait alt katman güvenliğinin de sağlanmış olması gerekir.

İşletmelerde genellikle, Sql Server ile ilgili tüm konular yazılım bölümüne veya yazılımcıya atanmıştır. Bölümler arası çekişmeler veya senin görevin / benim görevim, sen yaptın / ben yaptım gibi anlaşmazlıklardan dolayı Sql Server’da ortaya çıkan sorunlar sahipsiz kalmakta, sistem bilgisi olmayan yazılımcıların bildiği kadar tedbirler alınmaktadır. Sql Server yazılımı bağımsız bir platformdur, herhangi bir yazılım dilinde yazılan bir program Sql Server’a veri aktarabilir ve okuyabilir. Bu sebeple yazılım ile veriyi birbirinden güvenlik platform tasarımı bakışı açısından ayırmak gerekir.

Bir yazılımın silinmesi/bozulması mı yoksa tüm veritabanınızın silinmesi mi işinizi aksatacaktır? Kullandığınız bir paket programı, satın aldığınız yazılım firmasından tekrar isteyip yükleyebilirsiniz. Kendi geliştirdiğiniz bir yazılımın kaynak kodları sizde olduğu için tekrardan derleyip programı devreye alabilirsiniz. Fakat veritabanınızdaki veriler ve yedekler çalındığı / hacklendiği zaman bunları geri getiremezsiniz. Sistem ve veritabanı yedekleri her ne kadar bu tip durumlarda faydalı olsa da, bir saldırganın uzun süreli sunucunuza erişim sağladığı ve yedeklenme işlemine verileni de bozduğu senaryoları da düşünün. Hiçbir saldırgan sizin yazdığınız bir programın peşinde değildir, bu programın kaydettiği verilerin peşindedir, ancak bu şekilde zarar verebilir ve kendisine kar sağlayabilir.

Bu makalede, Sql Server için alınabilecek güvenlik tedbirlerini, Sql Server’ın kurulu olduğu sunucu ve sistemlerde ne gibi önlemler alınmalı gibi konuları anlatmaya çalışacağım. Güvenlik konusu, sistem veya network konuları gibi kesin kuralları içermez, güvenlik ürünlerden çok süreçlere bağımlı bir olgudur. Güvenlik için birikim, bilgi ve tecrübe çok önemlidir. Bu makalede veya başka makale ve kitaplarda anlatılan Sql Server güvenliği konuları ile, yüzde 100 güvenli olacağınızın garantisi verilmez. Güvenlik, içerisinde birden çok rol içeren, ana unsurların düzgün ve kararlı çalışmasını sağlayan bir süreçtir. Bu süreç ne kadar düzgün yönetilir ise, o kadar yeterli seviyede güvenli sistemler olacaktır. Bilgi teknolojileri dünyasında güvenlik bir teknoloji değildir, teknolojilerin ortaya çıkardığı zafiyetleri kapsayan genel bir konudur.

İlk olarak Sunucu ve Network güvenliğinde bahsedelim.

Sql Server Servis Hesabının Seçilmesi:

Sql Server bir Windows servisi olarak çalışır. Her Windows servisini çalıştıran bir kullanıcı hesabı vardır. Sql Server içinde bu hesabı doğru seçmek güvenlik için önemlidir. Sql Server kurulumunda, Sql Server’ı çalıştıracak hesabı değiştirmediyseniz, Sql Server Configuration Manager’dan bu değişikliği yapabilirsiniz.

Sql Server’ı çalıştıran hesabı görüntülemek için Sql Server – Configuration Tools – SQL Server Configuration Manager’ı açıyoruz

SSS-1

Sql Server Services – Sql Server (instance adınız) – Properties diyerek özellikler sayfasını açıyoruz.

SSS-2

Logon ekranında Sql Server’ı çalıştıran hesabımızı görüyoruz. Nt Service olarak gözüküyor.

SSS-3

Sql Server, kurulu olduğu Windows Server üzerinde yönetici haklarına sahip olmayı gerektirmez. Sadece veri tabanlarının, yedeklerin ve logların tutulduğu dizinlerde okuma-yazma yetkisini arar.

Built-in account: Built-in hesapların şifreleri olmaz. İşletim sistemi tarafından yönetilen hesaplardır. Local System hesabı, yönetici haklarına sahip yerel bir hesaptır. Active directory üzerinden bu hesap ile network kaynalarına erişelebilinmektedir.

Network service, bu hesabın lokal makinada yetkileri biraz daha kısıtlıdır. Local system hesabı gibi network kaynaklarına erişebilmektedir.

Local system ve Network Service dışında, bir domain hesabı da seçebilirsiniz. Fakat bu hesaba password policy uygulanmaması gerekmektedir. Şifrenin süresi dolduğunda hesap bloklanır ve Sql Server hizmeti çalışmaz hale gelir. Bir Built-in hesabı ile Sql Server’ı çalıştırmak yerine, domain hesabı seçmek daha iyidir. Domain bir hesaba bu yetki verildikten sonra, Local Sercurity Policy üzeriden de Log on as a service yetkisinin verilmesi gerekmektedir. Built-in hesaplar servisler ile paylaşılan hesaplardır, bu sebeple saldırganlar tarafından uzak komut istem ile Sql Server prosedürleri veya diğer servislerine müdahale edebilirler.

Technet: http://technet.microsoft.com/en-us/library/cc756898(v=ws.10).aspx

Sql Servislerinin Güvenlik ID’lerinin Kontrol Edilmesi ve Yönetilmesi:

Sql Server’ı çalıştıran servis, güvenlik olarak bir Windows hesabına bağlıdır. Bu Windows hesabına bağlı birden çok servis vardır. Bu hesapların diğer kaynaklara (dosyalar, klasörler v.b.) erişiminde çakışma çıkmaması için, Windows her bir service Security Identifier dediği Security ID numarası atar. Bu SID dediğimiz ID’ler Sql Server kurulumunda oluşturulur.

Sql Server servisinize SID’in atanıp atanmadığını öğrenmek için, komut satırını açın. Aşağıdaki kodu komut satırınıza yazın.

“sc qsidtype mssqlserver”

Not: Buradaki mssqlserver, sizin sisteminizdeki Sql Server’ın instance adıdır.

Technet: http://blogs.technet.com/b/askperf/archive/2008/02/03/ws2008-windows-service-hardening.aspx

SSS-4

En üst satırda Success olarak komut çalıştı. Service_name kısmında Sql Server’ın çalıştığı servis adı geldi. Service_SID_type kısmında ise Unrestricted olarak SID tipimizin olduğun gösteriyor. Unrestricted, servisimizin bir SID değerini aldığını belirtir. SID_type None olsaydı, Sql Servisinin SID değeri olmadığını, SID_type – Restricted olursa, servisin bir SID değeri olduğunu fakat sınırlı bir hakka sahip olduğunu belirtecekti.

Eğer SID değeri None olarak çıkar ise, yukarıdaki komutun yanına Unrestricted yazarak, komutu tekrar çalıştırın. Böylelikle Sql Server servisinize bir Security ID değeri atamış olursunuz.

SID değer olan bir Sql Server, çalıştığı makine üzerinde ekstra yetkilere sahip olur, yedekleri diske yazma, import etme gibi. Sql server’da genel olarak yapılan export ve import işlerinde başarılsızlık olur ise SID değerini kontrol etmekte fayda vardır.

SID değeri None olarak kalabilir, fakat Restricted olarak kalırsa Sql Server’ın erişmek istediği kaynakları bloklar ve Sql Server hizmeti başlamaz.

Sql Servislerinde Virtual Service Hesabı Kullanılması:

Virtual service hesabı ilk olarak Server 2008 R2 ile duyuruldu. Şifre gerektirmeyen yerel bir hesaptır. Network Service hesabı gibi çalışır. Network servisinden farklı en iyi özelliği her service için farklı bir hesap ile çalışmasıdır. Virtual bir servisi oluşturamaz ve silemezsiniz.

Şekil SSS-3 te olduğu gibi, Log on ekranında “This Account”u seçip NT Service\(instace adınız) yazıyorsunuz ve şfireyi boş bırakarak, Sql Server service’ini yeniden başlatarak bu hesap ile çalıştırmaya başlayabilirsiniz. Şifre alanları boş olarak geçilmektedir.

Technet: http://technet.microsoft.com/en-us/library/dd548356(v=ws.10).aspx

Sql Bağlantılarının SSL ile Şifrelenmesi:

Sql Server bilindiği üzere server to client – client to server bir yapıdadır. Doğal olarak network üzerinden haberleşerek veri girişleri ve veri sorgulamaları yapılır. Sql server ile clientlar arasındaki haberleşme network üzerinde, sniffer dediğimiz araçlar ile izlenmesi gayet kolaydır. Bir saldırganın bir sistemdeki Sql Serverları ve bu servera bağlı clientları tespit etmesi oldukça kolaydır.

Microsoft Network Analyzer’ın yerini alan Message Analyzer ile Sql Server’ın ağ trafiğini izlemeye başlayalım. İlk önce aşağıdaki linkten programı indiriyoruz. (İsterseniz Wireshark programı ile de aynı işlemleri yapabilirsiniz)

https://www.microsoft.com/en-us/download/details.aspx?id=44226

Basit bir kurulumu var. Kurulumdan sonra Quick Trace kısmında ağ bağlantımıza tıklayarak network trace’i başlatıyoruz.

SSS-5

Trace başladıktan sonra ikinci makinamdan Adventerworks2012 veri tabanındaki PurchaseOrderDetail tablosuna select sorgusu atıyorum.

SSS-6

Bu sorgudan sonra Message Analyzer’a gelip bakalım.

SSS-7

Çok rahatlıkla hangi makinadan sorgu geliyor ve hangi Sql Server’a gidiyor tespit edebildik. Eğer networkünüzdeki Sql Server’ın bu şekilde izlenip tespit edilmesini istemiyorsanız, bir SSL sertifikası alıp bunun önüne geçebilirsiniz. SSL Sertifikasını Verisign, Digicert veya Comodo gidi firmalardan temin edebilirsiniz.

Alınan bu sertifikayı Mmc konsolu açarak, Snap add ins den, yüklemelisiniz. Sertifikayı Sql Server servisini çalıştıran kullanıcıya yüklemeniz gerektedir.

Sertifikayı yükledikten sonra, Sql Server Conf. Manager – Sql Server Network Configuration – Protocols for Sql Server’ın properties ekranını açıyoruz.

Flags sekmesinde, Force Encryption’a yes diyoruz. Certificate kısmında da yüklediğiniz sertifikayı seçip Ok diyoruz.

SSS-8

Sql Server Management Studio’ya bağlanırkende encrypt bağlantı sağlanabilir. SSMS açıldıktan sonra Connect to Server ekranında Options ile özellikleri açıyoruz.

SSS-9

Connection Properties ekranında Encrpt Connection diyerek client ile Sql Server arasında SSMS iletişimi encrypt edilebilmektedir.

SSS-10

Windows Firewall’un Yapılandırılması:

Güvenlik duvarı olarak Windows firewall kullanıyorsanız, Sql Server’a erişmek için gerekli TCP ve UDP portlarını açmanız gerekmektedir. Windows firewall’u Server 2008 ile varsayılan olarak açık gelmektedir.

Control Panel – Windows Firewall’u açalım. Advanced settings’e geliyoruz.

SSS-11

Inbound Rules ( Gelen Kuralları) sekmesinde, Action tabındaki “New Rule” ile yeni bir kural oluşturacağız.

SSS-12

Rule type, rol tipinde Port’u seçiyoruz.

SSRS-13

Protocol and Port sekmesinde TCP ve Specific local port’u seçip, ports kısmında 1433 yazıyoruz.

SSS-14

Action sekmesini Allow the connecton- bağlantıya izin ver, olarak seçip devam ediyoruz.

SSS-15

Profile sekmesinde karşımıza 3 farklı seçenek çıkıyor. Domain, yapıda active directory var ise sadece domain deki makinalara erişim verir. Private, domain olmayan yapılarda workgroup olan yapılardaki bağlantılara izin verir. Public ise Sql Server’a dışarıdan erişimi sağlar.

SSS-16

Name kısmında kuralımız için isim verip Finish ile kural oluşturma işlemini tamamlıyoruz.

SSS-17

Kuralımız Inbound Rules ekranına geldi. Eğer daha fazla kısıtlama ve sadece güvenli makinaların erişmesini istiyorsak. Kuralımızın özellikler ekranını açarak, gerekli ayarlamaları yapalım.

SSS-18

General sekmesindeki Action bölümünde “Allow the connetion if it is secure” (Eğer bağlantı güvenli ise izin ver)seçeneğini seçiyoruz.

SSS-19

Sonrasında Remote Users ve Remote Computers sekmelerinden istediğimiz bilgisayar veya kullanıcıyı seçerek izin veriyoruz.

SSS-20

Sql Server Browser’ın Devre Dışı Bırakılması:

Sql Server’ı yükledikten sonra Sql Server Browser hizmeti otomatik olarak devreye girer ve çalışmaya başlar. Kullanıcı tarafındaki bilgisayarlara Sql Server’ın olduğunun bilgisini gönderir. Network üzerinde hangi sunucularda Sql Server çalıştığı kolaylıkla Browser’ı açık olan sunuculardan tespit edilebilmektedir. Sql Server Browser’ı kapatmak için Sql Server Configuration Manager’ı açıyoruz (Şekil SSS-1).

Sql Server Services bölümünde Sql Server Browser hizmetine çift tıklayarak properties ekranını açıyoruz. Stop butonuna tıklayarak Browser servisini durduruyoruz.

SSS-21

Sql Server yeniden başladığında Browser hizmetini tekrardan çalıştıracaktır, bu sebeple Service sekmesinde, Browser hizmetinin başlangıç ayarlarını devre dışı bırakıyoruz.

SSS-22

Server – Client Arasında Extended Protection Yapılandırılması:

Sql Server ile client arasında kimlik doğrulama katmanlı bir bağlantı vardır. Client bağlanacağı Sql Server’ı kayıtlı kimlik bilgilerinden bilir, her seferinde bağlanacağı Sql Server’ı aramaz. Aynı şekilde server tarafında da benzer durum yaşanır. Client geçerli giriş anahtarını ve şifresini sağladığı için server’a erişim hakkı sağlamıştır.

Bu bağlantı şeklinde, saldırgan server ve client arasına girerek, kendisini Sql Server olarak gösterir. Client yemi yutmuş olur, Sql Server’a bağlandığını zanneder, aslında saldırganın makinasına bağlanmıştır. Saldırganda client’tan Windows Authentication bilgilerini çalarak, Sql Server’a bağlanmaya çalışır. Bu saldırı tipine Luring Attacks denir. Lure yem anlamına gelmektedir, yemleme atakları da diyebiliriz.

Diğer saldırı şeklide, yaygınca bilinen Man-in-the-Middle atak diye tabir edilen, ortadaki adam manasına gelen bu saldırı yönteminde, Dns yönlendirmesi veya Ip routing yapan saldırgan Server ile client arasına girip dinleme yapar. Sql Server kimlik bilgilerini client tarafında onayladığı sırada saldırgan bilgileri ele geçirmiş olur. Bu saldırı tipine de Spoofing Attacks denmektedir.

Bu tip saldırılardan korunmak için Sql Server üzerinde Extended Protection özelliğini aktif hale getirmemiz gerekmektedir.

Sql Server Configuration Manager – Sql Server Network Configuration – Protocols Sql Server’ın Properties ekranını açıyoruz.

SSS-23

Advanced sekmesinde “Extended Protection” kısmında Allowed’u seçiyoruz.

SSS-24

Extended protection özelliği Windows7 ve Server 2008 R2 işletim sistemlerinde gelmektedir. Eski sürümler için aşağıdaki güncellemeyi yüklemeniz gerekmektedir.

http://support.microsoft.com/kb/968389

Msdn: http://msdn.microsoft.com/en-us/library/ff487261.aspx

Veritabanı Dosyalarının Şifrelemesi:

Veritabanı dosyaları, Sql Server çalışırken kilitlenir ve mdf-ldf uzantılı dosyaları normal şartlarda kopyalamayız. Kopyalayabilmek için Sql Server hizmetinin durdurulması gerekmektedir. Fakat bu dosyaların Sql Server çalışırken kopyalanması Hobocopy gibi programlarla mümkündür. Veritabanı dosyalarınızı ele geçiren bir saldırgan bu dosyaları farklı bir sunucuda akitf edip, istediği verilere ulaşabilir.

Yukarıdaki durumu yaşamamak için veritabanı dosyalarını şifrelenmesi, bu dosyaların farklı Sql Server’lar üzerinde açılmasını engelleyecektir. Çalınan veritabanı dosyalarını açmak için bu şifrenin decrypt yani çözülmesi gerekmektedir. Bu şifreleme işlemine Transparent Database Encryption denmektedir. Bu özellik Enterprise, Datacenter ve Developer sürümlerinde geçerlidir.

Veritabanı dosyaları nasıl şifrelenir buna bakalım;

İlk olarak server encryption master key – ana anahtar oluşturmamız gerekmektedir. Yeni bir sorgu ekranı açarak master key’i aşağıdaki gibi oluşturalım.

USEmaster;

CREATEMASTERKEYENCRYPTIONBYPASSWORD='Guclu_Sifre';

Bu şifrelemenin hemen yedeklenmesi gerekmektedir. Eğer master veritabanınızı kaybederseniz, şifrelenmiş veritabanınızın içeriğini hiçbir şekilde göremezsiniz. Yedek alınan klasörü paylaşıma açın, ve klasör yolunu doğru yazdığınızda emin olun, aksi takdirde hata verecektir, yedek almayacaktır. Yedek almak için aşağıdaki kodu yazıyoruz.

BACKUPMASTERKEYTOFILE='\\YAVUZSONY\Yedek\Yavuzsony_master.key'ENCRYPTIONBY

PASSWORD='Guclu_bir_sifre_daha';

Eğer bir password policy kullanıyorsanız, örnek olarak en az 8 karater, en az bir büyük harf, en az bir özel karakter gibi, şifrenizi bu policy’e göre vermeniz gerekmektedir.

Şimdi sıra server sertifikası üretmesine geldi, bu sertifika sunucuya özel bir sertifikadır. Veritabanı dosyalarınızın şifrelenmesinde kullanılacaktır.

CREATECERTIFICATE SqlSertifikasi WITHSUBJECT='Sql Sertifika';

Oluşturduğumuz sertifikayı yedekleyelim, hem de dosya olarak elimizde bulunsun.

BACKUPCERTIFICATE SqlSertifikasi TOFILE='\\YAVUZSONY\Yedek\SQL_SqlSertifikasi.cer'

WITHPRIVATEKEY ( FILE='\\YAVUZSONY\Yedek\SQL_SqlSertifikasi.pvk',

ENCRYPTIONBYPASSWORD='Guclu_Sifre_Guclu_Sql');

Oluştruduğumuz server sertifikası ile, veritabanı üzerinde encryption key oluştuyoruz.

USE SATIS;

CREATEDATABASEENCRYPTIONKEY

WITHALGORITHM=AES_128

ENCRYPTIONBYSERVERCERTIFICATE SqlSertifikasi;

Son olarak veritabanı şifrelemesini aktif hale getiriyoruz.

ALTERDATABASE SATIS

SETENCRYPTIONON

Oluşturduğumuz key ve sertifika dosyalarına bakalım, bu dosyaların yedeğini almayı unutmayın.

SSS-25

Güvenlik sertifikası, private key ve master key olarak 3 dosyayı veritabanı şifrelemesinde kullandık.

Transparent Database Encryption, veritabanı mdf ve ldf dosyalarınızı görünmez bir şekilde şifreledi. Bu dosyaların şifrelendiği bilgisi Sql Server üzerinde veya dosyaların özellik sayfalarında gözükmez.

Şifrelenmiş bir veritabanını Sql Server’a geri eklemeniz için, ilk önce güvenlik sertifikasını ve encryption key’i geri yüklemeniz gerekmektedir. Geri yüklerken şifreyi yazıyoruz.

USEmaster;

CREATECERTIFICATE SqlSertifikasi FROMFILE='\\YAVUZSONY\Yedek\SQL_SqlSertifikasi.cer'

WITHPRIVATEKEY ( FILE='\\YAVUZSONY\Yedek\SQL_SqlSertifikasi.pvk',

DECRYPTIONBYPASSWORD='Guclu_Sifre_Guclu_Sql')

Msdn: http://msdn.microsoft.com/en-us/library/bb934049.aspx

Xp_CmdShell Özelliklerinin Kısıtlanması:

Sql Server 2005’te güvenlik sorunları teşkil eden bazı özellikler, yeni Sql Server versiyonlarında, kurulumda varsayılan olarak devre dışı bırakılıp getirilmiştir. Bunlardan en önemlisi xp_cmdshell komutudur. Bu özelliklerin aktif etmek için Sql Server Management Studio da instance adına sağ tıklayıp “Facets” bölümüne gelelim.

SSS-26

Facet alanından Surface Area Configuration’ı seçiyoruz.

SSS-27

AdHocRemoteQueriesEnabled, OleAutomationEnabled ve XPCmdShellEnabled alanlarının False değerinde olması gerekiyor, eğer değilse bu alanları False değerine getiriyoruz.

SSS-28

Sql Server’da Güvenlik makale dizisinin 1. Bölümünün sonuna geldik, 2. Bölümde görüşmek üzere.

İlk bölümde Sql Server’ın kurulu olduğu server ve network üzerindeki güvenlik ayarlarından bahsettik. Bu bölümde, Sql Server’ın kendi içindeki güvenlik tanımlamalarından bahsedeceğiz. Kimlik doğrulama seçenekleri, kullanıcı yönetimi, Sa kullanıcısının yetkileri, kullanıcı rolleri ve veritabanı yetkileri hakkındaki detaylara bakacağız.

Bölüm1

İlk olarak Sql Server’da kimlik doğrulama konusuna değinelim.

Kimlik Doğrulama:

Sql Server ile clientlar arasında iki çeşit kimlik doğrulama yöntemi vardır. Windows Authentication ve Sql Server Authentication. Sql Server kurulumunda hangi yöntem ile kimlik doğrulama yapacağınız size sorulur. Windows Authentication modu devre dışı bırakılamaz. Tek olarak Windows Authentication veya Sql Server – Windows Authentication modları bütünleşik olarak seçilebilir.

Kimlik doğrulama seçeneklerini görmek için, Sql Server Management Studio – Object Explorer instance adınız üzerinde sağ klik Properties

SSS-29

Security sekmesine geliyoruz.

SSS-30

“Windows Authentication mode” Sadece Windows hesaplarından açılan oturumları kabul eder.

“Sql Server and Windows Authentication mode” Hem Windows hem de Sql Server hesaplarından açılan oturumları kabul eder.

Server Authentication kısmında yaptığınız kimlik doğrulama yöntemlerinden sonra Sql Server servisinin yeniden başlatılması gerekmektedir.

Windows Authentication varsayılan olarak Sql Server kurulumunda seçili olarak gelmektedir. Öngörülen ve daha güvenli olan kimlik doğrulama seçeneğidir. Kullanıcı Sql Server’a kullanıcı adı ve şifre girmeden, Windows hesabı ile bağlanabilmektedir. Windows Authentication devre dışı bırakılamaz. Mixed mode seçili olduğunda aynı zamanda Windows Authentication kullanılabilmektedir.

Sql Server Authentication’ı dışarıdan erişecek ve domain yapınızın dışından erişecek kullanıcılar için açabilirsiniz. Sql Server hesapları, Sql Server’ın içinden yönetilir, Windows hesapları ile bir bağlantısı yoktur.

Msdn: http://msdn.microsoft.com/en-us/library/bb669066(v=vs.110).aspx

Sql Server Kullanıcı Hesapları:

Sql Server’daki kullanıcıların hesaplarına Logins denmektedir. Her bir login’e ayrı yetkiler verilebilir, erişebileceği veri tabanları belirlenebilir. Sql Server’da güvenlik seviyesi iki katmandan oluşur Server ve Veritabanı seviyesi. Login hesabı ilk önce server seviyesi oluşturulur, daha sonra ilgili veri tabanına mapped denilen ataması yapılır ve veri tabanına erişimi sağlanmış olur.

Sql Server üzerinde kullanıcı – login açmak için SS Management Studio – Security – Logins üzerinde sağ klik “New Login” diyorurz.

SSS-31

Windows Authentication ile domain kullanıcısına Sql Server için yetki verilebilir. Search kısmından yetki verilmek istenen kullanıcı seçilebilir.

SSS-32

Sql Server Authentication seçildiğinde kullanıcı adını yazabilirsiniz. Sql Server’ın yönettiği hesaplar olduğu için Windows hesaplarından farklı olacaktır.

“Enforce password policy” – Domaindeki veya Windows işletim sisteminde password policy kuralları geçerli olur.

“Enforce password expiration” - Domaindeki veya Windows işletim sisteminde şifre geçerlilik süresi bu seçenek ile geçerli olur.

“User must change password at next login” – Kullanıcı bir sonraki oturumunda şifresini değiştirmek zorunda kalır. SSMS ile bu şifre değiştirebilir.

“Default Database” – SSMS bağlanıldığında kullanıcı bazlı, çalışılacak olan veritabanı otomatik olarak gelir.

“Default Language” – SSMS üzerindeki dil ayarları, format ve hata mesajları istenen dilde bu seçenek ile ayarlanabilir.

SSS-33

Enforce password policy ve pasword expiration seçeneklerinin Sql logini için seçilmesi, basit şifrelerin kullanılmasının önüne geçeceği gibi, uzun süre değiştirilmeyen şifreler içinde tedbir olacaktır.

Domain Password Policy Technet: http://technet.microsoft.com/en-us/library/cc264456.aspx

T-Sql kodu ile Sql login aşağıdaki gibi oluşturulmaktadır.

USE [master]

CREATELOGIN [yavuzsql] WITHPASSWORD=N'Guclu_bir_sifre'MUST_CHANGE,

DEFAULT_DATABASE=[PLANLAMA],

DEFAULT_LANGUAGE=[Türkçe],

CHECK_EXPIRATION=ON,

CHECK_POLICY=ON

Password policy seçili olan bir Sql hesabında, şifre denemesi aynı Windows hesabında olduğu gibi geçerlidir. Yanlış girilen şifrelerden dolayı Sql hesabı kilitlenebilir. Sql hesabının kilidini açmak için aşağdaki T-Sql kodu çalıştırılır.

ALTERLOGIN yavuzsql WITHPASSWORD='yeni_sifre'UNLOCK;

-- Şifre değiştirilmek istenmiyor ise, aşağıdaki komutlar ile çalıştırılır

ALTERLOGIN fred WITHCHECK_POLICY=OFF;

ALTERLOGIN fred WITHCHECK_POLICY=ON;

Bir Sql hesabını devre dışı bırakmak veya tekrar aktifleştirmek için aşağıdaki T-Sql kodu kullanılır.

-- Hesabı devre dışı bırakır

ALTERLOGIN yavuzsql DISABLE;

-- Hesabı aktifleştirir

ALTERLOGIN yavuzsql ENABLE;

Bir Sql hesabını silince, bu hesabın tüm ayarları kaybolur, tekrar bu hesabı oluşturduğunuzda tüm tanımları yeniden yapmanız gerekmektedir. Bu sebeple, hesabın Sql Server’a erişimimi kapatarak, hesabı silmeden kullanıcının Sql Server’a erişimini engelleyebilirsiniz.

DENYCONNECTSQLTO yavuzsql;

Bu ayarları kullanıcının Properties sayfasındaki Status sekmesinden de yapabilirsiniz.

SSS-34

“Permission to connect database engine” – Kullanıcının Sql Server’a bağlanmasına izin/engel vermesi.

“Login” – Kullanıcı hesabının devre dışı/aktif edilmesi.

“Sql Server Authentication – Login is locked out” – Kilitlenen Sql Server hesabı buradan açılabilir.

Kullanıcı hesaplarının güvenlik ile alakalı kısımlarından bahsettik. Login – Properties’in diğer sekmeleri olan Server Roles, User Mapping ve Securables bölümleri kullanıcının Sql Server içindeki erişim izinleri ile alakalıdır.

Sql Login Msdn: http://msdn.microsoft.com/en-us/library/aa337562.aspx

Sql Saldırılarından Korunma Yöntemleri:

Windows sunucularına saldırdıkları gibi, Sql Server’a aynı şekilde Brute-force denilen saldırı yöntemi ile ataklar sürekli olmaktadır. Windows tarafında kullanılan password policy eğer Sql tarafında kullanılmıyorsa, Sql Server’ınızda güvenlik olarak büyük bir açığınız var demektir. Sql login şifrelerini 12345 gibi basit şifreler koydu iseniz, kırılması sadece birkaç saniye sürecektir. Önerilen en temel şifreleme policy’si en az bir rakam, en az bir büyük harf, en az bir özel karakter olacak şekilde 8 karakterden az olmamak şartıdır. Şifrenizin ne kadar uzun ve ne kadar çok karmaşık olması brute-force ataklarından sizi daha iyi koruyacaktır.

Şifrenin uzun ve karmaşık olmasının yanı sıra, belirli periyodlarla değiştirilmesi gerekmektedir. Sürekli aylarca, yıllarca aynı kalan şifrelere uzun süren brute-force ataklar ile kırılabilmektedir.

İlk olarak Sql Server’ımızda kaç tane login-hesabınımız var bakalım.

SELECT*FROMsys.sql_logins

Sys.sql_logins Sistem tablosundan tüm loginlerimizi bize getiriyor. Loginlerimizde password policy olmayan hesapları tespit etmemiz içn, SSMS üzerinde tek tek loginlerin özellikler sayfasına girmek çok fazla vakit kaybı olacaktır. Sql_logins tablosunda password policy olmayan hesapları tespit etmek için aşağıdaki sorguyu çalıştırıyoruz.

SELECT name, is_disabled

FROMsys.sql_logins

WHERE is_policy_checked = 0

İki tane Sql loginde password policy olmadığı gözüküyor.

SSS-35

Birden çok login hesabınız olduğunda password policyleri aktif etmeniz uzun sürecektir. Aşağıdaki sorgu ile login veya loginlerin password policylerini aktif hale getirebilirsiniz.

ALTERLOGIN yavuzsql WITHCHECK_POLICY=ON,

CHECK_EXPIRATION=ON;

Check_Expiration ile de şifre değiştirme süresini aktif hale getirmiş olduk. Şifrenin süresinin ne zaman dolacağınız aşağıdaki komut ile sorguluyoruz.

SELECTLOGINPROPERTY('yavuzsql','DaysUntilExpiration');

SSS-36

Şifreyi değiştirmek için 39 gün kaldığını gösteriyor.

Msdn: http://msdn.microsoft.com/en-us/library/ms161959.aspx

Sql hesabınıza şifre deneme saldırısı yapıldığında, bu denemeleri kendinize veya tanımlı kişilere mail olarak bildirebilirsiniz.

İlk olarak Sql Server Management Studio – Management – Database Mail bölümünde tanımlı bir Sql Database hesabı yapılandırmanız gerekiyor. Bunun Database maile sağ klik “Configure Database Mail”

SSS-37

Wizard karşılama ekranını Next ile geçiyoruz.

Set up Database Mail by performing the following task seçeneğini seçip Next ilerliyoruz.

SSS_38

Profil adını yazdıktan sonra Add butonuna tıklıyoruz.

SSS-39

New Database Mail Account ekranını aşağıdaki gibi dolduruyoruz. Sisteminizde bir Smtp server var ise, Smtp serverınızdan bir hesap ile Database mail oluşturabilirsiniz.

SSS-40

Ok dedikten sonra Manage Profile Security ekranında “Public Profiles” sekmesinde Public check box’ını işaretliyor ve “Default Profile”i Yes olarak ayarlıyoruz.

SSS-41

Database mail hesabımız tanımlanmış oldu. Mutlaka aşağıdaki gibi bir test maili gönderip, Database mailin çalışıp çalışmadığını kontrol edin.

SSS-42

Mail tanımlarını yaptık, test mailini gönderdik. Sa hesabına şifre denemesi yapıldığında bize mail gelmesini istiyoruz.

Sql Server Agent üzerinde sağ klik New – Alert diyoruz. Yeni bir uyarı tanımlayacağız.

SSS-43

New Alert ekranında tanımları aşağıdaki gibi yazıyoruz.

SSS-44

Bu tanımdan sonra mail gelmesi için Response sekmesinde Notify Operators seçeneğini seçerek istenen kişilere mail gönderilmesi sağlanır. Eğer Operator tanımı yok ise New Operator ile yeni bir operatör tanımlanır. Tanımlanan operatör Response ekranına gelecektir.

SSS-45

Tüm ayarları yaptıktan sonra Database mailin Sql Server Agent için aktif edilmesi gerekmektedir. Database mail varsayılan olarak Sql Server içinde sys.send_mail prosedürü tarafından kullanılmak üzere ayarlanmaktadır. Sql Server Agent için Database maili aktifleştirmek içi, Sql Server Agent üzerinde sağ klik Properties ekranı açılır. Alert System sekmesindeki Enable Mail Profile ile aktifleştirme işlemi tamamlanır.

SSS-46

Bu ayar yapılmazsa, Sql Server Agent üzerindeki Alert’lerden mailler gelmez.

Sa kullanıcısına şifre denemeleri yapalım.

SSS-47

18456 nolu hatayı aldık, bakalım bu deneme Sql Server tarafından bize mail atıldı mı, mailimize gidip kontrol ediyoruz.

SSS-48

Operatöre Yahoo mailimi tanımlamıştım. Hatalı yapılan girişler mail olarak geldi.

Sa Hesabının Kısıtlanması:

Sa kullanıcısı ilk Sql Server çıktığından beri olan, System Administrator anlamına gelen, Sql Server’ın sistem yöneticisi hesabıdır. Eski Sql Server sürümlerinde devre dışı bırakılması mümkün değildi. Sql Server 2005 ile birlikte devre dışı bırakılması ve değiştirilmesi sağlandı.

Sa hesabını neden kapamalıyız veya neden kısıtlamalıyız, çünkü en çok saldırı alan Sql Server hesabıdır. Saldırganlar tarafından ilk önce kontrol edilen hesaptır, sa hesabında sistem yöneticiliği rolü olduğundan ilk önce bu hesap yoklanır. Birçok firmada sa hesapları aktif haldedir. Ne yazık ki kobi dediğimiz küçük ve orta boy ölçekteki bir çok firmada ise durum daha vahimdir. Bazı firmalarda halen sa hesabı aktif olup şifreside yoktur. Firma sahipleri etkili bir atak yedikten sonra, verileri çalınıp şifrelendikten sonra tedbir almaya başlarlar.

Sa hesabını aşağıdaki komutla devre dışı bırakıyoruz.

ALTERLOGIN [sa] DISABLE

Sa hesabının adını aşağıdaki komut ile değiştirebilirsiniz.

ALTERLOGIN [sa] WITH NAME = [test_kullanici]

Sa hesabının Securtiy ID’si (SID) 1 olduğundan daha aşağıdaki sorgu ile sa hesabının adını öğrenebilirsiniz.

SELECT*FROMsys.sql_loginsWHERE principal_id = 1

Sa hesabını SSMS üzerinden devre dışı bırakmak için. SSMS – Security – Logins Sa hesabına sağ tıklayıp özelliklerine giriyoruz.

Status sekmesinden aşağıdaki şekildeki gibi database engine için Deny, SSMS erişimi içinde Login Disable yapıyoruz.

SSS-49

Sql Server kurulumunda Windoıws Authentication seçeneği seçilerek kurulum yapıldı ise, sa devre dışı kalır. Sa şifresini hatırlamanıza gerek yoktur. Olabildiğince zor bir şifre koyarak sa hesabının adını değiştirmek gerekmektedir.

Msdn: http://msdn.microsoft.com/en-us/library/ms188670.aspx

Sql Server Rolleri:

Bir Sql Server hesabı varsayılan olarak hiçbir yönetici yetkisi olmadan oluşturulur. Bu role public rolü denir. Daha sonra hangi veritabanına erişmek istiyor ise Logins – Properties – User Mapping sekmesinden veritabanı yetkileri atanır. Eğer bir kullanıcıya yönetici yetkileri vermek istiyorsanız, Login’nin server roles sekmesinden gerekli rolü verebilirsiniz.

Sql Server’da roller aşağıdaki gibidir;

- Bulk Admin: Bulk insert yapma yetkisine sahiptir. Bir dosyadan veritabanına kayıt eklemek için kullanılır. Genellikle excelden veri çekmek için kullanılmaktadır.

- Dbcreator: Herhangi bir veritabanını oluşturma, düzenleme ve kaldırma yetkisi vardır. Yazılımcılara test amaçlı bu yetkiden verilebilir.

- Processadmin: Sql proseslerini görme ve sonlandırma yetkisi vardır. Tüm çalışan prosesleri görebilirler. Kill komutu ile istenen proses veya prosesleri sonlandırabilirler.

- Securityadmin: Sql hesabı oluşturup silebilirler. Server rolü oluşturma yetkileri yoktur.

- Serveradmin: Sql server instance’ının özelliklerini değiştirebilir, yeniden başlatabilir veya hizmeti durdurabilirler.

- Setupadmin: Linked server oluşturma yetkileri vardır.

- Sysadmin: Tüm yönetici yetkilerine sahip roldür.

Sql Server hesaplarına atanmış olan rolleri aşağıdaki sorgu ile görebilirsiniz.

SELECTrole.name asrole,role.is_fixed_role,login.name aslogin

FROMsys.server_role_members srm

JOINsys.server_principalsroleON srm.role_principal_id =role.principal_id

JOINsys.server_principalsloginON srm.member_principal_id =login.principal_id

SSMS üzerinde bir kullanıcının rolünü ayarlamak için,

SSMS – Security – Logins bölümünde kullanıcının Properties ekranından Server Roles sekmesinden istenen rol kullanıcıya atanır.

SSS-50

Veritabanı Seviyesinde Kullanıcı Yetkisinin Yapılandırılması:

Sql Server’da kullanıcıya Server Roles verilmesi birçok yetkiyi de beraberinde getirir. Kullanıcı sadece istenen veri tabanlarında yetki istediği zaman, login özelliklerinden User Mapping sekmesinden istenen yetkiler atanabilir.

SSMS – Security – Logins kullanıcının properties sayfası açılır. User Mappings sekmesine gelip, hangi veritabanında nasıl bir yetki isteniyor ise “Database role membership for: <veritabanı_adi>” bölümünden ilgili yetkiler işaretlenir.

SSS-51

“Map” checkbox’I ile hangi veritabanında yetki verilecekse seçilir. Map seçildikten sonra yetkiler açılır. User otomatik olarak gelir, istenirse “Default Schema” dan varsayılan şema seçilebilir.

Veritabanı map edildikten sonra “ Database role membership for: “ alanından ilgili yetkiler seçilir. Database rolleri nedir, bunları inceleyelim.

Database Roles:

- Db_accessadmin: Veritabanına erişim için yetki verir.

- Db_backupoperator: Veritabanının yedek alması için yetki verir. Sistem yöneticilerine yedek alınan 3. Parti bir yazılımda kullanılmak üzere bu yetki verilebilir.

- Db_datareader: Tablolardaki verileri okuma yetkisi verir. Sadece Select sorgusu kullanan ve Self Service raporlaama yapan son kullanıcılara bu yetki verilebilir.

- Db_datawriter: Tablolardaki verileri düzenleme, silme veya ekleme yetkisi verir. Server bazında yetki kısıtlanarak farklı programlardaki farklı kullanıcılara bu yetki verilebilir.

- Db_ddladmin: Veritabanı üzerinde DDL (Data Definition Language) komutlarını çalıştırma izni verir.

- Db_denydatareader: Veritabanı üzerinde okuma işlemi yetkisini engeller.

- Db_denydatawriter: Veritabanı üzerinde değiştirme, ekleme ve silme yetkisini engeller.

- Db_owner: Veritabanı üzerindeki tüm yapılandırma ve bakım yetkilerini verir. Veritabanını drop etme yetkisine sahiptir. Owner, sahip anlamına gelmektedir.

- Db_securityadmin: Veritabanı üzerindeki üyelikleri ve izinleri yönetme yetkisidir.

User Mapping Technet: http://technet.microsoft.com/en-us/library/ms178316(v=sql.105).aspx

Database Roles Technet: http://technet.microsoft.com/en-us/library/ms189121(v=sql.105).aspx

Server Seviyesinde Kullanıcı Yetkisinin Yapılandırılması:

Sql Server’da kullanıcılara yetki verme ve yetki kısıtlamaları detaylı olarak sunulmuştur. Doğru yapılandırıldığında sistem güvenliği daha da artaracaktır. Veritabanı seviyesindeki yetkileri gördükten sonra, Server seviyesinde de Sql Server bize yetkilendirme imkanı sunmaktadır.

SSMS – Security – Logins kullanıcının properties sayfasından Securables sekmesine geliyoruz.

SSS-52

Bu ekrandan kullanıcıya yetkileri Grant ile verebilir, Deny ile de engelleyebiliriz.

T-Sql ile yapmak içinde,

GRANTALTERANY CONNECTION TO yavuzsql;

Loginin Securables sekmesine baktığınızda Alter Any Connection bölümünde Grant’ın seçili olduğunu göreceksiniz.

Yetki verilen server permissionlarına aşağıdaki sorgu ile kontrol edilebilir.

SELECT*FROMsys.server_permissions

SSS-53

Kullanıcının izin verilen yetkileri aşağıdaki sorgu ile kontrol edilebilir.

SELECT SP.class_desc, SP.permission_name, SP.state_desc

FROMsys.server_permissions SP

JOINsys.server_principals SPR

ON SP.grantee_principal_id = SPR.principal_id

WHERE SPR.name ='yavuzsql'

SSS-54

Alter Any Connection için Grant yetkisi vermiştik, sorguda karşımıza çıkıyor.

Database level permission ile ilgili aşağıdaki posteri indirip detaylı inceleme yapabilirsiniz. Sql 2008 R2 ve Sql 2012 için geçerlidir.

Technet Poster: http://social.technet.microsoft.com/wiki/cfs-file.ashx/__key/communityserver-wikis-components-files/00-00-00-00-05/5710.Permissions_5F00_Poster_5F00_2008_5F00_R2_5F00_Wiki.pdf

Msdn: http://msdn.microsoft.com/en-us/library/ms191291.aspx

Veritabanı Kullanıcısı Yönetimi:

Loginler Sql Server’daki kullanıcı hesaplarıdır. Yönetilmeleri de dikkat ister, yetkileri detaylıdır. Database user yani veritabanı kullanıcısı ise sadece, ilgili veritabanındaki temel güvenliğe bağlıdır. Sql Server’a server bazında bir yetkilendirme yapmaya gerek kalmadan kullanabilir. Bu da gereksiz login açmaya gerek bırakmadan basit ve kolay bir güvenlik sağlar. Varolan bir logine Database user bağlanabilir, böylelikle sürekli login açmaya gerek kalmaz.

Veritabanı kullanıcısı açmak için SSMS – Databases – VeritabanıAdi – Security – Users bölümde sağ klik – New User ile yeni veritabanı kullanıcısını açıyoruz.

SSS-55

Database user ekranında, ilk olarak General sekmesi karşımıza geliyor, User Type alanında kullanıcının tipini seçiyoruz.

SSS-56

Kullanıcı tiplerine kısaca bakalım;

- Sql user with login: Bir Sql login hesabına map edilmiş kullanıcı tipidir.

- Sql user without login: Bir Sql login hesabına bağlanmamış kullanıcıdır, T-Sql de execute as user komutları ile kullanılabilir.

- User mapped to a certificate/an asymetric key: Bir signature key’e atanmış kullanıcı tipidir.

- Windows user: Windows Authentication hesabına map edilmiş kullanıcı tipidir.

Windows user’a map edilmiş bir kullanıcı oluşturalım. User Name kısmında kullanıcı adını yazıyoruz.

Kullanıcı adını yazdıktan sonra, database user’ı Windows User’a atamamız gerekiyor. Login name kısmından bu atamayı yapıyoruz.

SSS-57

İstenirse default schema da atanabilir.

Windows user map edilirken, domaindeki bir kullanıcıyı siz biliyor olabilirsiniz ama Sql Server bunu bilemez, bu yüzden Windows user olarak domaindeki kullanıcınızı Logins kısmından ilk önce Sql Server’a eklemeniz gerekmektedir. Browse for object dediğimizde karşımıza sadece Logins ekranında eklediğimiz Windows kullanıcıları gelecektir.

Owned Schema ve Membership sekmelerinden rol yetkilerini verebiliriz.

SSS-58

Veri tabanlarına atanmış olan Database owner yani veritabanı sahibi olarak atanmış kullanıcıları sorgulayarak, hangi veritabanında hangi kullanıcıların yetkileri var kontrol edebilirsiniz. Gereksiz gördüğünüz ve kullanılmayan hesapları mutlaka kapatın veya devre dışı bırakın.

Veri tabanlarındaki database owner ları görmek için aşağıdaki sorguyu çalıştırın.

SELECTSUSER_SNAME(owner_sid), name FROMsys.databases

SSS-59

Msdn: http://msdn.microsoft.com/en-us/library/aa337545.aspx

Sistem Fonksiyonları - Kullanıcı ve Login Bilgileri Kontrolü:

SSMS üzerinden kullanıcı ve loginleri ilgili ekranlara tek tek girerek incelemek gerekmektedir. Böyle bir işlem çok fazla zaman alacağından, Sql Server’ın sistem fonksiyonları ile kontrol edebiliriz.

Is_Member ile mevcut kullanıcının grup üyesi olup olmadığını kontrol edebilirsiniz.

SELECTIS_MEMBER('yavuzsony\yavuz');

SSS-60

Diğer fonksiyonlarda aşağıdaki gibidir;

- SYSTEM_USER: Bağlı olan login hesabını gösterir

SELECTSYSTEM_USER veyaSELECTSUSER_SNAME();

SSS-61

- SUSER_ID(): Mevcut kullanıcının Security ID’sini gösterir.

SELECTSUSER_ID();

SSS-62

- CURRENT_USER / SESSION_USER: Mevcut Database kullanıcısını gösterir.

SELECTCURRENT_USER;

SELECTSESSION_USER;

SSS-63

- ORIGINAL_LOGIN: Windows hesabındaki kullanıcı adını gösterir.

SELECTORIGINAL_LOGIN();

SSS-64

- HAS_DBACCESS('veritabani_adi'): Mevcut kullanıcının veritabanına erişimi olup olmadığını gösterir. 1 Değeri döner ise erişim var demektir.

SELECTHAS_DBACCESS('ARGE');

SSS_65

Msdn: http://msdn.microsoft.com/en-us/library/ms186236.aspx

Kullanıcılardan ve Sql Hesaplarından Ana Verileri Gizleme:

Sql serverdaki veritabanları ve diğer nesneler, yetkisi az olan bir kullanıcıya da açık olarak gelir. Gözükmesini istemediğiniz bu nesneler için engellemeler yapabilirsiniz. İlk olarak yapılması gerek public rolü için View Any Databases özelliğini kapatmak olacaktır.

USEmaster;

REVOKEVIEWANYDATABASETOpublic;

Public rolündeki kullanıcımla SSMS’e giriş yapıp kontrol ediyorum.

SSS-66

Görüldüğü gibi yavuzsql kullanıcısında sadece ARGE veritabanını görme yetkisi vardı, Databases altında sadece ARGE gözüküyor.

SSS-67

Kullanıcı için bir veritabanındaki belli bir nesneye yetki vermek için, veritabanı içindeki Security - Users özellikler sayfasında, Securables sekmesinden gerekli izinler atanabilir. Örnek olarak bir stored procedure veya bir tablo bu ekrandan yetkilendirilebilir.

Kullanıcının üzerinde sağ klik Properties ekranına giriyoruz. Securables sekmesindeki Search’e tıklıyoruz.

SSS-68

Search – Specify Objects

SSS-69

Object Types’a tıklayıp seçebilecek nesneleri göreceğiz.

SSS-70

Select Object Types ekranında veritabanındaki tüm nesnelerin ana grupları gözükmekte. Örnek olarak View seçip Ok ile devam edelim.

SSS-71

Select Objects ekranında Browse diyoruz. Hangi nesne tipini seçersek, onunla ilgili kayıtlar gelecektir.

SSS-72

Sistem viewleri dahil veritabanındaki tüm viewler geldi. Daha önce oluşturduğum arge_view’i seçiyorum.

SSS-73

Select Objects ekranına view geldi, Ok ile devam ediyoruz.

Securables ekranına view geldi. Görüldüğü detaylı bir yetkilendirme var, sadece Select ve View Definition’a Grant yetkisi verip Ok diyorum.

SSS-74

View üzerinde sağ klik Edit top 200 rows diyelim, verilerde değişiklik yapmaya çalışalım.

SSS_75

Edit yetkisi olmadığı için izin vermedi.

View’i komple silmeye çalışalım.

SSS_76

Yetki olmadığı için silmeye izin vermedi.

Technet: http://technet.microsoft.com/en-us/library/ms190785(v=sql.105).aspx

Sql Server’da kullanıcı yetkilerinin ne kadar detaylı olduğunu görmüş olduk. Genelde uğraşmamak için loginlere sysadmin yetkisi verilir. Firmaya yeni bir yazılım alınır, yazılımcı firma Sql de bir kullanıcı ister ve Sql kullanıcısı sysadmin olarak açılır. Genel senaryo bu şekilde oluşur, siz farkında olmadan verilerinizi başka bir firmadaki kişiye teslim etmiş oluyorsunuz. Bir yanlışlık yapıldığında da geri dönülmesi zor hatalara yol açabilir.

Saldırganlarda bu açıklardan faydalanarak, sql loginlerindeki yetkileri kontrol ederler. Gerekli tedbirler alınmayan sistemlerde saldırgan, kıyıda köşede kalmış bir Sql hesabı ile istediği zararı verebilir.

Bu bölümde kod ve veri şifrelemesi konularını inceleyeceğiz. Terminalojide Encryption olarak bilinen şifreleme, aslında bilgi sistemlerinin her alanında kullanılmaktadır. Temel bilgisayar dilinde okunabilen veriye plaintext, şifrelenmiş algoritmasına da ciphertext denmektedir. Ciphertext veriyi şifreleyen bir anahtar kullanır, bu veriyi sadece o anahtara sahip bilgisayar görebilir. Encryption – şifrelemenin temeli bu şekilde çalışmaktadır.

Sql Server’da key değimi bu anahtarlardan 128 bit 192bit ve 256bit kullanmaktadır. Bu keylerin en basiti symmetric key olarak adlandırılır. Bu symmetric key veriyi hem şifreler, hem de şifreyi çözer, encrypt – decrypt. Performans açısından gayet iyidir fakat güvenlik konusunda, bu simetrik keyler çalındığında şifreleri kırmak çok da zor olmamaktadır.

Simetrik keylerdeki bu sorundan dolayı asimetrik keyler geliştirilmiştir. İki parçadan oluşan asimetrik keylerin public key kısmında sadece veri şifrelenir, private key tarafında ise şifrelenen veriyi çözme işlemi gerçekleşir. Asimetrik keyler simetrik keylere göre daha güvenlidir, fakat performans açısından simetrik keylerden daha yavaş çalışırlar.

Diğer bir yöntem de sertifika kullanmaktır. Sertifika, private keydeki kimlik bilgisini içeren public keyin asimetrik bir parçasıdır. Yetkili dijital imza sağlayıcıdan alınan sertifikalarda kimlik bilgisi bulunur. Sertifikalarda veriler şifrelenmez, web sitelerindeki güvenlik sertifikası mantığı ile çalışır. Sahte web güvenlik sertifikası olamayacağı gibi Sql Server içinde bu böyledir. Sql Server 2005’ten bu yana simetrik, asimetrik ve sertifika şifreleme desteği verilmektedir.

Database Master Keyleri:

Sql Server’da her veritabanının kendine ait bir master keyi vardır. Bu keyler sunucu seviyesinde şifrelenirler. Master key kullanımında ilk önce open ile açılır, daha sonra close komutu ile kapatılması gerekmektedir. Şifreleme hiyerarşisinin en temelinde Service Master Key – SMK bulunur, Sql Server bu keyi otomatik üretir. Eğer veritabanı seviyesinde bir key kullanılacaksa ise bu key manuel olarak oluşturulmalıdır. Bu keylere de Database Master Key – DMK denmektedir.

Service Master Key Msdn: https://msdn.microsoft.com/en-us/library/ms189060.aspx

Database Master Key Msdn: https://msdn.microsoft.com/en-us/library/aa337551.aspx

Service master key SMK otomatik olarak oluşturulduğu için yedeklenmesini önemlidir. Aşağıdaki komut ile SMK’yi yedekliyoruz.

BACKUPSERVICEMASTERKEYTOFILE='c:\ServiceMasterKey\smk.key'

ENCRYPTIONBYPASSWORD='Buraya_guclu_bir_sifre_yazin';

Yedeklediğim klasöre bakıyorum

SSS-77

SMK’yı geri yüklemek istediğimizde, yedeklerken kullandığımız şifreyi kullanıyoruz. Bu şifreyi kaybetmemek gerekir. SMK’yı geri yüklemek için aşağıdaki kodu kullanıyoruz.

RESTORESERVICEMASTERKEYFROMFILE='c:\ServiceMasterKey\smk.key'

DECRYPTIONBYPASSWORD='Buraya_guclu_bir_sifre_yazin'FORCE;

Eğer Service Master Key’de bir bozulma olursa geri yükleme yapmak gerekir. Buradaki force komutu bir önceki keyi yok sayar, ve üzerine yedekteki keyi yazar. Yedeklenen keyin doğru key olduğundan emin olduktan sonra bu işlem yapılmalıdır.

Service Master Keyleri tüm diğer keyleri korumaya alır ve diğer tüm keylerden sorumludur. SMK’yı da Windows Data Protection API (DPAPI) korumaktadır.

DPAPI Msdn: https://msdn.microsoft.com/en-us/library/ms995355.aspx

DPAPI bu korumayı sağlarken Advanced Encryption Standard (AES)’i kullanır. Şifrelenmiş datayı yani cipher’ı kullanıcı hesap bilgilerini dahil ederek veri iletişimini sağlar.

Database master keyleri, SMK tarafından koruma altındadır. Database master key, manuel oluşturulan ve veritabanına özel keydir. DMK oluşturmak için aşağıdaki kod kullanılır.

USE ARGE;

CREATEMASTERKEYENCRYPTIONBYPASSWORD='guclu_sifre_guclu_key';

Sadece veritabanı seviyesinde bir şifreleme istendiğin ise, SMK’yı kaldırıp DMK kullanılabilir. İlk olarak SMK’yı ilgili veritabanı için Drop ediyoruz.

USE ARGE;

ALTERMASTERKEY

DROPENCRYPTIONBYSERVICEMASTERKEY;

Ardından veritabanımız için bir DMK oluşturuyoruz.

USE ARGE;

OPENMASTERKEYDECRYPTIONBYPASSWORD='guclu_bir_sifre';

Sql kod bloğu

CLOSEMASTERKEY;

Hangi veri tabanlarının SMK ile şifrelendiğini aşağıdaki sorgu ile görebiliriz.

SELECT name, is_master_key_encrypted_by_server

FROMsys.databases

ORDERBY name;

SSS-78

SMK ve DMK’larda kullandığımı simetrik keyleri de aşağıdaki sorgu ile detaylarına bakabiliriz.

SELECT*

FROMsys.symmetric_keys

SSS-79

DPAPI, SMK ve DMK’nın yapısını gösteren şema

SSS-80

Simetrik encryption keyler nasıl oluşturulur, nasıl kullanılır detaylarına bakalım.

Symmetric Encryption Keys – Simetrik Şifreleme Anahtarları:

Sql Server’da veriyi şifrelemek için ilk önce encryption keyleri oluşturmanız gerekmektedir. Sql Server kriptografi temellerinden iki farklı key sunmaktadır.

- Symmetric keys: Verinin şifrelenmesinde ve çözülmesinde aynı keyi kullanır.

- Asymmetric keys: Çift key kullanır, public key sadece veriyi şifreler, private key de public key’in ciphertext haline çevirdiği verir çözme işinde kullanılır.

Symmetric şifreleme daha hızlı çalışır fakat daha az güvenlidir. Symmetric key nasıl oluşturulur bakalım.

Aşağıdaki komut ile şifre ile korunan bir symmetric key oluşturuyoruz.

USE ARGE;

CREATESYMMETRICKEY Symmetrickey

WITHALGORITHM=AES_256

ENCRYPTIONBYPASSWORD='simetrik_key_sifresi';

Symmetric keyi oluşturduk, bu keyi açmak için aşağıdaki kodu kullanıyoruz.

USE ARGE;

OPENSYMMETRICKEY Symmetrickey

DECRYPTIONBYPASSWORD='simetrik_key_sifresi';

Tsql kodunda nasıl kullanacağımızı ilerki bölümlerde göreceğiz. Keyimiz açık kaldığı için kapatmamız gerekiyor.

CLOSESYMMETRICKEY Symmetrickey

Açıkta kalan keyleri görmek içinde aşağıdaki sorgu kullanılabilir.

SELECT*FROMsys.openkeys;

Bu keyi AES_256 algoritmasıyla şifreledik. Symmetric şifreleme de kullanabileceğimiz şifreleme algoritmaları şunlardır;
DES, TRIPLE_DES, TRIPLE_DES_3KEY, RC2, RC4, RC4_128, DESX, AES_128, AES_192, AES_256

Bu algoritmalardan en güçlüleri AES algoritmalarıdır, AES_256 aralarında en uzun ve en güçlü algoritmadır, büyük verilerin şifrelenmesinde biraz performans kaybına yol açmaktadır.

Şifreleme Algoritmaları Msdn: https://msdn.microsoft.com/en-us/library/ms345262.aspx

Oluşturduğumuz keylere SSMS üzerinden bakmak için ;

SSMS – Veritabanı_adi – Security – Symmetric Keys / Asymmetric Keys

SSS-81

Bir Symmetric key’i OPEN SYMMETRIC KEY komutu ile açıp kullanmaya başlarsınız, kod içerisinde kullanıldıktan sonra close komutu ile kapatırsınız veya session sonlandırıldığında kapanmış olur. Bir stored procedure da kullandığınız zaman kapatmayı unutursanız eğer, stored procedure sonlandığında key kendiliğinden kapanacaktır.

Stored procedure içinde begin-try-catch bloğu içerisinde de kullanılabilir, aşağıdaki örnekte stored procedure oturumu devam ettiği sürece key açık olacaktır, key eğer open ise catch bloğunun sonunda kontrol ederek kapatacaktır.

BEGINTRY

OPENSYMMETRICKEY Symmetrickey

DECRYPTIONBYPASSWORD='simetrik_key_sifresi';

kod bloğu

CLOSESYMMETRICKEY Symmetrickey;

ENDTRY

BEGINCATCH

IFEXISTS(SELECT*FROMsys.openkeysWHEREkey_name='Symmetrickey')

CLOSESYMMETRICKEY Symmetrickey;

ENDCATCH

Symmetric Keys Msdn: https://msdn.microsoft.com/en-us/library/ms189446.aspx

Asymmetric Encryption Keys – Asimetrik Şifreleme Anahtarları:

Asimetrik keyler iki bölümden oluşur, public key ve private key. Public key sadece veriyi şifreler, private key de public keyin şifrelemiş olduğu veriyi çözer. Asimetrik keyler, Database Master Keyler tarafından şifrelenirler, asimetrik key oluşturmak için önce DMK oluşturmak gerekmektedir. Eğer veritabanına ait bir DMK key yok ise, gene de asimetrik key oluşturabilir fakat bu asimetrik keyi şifre ile korumanız gerekmektedir.

RSA-2048 algoritması ile bir asimetrik key oluşturalım;

CREATEASYMMETRICKEY ArgeAsKey

WITHALGORITHM=RSA_2048;

Veritabanı ARGE seçili iken execute ettim, şifre ataması yapmadığım içinde asimetrik keyin private keyini DMK tarafından şifrelenmiş oldu.

Oluşturulan asimetrik keyleri aşağıdaki sorgu ile kontrol edebiliriz.

SELECT*FROMsys.asymmetric_keys

Arge veritabanında Security – Asymmetric Keys kısmına oluşturduğumuz key gözüküyor

SSS-82

Asimetrik keyler, simetrik keyler gibi open ve close komutlarını kullanmazlar. Microsoft veri şifrelemesinde simetrik keyleri önerir, çünkü asimetrik keyler simetrik keylere göre daha fazla sistem kaynağı kullanırlar.

Asymmetric Keys Msdn: https://msdn.microsoft.com/en-us/library/ms174430.aspx

Certificates – Sertifikalar:

Asimetrik keylerin kimlik bilgileri sertifikalara bağlıdır. Public key altyapısındaki X.509 standardını kullanır. Sertifikalar şifrelenmiş veriyi saklamaz ve taşımazlar. Verinin alıcısını dijital imza ile doğrularlar. Asimetrik keyler ile sertifika kullanılması kullanışlı bir yöntemdir, örnek olarak sertifika içine sona eriş tarihi eklenebilmektedir.

Sertifikalar mutlaka imzalı olmalıdır. Dijital imzalar sertifikanın yetkili bir sertifika sağlayıcısı tarafından imzalandığının kanıtıdır. İmzalanmış sertifikalar, asimetrik keylerin yerine simetrik keyleri koruyabilir. Daha da netleşmesi için veritabanı seviyesinde simetik, asimetrik ve sertifikaların nasıl kullanıldığı aşağıdaki şemada gösterilmiştir.

SSS-83

Şifreleme Hiyerarşisi Msdn: https://msdn.microsoft.com/en-us/library/ms189586.aspx

Sertifikalar Database Master Key tarafından şifrelenmektedir, sertifika kullanmadan önce DMK oluşturulması gerekmektedir. SMK ve DMK keylerine alıcıya ulaşmak için başvurur.

Şifre ile korunan bir sertifika nasıl oluşturulur görelim;

CREATECERTIFICATE ArgeSertifika

ENCRYPTIONBYPASSWORD='guclu_sertifika_sifresi'

WITHSUBJECT='Arge Db Sertifika',

EXPIRY_DATE='20150317';

Geçerlilik zamanıda belirtmiş olduk. Oluşturulan sertifika Veritabanı – Security – Certificates bölümünde bulunmaktadır.

SSS-84

Tüm sertifikaları görmek için aşağıdaki sorguyu kullanabilirsiniz.

SELECT*FROMsys.certificates

SSS-85

Sql Server’da sertifikalar X.509v3 standardını kullanmaktadır. RSA algoritmasını cipher tarafında kullanırlar. Private key 1024 bit uzunluğundadır. Dışardan import edilmek istenen sertifikaların formatı CER veya PVK olmalıdır, Sql Server’a direk olarak PFX veya PKCS#12 p.12 sertifikaları yüklenememektedir. OpenSSL gibi açık kaynak kodlu araçlar ile sertifikayı uygun formata dönüştürmeniz gerekmektedir.

Sertifikalar bir dosya halinde yedeklenebilmektedir. Sertifikalar SSMS üzerinden yedeklenememektedir. Aşağıdaki Tsql kodu ile yedeklenebilmektedir.

BACKUPCERTIFICATE ArgeSertifika TOFILE='C:\Sertifikalar\ArgeSertifika.cer'

WITHPRIVATEKEY (

FILE='C:\Sertifikalar\ArgeSertifika.pvk',

ENCRYPTIONBYPASSWORD='enc_sifre',

DECRYPTIONBYPASSWORD='dec sifre'

);

Simetrik Key ile Verilerin Şifrelenmesi:

Keylerin esas görevi verilerin şifrelenmesidir. Sql Server’da tavsiye edilen, daha performanslı çalışan simetrik keylerdir.

Simetrik key ile veri şifrelemek için EncryptByKey fonksiyonunu kullanacağız. Veritabanımızda bir tablo oluşturarak örneğimize başlayalım.

USE TICARET

CREATETABLE dbo.musteriler(

MusteriId intNOTNULLIDENTITY(1,1)PRIMARYKEY,

Ad varchar(50)NOTNULL,

Soyisim varchar(50)NOTNULL,

KrediBilgisi varbinary(1000)NOTNULL)

İlk olarak sertifika oluşturuyoruz

CREATECERTIFICATE MusterilerSertfika

WITHSUBJECT='Musteriler tablosunu simetrik key ile şifreleme';

Simetrik keyi oluşturuyoruz, oluşturduğumuz sertifika ile şifrelenecek şekilde yazıyoruz

CREATESYMMETRICKEY MusterilerSimetrikKey

WITHALGORITHM=AES_256,

KEY_SOURCE='33rdf03rkfs0d',

IDENTITY_VALUE='123100sdfsdk0'

ENCRYPTIONBYCERTIFICATE MusterilerSertfika;

Oluşturduğumuz simetrik keyi kullanarak, müşteriler tablosuna şifrelenmiş olarak KrediBilgisi insert edeceğiz.

OPENSYMMETRICKEY MusterilerSimetrikKey

DECRYPTIONBYCERTIFICATE MusterilerSertfika;

INSERTINTO dbo.musteriler

(

Ad ,

Soyisim ,

KrediBilgisi

)

VALUES (

'Yavuz',

'Filizlibay',

EncryptByKey(Key_Guid('MusterilerSimetrikKey'),

'4.000.000;Borcu yok,Sicili temiz', 1,'KrediBilgisiKey')

);

CLOSESYMMETRICKEY MusterilerSimetrikKey;

Kredibilgisi alanına müşteri hakkındaki özel bilgileri şifreleri olarak kaydetmiş olduk. İlk olarak simetrik keyi open komutu ile açtık, sonrasında MusterilerSertifika sertifikası ile şifreledik, verilerin girişi yapıldı, son olarakta close komutu ile açık olan simetrik keyi kapatmış olduk.

Bakalım kredibilgisi alanın gerçekten de şifrelenmiş mi, musterleri tablosuna sorgu atıyoruz.

SSS-86

Kredibilgisi alanı şifrelenmiş durumda, bunun gibi hassas verilerin şifrelenmesi veri güvenliği açısından çok önem kazanmaktadır.

Veriyi şifreledik, ciphertext olarak görüyoruz, peki bu veriyi nasıl okuruz yani plaintext olması için ne yapmamız gerekir buna bakalım. Direk sorguyu çekince gelmeyeceğini gördük, bu sebeple ilk olarak open komutu ile simetrik keyi açacağız, ardından DecryptByKey fonksiyonu ile sorguyu çekeceğiz, son olarak da close komutu ile açık olan keyi kapatacağız.

OPENSYMMETRICKEY MusterilerSimetrikKey

DECRYPTIONBYCERTIFICATE MusterilerSertfika;

SELECT Ad, Soyisim,

CAST(DecryptByKey(KrediBilgisi ,1 ,'KrediBilgisiKey')as

VARCHAR(50))

FROM dbo.musteriler;

CLOSESYMMETRICKEY MusterilerSimetrikKey;

Sorgu sonucunda kredi bilgisi plaintext olarak geldi.

SSS-87

Eğer sorgu sırasında key yanlış ise veya şifre hatalı ise, Kredibilgisi alanında NULL yazar.

EncryptByKey Msdn: https://msdn.microsoft.com/en-us/library/ms174361.aspx

DecryptByKey Msdn: https://msdn.microsoft.com/en-us/library/ms181860.aspx

Stored Procedure’de İmza İle Kimlik Doğrulama:

Tsql kodları dijital imzalar ile imzalanabiliyor, doğrulama sağlayabiliyordu. Bunu yaparken asirmetrik keylerin private keylerindeki sertifika bu bilgileri taşıyor ve karşı tarafta bu bilgilerin doğruluğunu onaylıyordu. Bunların yanında Sql Server’da stored procedureler, triggerlar ve fonksiyonlarda kimlik doğrulama yöntemi ile imzalanabilmektedir.

Bir stored procedure nasıl kimlik doğrulama ile imzalanır buna bakalım, Satış veritabanında aşağıdaki stored procedure’ü oluşturuyoruz.

USE SATIS;

CREATEPROCEDURE dbo.SP_Musteriler

ASBEGIN

DECLARE @sql varchar(2000)='SELECT * FROM dbo.satisdata'

EXECUTE (@sql)

END;

Burada yavuz_sql kullanıcısına bu stored procedure’ü çalıştırabilmesi için yetki veriyoruz.

GRANTEXECUTEONOBJECT::dbo.SP_Musteriler TO yavuz_sql;

Fakat yavuz_sql kullanıcısının satisdata tablosunda Select yetkisi yok, stored procedure yavuz_sql ile çalışacak mı bakalım

EXECUTEASUSER='yavuz_sql';

EXECUTE dbo.SP_Musteriler;

REVERT;

Aşağıdaki hatayı bize verdi, kullanıcıda select yetkisi olmadığı için sp çalışmadı.

Msg 229, Level 14, State 5, Line 1

The SELECT permission was denied on the object 'satisdata', database 'SATIS', schema 'dbo'.

Stored procedure’ü çalıştıracak sertifika sahibi bir kullanıcı oluşturacağız, bu sertifikaya bir bitiş süresi de koyabiliriz. Süre dolan sertifika süre sonunda çalışmayacaktır. Stored procedure’ü de bu sertifika ile imzalayacağız.

SETIDENTITY_INSERT db_owner ='yavuz_sql'

EXECUTEASUSER='yavuzdatabase'

CREATECERTIFICATE SP_Sertifika

WITHSUBJECT='Sp sertifikası',

EXPIRY_DATE='2015-11-15';

SELECT@@IDENTITY

ADDSIGNATURETO dbo.SP_Musteriler

BYCERTIFICATE SP_Sertifika;

Technet: https://technet.microsoft.com/en-us/library/ms188304(v=sql.105).aspx

Sql Server Nesnelerinin Şifrelenmesi:

Sql Server’daki bazı önemli nesnelerin gözükmesini kullanıcılardan ve programı sattığınız müşterilerden gizleyebilirisiniz. Kritik bir yerdeki stored procedure veya bir trigger şifrelenebilmektedir. Bu gibi önemli nesneler karmaşık kod yapısına sahip olabilmektedirler ve yazan kişi bu kodlara müdahale edilmemesini ister.

Örnek olarak bir stored prosedürü şifreli olarak oluşturalım;

CREATEPROCEDURE dbo.Sifrelenmis_SP

WITHENCRYPTION

ASBEGIN

SETNOCOUNTON;

SELECT*FROM dbo.Satis_adetleri

END

Prosedür oluşturuldu, tablomuzdaki Programmability – Stored Procedures den prosedürümüze bakalım.

SSS-88

Prosedüre ikonunun yanına bir de kilit ikonu eklenmiş durumda, prosedürü modify etmeye çalışalım.

SSS-89

Modify seçeneği de devre dışı aktif değil.

Sql serverda şifrelenmiş tüm nesneleri aşağıdaki sorgu ile görebilirsiniz.

-- Sql serverdaki şfirelenmiş nesneleri gösterir

SELECT o.Name as Nesne_Adi, o.Type_desc as Tipi

FROMsys.sql_modules m

JOINsys.objects o ON m.object_id= o.object_id

WHEREdefinitionISNULL

SSS-90

Nesne adını ve nesne tipini göstermektedir.

Şifrelenmiş bir nesne decrypt edilemez, şfiresi çözülemez. Nesnenin kodlarında bir değişiklik yapılacak ise önce DROP edilip sonradan CREATE edilmesi gerekmektedir.

Msdn: https://msdn.microsoft.com/en-us/library/ms187926.aspx

SQL server 1989 yılınan beri hayatımızda olan ve Microsoft’ un en değerli ürün ailesinden birini oluşturmaktadır. Özellikle 2008 sürümünden sonra çok hızlı bir gelişim göstererek rakiplerine oranlar ciddi pazar payı kazanımı sağlamak ile beraber hangi büyüklükte olur ise olsun iş yüklerinin altından kalkmayı başarmaktadır.

Yıl	Sürüm Adı
1989	SQL Server 1.0
1991	SQL Server 1.1
1993	SQL Server 4.21
1995	SQL Server 6.0
1996	SQL Server 6.5
1998	SQL Server 7.0
1999	SQL Server 7.0
2000	SQL Server 2000
2003	SQL Server 2000
2005	SQL Server 2005
2008	SQL Server 2008
2010	SQL Azure
2010	SQL Server 2008 R2
2012	SQL Server 2012
2014	SQL Server 2014

Biz makalemizde SQL 2014 serveri konu alacağımız için makalemizi SQL Server 2014 kapsamında genişleterek ele alacağız. Sql Server 2014 kullanılma ortamlarına göre aşağıdaki sürümler ile hayatımıza girdi.

Enterprise

Business Intelligence

Standard

Web

Developer

Express

Sql Server 2014 Lisanslama politikası da aşağıdaki gibidir.

SQL 2014 Versiyonları	Lisanslama Modelleri	Lisanslama Türleri
Enterprise	Per Core	Volume Licensing, Hosting
Business Intelligence	Server + CAL	Volume Licensing, Hosting
Standard	Per Core, Server + CAL	Volume Licensing, Retail, Hosting
Developer	Per User Fee	Volume Licensing, Retail
Web	SPLA	Hosting
Express	Free	Free

Sql 2014 Yüksek erişilebilirlik yapısı da aşağıdaki gibi farklı senaryolar içermektedir.

AlwaysOn Availability

Database Mirroring

Log Shipping

Bu genel bilgilerden sonra Sql Mirroring yapısını detaylandırabiliriz. Biraz uzun soluklu bir anlatım olacak ama burada amaç bu işi bilmeyen birinin bu işi tamamıyla kavraması yönünde.

Sql mirroring yapısı aşağıdaki şekilde işlemektedir. Bu yapıda bir tane sunucumuzda aktif veritabanı çalışmakta ve ikinci bir sunucuya bu veritabanımız kendini senkronize etmektedir. Aktif veritabanından bir sorun olması durumunda Witness sunucumuz bunu algılamakta ve pasifte bekleyen veritabanına yönelerek yapıda bir süreklilik sağlamaktadır. Genel yapıyı özetledikten sonra daha da detaya girebiliriz.

Öncelikle Sql Mirroring yapısında kullanılan terimleri ele alalım. Makalemiz bu terimler üzerinden ilerleyecek olduğu için bu terimleri kavramamız önem taşımaktadır.

Sql Miroring : Felaketten kurtarma, iş sürekliliği sağlamak adına Microsoft firması tarafından SQL Veritabanı Sunucuları için geliştirilmiş yüksek erişilebilirlik çözümlerinden bir tanesidir. SQL Server 2005 sp1 ile hayatımıza giren bu çözüm sonraki SQL Server versiyonları olan SQL Server 2008, SQL Server 2012 versiyonları tarafından da desteklenmektedir. Bu yapıdaki amaç bir veritabanının iki farklı sunucuda kopyası oluşturularak, mevcut aktif sunucunun herhangi bir nedenden dolayı servis verememesi, devre dışı kalması ya da veritabanının bozulması durumunda yedek sunucu üzerinde bulunan veritabanı ile erişimin ve servisin aynen devam ettirilmesidir.

Principal : Aktif olarak hizmet veren kaynak veritabanının tutulduğu sunucudur. Kaynak sunucu. Bu sunucu üzerinde bulunan veritabanının kendisi de kaynak veritabanı veya principal database olarak isimlendirilir.

Mirror : Kaynak veritabanının kopyasının oluşturulduğu yedek sunucudur. Bu sunucu üzerinde oluşan veritabanı da kopya veritabanı, yedek veritabanı veya mirror database olarak adlandırılır.

Witness : Principal ve Mirror sunucuları sürekli izleyerek bir kesinti olayı gerçekleşmesi durumunda otomatik olarak rollerin değiştirilmesi görevini yapar. Farklı bir tabirle database mirroring çözümünde ana sunucuda oluşabilecek bir kesinti durumunda yedek sunucuyu ana sunucu konumuna getirip manuel bir müdahaleye gereksinim olmadan sistemin aksamadan yürümesini sağlar. Witness sunucu kullanmak isteğe bağlıdır. Eğer otomatik geçiş istenmiyor veya buna bir sunucu ayrılamıyor ise kesintilerde rol geçişini manuel yapılacağı durumlarda tercih edilir.

Database Mirroring yapısna geçiş yapmadan önce dikkat edilmesi gerekenler;

- Database Mirroring yapısına geçiş için karar verilecek olunursa Sql Server versiyonları minimum SQL 2005 SP1 olmalıdır.

- Sql Server Sunucularının kurulu oldukları işletim sistemleri farklı olabilir. (Örn: Server 2008, Server 2012)

- Sql server kurulu olan işletim sistemleri 32 bit veya farklı olarak 64 bit olabilir.

- Principall ve mirror sunucuları aynı versiyon ve sürümde olmaları zorundadır.(Enterprise, Standart)

- Database Mirroring Enterperise ve Standart versiyonlar tarafından desteklenmektedir.

- Witness sunucusu ise Sql 2005 SP1 üzeri bir sql versiyonu olabilir. Express Edition bile kullanılabilir.

Artık ufaktan yapımızın kurulumuna geçebiliriz. Ben test ortamımı aşağıdaki şekilde kurdum.

Server	Rol	Versiyon
Dc	Witness	Sql 2014 Standart
SQLSERVER1	Principal	Sql 2014 Standart
SQLSERVER2	Mirror	Sql 2014 Standart

Yapımızda aşağıdaki gibidir. Test ortamım için tamamen sanal sistemimi kullanacağım.

Domain Controller sunucum aşağıda olduğu gibi görünmektedir. Bu DC olan sunucumda Witness rolünü barındıracağım.

SQLSERVER1 ve SQLSERVER2 sunucularımda ise Principal ve Mirroring sunucularımı barındıracağım. Bu gerekli ortam tanıtımından sonra artık ufak ufak adımlarımıza geçelim.

Öncelikle 3 sunucumuza da SQL Server 2014 Standart kurulumunu yapıyor olacağım. Ben bir sunucumda kurulumu anlatacağım. 3 sunucu üzerinde aynı işlemler yapılacağı için bu adımları 3 sunucu üzerinde tekrarlamanız gerekmektedir. Önceki zamanlarda Sql Server 2012 kurulum makalesi paylaştığım için bu adımları kısaca resim olarak gerektiği yerde açıklayarak geçeceğim. Sql Server 2012 kurulum makaleme aşağıdaki link üzerinden erişim sağlayabilirsiniz. SQL Server 2014 kurulum olarak aynı şekilde kurulmaktadır.

http://www.cozumpark.com/blogs/sql/archive/2013/04/07/sql-server-2012-kurulumu.aspx

SQL Server 2014 kurulum medyamızdan Setup.exe dosyasını çalıştıralım.

Karşımıza gelen kurulum ekranında ortamımıza yeni bir SQL Server kuracağımız için “New SQL Server standalone installation or add features to an existing installation” seçeneğini seçelim.

Ben test ortamı için kurulum yapacağımdan dolayı “Evaluation” seçeneğini seçip ilerliyorum. Siz kurulumuzu yaparken burada gerekli sürümü seçer sürümün gereksinimine göre key girerek veya girmeyerek bir sonraki ekrana ilerleyebilirsiniz.

Lisans anlaşmasını kabul edip bir sonraki adıma ilerleyelim.

Gerekli güncellemeleri kurulum öncesinde denetlettirebiliriz. Tabi bu sizin seçiminize kalmış ben bu şekilde bir sonraki adıma ilerliyorum.

Kurulum için gerekli sistem denetlemesi yapıldı. İleride portlar noktasında sorun olabilir diye Firewall uyarı verdi. Biz bu adımı ayrıca ele alacağımız için bir sonraki ekrana ilerliyoruz.

Biz tüm özellikleri eklemeyeceğimiz ve Share Point ortamı için SQL Server kurmayacağımız için yeni bir SQL Server kurulumu yapacağımız için “SQL Server Feature Installation” seçeneğini seçerek bir sonraki ekrana ilerliyoruz.

Bu ekranımızda gerekli rolleri seçiyoruz. Aşağıdaki seçimleri yapmamız bizim için yeterli. Geri kalan özellekler bizim senaryomuzda bize lazım değil boş yere zaman ve sistem kaynaklarını kaybetmemek için bu adımları geçiyoruz.”Management Tools-Complete” kesinlikle kurulmalıdır. Mirroring yapılandırması bu toolun kurulumu ile aktif olmaktadır.

Kurulum için gerekli olan Feature’lar denetlendiğinde .NET Framework 3.5’un kurulu olmadığı görünüyor öncelikle bu Feature’ı kurmamız gerekiyor.

Server manager konsolunu açarak “Add roles and features” linkine tıklayalım.

Gelen ekranı geçerek sonraki ekrana ilerleyelim.

“Role – based or feature-based installation” seçimi ile sonraki ekranımıza ilerleyelim.

Bu sunucumuza gerekli olan .NET özelliğini kuracağımız için zaten diğer ortamdaki sunucularımızda eklenmediği için mevcut sunucumuzu seçerek ilerleyelim.

Biz rol kurulumu yapmayacağımız için bir sonraki ekrana ilerleyelim.

Karşımıza gelen Feature ekleme ekranından .NET Framework 3.5 Features seçimini yaparak bir sonraki ekranımıza ilerleyelim.

Sihirbaz bize yapılacak olan işlemler noktasında bir özet sundu. Install butonu ile özelliğimizin kurulması adımını başlatalım.

Kurulum tamamlandı “Close” ile adımımızı bitirip SQL Server 2014 kurulum ekranımıza geri dönelim.

SQL Server 2014 kurulum adımımızda karşımıza çıkan sorunu aştık ve sonraki adıma ilerledik. Burada bir instance ismi belirleyebilir veya var olan ile ilerleyebiliriz. Ben var olan isimle bir sonraki ekranımıza ilerliyorum.

Karşımıza Server Configuration ekranı geldi. Service Accounts tabında SQL Server 2012 Servislerini çalıştıracak kullanıcı hesapları belirlenir. Bu servis seçimlerini aşağıdaki gibi bırakabilirsiniz. İlerleyen makale serilerimizde yapacağımız bazı örnekler ile bu kısımlara zaten yer vermek durumunda kalacağız.

Collation tabından SQL Server dil ve karakter set ayarlarını “SQL_Latin1_General_CP1_CI_AS” olarak seçip bir sonraki ekrana ilerleyelim.

Biz yapımızda şu anda “Windows authencation mode” seçimini yapacağız. Bu metot ile kimlik doğrulaması yaptığım için Windows kullanıcılarından bir tanesini seçmem gerekmekte. Kurulumu Administrator hesabı ile yaptığımız için “Add Currnet User” seçimini yaparak Administrator kullanıcısının otomatik eklenmesini sağlayabiliriz.

Biz Database Mirroing yapılandırması yapacağımız için Gerekli SQL Server Directory’lerini belirlerken iki tarafta da aynı yolları göstermek durumundayız. Bu nedenle ben SQL Directory yapılandırmasında farklı bir disk yapısı kullanmadığım için tüm sistem yapısını varsayılan değerde bırakıp bir sonraki ekrana ilerliyorum.

Sihirbaz bize yapılacak olan işlemlerin bir özetini getirdi. Bu ayarları Configuration file path birimine bir dosya olarak atacak. Biz Install ile kurulumu başlatalım.

Kurulum işlemleri başladı.

Kurulum tamamlandı ve hatasız olarak tüm işlevler başarı ile tamamlandı.

Sql servislerimiz sorunsuz olarak konsola eklenmiş ve instance’ımıza ait olan SQL Server (MSSQLSERVER)” rolü “running” olarak çalışır durumda.

Kısa yollarımız sorunsuzca oluşturuldu. “SQL Server 2014 Management Studio” ekranını açabiliriz.

Mixed mode olarak kurulum yaptığımız için ve kurulumu ADMINISTRATOR hesabı ile yaptığımız için “Connect” butonu ile yönetim konsolumuzun açılmasını sağlayabiliriz.

Konsolumuz sorunsuzca açıldı. Bizim buraya kadar olan SQL Server 2014 kurulum adımlarını geriye kalan 2 sunucumuz üzerinde de yapmamız gerekmektedir.

Geri kalan 2 sunucumuzda da SQL Server 2014 kurulumlarını tamamladıktan sonra 3 sunucumuzda 1433 numaralı porta izin vermemiz gerekmektedir.

3 sunucumuzda kurulum tamamlandıktan sonra ve 3 sunucumuzda 1433 numralı portmuza firewall üzerinden izin verdiğimizde diğer sunucularımız üzerinde bulunan SQL Server 2014 sunucularımızı SQL Server Management Studio üzerine ekleyebilir ve erişebilir duruma geldik.

Resmimizde görüldüğü gibi Witness, Principal ve Mirror sunucularımız konsolumuza eklendi ve Mirroring yapılandırmasına hazır durumda.

SQLSERVER1 sunucum üzerinde “RIZASAHAN” isminde bir veritabanı oluşturdum. Bu veritabanımda “MUSTERILER” isminde bir tablo oluşturdum ve içerisine birkaç kayıt girdim.

Database Mirroring yapacağımız veritabanımızın özelliklerine girelim. Daha önce SQL sunucusu kurulan yapıda Database Mirroring yapılacak ise veritabanı “Recovery Model yapısı Full“olarak ayarlanmak zorundadır. Biz sıfırdan bir veritabanı oluşturduğumuz için zaten özelliğini Full olarak ayarladık.

Veritabanımız üzerinde Mirroring özelliği bulunmakta fakat aktif edilmemiş durumdadır.

Veritabanımızın full recovery modelinde olup olmadığını kontrol ettikten sonra Database Mirroring özelliğini aktif edebilmemiz için Principal sunucumuz üzerindeki veritabanının yedeğini almamız gerekmektedir. Bu nedenle veritabanımız üzerinde sağ tuş yaparak TaskàBack Up.. menülerine tıklayalım.

Karşımıza gelen ekranda Backup Type olarak Full seçiliyken yedek almak için “OK” butonuna tıklayalım.

Yedeğimizin başarı ile alındığı mesajını “OK” ile geçelim.

Full olarak veritabanımızı yedekledikten sonra birde Transaction log backup olarak yedek almamız gerekmektedir. Bu işlem için yine veritabanımız üzerinde sağ tuş TaskàBack Up… menüsüne tıklayalım.

Backup Type seçeneğini Transaction log backup olarak seçip “OK” ile yedeği başlatalım.

Yedeğimiz başarı ile tamamlandı uyarısını yine “OK” butonuna tıklayarak kapatalım.

Öncelikle full yedeğimiz alınmış durumda ve üzerine Transaction yedeğimizde eklenmiş durumda. Yedek dizinimize baktığımızda yedeklerimizin tek bir dosyaya sorunsuzca alındığını görebilmekteyiz.

Evet buraya kadar olan adımlarımızı tamamlayarak Database Mirroring için gerekli olan zorunlu adımları tamamladık. Principal sunucumuz üzerinde şimdilik işlemimiz bitti. Şimdi Mirror sunucumuza geçip işlemlerimize devam edebiliriz. Mirror sunucumuzda Principal sunucu üzerinde yedeği alınan veritabanının geri dönülme işlemi yapılması gerekmektedir. Mirror sunucumuzda Database üzerinde sağ tıklayarak “Restore Database…” menüsüne tıklayalım.

Yedeğimizin yolunu göstermek için “…” butonuna tıklayalım.

Açılan ekranda “Add” butonuna tıklayalım.

Yedeğimizi seçip “OK” butonuna tıklayalım.

Yedeğimiz eklendi “OK” butonuna tıklayalım.

Yedeğimizin içinde iki adet yedek barındığı için “Companent” sütununda bu yedeğin Database Full ve Log Transaction yedek barındırdığını görebiliyoruz. Biz ilk seçenek olan Database Full yedeğimizi seçelim ve ek ayarlar için “Option” kısmına gelelim.

Yedeğimizin dönüş özelliğini “RESTORE WITH NORECOVERY” mod olarak seçmemiz gerekiyor. Bu işlemden sonra “OK” ile restore işlemini başlatalım.

RIZASAHAN veritabanı yedeğimiz SQLSERVER2 sunucumuz üzerine başarılı şekilde restore edildi.

Bu durum SQLSERVER2 sunucumuz üzerinde aşağıdaki gibi görünmektedir.

Şimdi SQLSERVER1üzerinden alınan yedeğimizi SQLSERVER2 Sql sunucumuz üzerinde döndüğümüze göre geri kalan adımlara ilerleyebiliriz. Full yedeği döndükten sonra birde bu yedeğin üzerinde Transaction Log yedeğini dönmemiz gerekmektedir. Bu nedenle Restore ettiğimiz veritabanı üzerinde yarım kalan adımımızı tamamlamak için sağ tuş TaskàRestoreàTransaction Log.. menüsüne tıklayalım.

Yedeğimizin yolunu göstermek için “…” butonuna tıklayalım.

Açılan ekranda “Add” butonuna tıklayalım.

Yedeğimizi seçip “OK” butonuna tıklayalım.

Yedeğimiz eklendi “OK” butonuna tıklayalım.

Yedeğimizin içinde RIZASAHAN veritabanına ait olan Full Database yedekleme ekranımıza eklendi. Biz “Option” kısmına gelelim.

Bu yedeğimizi de yine (RESTORE WITH NORECOVERY) modda döneceğimiz için aşağıdaki ekranda gözüktüğü gibi bir seçim yapalım ve “OK” tuşuna tıklayalım.

Transaction Log Yedeğimiz “RIZASAHAN” veritabanı üzerine başarı ile dönüldü.

Buraya kadar olan adımları tamamladıktan sonra Database Mirror özelliğini faaliyete geçirmek için 5022 portunu da 3 sunucumuzda açmamız gerekmektedir.

Bu kadar ön bilgi ve hazırlıktan sonra Database Mirror özelliğini aktif edebilir hale geldik. JŞimdi Principal sunucumuz üzerinde yer alan RIZASAHAN veritabanına sağ tıklayarak “TaskàMirror” butonuna tıklayalım.

Sarı alanda görüldüğü gibi Mirroring yapımız konfigüre edilmemiş durumda. “Configure Securtiy…” butonumuza tıklayarak konfigürasyon adımlarını başlatalım.

Bize genel bilgi veren sihirbaz ekranını geçerek bir sonraki ekrana ilerleyelim.

Bu ekranımızda Witness sunucumuzun güvenliğinin konfigüre edilip edilmeyeceği sorulmaktadır. Makalemizin başında da belirttiğimiz gibi Witness kullanılması zorunlu değildir. İşlemlerimizi otomatikleştirir. Biz gerekli masrafı yapmak istemiyor veya mirroring geçişini manuel yapmak istiyorsak Witness kullanmak zorunda değiliz. Makalemizde Witness kullanacağımız için bu ekrandaki soruyu YES seçeneği ile geçerek sonraki ekranımıza ilerliyoruz.

Yapılandıracağımız rolleri seçip ilerlememiz gerekiyor. SQL Database Mirroring senaryomuzda Pricipal ve Mirror zorunlu olduğundan bunların seçimine müdahale edemiyoruz. Bu ekranda yine Witness serveri iptal etme hakkımız var ama biz Witness yapılandırmasını yapacağız. Şunu da belirtmekte yarar var Witness ortama sonradan dahil edilebilir.

Mirror sunucumuzu seçiyoruz. Port olarak ise 5022 portunu seçiyoruz. Buradaki instance serverler tek SQL server üzerinde olsa farklı portlar kullanmamız gerekecekti. Bizim SQL serverlerimiz ayrı ayrı kurulduğu için yapılandırmadaki Mirror ve Witness sunucularda yine 5022 portunu kullanabiliriz. Bir sonraki ekranımıza ilerliyoruz.

Bizden Mirroring sunucusunu göstermemiz istenmektedir. Kendisi otomatik olarak SQLSERVER2 serverini seçti. Biz bunu seçmeyip farklı sunucu seçebilirdik fakat bu serveri seçeceğimiz için bu kısma dokunmuyoruz. Bu nedenle bu server’imize bağlantı sağlamamız gerekmektedir. Bu nedenle Connect butonumuza tıklayalım.

Gelen ekranda Authencation tipimize göre login olmamız gerekmektedir. SQLSERVER sunucularımın tamamını Mixed Mode olarak kurduğum için Administrator hesabı ile bağlantı sağlayacağım için direkt olarak Connect butonuna tıklıyorum

Gerekli check işlemi tamamlandı bağlantı bilgilerimizde sorun olmadığı için SQLSERVER2 sunucumuz mirror konumuna geldi. Port olarak yine yukarıda bahsettiğimiz gibi server’lerimizi ayrı ayrı kurduğumuz için 5022 numaralı portu kullanabiliriz. Endpoint isimlerini karışıklık olmaması adına Principal server’da Pricipal olarak, Mirror Server’da mirror olarak bırakıp sonraki ekranımıza ilerliyoruz.

Bu ekranımızda bizden Witness Serverimizi tanıtmamız istenmektedir. Witness rolünü barındıracak olan SQL Server’i DC isimli sunucuma kurduğum için seçimi bu şekilde bırakarak Connect… butonuna tıklıyorum. İki önceki ekranımızda olduğu gibi yine bağlantı sağlıyoruz. Yine portumuzu 5022 olarak varsayılan ayarda bırakıp, Endpoint ismini Witness olarak bırakıp sonraki ekrana ilerliyoruz.

Bu ekranımızda bizden Service Account hesabının bilgileri istenmektedir. Her sunucu için ayrı hesap kullanılabileceği gibi tek bir hesapta kullanılabilir. Ben Mixed Mode olarak kurulum yaptığım için Administrator hesabımı domainismi\hesapismi şeklide yazarak sonraki ekrana ilerliyorum.

Bu ekranımızda yapılacak olan işlemlerin özeti yer almaktadır. Finish ile yapılandırmamızın başlamasını sağlayalım.

Yapılandırmamız 3 sunucumuz içinde başarı ile uygulandı. Close ile bu ekranımızdan çıkalım.

Karşımıza gelen ekranda bize Database Mirroring yapısını start edip etmeyeceğimiz sorulmaktadır. “Start Mirroring” butonu ile tıklayarak Database Mirroring yapısının başlamasını sağlayalım.

Mirroring işlemi başlatılamadı ve aşağıdaki hata ile karşılaştık. Bunun nedeni Database Mirroring işlemini başlatabilmemiz için SQL Server kurulumu sırasında Servis Hesapları kullanmış olmamızdır. Bu nedenle işlemimize başlayabilmek adına Servis hesabı yerine farklı bir hesap ataması yapalım.

Sql Server Configuration Managerüzerinde MSSQL instance üzerinde çift tıklayarak Log On tabında Administrator hesabını gösterelim ve gerekli şifreyi girelim. Apply ve OK butonlarına tıklayarak bu ekranımızdan çıkalım.

Yukarıda yapılan işlemi Witness, Principal ve Mirror sunucularımızın hepsinde yapıyor olmamız gerekmektedir. Bu işlemi yaptıktan sonra Database Mirroring işlemini başlatmak için tekrardan “Start Mirroring” butonumuza tıklayalım.

Bu kez hata almadan Database Mirroring yapımız aktif oldu. Aktif olduktan sonra senkronizasyon işleminin başladığını aşağıdaki kırmızı alanımızda görebilirsiniz.

Artık bu durumda senkronizasyon tamamlandığında veri tabanımıza gelen bilgiler aynı anda iki veri tabanımıza birlikte yazılacaktır. Çalıştırılan bir komut iki tarafa commit edildiğinde görevini yerine getirecektir. Burada minimal düzeyde bir performans sıkıntısı olacaktır.

Database Mirroring yapısının ne durumda olduğunu görebilmek adına SQL Server Management Studio üzerinden durumu monitorize edebilmekteyiz. Bu işlemi yapabilmek için Database Mirroring yapısına kattığımız veritabanımız üzerinden sağ tıklayarak TaskàLaunch Database Mirroring Monitor… menüsüne tıklayalım.

Açılan ekranımızda replikasyon durumunu görebilmek adına Replication monitör menüsünü tıklayalım.

Açılan ekranda monitorize edeceğimiz sunucularımızı eklemek için Register mirrored database linkine tıklayalım.

Öncelikle ekranımızda ilk görülen Mirroring Sunucumuza “Connect” butonuna tıklayarak bağlantı sağlayalım.

Konsolumuza Database Mirroring sunucularımız eklendi. Şu anda senkronizasyon tam olarak tamamlanmadığı için hatalar görmekteyiz. Tam senkronizasyon sağlandığında burada sadece yeşil ikonlar görerek işlerin yoluna girdiğini anlayacağız.

Belirli bir zaman bekledikten sonra, veritabanının büyüklüğü, disk network performansı gibi kriterlere göre senkronizasyon zamanı biraz değişiklik gösterebilmektedir. Şu anda sorunsuz şekilde senkronizasyon tamamlanmış olarak görünüyor. Sunucularımız senkronize bir şekilde işlevlerini sürdürmeye başlamış durumdalar.

Bu durum SQL sunucularımızın olduğu ekranda aşağıdaki şekilde gözlemlenmektedir.

Dilerseniz senkronizasyon sırasında oluşabilecek durumlarda karşımıza çıkan terimlerden kısaca bahsediyor olalım.

Synchronized : Principal sunucu ile mirror sunucu aynı veritabanı kopyasına sahiptir ve senkronize edilecek veri farkı yoktur.

Synchronizing : Database mirroring yapısının kurulduğu anda görülen durumdur. Doğal olarak mirror sunucusu principal’in gerisinde kalmıştır ve değişiklikleri kendisine güncellemeye çalışıyor demektir.

Suspended : Principal sunucunun mirror sunucuya transaction’ları gönderemediği durumlarda mirroring durum olarak bunu gösterir. Özellikle failover gerçekleşirse bu durum görülür. Ayrıca eğer manuel olarak database mirroring pause edilirse de yine bu durum görülebilir.

Pending_Failover : Failover olduğunda ve principal sunucu kendi üzerindeki açık sessionları kapatıp kendisini mirror sunucu olarak ayarladığı anda gözüken durumdur.

Disconnected : Mirroring yapısındaki ortakların (principal, mirror vb.) aralarındaki bağlantıyı kaybettikleri zaman oluşan durumdur.

Buraya kadar gerçekleşen senaryoda Database Mirroring yapısının ne olduğunu ve nasıl kurgulanacağını anlattık ver gerçekleştirdik. Şimdi birazda testler yapalım ve Mirroring durum ve terimlerini inceleyelim. Database Mirroring ekranımıza girebilmek için veritabanımız üzerinde sağ tılayarak TaskàMirror… menüsüne tıklayalım.

Şu an açılan ekranımızda Pricipal, Mirror ve Witness sunucularımızı görebilmekteyiz. Burada dilersek yukarıda belirttiğimiz gibi Witness sunucumuz olmasaydı “Failover” butonu ile rol değişimini yapabilir principal ve mirror sunucularımıza rol değişimi yaptırabilirdik. Bu durum felaket anından Principal sunucumuzda sorun olması durumunda uygulanabilir.

Pause ile Database mirrorin işlemini geçici süre durdurabiliriz. Bu sunucularda bakım yapılması durumunda geçerli olacak bir durumdur.

Remove Mirroring ise ortamımızdan Database Mirroring yapısını kaldırmak istediğimiz durumda kullanılabilir.

High Performance (Asynchronous):Bu modda öncelikli olarak Principal veritabanına işlem onaylanarak yazılır, sonra da Mirror veritabanına yazar. Biraz açmak gerekir ise Principal veritabanı yapılan transaction sonucunu kendi veritabanına yazmak için mirror veritabanından da eşzamanlı yazma onayı beklemeden hemen kendi üzerine yazar. Dolayısıyla mirror veritabanı, principal veritabanı ile farklı zamanlarda yazma işlevini yerine getirirler, mirror veritabanı principal veritabanını geriden takip eder. Bu modda sadece Principal Server ve Mirror Server rolleri kullanılır, Witness Server rolü kullanılmaz. Principal sunucu ile mirroring sunucu rollerinin değişimi manuel olarak gerçekleştirilir.

Yüksek Güvenlikli (High Safety): Bu modda gerçekleştirilen bir transaction principal veritabanına yazılmadan önce mirror veritabanı sunucusuna da aynı transaction bilgisi gönderilerek mirror sunucusundan gelecek transaction onayı beklenir. Mirror veritabanında transaction onaylandığı ve işletildiği bilgisi geldikten sonra principal veritabanı üzerinde o transaction onaylanarak işlevini yerine getirir. Principal veritabanı gerçekleşen transaction işlevinin mirror veritabanına yazılma onayı sonrasında eş zamanlı olarak yazma işlevini yerine getirir. Bu şekilde hem principal hem de mirror eş zamanlı olarak aynı değişikliğe uğradıkları için bu moda biz aynı zamanda Senkron Mod adı verilir. Bu modda herhangi bir şekilde veri farkı ya da kaybı olmadığı için biz bu moda “yüksek güvenlikli (high safety) adı verilir.

High Safety without automatic failover (synchronous): Hem principal hem de mirror veritabanlarına eş zamanlı olarak yazılan modudur. Witness Server rolü kullanılmayan çalışma modudur. Bu modda principal sunucusundaki veritabanında sorun olursa mirror sunucudaki veritabanını principal rolüne transfer etme işlemi manuel olarak gerçekleştirilir.

Şimdi dilerseniz manuel olarak rol değişimi yapalım. Sunucularımız arasında principal ve mirror rolleri arasında geçiş yapalım. Bu işlem için Failover butonuna tıklayalım.

Karşımıza gelen ekrandaki sorumuza YES ile yanıt verelim.

Şu anda aşağıda olduğu gibi rollerimizin değiştiğini görebilmekteyiz. Principal olan SQLSERVER1 sunucumuz Mirror, Mirror olan SQLSERVER2 sunucumuz ise Principal olarak hizmet etmeye başladı.

Bu durumda SQLSERVER2 sunucumuzu bir sorun olduğunu düşünerek kapatalım. Bakalım bir failover durumunda ne olacak?

Biz yukarıdaki test işlemlerimizde SQLSERVER2 sunucusunu principal yapmıştık. Son testimizde SQLSERVER2 sunucumuzu kapattık. Witness rolü sayesinde roller yer değiştirdi. Aşağıdaki durumda gördüğünüz gibi Principal sunucumuz tekrardan SQLSERVER1, mirror sunucumuz ise SQLSERVER2 oldu.

Bu durum SQL sunucularımız üzerinde aşağıdaki şekilde görülmektedir.

SQLSERVER2 sunucumuzu açtığımızda tekrardan otomatik olarak senkronizasyon başlamaktadır.

Şimdi ise farklı bir test yaparak DC olan Witness sunucumuzu kapatalım.

Bu durumda artık ortamda bir failover olması durumunda geçişlere karar verecek olan sunucumuz ortadan kalktı. Bu durumda geçişleri manuel olarak yapmamız gerekmektedir. Witness kapalı olmasına rağmen yapıda bir aksama olmadan hizmet vermeye devam etmektedir. Durum aşağıda gözlemlenmektedir.

Biz senaryomuzu biraz zorlaştırarak principal sunucumuzu da kapatalım. Ortamda sadece Mirror sunucumuzun aktif olarak hizmet verdiğini düşünelim. Şu anda mirror sunucumuzun da Principal sunucumuz ile olan bağlantısı koptu. Bu durum sunucumuza aşağıdaki şekilde yansıdı.

Bu gibi durumlar çok elzem ve büyük bir sorunun olduğuna dair durumlarda meydana gelebilir. Ortamda Witness sunucunun ulaşılmaz olması durumu istenmeyen senaryodur. Buna karşın yine komut ile zorlama metodu ile principal sunucunun rolü almasını sağlayabilmekteyiz.

SQL sunucumuz üzerinden aşağıdaki şekilde bir sorguyu çalıştırmamız gerekmektedir.

ALTER Database RIZASAHAN SET PATNER FORCE_SERVICE_ALLOW_DATA_LOSS

Bu komuttan sonra sunucumuzu Refresh edelim.

Böyle elzem bir senaryoda Witness olmadığı durumda Principal çökse bile mirror sunumuz ayağa kalkmakta ve principal rolünü almaktadır. Durum aşağıdaki gibi gözükmektedir. Veritabanımıza ve tablolarımıza erişim sağlayabilir duruma geldik.

Uzun soluklu makalemizin sonuna geldik. Umarım yararlı olur. Farklı bir makalemizde görüşmek üzere.

Sql Server sürümlerinin en son versiyon olan Sql Server 2014 ile birlikte birçok yeni özellik gelmiştir. Daha fazla cloud desteği ve daha fazla performans sunmaktadır. Cloud üzerine yedek alınması ve In-Memory tablolar en dikkat çekici yeni özelliklerdir. Azure üzerinde lokal veritabanlarınızı tutabilir veya lokal veritabanlarınızı Azure üzerine yedek alabilir hale gelmiştir.

Klasik veritabanı yedeklemenin dışında, URL backup ve Encrypt backup ile yedeklerimizin güvenliği daha da artmaktadır.

In-Memory Optimized Tables – Hafıza üzerinde çalışan tablolar ile birlikte 30 kata kadar performans büyük ölçüde arttırılmıştır.

Azure üzerine Sql Server’ın replikasını konumladırma imkanı ve veri dosyalarının Azure üzerinden kullanılabilmesi sağlanmıştır.

Columnstore indeksler önceki sürümlerde güncellenemiyordu, Sql Server 2014 ile birlikte artık columnstore indeksler güncellenebilmektedir. Columnstore indeksleri drop-create etmeye gerek kalmadan güncelleme imkanı sunmaktadır.

Delayed Durability özelliği sayesinde, transactionların, transaction log dosyasına yazma metodu yönetilebilir hale getirilmiştir. Performans açısından bu özelliğin yönetilebilmesi önemli bir konudur.

Buffer pool extension ile birlikte, Sql Server için yeni bir sanal bellek dosyası oluşturup, bu sanal belleği SSD diskler üzerinde çalıştırılması sağlanmıştır.

Bu yeni özellikleri incelemeye başlayalım, ilk olarak Azure üzerinde nasıl veritabanı oluşturulur buna bakalım.

Windows Azure Sql Database:

Cloud kavramı uzun zamandır konuşulan ve farklı alanlarda kullanılan bir kavramdır. Temelde uzaktaki sunucuların internet üzerinden hizmet vermesi anlamına gelir. Cloud hizmetleri olarak, Software as a service (SaaS) – yazılım servisi veya Infrastructure as a service (IasS) – Altyapı, donanım servisi olarak hizmet vermektedirler. Microsoft’un yeni vizyonu olan “Cloud first, mobile first” kavramında ileriki zamanlarda daha çok cloud hizmetlere yöneleceğinin sinyalini vermektedir. Sql Server veri dosyaları Azure üzerinde nasıl oluşturulur bunu inceleyeceğiz.

SaaS’ın temelinde, yazılım hizmeti müşteriye sunulur, müşteri de kullandığı kadar bu servisin ücretini öder. Sql Azure SaaS için güzel bir örnektir. IaaS hizmetinden farkı, kullandığınız kadar ödemenizdir. Iaas hizmetlerinde ücretler genel olarak kiralama mantığında çalışır, kullanın veya kullanmayın kira ücretini ödemek zorunda kalırsınız. Azure üzerinde isterseniz Sql database, isterseniz de Windows Server üzerine kurulu olan Sql Server 2014’ü kullanabilirsiniz.

Sql Azure veritabanı oluşturabilmeniz için, Azure hesabınızın olması gerekmektedir. Deneme sürümünü kullanmak içinde geçerli bir kredi kartınızı kayıt olarak kullanmanız gerekmektedir. Aşağıdaki linkten Azure sitesine gidiyoruz.

http://azure.microsoft.com/tr-tr/

Siteye kayıt olduktan sonra, portal kısmından giriş yapıyoruz. Aşağıdaki gibi ana sayfa karşımıza geliyor.

SSA-1

Sol taraftaki menüden SQL DATABASES bölümüne tıklıyoruz.

SSA-2

Ekranın aşağısındaki + NEW butonuna basarak menüleri açıyoruz, açılan menüde Custom Create’e tıklıyoruz.

SSA-3

Karşımıza bir sihirbaz geliyor, bu ekranda veritabanımıza bir isim veriyoruz. Service Tiers kısmında veritabanının kapasitesini belirtiyoruz, Basic 2gb a kadar boyut sunan en temel veritabanı, Standart tier en yaygın kullanılan cloud uygulamaları için yeterli seviyede ve kapasitesi 250 gb kadar destekliyor, Premium tier ise büyük yapılar için tercih edilen, mission critical uygulamalar için olan tiptir, 500 gb’a kadar boyutu desteklemektedir.

Collation seçimini yaptıktan sonra, Server kısmında New Sql database server’ı seçiyoruz.

SSA-4

Service Tiers ve Performance levellar ile ilgili detaylı tablo

SSA-5

Msdn Service Tiers ve Performance Levels: https://msdn.microsoft.com/library/dn741336.aspx

İkinci sayfada, New Sql database Server oluşturacağız. Veritabanına erişmek için Login name’i yazıyoruz, login name için sa, admin v.b. bilinen kullanıcı isimlerinin verilmesine izin verişmiyor. Şifre içinde kompleks yapıdaki en az 8 karakter, büyük-küçük harf, özel karakter ve rakamlardan oluşturmak zorunlu. Region kısmında ise veritabanının hangi Azıre bölgesinde olmasını belirtiyorsunuz, bulunduğunuz bölgeye yakın bir Azure datacenter seçmekte fayda var.

Azure servislerinin Sql Database Server’a erişebilmesi için aşağıdaki checkboxın işaretli olması gerekiyor.

SSA-6

Azure Sql veritabanımızı başarılı bir şekilde oluşturmuş olduk, Sql Databases ekranına gelmiş oldu.

SSA-7

Azure üzerinde Sql database’i oluşturduk, bu database’i lokaldeki Management Studio’ya nasıl bağlayacağız bakalım. İlk olarak Azure tarafındaki firewall ayarlarını yapmamız gerekecek. Yukarıdaki şekilde Sql Databases altındaki veritabanına tıklıyoruz, karşımıza aşağıdaki detaylar ekranı geliyor. Set up Windows Azure firewall rules for this IP address bağlantısına tıklıyoruz.

SSA-8

Firewall kuralı eklendiğinde aşağıdaki bilgi alanında açıklaması gözükecektir.

SSA-9

Firewall kuralını ekledikten sonra Management studio dan Azure üzerindeki veritabanımıza bağlanalım. Management Studio bağlantı ekranına SSA-8 deki Server adını yazıyoruz. Kullanıcı adı ve şifre kısımına da SSA-6 şeklindeki, Azure veritabatanını oluştururken kullandığımız kullanıcı adı ve şifreyi yazıyoruz. Connect dedikten sonra, veritabanımız management studio ya gelmiş oluyor.

SSA-10

Karşımıza 3 klasör geliyor, Databases, Security ve Management. Azure database üzerindeki tüm işlemleri SSMS üzerinden yapabilmekteyiz.

Lokal Veritabanı Azure’a Taşıma:

Lokaldeki bir veritabanını Azure üzerine taşıyarak burada kullanılabilmektedir. Veritabanı üzerinde sağ klik yaparak Tasks – Deploy Database to Windows Azure Sql Database sihirbazı ile bu işlemi gerçekleştirebiliriz.

SSA-11

İlk tanıtım ekranını geçiyoruz. Deployment Settings ekranında Connect ile Azure bağlantımızı gerçekleştiriyoruz. Veritabanı adımız seçtiğimiz veritabanından otomatik olarak geliyor. Edition of Windows Azure SQL Database kısmından veritabanının tipini seçiyoruz. Maximum database size (GB) kısmında da veritabanımızın ulaşacağı maksimum boyut seçilmektedir.

SSA-12

Next ile Summary ekranına geliyoruz, genel bir bilgi veriyor. Ardndan Finish’e tıkladığımızda lokal veritabanımız Azure tarafına taşınmaya başlıyor. Result kısmında eğer veritabanı geçişi başarılı oldu ise tüm kontroller yeşil checkbox olarak geliyor.

SSA-13

SSMS üzerinden kontrol ettiğimizde LokalDB isimli veritabanımız Azure tarafına taşınmış oldu. Veritabanındaki tablomuzu sorgulayarak Azure üzerinden verilerimize ulaşabiliyoruz.

SSA-14

Yedeklemedeki Yenilikler:

Sql Server 2014 ile birlikte gelen en önemli özelliklerden biri de, veritabanı yedeklerinin Azure üzerine alınmasıdır. Bir felaket durumunda (Disaster Recovery – DR) Azure üzerinden veritabanları geri yüklenebilmektedir. Yedekleme için gelen yeni özellikler, Backup to URL, Backup to Microsoft Azure ve Encryption.

URL yedekleme özelliği Sql Server 2012 SP1 update 2’de gelmişti. Sql Server 2012’de URL backup almak için T-Sql ile veya PowerShell scriptleri yedek almak mümkün. Sql Server 2014 ise SSMS içine entegre edilmiş şekilde gelmektedir. URL tarafına yedeklemeye geçilmesine en büyük nedenlerden biri de, veritabanlarının yedeklerinin Azure üzerinde on-premise olarak çalışmasıdır. Böylelikle daha güvenli ve korunaklı bir şekilde yedekler Azure üzerinde durmaktadır. İlk bölümde Azure üzerindeki veritabanlarına SSMS üzerinden nasıl bağlanacağımızı görmüştük. İstersek on-premise olarak Azure’u kullanıp, lokalimizi ise yedek için tutabiliriz.

Azure üzerine yedek alabilmek için, storage hesabınızın ve storage containerın olması gerekir. Azure üzerinde oluşturduğumuz veritabanını Azure Storage üzerinde tutmaktadır.

Azure URL backup yedeklemede bazı kısıtlamalar vardır. Bu kısıtlamalar şu şekildedir.

- Maksimum yedek boyutu 1 Tb

- Yedekleme cihazları ile birlikte kullanılamaz

- Var olan mevcut yedekler ile ilişkilendirilemezler.

- Birden çok blob’a yedek alınamaz. Sql server da normal yedeklemede birden çok yere yedek alınabiliyor, fakat Azure URL backup buna izin vermemektedir.

Azure üzerinde yeni bir storage ve storage içinde de container oluşturmamız gerekiyor. İlk olarak Azure üzerinde Storage bölüne gelip New – Storage – Quick Create ile yeni bir storage alanı oluşturuyoruz. Url adını girip hangi bölgedeki datacenterı kullanacağımızı seçtikten sonra Create Storage Account’a tıklayıp devam ediyoruz.

SSA-15

Storage ekranına sqlyedekstorage adında storage geldi. Üzerine tıklayarak gelen menüde container kısmına giriyoruz.

SSA-16

Create a new container’a tıkladıktan sonra, New container ekranında yeni bir blob container oluşturuyoruz.

SSA-17

Container’ı da oluşturduktan sonra Sql server tarafında yedeklemeye geçebiliriz. Yedeklemek istediğimiz veritabanında sağ klik Tasks – Backup diyoruz.

SSA-18

Backup database ekranında Destination kısmında URL olarak seçenek geliyor. Url’i seçtiğimizde bize File name, Sql Credential, Azure Storage Container ve Url Prefix seçenekleri gelmektedir. Url Prefix kısmına Azure storage imizin blob service adresini giriyoruz.

Blob service url, Azure storage imizin Dashboard ekranında yer almaktadır. İlk olarak bu ekrandan blob service url’i kopyalayalım.

SSA-19

Backup database ekranında Url prefix alanına yapıştırıyoruz.

Azure storage container kısmınada, storage’in container adını yazıyoruz.

SSA-20

Sql credential kısmında Azure ile bağlantıyı sağlayacak hesabı oluşturmamız gerekiyor. Create butonuna tıklıyoruz.

SSA-21

İlk olarak publish edilmiş profilimizi indirip, Browse ile bu ekrana getirmemiz gerekiyor. Subcription dosyasını aşağıdaki linkten indiriyoruz.

https://manage.windowsazure.com/publishsettings/

İndirdiğimiz dosyayı Browse ile seçtiğimiz zaman ID alanı ve sertifika bölümleri gelmiş oluyor, ardından Storage hesabımızı seçtikten sonra Create diyerek ekranı kapatıyoruz.

Backup database ekranındaki Destination bölümü aşağıdaki gibi olması gerekiyor.

SSA-22

Ekranda Ok dediğimizde yedek alma işlemi Azure tarafına başlamış oluyor. İnternet bağlantınızın upload hızına göre Url backup süreleri değişkenlik göstermektedir.

Yedeği Azure tarafında kontrol edelim.

Storage – Storage adınız – Containers bölümünde container adınımıza tıklıyoruz.

SSA-23

Yedeğimizin başarılı bir şekilde alındığını görüyoruz.

SSA-24

Yedeklerin Şifrelenmesi - Encryption:

Sql Server versiyonlarında farklı bir araç kullanmadan, yedeklerin şifrelenmesi Sql Server 2014 ile gelmiş oldu. Yedeklerin şifrelenmesinde AES 128, AES 192, AES 256 ve Triple DES algoritmaları kullanılmaktadır. Şifreleme yapmak için bir sertifika veya asimetrik key’in olması gerekmektedir. Yedeklerin şifrelenmesi özelliği ile, korumasız olarak Sql yedeklerinde de güvenlik sağlanmış oluyor.

Yedekleri şifrelemeden önce birkaç ön koşulu gerçekleştirmek gerekiyor. Sql Server Güvenlik Kavramı makale serilerinin 3. Bölümünde anlattığımız, bir kereye mahsus oluşturulan Database Master Key’i yedekleme şifrelemesinde de kullanacağız.

Database Master Key, private key sertifikasını ve asimetrik keyleri korur ve master database’inde saklar. Aşağıdaki kod ile master veritabanı için Database Master Key’i oluşturuyoruz.

USE master;

CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'guclu_bir_sifre';

Yedekleme şifrelemesi sertfika veya asimetric key’e ihtiyaç duymaktadır. Aşağıdaki kod ile sertifikayı oluşturuyoruz.

Use Master

CREATE CERTIFICATE YedeklemeSertifikasi

WITH SUBJECT = 'Otel veritabani yedekleme sertifikası';

Sertifikayı oluşturduktan sonra yedeklerimizi şifreleyebiliriz. Aşağıdaki örnek kod ile veritabanı yedeklerken şifrelenme işlemini gerçekleştiriyoruz.

BACKUP DATABASE Otel

TO DISK = N'D:\Yedek\otel_encrypt.bak'

WITH

COMPRESSION,

ENCRYPTION

(

ALGORITHM = AES_256,

SERVER CERTIFICATE = YedeklemeSertifikasi

STATS = 10

Stats = 10 parametresi ile de, yedek alırken, durumu görmüş olduk.

SSA-25

In-Memory Optimized Tablolar

Önceki Sql Server versiyonlarında, genel olarak iş zekası uygulamarlında gelişmeler yaşandı. Database engine kısmının karalı çalışması sağlandı. Sql Server 2014 ile gelen, In-memory optimize tablolar ile performans sıkıntısı yaşayan sistemler için büyük bir yenilik ve hız getirmiş oldu. Ön sürümde duyurulan adı Hekaton olan bu yapı ile, transactionların kat ve kat daha hızlanması sağlandı.

In-Memory Optimize tablolar sadece Enterprise sürümünde kullanılabilmektedir. Ayrıca Sql Server’da yeteri kadar memory olması gerekmektedir. Bu tablolar memory de tutulacağı için düşük memory’e sahip sistemlerde istenen verimi vermeyecektir. In-Memory Optimize tablolar kullanılan bir yapıda, Sql Server’a atana memory atamasının iyi planlanması gerekmektedir. Memory’nin tamamının Sql server’a verilmesi durumunda, memory optimize tabloların çalışmasında performans düşüklüğü olacaktır.

Disk tabanlı tablolarda Sql server verilerin ikinci bir kopyasınıda saklamaktadır, bir geri yükleme durumunda bu ikinci kopyadan geri dönme sağlanmaktadır. Insert, update ve delete işlemleri içinde aynı durum geçerlidir. Sunucunun yeniden başlaması veya bir sorun oluştuğundan Sql server hizmetinin yeniden başlamasında memory optimize tablolar yeniden oluşmaya başlayacak ve memory üzerinde belli bir oradan yer kaplayacaktır, disk tabanlı tablolar gibi ikinci bir kopya tutmayarak performansı arttırmaktadırlar.

Memory optimize filegroup içeren bir veritabanı oluşturalım.

CREATE DATABASE mem_opt_tab

PRIMARY(NAME = [mem_opt_tab_data],

FILENAME = 'd:\data\mem_opt_tab_mod1.mdf', size=500MB)

, FILEGROUP [mem_opt_tab_mod] CONTAINS MEMORY_OPTIMIZED_DATA(

NAME = [mem_opt_tab_dir],

FILENAME = 'd:\data\mem_opt_tab_dir')

, (NAME = [mem_opt_tab_dir2],

FILENAME = 'd:\data\mem_opt_tab_dir2')

LOG ON (name = [mem_opt_tab_log], Filename='D:\DATA\mem_opt_tab_log.ldf',

size=500MB)

Yukardaki script ile veritabanımızı oluşturduk, memory optimize filegroup içeren bu veritabanının, disk üzerindeki dosyalarına baktığımızda, iki klasörü de filegroup için açtığını görüyoruz.

SSA-26

SSMS üzerinde New Database diyerek açtığımız yeni bir veritabanında, filegroups sekmesinde, Memory Optimized Data bölümünden filegroupları ilave edebilmekteyiz.

SSA-27

Memory optimize tablolarda veri tipleri kullanımında kısıtlama vardır, kullanılabilen veri tipleri aşağıdaki gibidir;

- Bit

- Tinyint

- Smallint

- Int

- Bigint

- Money

- Smallmoney

- Float

- Real

- Datetime

- Smalldatetime

- Datetime2

- Date

- Time

- Numeric

- Decimal Types

- Sysname

- Char, varchar, nchar, nvarchar

- Binary, varbinary

- Uniqueidentifier

Memory optimize tablolar ile ilgili diğer kısıtlamalar aşağıdaki gibidir;

- Foreign key ve check constraints kullanılamaz

- Primary key var ise unique indeksler birden fazla olamaz

- Identity kolonlar kullanılamaz

- Dml triggerlar kullanılamaz

- En fazla 8 adet index olabilir

- Tablo oluşturulduktan sonra schema değişikliğine izin vermez

- Drop – create edilen bir tabloda schema değişikliği olmuş ise bu tabloada değişiklil yapılamaz.

- Create alter ve drop edilen indeksler çalışmazlar.

- Satır uzunluğu 8060 byte ile sınırlıdır.

Memory optimize tablolar iki farklı türde indeks destekler;

- Non-clustered hash indexes

- Non-clustered indexes

Memory optimize tablolar ile birlikte yeni bir indeks tipi olan hash indexes duyurulmuştur. Hash indeksler memory optimize tablolar üzerinde oluşturulurlar, bilinen indeks yapıları gibi değillerdir. Hash indeksler tablodaki tüm satırlar ile bağlantı kurarlar. Hash indeksler disk üzerinde tutulmazlar, bu sebeple hash indekslerin hareketleri transaction log üzerinde tutulmaz. Memory optimize indeksler, sunucu yeniden başlatıldığında, kendi kendilerine rebuild işlemlerini yaparlar.

Memory optimize tablolar, disk üzerinde tutulan tablolar gibi kendilerine alan ayırmazlar, adreslenebilir memory üzerinde çalışmak için tasarlanmışlardır.

Memory optimize bir tablo oluşturmak için, Tables kısmında New Table – Memory Optimize Table’a tıklıyoruz. Karşımıza aşağıdaki gibi bir script çıkıyor, normal tablo ekranı gibi bir ekranı bulunmuyor.

--======================================================

-- Create Memory Optimized Table Template

-- Use the Specify Values for Template Parameters command (Ctrl-Shift-M) to fill in the parameter values below.

-- This template creates a memory optimized table and indexes on the memory optimized table.

-- The database must have a MEMORY_OPTIMIZED_DATA filegroup before the memory optimized table can be created.

--======================================================

USE <database, sysname, AdventureWorks>

--Drop table if it already exists.

IF OBJECT_ID('<schema_name, sysname, dbo>.<table_name,sysname,sample_memoryoptimizedtable>','U') IS NOT NULL

DROP TABLE <schema_name, sysname, dbo>.<table_name,sysname,sample_memoryoptimizedtable>

CREATE TABLE <schema_name, sysname, dbo>.<table_name,sysname,sample_memoryoptimizedtable>

(

<column_in_primary_key, sysname, c1> <column1_datatype, , int> <column1_nullability, , NOT NULL>,

<column2_name, sysname, c2> <column2_datatype, , float> <column2_nullability, , NOT NULL>,

<column3_name, sysname, c3> <column3_datatype, , decimal(10,2)> <column3_nullability, , NOT NULL> INDEX <index3_name, sysname, index_sample_memoryoptimizedtable_c3> NONCLUSTERED (<column3_name, sysname, c3>),

CONSTRAINT <constraint_name, sysname, PK_sample_memoryoptimizedtable> PRIMARY KEY NONCLUSTERED (<column1_name, sysname, c1>),

-- See SQL Server Books Online for guidelines on determining appropriate bucket count for the index

INDEX <index2_name, sysname, hash_index_sample_memoryoptimizedtable_c2> HASH (<column2_name, sysname, c2>) WITH (BUCKET_COUNT = <sample_bucket_count, int, 131072>)

) WITH (MEMORY_OPTIMIZED = ON, DURABILITY = <durability_type, , SCHEMA_AND_DATA>)

Son satırda WITH(MEMORY_OPTIMIZED = ON) seçeneği ile, bu tablonun memory optimize bir tablo olduğunu belirtiyoruz.

AlwaysOn Availability Groups:

AlwaysOn Availability Groups, Sql Server 2012 ile gelen yeni bir özellikti. Sql Server 2014’e geçiş için AlwaysOn geçişi de merak edilen konular arasındaydı. Sql Server 2014’te ve Azure daki Sql makinalar arasında AlwaysOn yapılabilmektedir.

AlwaysOn ile farklı instance ve farklı sunuculardaki veritabanlarınızı otomatik olarak failover replikalarını tutabilirsiniz. İlave olarak, yüksek erişebilirlik ve felaket durumlarında uygulamalarınızı otomatik olarak yönlendirebilmektedir. Bu da en az kesinti ile Sql Server sunucularınızı ayakta tutmanızı sağlamaktadır.

Sql Server 2014’ün en güzel özelliklerinden biri de, Azure replikanın yapılıyor olmasıdır. Lokalda bulunan sunucunuzun bir de Azure tarafında replikası tutulmaktadır. Bir felaket durumunda Azure’daki replika ile kesintisiz çalışmaya devam edebilmektedir.

Sql Server 2012’de AlwaysOn groups kapsamında 4 adet replika limiti vardı. Sql Server 2014 ile bu replika sayısı 8’e çıkartıldı.

Performans İyileştirilmeleri:

In-memory optimize tablolar ve delayed durability özellikleri Sql Server 2014’ün en belirgin perfomans iyileştirici yeniliklerindendir. Bu iki özelliğe ek olarak, Columnstore indeksler, buffer pool extension, Cardinality estimator, Statistics ve kaynak yöneticisi özellikleri performans arttırcı öğelerdir.

Column store indeksler ilk olarak Sql Server 2012 ile duyurulmuştu fakat bazı kısıtlamaları vardı. Bu kısıtlamaların bazıları Sql Server 2014 ile kaldırıldı. Sql Server 2014 her iki cluster tipi olan non-clustered columnstore indeksleri ve clustered indekleri desteklemektedir. Columnstore indekslerin klasik indekslere göre farkı, kolon bazında veriyi tutarak kolon bazında yönetmesidir. Sorgu işlemlerinide kolon bazında gerçekleştirmektedir. Columnstore indeksler data warehouse için kullanılmaya en uygun indekslerdir. Büyük veri diye tabir edilen büyük veritabanlarında çok daha iyi sonuç elde edilmektedir. Columnstore indeksler doğru yapılandırıldıklarında 10 kat daha iyi sorgu performansı sunabilmektedirler. Veri sıkıştırmasında da 7 kata kadar daha az yer kaplamaktadırlar. Daha az işlemci kaynağı kullanırlar. Clustered columnstore indeksler sadece Sql Server 2014 Enterprise versiyonunda kullanılabilmektedir.

Clustered indeksler nasıl oluşturulur buna bakalım, Sql Serve management studio arayüzünden ve TSql ile clustered indeksler oluşturmak mümkündür. SSMS üzerindeki tablomuzun indexes kısmına gelip sağ klik – New Index – Clustered Index diyoruz.

SSA-28

Karşımıza gelen pencerede, üst tarafında en az bir kolonun index için seçilmesini söylüyor. Clustered indexler diğer indeks tipleri ile birlikte çalışmayacakları için, eğer farklı tipte bir indeks var ise, clustered indeks oluşturmanıza izin vermeyecektir. Eğer bir tabloda daha önce clustered indeks açtıysanız, yeni bir tane daha açmanıza izin vermiyor.

General sekmesinde Add diyerek hangi kolonu seçeceğimizi belirtiyoruz.

SSA-29

SSA-30

İndeks eklendikten sonra Index key columns ekranına gelmektetedir. Ok ile ekranı kapatıyoruz. Tablomuzun indexes kısmına baktığımızda Clustered indeksin oluştuğunu görüyoruz.

SSA-31

Performans yeniliklerinden biri de, Buffer pool extensions SSD diskler üzerinde fazladan ram kullanabilmemize olanak sağlamaktadır. Bu sayede I/O giriş çıkış değerlerinde ciddi anlamda peformans artışı sağlanmaktadır. Buffer pool extension özelliği Enterprise versiyonunda kullanılabilmektedir.

Sql Server’ın ana amacı, veriyi saklayıp, bu saklanan verinin işlenmesini de ssitem kaynaklarını en yüksek seviyede kullanarak sağlamaktadır. Disk üzerindeki operasyonların hızı bu noktada önem kazanmaktadır. Performansı düşük çoğu Sql sunucusunda disk I/O larındaki düşük performanstan kaynaklanmaktadır. Bu sebepten ötürü, günümüzde sanallaştırma teknolojileri yaygın olmasına rağmen, Sql sunucuları halen fiziksel sunuculara kurulmaktadır. Disklerdeki yetersiz performansı aşmak için daha fazla memory kullanılan sistemler oluşturulmaktadır. Buffer pool extensions ile ilave ram ihityacı ssd diskler üzerinden karşılanmış olur.

Sunucu üzerinde fiziksel ram ilave edilmesi, disk ilavesinden daha maliyetli bir operasyondur. Ayrıca sunucunun kapanmasına ve ekstra ram slotuna ihtiyaç duyulmaktadır. Buffer pool extension ile ilave ram takılmadan ssd disk desteği ile ilave ram sorunu çözülebilmektedir.

Aşağıdaki kod ile Sql serverdaki buffer pool extension aktif hale getirebilir. Takılan Sdd diskin içinde bir klasör belirlenebilir. Tüm ssd diski kullanmanıza da gerek yoktur.

ALTER SERVER CONFIGURATION

SET BUFFER POOL EXTENSION ON

(FILENAME = 'G:\Sql_buffer_pool\ssd.BPE', SIZE = 64 GB)

Mevcut memory’nizden daha fazla buffer pool ayırmanız gerekiyor, buffer pool klasörüne gidip, buffer pool extension dosyamıza bakalım

SSA-32

Bu makalemizde Sql Server 2014’ün yönetimsel yeniliklerinden bahsettik. Genel olarak performansa yönelik değişiklikler ve Azure tarafındaki yenilikler göze çarpmakta. Sql Server 2014, bizlere sunucularımızı yenilemeden mevcut sunucularımız ile daha fazla performans vaad etmektedir. Sürekli donanım ilaveleri yapmak yerine Sql Server 2014’e geçiş yaparak yeni teknolojileri sayesinde daha performanslı Sql sunucuları ile çalışılabilmeyi bizlere sunmaktadır.

SQL Server Data Tools, SQL Server 2012 ile birlikte gelen yeni bir tooldur. SSDT sayesinde yazılım geliştiriciler SQL Server Management Studio kullanma ihtiyacı olmadan, database oluşturma, tablo, view ,procedure gibi nesleleri oluşturma imkanına sahip olmaktadır.

SSDT Local DB

SQL Server Data Tools – Local DBözelliği ile geliştirme yapılan makinede SQL Server kurulumu yapılmamış olsada sanki SQL Server servislerinin kurulumu yapılmış gibi veritabanı oluşturmaya ve geliştirmeye imkan sağlar. Local DBözelliği sayesinde yazılım geliştiriciler makinalarına SQL Server kurulumu yapmak zorunda kalmazlar.

SSDT Local DB özelliğini kullanmak için Visual Studio’yu başlattıktan sonra New Project ekranında SQL Serverşablonları altında SQL Server Database Project‘i seçiyoruz.

Projeyi oluşturduktan sonra Visual Studio ‘da sağ tarafta bulunan SQL Server Object Explorer ekranında SQL Server bağlantılarımızı görebiliriz. Visual Studio’da SQL Server Object Explorer gözkümüyor ise View menüsünden SQL Server Object Explorer ile ekranı açabilir veya ( ctlr+ç , ctlr+s ) kısayolunu kullanabilirsiniz.

Ekranda bulunan localdb nesnesini incelediğimizde sanki bir SQL Server Instance gibi gözüküyor. Aslında yüklü olan bir SQL Server Instance değil, SSDT ile birlikte gelen Local Db özelliğidir.

SQL Server Object Explorer ekranında yeni bir tablo,view,procedure oluşturabilir veya daha önce oluşturulmuş nesneleri görüntüleyebiliriz.

SQL Server Data Tools İle Tablo Oluşturma

SQL Server Data Tools’ta tablo oluşturmak için SQL Server Object Explorer listesinde oluşturduğumuz database altında Tables nesnesine sağ tıklayıp Add New Table yöntemi ile veya SQL Server Solution Explorer penceresinde bulunan proje ismin sağ tıklayıp Add>New Item menüsü ile açılan ekrandan Table seçilerek oluşturabilirsiniz.

Karşımıza gelen ekranda Table’yi seçtikten sonra ismini Table_First olarak tanımlıyor ve Add ile oluşturuyorum.

Tabloyu projemize ekledikten sonra karşımıza eklediğimiz tabloyu düzenlememiz için “Desing” ekranı geliyor. SQL Server Data Tools ile gelen en güzel özelliklerden birisi de T-SQL penceresinde yazdığımız sorgunun aynı anda görsel ekran olan Desing ekranına da yansıması. Aynı şekilde desing ekranında yapılan değişikler de T-SQL kodlarının bulunduğu pencereye yansımaktadır.

Tabloyu tasarladıktan sonra kaydediyor ve ekranı kapatıyoruz. Oluşturmuş olduğumuz tablonun Local DB’ye eklenmesi için Debug(F5) ile deploy ediyoruz.

SQL Server Object Explorer penceresinde LocalDB > SSTD_LocalDB> Tables altında oluşturmuş olduğumuz tablonun eklendiğini görüyoruz.

Oluşturduğumuz tabloda değişikli yapmak isterseniz SQL Server Object Explorer penceresinde ilgili tabloya sağ tıklayıp View Designer / View Code seçeneği ile tablo düzenleme ekranlarına ulaşabiliriz.

Bir diğer tabloda değişiklik yapma yöntemi ise; Visual Studio ekranında Solution Explorer penceresinde bulunan “tablo_adi.sql” dosyasına çift tıklayarak yada sağ tıklayıp Open diyerek tablo düzenleme ekranına ulaşabiliriz.

Tablo üzerinde değişiklik yaptıktan sonra tekrar Debug(F5) etmemiz gerektiğini unutmayalım. Aksi halde yapılan değişiklikler Local Dbüzerindeki tabloya uygulanmayacaktır.

SSDT – Mevcut Olan Veritabanından Local Db Projesi Oluşturmak

Kullanmakta olduğumuz bir veritabanını SQL Server Data Tools ‘a proje olarak ekleyebilirsiniz. Visual Studio’yu açtıktan sonra SQL Server Object Explorer penceresinin üstündeki “Add Server” düğmesi ile bilgisayarımda kurulu olan SQL Server Instance’a bağlanıyorum. Daha sonra var olan bir AdventureWorks2014 veritabanına sağ tıklayıp gelen menüden Create New Project seçeneğini seçiyoruz.

Karşımıza gelen ekranda oluşacak SSDT projesinin ismini ve hangi dizinde saklanacağı belirledikten sonra, yeni bir Solution oluşturulacak ise Create new solution kutusunu işaretliyoruz. Create new solution işaretlemezsek var olan solution’a yeni bir proje olarak eklenecektir.

Import kutucukları ile hangi nesnelerin projeye import edilip edilmeyeceğini belirleyebiliyoruz. Folder Structure açılır kutusu ile nesnelerin klasörde nasıl tutulması gerektiğini belirleyebiliyoruz ve Maximum files per folder değeri ile de her bir klasörde en fazla kaç tane nesne olabileceğini belirleyebiliyoruz.

Import tercihlerimizi yaptıktan sonra Start düğmesi ile import işlemini başlatıyoruz.

Import işlemi tamamlandıktan sonra Finish düğmesine tıklayarak ekranı kapatıyoruz.

Import işlemi bittikten sonra SSDT_AdventureWorks isimin verdiğimiz projemiz solution explorer’da oluşmuş olacaktır.

SQL Server Object Explorer Local DB’ye baktığımızda SSDT_AdventureWorks veritabanının oluştuğunu görebiliyoruz.

Dikkat ettiyseniz Local DB’de veribanımız oluştu ancak debug(F5) yapıp deploy etmediğimiz için veritabanı nesnelerimiz oluşmadı.

Debug işleminden sonra tekrar kontrol ettiğimizde nesnelerin oluştuğunu görebilirsiniz.

SSDT – Publish İşlemi

SQL Server Data Toolüzerinde değişiklik ve geliştirme yaptığımız veritabanı projesini nasıl publish yapabileceğimizi göreceğiz. SQL Server Data Tools ile geliştirilen veritabanı projesi SQL Server 2005 ve üst versiyonlara publish yapılabileceği gibi Azureüzerinde olan Instance’nıza da publish yapabilirsiniz.

SSDT projemizi hangi SQL Server versiyonuna publish yapabileceğimizi;

PROJECT > ProjeAdi_Properties menüsü ile karşımıza gelen özellikler sayfasından değiştirebiliyoruz.

Publish işlemi için daha önce oluşturduğum “SSDT_LocalDB” projesini kullanacağım. Solution Exlorer’de bulunan SSDT_LocalDB projesine sağ tıklayıp Publish seçeneğini seçiyorum.

Karşımıza gelen ekranda;

Target database connection : Publish işlemini hangi instance ve veritabanına yapacağımızı edit düğmesi ile belirliyoruz.

Database name ve oluşacak publish script dosyasının adını belirliyoruz. Gelişmiş publish seçenekleri için Advanced... düğmesi ile Advanced Publish Setting ekranını açıyoruz.

Nesnelerin silinip yeniden mi oluşturulacağı, deploy yaparken veritabanını single user mode almasını, deploy işleminden önce yedek alınıp alınmayacağı gibi gelişmiş seçenekleri bu ekranda tanımlayabiliyoruz.

Her publish işleminde bilgilerin ve ayarların tekrar tekrar yapılmasını istemiyorsanız Save Profile seçeneği ile yapılandırma ayarlarınızı kaydedebilirsiniz. Tekrar publish yapmak istediğinizde sadece Load Profile düğmene tıklayarak publish ayarlarınızı yükleyebilirsiniz.

Save Profile dedikten sonra Solution Explorer penceresinde bulunan projemizin içerisinde projeadi.publish.xml dosyası oluştuğunu görüyoruz.

Generate Script düğmesi ile de publish scriptini oluşturabiliyoruz.

Oluşan bu script içeriğini hedef sunucu üzerinde çalıştırarak publish yapabiliriz.

Publish düğmesine tıklayarak direk hedef sunucu üzerinde projemizi yayınlıyoruz.

Publish işleminden sonra SQL Server Management Studio‘ya bağlantı kurup veritabanı projemizin sağlıklı bir şekilde publish olup olmadığı kontrol ediyor ve publish işlemi sonucu hedef sunucuda veritabanı ve nesnelerin oluştuğunu görüyoruz.

Şimdi publish yaptığım proje üzerinde değişiklik yapıyor ve yeni bir nesne daha oluşturuyorum.

Tablo tasarım modunda değişiklik yapar yapmaz Solution Explorer‘da bulunan SSDT_LocalDB projesinin içerisinde SSDT_LocalDB.refactorlog dosyası oluştuğunu görüyoruz.

Yaptığımız değişiklik sonucunda projeAdi.refaktorlog dosyasında bir kayıt seti eklendiğini görüyoruz. Projeye “Second_Table” isminde bir tablo daha ekliyorum.

Tekrar oluşmuş olan refactorlog dosyasını inceliyoruz.

Dikkat ettiyseniz refactorlog dosyasında yeni eklediğimiz tablo için bir kayıt eklenmediğini bu dosyaya sadece kolonlar ile ilgili yapılan değişikliklerin tutulduğunu görmüş oluyoruz.

SSDT – Schema Karşılaştırma

Schema karşılaştırma işlemini 3. Parti uygulamalar ile gerçekleştirebiliyorduk. Artık SQL Server Data Tools ile kolayca ve ücretsiz olarak schema karşılaştırma işlemini yapabiliriz. Önceliklekle schema karşılaştırma işlemi sıklıkla; program geliştiriciler development ortamındaki veritabanı üzerinde bir değişiklik yaptığında, veritabanı yöneticisine değişikliği bildirmemiş olabilir. Aynı şekilde veritabanı yöneticisi de yaptığı değişikliği development ortamında bulunan veritabanına yansıtmamış olabilir. Uygulama kodlarındaki geliştirmeler yayına alındığında canlı sistemde olan veritabanı ile geliştirme ortamındaki olan veritabanı arasındaki farklılıktan dolayı hatalar meydana gelebilir. Bu hatalara engel olabilmek için 2 ortamdaki veritabanı schema yapısı karşılaştırılmalı varsa değişiklikler veya çakışmalar kodlar yayına alınmadan önce müdahale edilmelidir.

SQL Server Data Tools yardımı ile Schema karşılaştırma özelliğini görebilmek için hem SQL Server Management Studio’da bulunan bizim oluşturduğmuz “SSDT_LocalDB” veritabanı içinde bulunan “Table_First” tablosunda schema yapısını değiştireceğim hemde SSDTüzerinde olan SSDT_LocalDB projesindeki Table_First tablosundaki schema yapısını değiştirip bu iki taraftaki schema değişikliklerini karşılaştıracağız.

Öncelikle SQL Server Management Studioüzerinde olan veritabanımdaki “Table_First” tablosunun “CreatedDate” kolonunun siliyorum.

Daha sonra SSDT üzerindeki SSDT_LocalDB projemdeki Table_First tabloma “UpdatedDate” diye bir alan daha ekliyorum.

SSDT_LocalDB projesi içinde “Table_Second” isminde bir tablo daha oluşturuyorum.

İki veritabanında da değişiklikler yapıldığına göre artık Schema Compare özelliğini kullanabiliriz. Bu işlem için Solution Explorer’da bulunan SSDT_LocalDB projesine sağ tıklayıp Schema Compare... seçiyorum.

Gelen ekrandan karşılaştırma yapacağım veritabanının kaynağını ve hedef veritabanı kaynağını seçiyorum. Veritabanı kaynağı olarak SSDT_LocalDB projesindeki veritabanımı kullanıyorum. Hedef olarak farklı bir instance’da bulunan yine aynı isimdeki veritabanını kullanıyorum.

Hedef ve kaynak veritabanını seçtikten sonra, ekranın sol üstünde bulunan Compare düğmesine basıyorum.

Compare işlemi tamamlandıktan sonra “Result” ve “Object Definitions” isminde 2 bölümden oluşan bir ekran karşılıyor bizi.

Result bölümünde karşılaştırılan veritabanları içinde farklı olan objeler mevcutken, Object Definition bölümünde ise seçili olan farklılığın detayları gösteriliyor.

Karşılaştırma yapılan her iki veritabanında da aynı isimde bir tablo nesnesi olduğu için bize arasındaki farkları gösteriyor, ancak kaynak veritabanına oluşturduğum “Table_Second” tablosu hedef veritabanında olmadığı için Result ekranında Add klasörü altında toplanıyor ve Object Definition kısmında ise sadece kaynaktaki tablo yapısı gösterilebiliyor.

Veritabanları arasındaki farklılıkları inceledikten sonra iki veritabanını birbiri ile eşitlemek için üst tarafda bulunan Update düğmesi ile veya Generate Script yardımıyla eşitleme işlemini tamamlayabilirsiniz.

Generate Script komutu ile eşitleme işlemi için gereken sorguyu SSDT sizin için oluşturabiliyor. Oluşan bu sorguyu hedef veritabanında çalıştırmanız işlemi tamamlamak için yeterli olacaktır.

Update butonu ile değişiklikleri direk hedef veritabanı üzerinde uygulayabilirsiniz.

SSDT – Project Snapshot

SQL Server Data Tools ile proje veritabanının snapshot’unu alabiliriz. SSDT snapshot yapısı SQL Server’da var olan snapshot ile aynı yapıya sahiptir. Snapshot basit bir tanımla ; veritabanının herhangi bir anında alınan salt okunur bir kopyası, görüntüsüdür denilebilir.

SSDT ile Snapshot Oluşturma

SSDT ile snapshot olurşturmak için Solution Explorer penceresinde bulunan projemize sağ tıklayıp açılan menüden “Snapshot Project” seçeneğini seçiyoruz.

Snapshot Project komutunu verdikten sonra çok hızlı bir şekilde projemiz içerisinde “Snapshot” diye bir klasör oluştuğunu ve içerisinde “proje_adi_tarih_saat.dacpac” isimli bir snapshot dosyası eklendiğini görüyoruz.

Oluşturmuş olduğumuz snapshot dosyasını projelerimize import ederek yeni bir proje veritabanı oluşturabilirsiniz.

SSDT – Tablodaki Verileri Aktarmak İçin Insert Sorgusu Oluşturmak

SQL Server Data Tools ile oluşturmuş olduğumuz proje veritabanındaki bir tablo içindeki verileri başka bir yere aktarmak için satırların Insert script’ini kolaylıkla oluşturabilirsiniz. SQL Server Object Explorer penceresinden script’ini almak istediğimiz tabloya sağ tıkladıktan sonra “View Data” seçeneğini seçiyoruz.

Karşımıza gelen pencerenin üst kısmında bulunan “Max Rows” değerini “All” olarak değiştiriyoruz. Bu sayede tabloda bulunan tüm kayıtlar için script oluşturabileceğiz.

Max Rows seçeneğini değiştirdikten sonra insert script’ini oluşturabiliriz. Insert sorgularını oluşturmak için Max Rows kutucuğu yanında bulunan iki düğmeyi de kullanabiliriz.

Script düğmesini kullanırsak SSDT bizim için bir sorgu ekranı açıp bu ekranda bize kayıtlarımızın insert sorgusunu verecektir.

Script düğmesi yanında bulunan “Script To File” düğmesini kullanırsak SSDT bizim için bu insert sorgularını barındıran “.sql” uzantılı bir dosya oluşturacak ve belirteceğimiz dizine kaydedecektir.

SSDT - Code Analysis

SQL Server Data Tools aracının en sevdiğim özelliklerinden birisi olan Code Analysis; dizayn,isimlendirme,performans açısından sorun teşkil edecek potansiyel durumlar için analiz yapar. Code Analysisözelliği sayesinde geliştirme aşamasındayken potansiyel sorunları tespit edebilir ve proje / kod kalitesini arttırabilirsiniz.

Code Analysisözelliği ile birlikte kontrol edilecek olan kuralları ayarlamak için: View > ProjeAdi_Properties menüsünden aşağıdaki yapılandırma ekranına ulaşabilirsiniz.

Kontrol edilmesini istemediğimiz durumları bu ekrandan kaldırabilirsiniz. “Enable Code Analysis on Build” seçeneğini işaretlerseniz her build işleminden sonra code analysis özelliği otomatik olarak çalışacaktır.

Code Analysisözelliğini çalıştırmak için solution explorer’da bulunan projemize sağ tıklayıp Run Code Analysis seçeneğini seçiyoruz.

Code Analysisözelliğini test etmek için “Usp_GetCategory” isminde bir stored procedure ve “Vw_GetAllRows” isminde bir view oluşturdum.

Sorgularda da görüldüğü gibi iki sorgu cümlesi de kullanılması önerilmeyen, performans kaybına sebep olan bir yazım şekline sahip.

Code Analysisçalıştıktan sonra analiz sonusunu “Error List” penceresinden görebilirsiniz.

Analiz sonucunda view’de kullanmış olduğum “SELECT *“ şeklinin, prosedürde kullandığım “%” LIKE ve INT türündeki bir alanda string şekilde bir değerle koşul verdiğim için bu üç uyarıyı almış oldum.

Code Analysis ile birlikte daha geliştirme ortamındayken olası potansiyel hataları tespit edip düzeltmemiz hep kod kalitemizi arttıracak hemde canlı ortama daha az risk ile geliştirmiş olduğumuz kodları / nesneleri gönül rahatlığı ile aktaracağız.

SSDT - Refactor

SQL Server Data Tools ile birlikte kullanabileceğimiz bir diğer güzel özelliklerden birisi de Refactor menüsüdür. SSDT sorgu ekranında sağ tıkladıktan sonra gelen bu menüde dört seçenek mevcuttur.

Refactor > Rename

Nesnenin kendini ve kullanıldığı tüm yerlerdeki ismini değiştirmek için kullanılır.

Karşıma gelen Rename penceresinden Table_Second ismindeki tablomun adını Table_Second_2 olarak değiştiriyorum.

Preview changes seçeneği işaretli bırakılırsa ismini değiştireceğimiz nesnenin kullanıldığı tüm yerlerin listesi oluşturulacak ve Ok komutu verdikten sonra karşımıza gelecektir.

Bu ekranda değişiklikten etkilenecek nesneleri görebilirsiniz. Son olarak Apply komutunu verdikten sonra seçilen nesnenin adı kendisi ile birlikte referans olarak kullanılan tüm yerlerde değiştirilecektir.

Refactor > Move To Schema

Seçilen nesnenin kendisi ile birlikte kullanıldığı tüm yerlerdeki schema bilgisi değişecektir. Rename komutu ile aynı çalışma mantığına sahiptir.

Refactor > Expand Wildcards

Expand Wildcards seçeneği ile birlikte “Select * “şeklinde yazmış olduğunuz sorgularınızı “Select kolon_adlari”şekline çevirebilirsiniz. Tek tek kolon isimlerini yazmak yerine hızlıca tüm kolon isimlerini sorgunuza dahil edecek ve size hız kazandıracaktır.

Refactor > Fully-qualify Names

Full-qualify Names özelliği sayesinde “Select kolon_adlari”şeklinde olan sorgunuzdaki kolon isimlerinin başına alias “Select [Alias].KolonAdi” ekleyecektir. Expand Wildcards seçeneğinde olduğu gibi esas amaç kodlama aşamasında daha hızlı geliştirme / düzenleme sağlamasıdır.

SQL Server Data Tools ile birlikte gelen Refactor menüsü sayesinde kodlamalardaki değişiklikleri çok hızlı bir şekilde gerçekleştirmenize imkan sağlamaktadır.

SQL Server 2008 ile birlikte gelen ve üst sürümlerde de desteklenen Data Collection, veritabanları üzerinde performans bilgilerini toplamaya ve bu bilgileri raporlamak için kullanılan güzel bir özelliktir.

Data Collection‘a özel bir veri ambarı oluşturulmakta ve veritabanları üzerinden toplanan bu bilgiler veri ambarında saklanmaktadır.

Data Collection – Data Warehouse Kurulumu

Data Collection veri ambarını yapılandırmak için SQL Server Management Studio ‘ya bağlantı kurduktan sonra,

Management > Data Collection > Tasks > Configure Management Datawarehouse menüsünden, Configure Management Data Warehouse Wizard ekranını açıyoruz.

Karşımıza gelen ekrandan bilgi ekranını Next butonu ile geçiyoruz.

Karşımıza sunucu üzerinde Data Collection‘un topladığı verilerin tutulacağı veri ambarı için bir veritabanı belirlememizi istiyor.

New butonu ile Data Collection veri ambarı için “DWH_DataCollection” isminde bir veritabanı oluşturuyorum.

Veritabanımızı oluşturup ilerledikten sonra karşımıza veri ambarı database için kullanıcı tanımlama ekranı gelecektir.

Sağ altta bulunan New Login butonu ile yeni bir kullanıcı oluşturabilirsiniz. Ben kendi kullanıcımı seçtim. Next ile ilerledikten sonra karşımıza yaptığımız işlemlerin özetini gösteren “Complete The Wizard” ekranı geliyor.

Son kez yapılacak işlemlere gözattıktan sonra Finih butonu ile kurulumu tamamlıyoruz.

DWH_DataCollection veri ambarı database içerisinde tabloların oluştuğunu görüyoruz.

Data Collection – Collection Setlerin Yapılandırılması

DataWarehose kurulumu yaptıktan sonra sıra data toplama ayarlarını yapılandırmaya geldi. Bu işlem için;

Management > Data Collection > Tasks >Configure Data Collection menüsünden Configure Data Collection Wizard ekranını açıyoruz.

Yine karşımıza gelen ekrandan bilgi ekranını Next butonu ile geçiyoruz.

Gelen ekran bizden hangi sunucu üzerinde hangi veritabanına toplanılan bilgilerin yazılacağını, önbellek dosyalarının hangi dizinde tutulacağı gibi bilgiler talep ediyor.

Oluşturmuş olduğum “DWH_DataCollection” veritabanını seçtikten sonra bilgisayarımın C: diskindeDC_TEMP isminde bir klasör oluşturuyorum ve Cache Directory olarak ilgili klasörü seçiyorum.

Değerleri girip Next ile ilerledikten sonra bizi yapılacak işlemlerin özetini gösteren Compleate The Wizard ekranı karşılıyor. Kısaca göz attıktan sonra Finish buttonu ile işlemleri bitiriyoruz.

Sihirbazın görevini başarıyla tamamladığını görüyoruz.

Data Collection altında set‘lerin oluştuğunu ve SQL Server Agent > Jobs altında ise Data Collection Set‘leri için jobların otomatik olduşturulduğu görüyoruz.

Sırası ile veriambarımızı oluşturduk, Collection Set’lerimizi ayarladık. Artık toplanan verilerin nasıl raporlanabileceğini de görelim.

Toplanan performans verilerinin raporlanması için;

Management > Data Collection > Reports > Management Data Warehouse >

· Server Activity History

· Disk Usage Summary

· Query Statistics History

Hazır raporlarını kullanabilirsiniz. Dilerseniz .RDL – .RDLC uzantısında oluşturabileceğiniz raporlarınızı da bu menülerden çağırabilirsiniz.

Server Activity History

Sunucu üzerinde kullanılan CPU,disk,bellek, network kullanımlarını inceleyebileceğiniz bir rapordur.

Disk Usage Summary

Veritabanı bazında data veya log dosya boyutu, büyüme trendi, başlangıç boyutu,autogrow boyutu gibi önemli bilgileri alabileceğimiz rapor.

Query Statistics History

Bu rapor sayesinde maliyeti en yüksen on sorguyu , CPU / Duration / Total I/O / Physical Reads / Logical Writes bazında alabiliriz.

Görüldüğü gibi yapılandırılması ve kullanılması gayet kolay olan Data Collection özelliğini kullanarak sunucu aktivitelerini raporlamakla birlikte performans sıkıntılarına da çözüm bulabilirsiniz.

Bu makalemizde 2016 yılı başlarında piyasaya çıkması beklenen SQL Server 2016 ürününün beta versiyonunun kurulumunu ele alıyor olacağız. SQL Server 2016 şu anda piyasaya çıkmamış olmakla birlikte aşağıdaki özellikleri taşıyacağı belirtilmektedir.

SQL Server 2016 güvenlik, performans, farklı ortamlarla etkileşim noktasında şüphesiz birçok yenilikle bizlere sunulacak ancak biz Sistem Yönetimi Kısmını ele alacağımız için SQL Server 2016’yı bir Veritabanı Yöneticisi gibi değil Sistem Yöneticisi gözüyle ele alacağız. Bu ilk makalemizde kuruluma odaklanacak sonraki makalelerde yedekleme, temizlik, SQL Server 2016 ile bağlantı gibi konulara değineceğiz.

Genel olarak yeni çıkan ürünler alt sürüm ürünlerin yapabildiklerini yapmakla birlikte üzerine yeni özellikler koyarak ilerliyor. Bizde yeri geldiğinde bu yeniliklere yer veriyor olacağız. Öncelikle kurulum gereksinimlerine göz atalım. https://msdn.microsoft.com/en-us/library/ms143506.aspx buradaki link üzerinden detaylı olarak kurulum için gerekli olan donanımsal veya yazılımsal gereksinimlere göz atabilirsiniz. Ayrıca test amaçlı kurulum için https://www.microsoft.com/en-us/evalcenter/evaluate-sql-server-2016 buradan gerekli ISO dosyasını indirebilirsiniz.

İso dosyamızı indirdikten sonra açalım ve Setup.exe dosyasını çalıştıralım.

Gelen güvenlik uygulamasını “Evet” butonuna tıklayarak geçelim.

Sql kurulum sırasında gelen bu ekran ile yeni bir kurulum, var olan kurulum üzerinde özellik ekleme, çıkartma, cluster kurulumu, clustere nod ekleme, eski versiyondan yeni versiyona upgrade gibi işlemler yapabiliriz.

Biz yeni temiz bir kurulum yapacağımız için Installation tabında yer alan “New SQL Server stand-alone installation or add features to an existing installation” seçeneğine tıklayalım.

Kurulum için gerekli olan ürün anahtarımızı girelim. Ürün Release olmadığından Trial versiyon indirdiğimiz için Evaluation seçimini yaparak “Next” ile ilerleyelim.

Lisans anlaşmasını kabul edelim ve “Next” ile ilerleyelim.

Use Microsoft Update to check for updates(recommended) seçeneğini seçerek kurulum öncesi gerekli güncellemeleri çekelim.

Kurulum öncesi sistem gereksinimlerimiz kontrol ediliyor. Gerekli bileşenler var olduğundan sadece Windows Firewall uyarı veriyor. Bu hata değil uyarı olduğundan “Next” ile ilerliyoruz.

Bu ekranımızda istersek tüm Sql özelliklerini kurabilir, istersek sadece gerekli olan bileşenleri kurabiliriz. Ben ilk seçeneği seçerek “Next” ile ilerliyorum.

Burada yüklenebilecek olan rollerin bir listesi görüntülenmektedir. Burada gerekli olan rolleri kurabileceğiniz gibi bir önceki ekranda bize diğer seçenek olarak sunulan tüm rollerin kurulması işlemini de yapabilirsiniz. Ben sadece Database Engine Services ve Management Tools seçeneklerini seçip “Next” ile ilerliyorum.

Bu ekranımızda Sql server kurulduğunda hangi Instance ismi ile kurulacak ise bizden onun bilgisi istenmektedir. Özel bir geliştirme olmadığı için ben default instance ismi olan “MSSQLSERVER” ismini olduğu gibi bırakıyorum. Default dizine kurulmasını istediğimden değişiklik yapmıyorum. Bu adımı da geçerek “Next” ile ilerleyebiliriz.

Karşımıza Server Configuration ekranı geldi. Service Accounts tabında SQL Server 2016 Servislerini çalıştıracak kullanıcı hesapları belirlenir. Bu servis seçimlerini aşağıdaki gibi bırakabilirsiniz. İlerleyen makale serilerimizde yapacağımız bazı örnekler ile bu kısımlara zaten yer vermek durumunda kalacağız.

Collation tabından SQL Server dil ve karakter set ayarları yapılır.

Collation ayarında SQL_Latin1_General_CP1_CI_AS seçimini yapalım ve “OK” butonuna tıklayalım.

SQL_Latin1_General_CP1_CI_AS seçiminden sonra “Next” ile ilerleyelim.

Database Engine Configuration kısmında kimlik doğrulama metodunu seçmemiz ve bunun için kullanıcı belirlememiz istenmektedir.

Biz yapımızda şu anda “Windows authencation mode” seçimini yapacağız. Bu metot ile kimlik doğrulaması yaptığım için Windows kullanıcılarından bir tanesini seçmem gerekmekte. Kurulumu TEST hesabı ile yaptığımız için “Add Currnet User” seçimini yaparak TEST kullanıcısının otomatik eklenmesini sağlayabiliriz. TEST hesabımız eklendi.

Data Directories tabında log, db ve bileşenlerin kurulacağı yerler belirlenebilmektedir. Biz bu ekranda varsayılan konumları seçerek devam edeceğiz. Bu kısma büyük kurumlarda performans gerektiren durumlarda müdahale edilmektedir. Farklı diskler üzerinde farklı yerlerde directories oluşumları sağlanmaktadır.

Bu kısma kadar olan kısımda yapılan seçimlerin bir özeti karşımıza geldi. Bu ekranda yer alan “Configuration file path” yolundaki ini dosyasına erişerek bu kurulumlar sırasında hangi komutların işletileceğini görebiliriz. Bunlar otomasyonel kurulumlarda işimize yarayabilmektedir.

Kurulum başladı. Bilgisayarınızın performansına ve seçilen bileşenlere göre değişken bir zaman alacaktır. Ortalama 20 dakika gibi bir sürede kurulum tamamlanacaktır.

Kurulum başarı ile tamamlandı. Bize bir sonuç tablosu yansıtılmaktadır. “Close” ile kurulum işlemini noktalayabiliriz.

Sql Server 2016 CTP2.1 Management Studio’yu açarak durumu gözlemleyelim.

Ekranda gelen bilgiler ile login olalım.

Sorunsuz şekilde Sql serverimize login olup databaseleri görebilir duruma geldik.

Programımızın versiyon bilgisi aşağıdaki gibi.

Gerekli servislerimiz çalışır durumda.

Bir makalemizin daha sonuna geldik. Yararlı olması dileğiyle.

Live Query Statistics özelliği ilk olarak Sql Server 2016 CTP 2.1 sürümü ile birlikte duyuruldu. Aktif sorgunun çalışma planını canlı olarak bizlere sunan bu yeni özellik ile, sorgulardaki performans sorunlarını ve hata bulmayı daha kolaylıkla yapabileceğiz.

Bu makaledeki örnekler, Sql Server 2016 CTP 2.3 sürümü ile anlatılmıştır. Ana sürüm çıktıktan sonra versiyon değişiklikleri olabilir. Sorgu örnekleri için AdventurkWorks2014 veritabanı kullanılmıştır.

Sorgu ekranlarında Live Query Statistics özelliğini aktif etmek için, sorguyu çalıştırmadan önce üstteki menülerden “Include Live Query Statistics” butonuna tıklıyoruz.

LQS -1

Sorgu çalışmaya başladığında, sonuç alanına bir sekme daha geliyor.

LQS – 2

Sorgu çalışırken yukardaki şekil LQS-2 deki gibi hareketli olarak operatörler arası noktalı oklar ile çalışmayı gösteriyor. Çalışan operatörün hangi aşamada olduğu yüzdesel olarak operatörün altında gösteriliyor.

Tamamlanan operatör ise içi dolu oklar ile gösteriliyor.

LQS – 3

Sonuca yaklaşıldığında, oklar inceden kalına doğru değişiyor. Bir sorgu çalışırken canlı olarak neler olduğunu hangi aşamaların ne durumda olduklarını bu özellik sayesinde görebileceğiz.

Live Query Statistics’in diğer güzel bir özelliği de, her operatörde kaç satır çalıştığının bilgisinin vermesi. Operatörün üzerine tıkladığımızda, açılan pop-up ekranında ve yanda taraftaki properties ekranında “Actual Number of Rows” alanında satır sayısı bilgisi canlı olarak, yani sorgu devam ederken de verebiliyor.

LQS – 4

Operatörün üzerine geldiğimizde, Actual Number of Rows gözükmekte.

LQS – 5

Bu sorguda iki tabloyu cross join ile bağlanmıştık. Diğer iki tablonun da anlık olarak satır sayılarının bilgisini veriyor. Sorgudaki iki tablonun satır sayılarına bakalım.

Employee tablosunda 290 satır

Person tablosunda da 19972 satır var, bu iki tabloyu cross join ile birleştirdiğimizde 290 * 19972 = 5791880 satır yapıyor.

LQS – 6

Activity monitör üzerinde de büyük sorguların execution planlarını canlı olarak izleyebilirsiniz. İlk olarak Activity Monitor’ü açıyoruz.

LQS – 7

Active Expensive Queries bölümüne aktif olarak çalışan büyük sorgular gelmektedir. Çalışan sorgunun üzerinde sağ tıklayarak “Show Live Execution Plan”a tıkladığımızda Live Query sayfası yeni sekme olarak açılmaktadır.

LQS – 8

Live Execution planların sorgularda etkili olması için, SET STATISTICS PROFILE ON veya SET STATISTICS XML ON komutlarını sorguların başında kullanmanız gerekiyor, eğer bu komutlar olmadan sorgular çalışır ise, Active Expensice Queries ekranına sorgularınız gelmeyecektir.

Live Query Statistics’in bazı kısıtlamaları vardır, bunlar;

- Columnstore indeksler desteklenmemektedir.

- Memory-optimized tablolarda çalışmamaktadır.

- Tekil olarak çalıştırılan stored procedureları desteklememektedir.

Live Query Planlar daha çok native çalışan sorgularda darboğazları tespit etmek için kullanılacaktır. Performans sıkıntılarına yol açan darboğazların tespitinde kullanılacak bir özellik olarak ana sürümde yerini alacaktır.

Sql Server Performansı her zaman öncelikli konular arasında olmuştur. Sql Server yapısı itibari ile, cpu, memory ve disk I/O’larını yüksek seviyede tüketmektedir. Bu sebeplerden dolayı Sql Server doğru yapılandırılmadığı ve izlenmediği durumlarda, performans kaybı yaşanmaktadır.

Bu makalede sizlere, Dynamic Management View’ler ile elde edebileceğiniz verileri, Sql Server Management Studio üzerinde nasıl rapor haline getirebileceğinizi anlatacağım. Sql Server performansını izlemek için birçok 3. Parti yazılım mevcuttur, bu yazılımlar genellikle ücretlidir. Sql Server Performance Dashboard raporlarını ücretsiz olarak indirebilirsiniz. Sql Server Management Studio’da görebildiğimiz bu raporları, Sql Server Reporting Services üzerinden de çalıştırabilmekteyiz, Reporting Services Web arayüzüne bu raporları nasıl yükleyeceğimizi ve daha sonra bu raporlar periyodik olarak mail ile nasıl gönderebileceğimize değineceğiz.

İlk olarak, Microsoft’un ücretsiz olarak sunduğu Sql Server Performance Dashboard raporunu aşağıdaki linkten indiriyoruz.

https://www.microsoft.com/en-us/download/details.aspx?id=29063

Kurulum dosyasını çalıştırarak kurulumu başlatıyoruz, basit bir kurulumu var, next – next ile kurulum işlemini tamamlıyoruz.

Rapor dosyalarının kurulduğu klasör bilgisi önemli, bu dosyaları daha sonra SSMS içine ekleyeceğiz.

Rapor kurulumu tamamlandıktan sonra, Sql Server Management Studio’yu açıyoruz. Instance adı üzerinde sağ klik yaparak, Reports – Custom Report’u açıyoruz.

Open File ekranından Tools – Performance Dashboard altına kaydedilen raporumuzu açıyoruz.

Gelen uyarı ekranına Run diyerek raporu çalıştıryoruz.

Raporu direk eklediğimizde aşağıdaki uyarı karşımıza geliyor.

Report defiinition language ile yapılan bu rapor, Reporting Services ile uyumlu çalışmaktadır. İstenirse Reporting Service ile bu rapor alınabilir. Raporun çalışması için Sql Server dizini altına kurulan Perfomance Dashboard içindeki Setup.sql scriptini çalıştırmamız gerekiyor.

Script üzerine çlft tıklayarak, SSMS üzerinde Execute diyerek scripti çalıştırıyoruz.

Raporu Custom Reports – Performance Dashboard Main kısayolu ile açıyoruz. Aşağıdaki gibi karşımıza raporumuz geliyor.

Raporun üstünede iki tane grafik var, soldaki CPU genel kullanım oranını göstermekte, sağdaki ise bekleyen isteklerin hangi sebeplerden dolayı beklediğini gösteren bar grafik.

CPU grafiğindeki barlara tıkladığımızda, CPU kullanımındaki detaylara bizi yönlendirmektedir. Barlara tıkladığımızda aşağıdaki gibi bir hata alabiliriz.

Bu hatayı sub-report’un reginol ayarlardan dolayı çalışmadığı için alırız. Time verilerini Datatime yerine nvarchar veri tipinde aldığı için bu hatalar meydana gelmektedir. Hatayı düzeltmek için aşağıdaki scripti çalıştırmamız gerekiyor.

USE msdb

ALTER PROCEDURE MS_PerfDashboard.usp_Main_GetCPUHistory

begin

declare @ms_now bigint

select @ms_now = ms_ticks from sys.dm_os_sys_info;

select top 15 record_id,

CONVERT(NVARCHAR(30), dateadd(ms, -1 * (@ms_now - [timestamp]), GetDate()),121 )as EventTime,

SQLProcessUtilization,

SystemIdle,

100 - SystemIdle - SQLProcessUtilization as OtherProcessUtilization

from (

select

record.value('(./Record/@id)[1]', 'int') as record_id,

record.value('(./Record/SchedulerMonitorEvent/SystemHealth/SystemIdle)[1]', 'int') as SystemIdle,

record.value('(./Record/SchedulerMonitorEvent/SystemHealth/ProcessUtilization)[1]', 'int') as SQLProcessUtilization,

timestamp

from (

select timestamp, convert(xml, record) as record

from sys.dm_os_ring_buffers

where ring_buffer_type = N'RING_BUFFER_SCHEDULER_MONITOR'

and record like '%%') as x

) as y

order by record_id desc

end

Şimdi CPU grafiğindeki barlara tıkladığımızda detay ekranı karşımıza gelmektedir.

Wait Category grafiğindeki en yüksek beklemeyi yapan bar veya barlara tıklayarak bekleme nedenlerini incelebiliriz.

Query Text alanında sorguların üzerine tıkladığımızda, bize sorguların query planlarını vermektedir, eğer sorguda eksik bir index var ise, bunun bilgisini ve yeni index oluşturmak içinde hazır scriptini sunmaktadır.

Dashboard’un sol alt tarafında bulunan, Current Activity bölümünde, kullanıcı istekleri ve kullanıcı oturumları hakkında bilgi vermektedir. User Requests ve User Session linklerine tıkladığımızda detay ekranları karşımıza gelmektedir.

Anlık kullanıcı oturumlarının raporu için User Sessions bölümüne tıklamanız gerekmektedir.

Dashboard’un sağ alt köşesindeki Historical Information bölümü bulunmaktadır, bu bölümünde bekleme nedenleri, I/O İstatistikleri, CPU kullanım oranları, aktif oturumlar ve veritabanları hakkında bilgiler vermektedir.

Waits alt raporunda, bekleme nedenlerini grafiksel olarak göstermektedir.

Alt tarafında bulunan Wait Category de matrix rapor bulunmaktadır, bekleme kategorilerinin detaylarını buradan görebilirsiniz.

Historical I/O Statistics raporunda, veritabanlarının ne kadar I/O tükettiğini görebilirsiniz, okuma ve yazma değerlerine göre sıralama yapılabilmektedir.

Expensive Queries bölümünde, en fazla CPU tüketen, Logical read, logical write, fiziksel okuma ve CLR zamanına göre sorguları getirmektedir.

Miscellaneous Information raporlarında, Active Traceler, Active Xevent Sessionları, Veritabanlarının genel bilgileri ve Missing Indexler hakkında raporlar bulunmaktadır. Missing Index raporunda, Indexler hakkında bilgilerin yanı sıra, missing olan indexlerin oluşturulması için scriptini de raporda vermektedir.

Performans Raporlarının Reporting Service Üzerinden Alınması

Sql Server Performans raporları Management Studio üzerinden alınması için, raporun manuel tetiklenmesi gerekiyor. Belli bir süre geçtikten sonra bu raporlar unutulmaktadır. Management Studio’daki raporlar RDL – Report Definition Language ile yapıldığından, Sql Server Reporting Service ile birebir uyumlu raporlardır.

Reporting Service ile uyumlu olan bu raporları, kendi Reporting Service’imizi üzerine yükleyebilir, bu rapolar Reporting Service’in web arayüzünden görebiliriz. Diğer avantajı da, raporları günlük, haftalık veya aylık olarak istenen kullanıcılara mail olarak gönderebiliriz. Böylelikle, Sql Server Performansı gibi önemli raporların sürekli bildirimlerini yapabiliriz.

Reporting Services kurulumu ve konfigürasyonunu daha önceki makalelerimizde işlemiştik. Sisteminizde Reporting Service kurulu olduğunu varsayarak anlatmaya devam edeceğim. İlk olarak Visual Studio Data Tools programını açıyoruz. Boş yeni bir proje açıyoruz.

New Project ekranında, boş Report Server Project’i seçiyoruz.

Name kısmına, rapor projesinin adını yazıyoruz. Reporting Services web sitesinde, proje klasörüne verilen isim buradan gelmektedir.

Boş bir rapor projesi açtık, Visual Studio Data Tools ana ekranın sağında bulunan, Solution Explorer bölümündeki, Reports klasörüne sağ tıklayarak performans raporumuzu ekleyeceğiz.

Reports – Add – Existing Item’e tıkıyoruz

Add Existing Item klasör penceresinden Dashboard raporumuzu seçip ekleyeceğiz. Raporumuz Program Files x86/Microsoft Sql Server/110/Tools/Perfomarnce Dashboard klasörü altındaydı, bu klasöre gelip performance_dashboard_main.rdl dosyasını seçip Add diyerek rapor projemize ekliyoruz.

Dashboard raporundaki, alt raporların hepsi hidden dosyalardır, bu dosyaların özelliklerine girip hidden özelliğini kaldırmanız gerekmektedir. Dashboard raporunun ana sayfasında, alt raporlara linkler verilmiştir, link verilen alt raporların, rapor projesine eklenmesi gerekeceği için hidden özelliklerini kaldırmanız gerekmektedir.

Performance Dashboard raporumuz Solution Explorer ekranımıza geldi, rapor üzerinde sağ tıklayarak Open diyoruz.

Rapor design ekranında açıldı, sol tarafta bulunan Report Data bölümünde raporun DataSource’u ve Datasetleri de gelmiş oldu.

Raporun çalışması için, ilk olarak Data Source yani veri kaynağını ayarlamamız gerekiyor. Raporun hangi Sql Server’daki bilgilerini getireceğiniz belirtmemiz gerekmektedir. Eğer birden fazlla Sql Server için raporu almak istiyorsanız, Raporun bir kopyasını proje bazında yaparak, sadece Data Source’un da ilgili Sql Server’ı ayarlamanız yeterli olacaktır.

Data Source’da, Sql Server’ımızın bağlantı ayarlarını gireceğiz, bunu için DataSource1 sağ klik properties ekranını açıyoruz.

Rapor Sql Server içinde çalışması için Shared Data Source olarak ayarlanmış, bu ayarı Embedded Connection olarak değiştiriyoruz. Ardından Edit’e tıklayarak bağlantı özelliklerini yapıladıracağız.

Edit ile Connection Properties ekranı açılıyor, bu ekranda Server name kısmına Sql Server’ın adını veya Ip adresini yazıyoruz. Log on tipini seçiyoruz. Connect a database kısmından master veritabanını seçiyoruz. Rapordaki sorgular master veritabanından çalıştığı için, başka bir veritabanı seçtiğimizde hata alabiliriz. Son olarak test connection diyerek bağlantı ayarlamızın doğruluğunu test ediyoruz.

Raporumuzun connection string’i, Data Source Properties ekranına gelmiş oldu.

Data Source’un ikonu daha önce kısayol işareti bulunan shared data source idi, yapılan değişikliklerden sonra data source’umuz embedded olarak değişti.

Raporun data source’unu ayarladıktan sonra, raporumuzu Preview sekmesine tıklayarak çalıştırıyoruz.

Raporumuz sorunsuz bir şekilde çalıştı. Bu dashboard raporu olduğu için, bu ana ekrana bağlı bir çok alt rapor var. Örnek olarak Waiting Request grafiğindeki bar çubuğuna tıklayalım. Tıkladığımız zaman detaylarına gitmesi gerekir, fakat alt raporu projeye tanımlamadığımız için aşağıdaki uyarıyı alıyoruz.

Alt raporların hepsi, proje klasörümüzün içindeydi, bu alt raporları Add – Existing Item diyerek ekliyoruz

Performance_dashboard_main haricindeki tüm raporları seçiyoruz.

Alt raporlar, solution Explorer’a eklenmiş oldu.

Raporu tekrar çalıştırıp, Waits alt raporuna tıklayalım.

Raporumuz çalıştı, eğer rapor çalışmasında Data Source ile ilgili bir hata verirse, Data Source’u convert to shared datasource yaptığınız da sorun düzelmiş olacaktır.

Performans raporlarımızı Reporting Service üzerinde çalıştırdık, rapor düzenleme aracı olan Visual Studio Data Tools içinde raporlarımızı açtık, şimdi bu raporları Reporting Service web sunucusu üzerine nasıl aktaracağımıza bakalım.

Daha önceki Reporting Services makalelerimizden hatırlayacağınız üzere, raporlar web sunucusuna aktarmamız için, Reporting Services’in ftp sunucusunun adına ihtiyacımız var, ftp sunucusunu öğrenmek için, Sql Server dizini altındaki Reporting Services Configuration Manager’ı açıyoruz.

RS Configuration manager ekranında, Web Service Url sekmesindeki, Report Server Web Service Urls linkini kopyalalıyoruz. Link kopyalanmaya izin vermeyebilir, linki tıklayarak browser üzerinde açtıktan sonra Url’yi kopyalabilirsiniz.

Visual Studio Data Tools’da Project menüsünde rapor özellikleri sayfasını açıyoruz

Target Server Url kısmına, Web Service Url’imizi kopyalıyoruz

Ok ile ekranı kapadıktan sonra, Performans Raporunu Reporting Service Web service’ine yüklemesine geçiyoruz. Solution Explorer menüsünden proje adına sağ tıklayarak Deploy diyoruz.

Performans raporu web tarafına deploy edildi. Reporting Service web Url’sini açıyoruz. Raporun geldiğini kontrol ediyoruz.

Raporumuzu proje olarak oluşturduğumuz için klasör olarak Web tarafına gelmiş bulunuyor.

Performans Dashboard Raporunun Otomatik Olarak Mail Gönderilmesi

Performans Dashboard raporunun günlük, haftalık veya aylık olarak mail olarak gönderebiliriz. İlk olarak Sql Server Performans Dashboard klasörüne tıklıyoruz. Bir sürü alt raporunda geldiği gözüküyor. Sadece performance_dashboard_main raporunun Subscribe edilmesi yeterli olacaktır.

Performance-_dashboard_main raporunun yanındaki menü işaretine tıklayarak Subscribe diyoruz.

Subscription ekranında mail gidecek kişileri yazıyoruz. Parametre varsayılan olarak bırakılıyor.

Select Schedule bölümünden raporun hangi periyodlarda mail gönderileceği belirlenir.

Saatlik, günlük, haftalık, aylık veya bir kereliğine mail gönderilebilmektedir. Ok ile ekran kapatılır, subscribe ekranı da Ok ile kapatılır. Tanımlamış olduğumuz mail görevi, Reporting Service Web servisinin My Subcription bölümüne gelmektedir. Bu ekrana bakıp, mail görevimizi takip edebiliriz.

Bu ekranda mail görevlerimizi görebilmekteyiz

Reporting Service üzerinde mail gönderebilmek için, lokal yapımız içinde Exchange Server gibi bir mail sunucusu var ise, Exchange Server’ın bağlantı ayarlarını Reporting Services Configuration Manager altındaki E-Mail Settings bölümünde tanımladığımızda, mail görevlerimiz sorunsuz çalışacaktır.

Eğer lokalde bir mail sunucumuz yok ise, gmail hesabımız ile nasıl mail göndereceğimizi aşağıdaki makaledeki yönergeleri izleyerek yapabilirsiniz.

http://www.cozumpark.com/blogs/sql/archive/2014/10/26/sql-server-reporting-service-gmail-ile-mail-bildirimleri.aspx

Sql Server Performansını izlemek için birçok 3. Parti yazılım mevcuttur, bu makalede sizlere Sql Server içerisinden ek bir maliyet getirmeden, Sql Server Performansının nasıl izleneceği, bu raporlar Reporting Service üzerinde çalıştırılması ve bu raporların periyodik olarak mail ile bildirimlerinin sağlanmasını hakkında bilgiler aktarmaya çalıştım.

Virtualization, Türkçe karşılığı sanallaştırma, son dönemde çok popüler olan bir kavramdır. Sanallaştırma, bugün sıklıkla sunucu donanım kaynaklarının tek bir işletim sistemine atanması yerine, bir sanallaştırma ara katmanı (hypervisor) ile birden fazla işletim sistemine sunulması olarak kullanılır. Sanallaştırmanın ilk uygulamaları, 1960 yılında mainframe bilgisayarlarda, kaynakların farklı uygulamalara bölünmesiyle gerçekleştirilmiştir.

Son 15 yılda, sanallaştırma kullanımı artmış ve günümüzde sanallaştırmanın kullanılmadığı bir datacenter düşünmek mümkün olmayacak bir hale gelmiş, sistem uzmanlarına büyük yönetimsel esneklik ve maliyet avantajı getirmiştir. Sanallaştırma bu kadar yaygınken, Sql Server’ı sanala kurmayın gibi yanlış bir söylem de IT dünyasında yaygın bir şehir efsanesidir. Sql Server’ın hypervisor üzerine kurulmasının performans kayıplarına yol açtığı ve fiziksel sunucu üzerine kurulması tavsiye edilmektedir. Sanallaştırılması kabul edilemeyecek derecede kritik ve gerçek zamanlı işlem yapması gereken SQL sunucular bulunabilir. Fakat bu özel durum dışında bu makalede Sql Server Sanallaştırması hakkında yanlış bilinenleri ve Sql Server sanallaştırması sırasında nelere dikkat etmemiz gerektiğini anlatmaya çalışacağım.

Hypervisor, fiziksel sunucu üzerine kurulan yazılımsal sanal bir katmandır. Sanal işletim sistemleri bu hypervisor üzerine kurulur. Hypervisor, fiziksel sunucu ile sanal makinelerin arasında köprü görevi görür. Sanallaştırmada sunucu üzerine kurulan hypervisor makineye host machine, hypervisor üzerine kurulan sanal makinelere de guest machine denmektedir.

Sql Server Sanallaştırması yapılırken sık karşılaşılan hatalar, sanal makinenin yanlış konfigüre edilmesi, host sunucu kaynaklarının yanlış ölçeklendirilmesi, sanal makine performanslarının yanlış izlenmesidir. Günümüzde hypervisor limitleri istenen düzeye gelmiş olup, desteklenen işlemci ve hafıza boyutları kabul edilebilir performans değerleri sunmaktadır. Ayrıca sanallaştırma, hem maliyet hem de yönetilebilirlik açısından çok fazla fayda sağlamaktadır.

Bu makalede sizlere Vmware veya Hyper-V kurulumları veya yönetimsel konularından bahsetmeyeceğim, bu konular hakkında, konunun uzmanlarının yazdığı birçok makale vardır. Sql Server’ın sanallaştırma katmanları üzerindeki yapılandırılmasının nasıl olacağı, nasıl olması gerektiği ve Sql Server sanallaştırmasında karşılaşılan hataları en az seviyeye nasıl indirebiliriz bunları aktaracağım. Ama önce lisanslamadan biraz bahsedelim.

Sanal Sistemlerde SQL Server Lisanslaması

SQL Server, Microsoft’un Volume Licensing anlaşmaları içerisinde sattığı ürünleri arasında en pahalı olanıdır. Bu ürünün lisanslaması hakkında fikir sahibi olmak, organizasyonunuza lisanslama konusunda ciddi miktarda para kazandırmak anlamına gelir.

SQL Server lisanslaması hakkında bu makalede detaylı bilgi vermek zor fakat, sanallaştırma açısından çok önemli bir bilgi olan “Enterprise Core licensing with Software Assurance” tipinden bahsetmek önemlidir.

Ent Core modelinin sınırsız sanallaştırma özelliğini kullanmıyorsanız, her bir sanal makina için en az 4 core, yani 2 Ent Core lisansı almanız gerekir. Eğer bir fiziksel sunucu üzerinde diyelim ki 5 tane SQL Server çalıştırıyorsanız, her bir VM üzerinde tek bir core atanmış bile olsa, toplamda 20 core’luk lisans satın almanız gerekmektedir. Bu da hızlıca on binlerce dolar mertebesine ulaşacaktır. Bunun yerine, fiziksel sunucularınızı tek bir güçlü host üzerinde sanallaştırırsanız, 20 core – 10 lisans (her bir Ent Core lisansı 2 adet core lisanslamaya yarar) almak yerine, sadece fiziksel host üzerinden toplam core miktarını hesaplayıp ona göre lisans alımı yapabilirsiniz. Burada en önemli nokta, Ent Core sadece lisansını satın alıp Software Assurance eklemezseniz, bu anlattığımız çözüm geçerli olmayacaktır.

Yukarıda bahsettiğimiz, üzerinde 5 tane SQL VM çalışan host, eğer 2 işlemciye sahipse ve her işlemci üzerinde 4 tane core varsa, o zaman Ent Core w SA lisanslamada toplam lisanslamanız gereken core sayısı 8 olacaktır. 20 yerine 8 core, ciddi kazanımlar sağlamanıza yardımcı olur. Ayrıca bu şekilde lisanslama yaptığınız takdirde, bu sunucu üzerinde istediğiniz kadar sunucu performansı etkilenmediği sürece yeni sunucu eklemeniz mümkün. Aynı sunucudaki işlemci ve core sayıları değişmediği sürece, isterseniz 100 tane daha SQL Server kurun, yeni lisans satın almanız gerekmez.

Yukarıda bahsettiğimiz gibi SQL lisanslaması karmaşık bir konu ve bu makalede tüm başlıklarını incelememiz mümkün değil fakat Ent Core w SA lisanslamasını incelemenizi, sunucularınız yoğunluklarına ve iş yüklerine göre fiziksel hostlar üzerinde lisans masraflarınızı düşürmek üzere birleştirmenizi tavsiye ederim.

Sanallaştırma Tipleri:

Sanallaştırmanın temelinde, İşlemci, Donanım ve Memory sanallaştırması bulunur. Bunlar hakkında bilgi sahibi olmalıyız ki, Sql Server Sanallaştırmasını daha iyi anlayabilelim. Sanallaştırmanın 3 farklı donanımsal temeli olduğu gibi, 3 farklı da tipi vardır bunlar;

1- Full Virtualization using Binary Translation: Sanal makinadaki işletim sistemi, sanal olduğunu bilmez. İşletim sistemi istekleri doğrudan işlemciye iletilir.

2- OS Assisted Virtualization or Paravirtualization: Sanaldaki işletim sistemi ve hypervisor, daha performanslı bir şekilde direk haberleşir. İşletim sistemindeki uygulama istekleri direk işlemciye istekte bulunur, yüksek performans sağlamaktadır. Windows 2000/XP bu tipte desteklenmemektedir.

3- Hardware Assisted Virtualization: En temel seviyedeki sanallaştırmadır. Intel VT-x ve AMD-V olarak marka bazında terimleri vardır. Yukardaki iki tiptede olduğu gibi direk işlemciye uygulamalar erişim isteği gönderir. 64-Bit işletim sistemi desteği vardır.

Aşağıdaki şekilde, sol tarafta sanallaştırma yapılmadan kullanılan bir sunucuyu, sağ tarafta ise sanallaştırma yapılmış bir sunucunun katmanlarını görmekteyiz.

SSV-1

Cpu Virtualization – İşlemci Sanallaştırması

İşlemci sanallaştırmasında, fiziksel işlemci hypervisor vasıtası ile sanal işlemcilere ayrılır. Fiziksel işlemci ile sanal işlemciler arasında hypervisor haberleşmeyi ve yönetimini sağlar. Input/Output portların geçişi hypervisor üzerinden olur. Sanallaştırma yapılmamış X86 mimarisindeki bir işlemcinin bölümlerini inceleyelim. Vmware Whitepaper: http://www.vmware.com/files/pdf/VMware_paravirtualization.pdf

SSV-2

X86 Mimarisi, işletim sistemine erişim seviyesine gelen kadar 4 bölüm üzerinden geçer. Kullanıcı uygulamaları Ring3 üzerinde çalışır. İşletim sistemi memory ve donanıma direk erişmek istediğinde Ring 0’ı kullanır. İşletim sisteminin talepleri direk fiziksel sunucunun donanımı üzerinde gerçekleşir. Sanallaştırma, şekildeki OS ile “Host Computer System Hardware” yani sunucu arasında bir katman oluşturarak (Hypervisor), fiziksel sunucunun donanımını yönetir.

Hypervisorler iki tiptedir;

1- Sunucu üzerine kurulan, sanal makineleri ve sunucu donanımları yöneten hypervisorler. (Vmware Esx, Hyper-V, XenServer)

2- Uygulama olarak çalışan, kişisel bilgisayarlarda kurulan hypervisorler. (Vmware Workstation, VirtualBox, VirtualPC)

Hypervisorler, işlemciye erişimi, I/O (input/output) giriş çıkış isteklerini ve memory kaynaklarını kontrol eder ve yönetirler.

Memory Virtualization – Bellek Sanallaştırması

SSV-3

Bellek sanallaştırmasında, işletim sistemindeki bellek direk olarak sunucu üzerindeki belleğe erişim sağlayamaz. Sanal makinadaki şekil SSV-2’deki PA – Physical Memory aracılığı ile, işletim sistemdeki bellek sunucu üzerindeki belleğe erişim sağlamaktadır.

Sanallaştırmanın Getirdiği Faydalar:

- Maliyet Avantajı: Sanallaştırmanın son yıllarda popüler olmasında en büyük etkendir. Tek bir sunucu üzerinde kaynakların paylaşımı sayesinde daha uygun maliyetli projeler çıkmaktadır. Sistem yönetimi ve lisans maliyetlerinde büyük faydalar sağlamaktadır. Doğru yapılandırılma yapılmadığı zaman ise, sanallaştırma performans kayıplarına yol açmaktadır, bu da getirdiği maliyet avantajını kaybettirmektedir.

- Enerji Tasarrufu: Daha az sunucu ile sanallaştırmaya geçildiğinde, fiziksel sunucuların tükettiği elektrik ve soğutma maliyetleri azalacaktır.

- Sistem Yönetimi: Fiziksel sunucuya oranla, işletim sistemi kurulumları ve yapılandırılmaları çok daha basittir. Bilgi Teknolojileri bölümlerine büyük kolaylıklar sağlamaktadır.

- Felaket Kurtarma Senaryolarında Kolaylık: Sanal makinaların replikasyonu, fiziksel makinalara göre çok daha kolaydır. Sanal makinalar donanımdan bağımsız çalıştıkları için, yedekleme-geri yükleme gibi işlemler fiziksel makinalara göre daha basit olmaktadır.

- Yüksek Erişebilirlik: Vmotion ve Migration özellikleri ile, çalışan bir sistemde, sistem aksamasına uğramadan yüksek erişebilirlik sunmaktadır.

- BT’nin Masraf Merkezi İmajından Kurtulması:Çoğu yerde bilgi teknolojileri veya bilgi işlem bölümleri masraf merkezi olarak görülür. Sanallaştırmanın sağladığı maliyet ve yönetimsel avantajlar ile bu imaj artık geride kalmaktadır.

Sistem Uzmanı VS Veritabanı Uzmanı:

Sanallaştırma yapılmadan önce sanal makinaların ihtiyaçlarının önceden belirlenmesi gerekir. Mevcut fiziksel bir makinada çalışan Sql Server’ın performansı izlenerek, ne kadar işlemci kullanımı olduğu, ne kadar ram ihtiyacı ve disk alanın hesaplanması gerekmektedir.

Sql Server’ın sanallaştırması iki türlü olmaktadır. Yeni bir sistem kurulumunda veya mevcut sistemin fizikselden sanala taşınma durumda. Bu iki durumda da sistem uzmanı ile veritabanı uzmanları (Dba) karşı karşıya gelmektedirler. Yapısında Dba olmayan kurumlarda ise, yazılımcılar veya yazılım firmaları ile sistem uzmanları Sql Server konusunda çatışma yaşamaktadırlar.

Sistemci Sql Server’ı, fazla işlemci kullanmayan, işlemciden ziyade çok fazla ram ihtiyacı olan, ne kadar fazla ram olursa o kadar kullanır olarak gören ve çok fazla disk alanı isteyen bir sunucu olarak görür.

Aslında olması gereken, tek bir işlemci üzerindeki tüm çekirdekleri atamak yerine, iki işlemcinin ihtiyaç kadar olan çekirdeklerini eşit olarak atamak en ideal olan işlemci yapılandırılmasıdır. Sql Server birçok işlemi memory üzerinde yaptığından, memory boyutunun fazla olması tabiki önemlidir ama esas performans açısından memory’lerinde hızlı olması gerekmektedir. Çok yüksek miktarda uygun maliyetli memoryler yerine çok daha hızlı düşük kapasiteli ideal boyuttaki memory’ler atamak önemlidir. Gereksiz yere büyük disklere ihtiyaç yoktur. I/O değerleri yüksek performanslı diskler Sql Server’ın ihtiyaç duyduğu donanımlardandır.

Ufak gibi gözüken fakat dikkat edilmesi gereken diğer noktalar ise; Sql Server’ın kurulu olduğu sunucu üzerine başka bir uygulama kurulmamasıdır. Bu sunucunun bir application server gibi kullanılmaması gerekmektedir. Yapılan en büyük yanlışlardan biri de, sunucuya atanan memory’nin hiçbir ayar yapmadan hepsini Sql Server’un kullanımına sunmaktır. Bu gibi sunucularda sık sık hatalarla karşılaşılır. Örnek olarak 64gb’lık bir sunucunuz var, bunun 4gb’tını hpervisor için, %10’unu da Windows Server için ayırmalısınız. Sanalda bu makine için 60gb’lık ram oluşturulmalı ve Sql Server içinde de 54 gb’lık en fazla kullanacağı ram kapasitesi ayarlanmalıdır ki bu sunucu düzgün hizmet verebilsin.

Sanal Makine Kaynak Yapılandırılması:

İşlemci Yapılandırılması:

Sql Server’ın kurulacağı sanal makinanın işlemci sayısını belirlerken, ilk önce gereksinim neyi karşılıyor ise o kadar sanal işlemci (vCpu) atamak yeterli olacaktır. Fiziksel bir sunucudan aktarılan Sql Server’daki işlemci sayısı sanalda birebir aynı olduğunda, gerekli ihtiyacı karşılamayabilir. Sanal ortamda daha fazla, sanal işlemciye ihtiyaç duyabilmektedir.

Sanal ortamlarla ilk karşılaştığımızda, elimizdeki fiziksel işlemcilerden çok daha fazla sanal işlemci gördük. Ne kadar çok fazla sanal işlemci demek, o kadar çok sunucumuza iş yükü getirir. Sql Server’a bol bol sanal işlemci atadığınızda, çok daha hızlı bir Sql Server’ınız olacağı anlamına gelmez. Gereksiz yere atanan sanal işlemciler, sunucu (host) üzerinde aşırı yük getirir, bu da sunucunun isteklere yanıt vermesini geciktirir ve performansını düşürür.

Sanallaştırma ortamında işlemcilerin paylaştırılması bazen sorunlara neden olabilir. Şekil SSV-4’te, Sql server soket1 işlemcisinden çalışıyor, Sql boşa geçtiği zaman application server ile iki fiziksel işlemci paylaştırıldığından, app. Server soket1 e istek gönderebilir. Aynı zamanda Sql server çalışmaya başladığında, fiziksel soket1 üzerinde hem sql hem app. Server çalışmış olur. Bu çalışmada performans kaybına neden olmaktadır. Cross NUMA (Non-Uniform Memory Access) diye adlandırılan problem ortaya çıkacaktır. Plan yapılmadan yapılan işlemci paylaşımlarında bu tarz durumlarla sıkça karşılaşılmaktadır.

SSV-4

Sanallaştırmada sanal makinaların kapasite boyutlarını yapılandırırken, fiziksel işlemci soketi sayısı, işlemci başına düşen çekirdek sayıları ve memory yapılandırılmasına dikkat edilmelidir. Sanal makinaları ölçeklendirmede bazı hususlar vardır. Aşağıdaki örnekte, 2 adet fiziksel soket, her soket başına 6 çekirdek ve 96 gb toplam memory boyutumuz var. Sanal makinanımızın özellikleri de 4 çekirdek işlemciye ve 32 gb memory’e sahip bir makinadır.

Sanal makinadaki 4 çekirdek, VM host’tun bir fiziksel soketinde bulunan çekirdek sayılarından az veya eşit olduğu zaman, tüm işlemleri tek bir soket üzerinden yapar. Diğer soket üzerinden çalışma ihtiyacı duymaz, bu atamalar Hypervisor kendisi otomatik olarak yapmaktadır. Hypervisor’un bu şekilde çalışması, sanal makinanın diğer sokete ihtiyaç duymayacağından, sanal makinanın daha performanslı çalışmasını sağlamaktadır. Böyle bir yapılandırma için yapılandırma ayarlarından bir değişiklik yapılmasına gerek yoktur, Hypervisor otomatik olarak algılayarak, arka planda yapılandırmayı kendisi yapmaktadır.

SSV - 5

Eğer fiziksel soketteki çekirdeklerden daha fazla bir sanal makinamız var ise, 4 çekirdek değil de, 8 çekirdeğe sahip bir sanal makina için, yukarıda bahsettiğimiz durum gerçekleşmeyecektir. Bir fiziksel soketimizde 6 çekirdek olduğu için, sanal makina diğer 2. Fiziksel soketi de kullanacaktır. Fakat bu kullanım sırasında, hypervisor tarafında direkt olarak fiziksel sokete bir atama gerçekleşmeyecektir, sanal makina hangi CPU’ları kullanacağına karar veremez ve Co-Scheduling dediğimiz eş zamanlı CPU çalışması böyle bir yapıda bozulacaktır.

Şekil SSV – 6’da olduğu gibi, fiziksel soketteki 6 çekirdek var, sanal makinadaki çekirdek sayısı 8 olduğundan, hypervisor işlemci atamasını direk fiziksel sokete verememektedir. Cross yani çapraz bir şekilde işlemciyi kullanacaktır, cross olarak Sql Server’ın çekirdekleri kullanması best practice olarak önerilmemektedir. Sanallaştırmada, işlemci yapılandırılmasında karşımıza çıkan olumsuz durumlardan biridir.

SSV – 6

Virtual NUMA Yapılandırması

NUMA (Non-Uniform Memory Access) Türkçe’ye çevirmeye çalıştığımızda, Tekdüzen Olmayan Bellek Erişimi olarak çevirebiliriz. NUMA, bazı bellek bölümlerinin daha uzun erişim gecikme sürelerine sahip olduğu çok işlemcili tasarımlar ile kullanılan bir bilgisayar sistemi mimarisidir. Bunun nedeni, sistem belleği ve işlemcilerin birbirlerine bağlanış şeklidir. Bazı bellek bölümleri, çeşitli bağlantı dokusu türleri aracılığıyla tüm işlemciler birbirine bağlı olacak şekilde doğrudan bir veya daha fazla işlemciye bağlanır. Büyük çok işlemcili sistemler için, bu düzenleme bellek çekişmelerinin azalmasını ve sistem performansının artmasını sağlar. Sanallaştırma platformları Vmware ve Hyper-V de NUMA yapılandırılmasını desteklemektedir.

NUMA mimarisi, memory’i ve CPU’ları NUMA nodeları olarak adlandırılan gruplara böler. Sistemdeki tek işlemciler açısından, bu işlemci ile aynı NUMA nodedun da yer alan memory lokal olarak, başka bir NUMA nodedun da bulunan memory ise remote olarak bilinir. CPU’lar yerel memory’e daha hızlı erişebilir.

Vmware’de, ESX 5 ve üzeri sistemlerde, sanal makinadaki vCpu (virtual CPU) sayısı, sunucu üzerindeki fiziksel çekirdek sayısını geçtiğinde, sanal makinanın NUMA yapılandırması optimize olamamaktadır.

Vmware Esx 5 üzeri ve Hyper-V Server 2012 sistemleri, virtual NUMA nodelarının partition olarak çalıştırarak, hypervisor katmanında optimize edebilmektedir. Vmware üzerindeki sanal makinaya ait 8 vCPU veya sanal makinadaki vCPU sayısı, sunucu üzerindeki fiziksel çekirdekten daha fazla olduğu durumlarda bu optimizasyon yapılabilmektedir. Bu yapılandırmayı etkinleştirmek için konfigürasyon parametrelerine “numa.vcpu.min” ayarını eklememiz gerekmektedir.

Bu yapılandırmadan sonra, vCPU ve memory ataması virtual node’lara bölünerek, 4 vCPU’nun Fiziksel Soket 0’dan, 4 vCPU’nun da Fiziksel Soket 1’den çalışmasını sağlayacaktır. Sql Server sanal makinasını Virtual node’lara böldüğünde, Virtual Node 0’da 32 gb ram ve 4 vCPU, Virtual Node 1’de 32 gb ram ve 4vCPU olduğunu görmekteyiz. Şekil – SSV – 7

SSV – 7

Bu yapılandırmanın Esx üzerinde nasıl olduğuna bakalım, sanal makinanın Configuration Parametrelerine erişebilmemiz için, sanal makinanın kapalı olması gerekmektedir. Kapalı olan sanal makinamızın Edit Settings bölümünü açıyoruz.

SSV – 8

Options sekmesinde, General satırına tıklıyoruz. Configration Parameters bölümü sanal makinamız kapalı olduğu için aktif durumda.

SSV – 9

Add Row butonuna tıklayarak yeni bir satır ekliyoruz. Eklediğimiz satırın Name kısmına numa.vcpu.min, Value alanına da 2 yazıyoruz.

SSV – 10

Bu parametreyi girdikten sonra, SSV – 7’de gösterildiği gibi, sanal makinamızın vCPU’larını ve Memory atamalarını fiziksel soketlere ayrıştırmış olduk. Bu sayede, büyük yapıdaki sanal makinalara kurulu olan Sql Server’ların dar sanallaştırmadan kaynaklanan Cpu ve memory cross kullanımını engellemiş oluruz.

Vmware Cpu Reservation – Cpu Share

Sanal makinanız başladığı zaman, sanal makinaya ait kaynakların hepsi açıldığı gibi sanal makinaya atanmaz, ne kadar kaynak kullanacak ise, kaynak havuzundan ihtiyacı olan memory ve CPU’yu alır. Sql Server için bu yapı, istenmeyen bir yapıdır, Sql Server açıldığı andan itibaren, host üzerinden memory ve CPU’larının Sql Server sunucusuna atanması gerekmektedir.

Cpu rezervasyonu için, sanal makinanın kapalı olmasına gerek yoktur. Sanal makinanın Edit Settings’ten ayarlarına giriyoruz.

SSV-11

Resources sekmesinden CPU bölümüne geliyoruz, Reservation kısmından sunucuya ne kadar CPU rezerve edeceğimizi Mhz biriminden yazabilmekteyiz. Rezervasyonda komple çekirdek sayılarını rezerve etme gibi bir durum yerine, CPU hızlarını toplam mhz biriminden rezervasyon yapabilmekteyiz.

SSV-12

Turuncu üçgen ile gösterilen şekilde bize host üzerindeki tüm çekirdeklerin toplam hızlarını mhz biriminde göstermektedir, reservation’ı turuncu üçgene kadar getirdiğinizde, tüm CPU’ları sunucuya rezerve etmiş olursunuz, host üzerinde eğer başka sanal makinalar var ise, böyle bir yapıda çok yavaş çalışacaktır. Limit kısmından da sanal makinanın CPU hızına limit koyarak, diğer sanal makinaların CPU hızlarından kullanmamasını sağlayabilirsiniz.

Resource Allocation – Shares bölümü, eğer host üzerinde Sql Server dışında başka sunucular da var ise, bu bölümünden Sql Server işlemcilerine öncelik verebiliriz. Eğer Sql Server host üzerinde tek başına çalışıyor ise bu bölümü kullanmaya gerek yoktur. Sql Server olan bir host da, Sql Server için High share vermek daha doğru olur. CPU Shares ike Reservation’nın farkı, Reservation da Sql Server için CPU kullanımını ayırmaktadır, 8000 mhz olan bir reservation da Sql Server 8000 mhz’ini kendine ayırır. Shares de ise sanal makinaya yüksek veya düşük öncelikli CPU kullanımı verilmektedir, reservation tanımı yapılmadı ise CPU dinamik olarak sunucunun öncelik durumuna göre CPU kullanımını sağlar.

Memory Yapılandırması:

İşlemci yapılandırmasında shares ve reservation yapılandırması, memory yapılandırması içinde geçerlidir. Memory reservation ve share ayarları için, Edit Settings – Resource sekmesindeki memory alanından düzenlemeleri yapabiliriz.

SSV-13

Vmware, host üzerinde bulunan toplam memory’nin daha fazlasını sanal makinalar için kullandırmaya izin vermektedir. Host üzerinde 64 gb memory olan bir senaryoda, 3 adet sanal makine için her sanal makinaya 24 gb memory atanabilmektedir. Böyle bir yapıda memory overcommit diye tabir edilen, atanan değerin üzerinde bir kullanıma sebep olacaktır. Bu yapılandırmanın başlıca sebebi, boşta memory olduğunda, diğer sanal makinaların boştaki memory kendisinin kullanabilmesidir. Sanal makinalarda tüm memory kullandığında ise ballooning diye tabir edilen, fiziksel memory fazlası kullanımı meydana gelecektir. Bu da memory hızlarında düşüşlere sebebiyet vermektedir.

Vmware balloning işlemini, sanal makine kurulumundan hemen sonra kurduğumuz Vmware Tools ile birlikte, Vmware Balloon Driver’ı kurmaktadır. Bu driver sahte bir memory kaynağı oluşturarak, sanal makinaya sunucu üzerinde, yeteri kadar memory varmış gibi göstermektedir. Sql Server proseslerinin hata almasındaki en büyük sebeplerden biri de memory ballooning yaşanmasıdır. Sql Server yapı itibari ile hızlı ve stabil çalışan memorylere ihtiyaç duymaktadır.

Vmware üzerinde çalışan Sql Server’ın önerilen konfigürasyonu özetle şu şekilde olmalıdır;

- Host’un sahip olduğu memory’den daha fazla memory Sql Server sunucusuna verilmemelidir.

- Host üzerinde birden çok sanal makine var ise, ve bu sanal makinalar için kullanılan memory değeri, host memory değerinden fazla olduğunda Sql Server sunucusu için memory reservation yapılmalıdır. Böylelikle Sql Server’ın kullanacağı memory ayrılmış olur, diğer sanal makinalar ile kaynak havuzundan memory’i paylaşmamış olur.

- Sql Server özelliklerinde Lock Pages in Memory seçeneği kullanılmalıdır. Bir ballooning durumunda memory baskısı en aza indirgenmiş olur.

- Sql Server’ın minimum ve maximum server memory değeri atanması halinde, buffer pool’u Sql Server yöneteceğinden bu ayar yapılmalıdır.

- Host üzerinde fiziksel iki işlemci bulunduğunda, Sql Server’ın bu işlemcileri kullanırken cross numa olarak kullanmaması için numa.vcpu.min değeri ayarlanmalıdır.

Vmware Performans İzleme

Sql Server yapılandırmasından sonra, Vmware üzerinde Sql Server’ın performansını izleyerek, Sql Server’ın host üzerindeki değerlerini gözlemleyebiliriz. İlk olarak SSH bağlantı ile Vmware’in konsoluna bağlanarak esxtop komutunu inceleyeceğiz.

Vmware konsoluna bağlanabilmemiz için Puttu programını aşağıdaki linkten indiriyoruz.

http://www.putty.org/

Putty programını açmadan, Vmware host üzerinde SSH servisinin çalışıyor olması gerekiyor, öncelikle bu servis nasıl açılır buna bakalım.

Host’un Configuration sekmesine geliyoruz, buradan Software – Security Profile bölümünü açıyoruz. Security Profile bölümünün sağ üst köşesinde bulunan Properties’e giriyoruz.

SSV-14

SSH’ın üzerine tıkladıktan sonra aşağıdaki Option bölümüne giriyoruz. Servisi start diyerek başlatıyoruz.

SSV-15

Bu ayarı tamamladıktan sonra indirdiğimiz Putty.exe programını açıyoruz. Putty programında, Host name kısmına Vmware hostun adı veya Ip adresini yazıyoruz. Connection type: SSH, Port: 22 varsayılan olarak gelmektedir.

SSV-16

Open ile SSH bağlantısını başlatıyoruz, karşımıza gelen komut satırında ilk olarak Login bilgisi sormakta, Esx hostumuzdaki kullanıcı adı ve şifreyi girerek hoşta login oluyoruz.

SSV-17

Komut satırına esxtop yazarak, Vmware’in host seviyesinde performans sayaçlarını görebilmekteyiz.

SSV-18

Bu ekranda, host üzerinde çalışan ve hypervisor işlemlerini de getirmektedir, biz sadece host üzerinde çalışan sanal makinalara bakacağımızdan SHIFT + V tuş kombinasyonuna tıklayarak, sanal makinaları ekrana getiriyoruz.

SSV-19

Esxtop değerlerini inceleyelim;

%RDY time– İşlemcinin aktif çalışma yüzdesini gösterir

%CSTP – Co-Scheduling olan işlemcilerin yüzdesel değerlerini gösterir, sanal makinalar arası işlemcilerin diğer sanal makinalar ile paylaştığı durumlarda buradaki yüzdesel değer artar.

%WAIT - %IDLE – Buradaki değerler yüksek olduğunda, CPU üzerindeki iş yüklerinin yoğun olmadığı anlamına gelir.

&MLMTD – Eğer burada bir değer yazıyor ise, sanal makine özelliklerinde CPU’ya limit verilmiştir demektir, verilen limit değerleri bu alanda çıkmaktadır.

Soru işaretine basarak ? diğer disk, memory gibi değerleri de görebiliriz.

SSV-20

Memory kullanımı

SSV-21

Klavye kısa yolları ile, d – m – c ye tıklayarak ekranlar arası geçiş yapılabilmektedir.

Sanallaştırmanın Getirdiği Kısıtlamalar

Sql Server’ın sanallaştırma üzerinde çalışmasında, performans açısından bazı sıkıntılar olduğunu makalenin başında bahsetmiştik. Bu sıkıntılar nelerdir, Sql Server’ı sanal sistemler üzerine kurduğumuzda ne gibi zorluklarla karşılaşırız bunlara bakalım.

Vmware ve Hyper-V’de sanal makinaların donanım özelliklerinde kısıtlamalar mevcuttur. Her yeni versiyonda bu değerler yükseltilsede, Sql Server iş yüklerinde belli bir limit getirmektedir. CPU ve memory atamalarında bu limitlerin dahilinde kalmak zorunda oluyoruz. Vmware Esx 6 ile bu limitler oldukça arttırılmıştır. VM başına 128 vCPU, 4 TB memory ve 62 TB disk kapasitesine izin vermektedir. Bu özelliklerden daha fazla donanım ihtiyacınız olduğunda sanallaştırma size uygun olmayacaktır.

Failover cluster yapısında, Vmware’deki shared disk ayarlarından dolayı IO sıkıntısı yaşanmaktadır. Raw Device Mappings sadece fiber channel desteği bulunduğundan farklı bağlantılar için destek verememektedir.

Vmware, storagelerde 1gb/s iSCSI kullanıldığından yoğun Sql Server iş yüklerinde dar boğaza sebebiyet verebilmektedir. Fiziksel sunucudaki direct-attached storage yapısı SAN’lere göre daha ucuz olduğundan tercih sebebi olabilmektedir.

Bu teknik kısıtlamaların yanı sıra, Vmware gibi kendine özgü bir yapısı olan bir sistemi yönetmek, sistem ekibine ekstra yük getirecektir, Windows sunucuları yönetmenin yanında sanal sistemleri de yönetmek için yetkin personele ihtiyaç duyulmaktadır. Sanallaştırma çok yaygınlaşmış olsa da, günümüzde halen birçok Sql Server fiziksel sunucularda çalıştığını unutmamak gerekir.

Bu makalede, Sql Server’ın sanal sistemlerdeki yapılandırılmasının nasıl olacağı, sanallaştırma yapılan Sql Server sunucularında yapılan yanlışlıkları anlatmaya çalıştım. Sıkça karşılaştığımız Sql Server’ın sanala geçişindeki performans kayıplarını minimize etmek açısından, Sql Server sunucularının sanallaştırmaya geçmeden önce kaynak planlamasının doğru bir şekilde yapılması gerekmektedir.

Zaman zaman Microsoft Power BI yazılarımız ve sunumlarımız oldu bu zaman içerisinde Microsoft Power BI raporlama ve analiz aracını sizlere sunarken Power BI nihai versiyonuna erişerek kullanıcıların erişimine tam olarak açıldı.

Bu yazımızda sizlere gerçek zamanlı raporlama ekranları oluşturabilmeniz için Microsoft tarafından sunulan örnekleri ve dosyaları paylaşacağım bundan sonraki yazılarımızda da bu dosyalar ile meşhur AdventureWorks veri tabanı, Azure veri dosyaları, web siteleri ve aklımıza gelebilecek her veri tipinde dosya, verileri Power BI içerisine alarak sizlere örneklemeler yapmaya ve etkileşimli rapor ekranları sunmaya çalışacağız.

Aşağıda vereceğimiz veri dosyaları endüstri içerisinde bulunan çapraz satışlar, bürüt kar marjları ve varyant dataları gibi çalışmalarınız esnasında sizlere yardımcı olabilecek örnek verileri içermektedir. Paylaşılan bu veriler anonim olarak sağlanmaktadır ve gerçek verileri www.obvience.comüzerinden elde edebilirsiniz.

Gerçek Zamanlı Analitik

Power BI’ın üstün özelliklerinden biri de gerçek zamanlı olarak interaktif raporlama ve analitik veri listeleme hizmeti sunmasıdır. Yukarıda belirttiğimiz örnek datalar üzerinden bir dashboard hazırladığımızda aşağıdaki gibi bir görünüme sahip olabiliriz.

Bu ekranda tamamen tüm satışları ve detayları görebileceğimiz gibi az önce bahsettiğimiz interaktif filtreleme özelliği ile de hızlıca aynı ekran üzerinde sadece süzülmüş verimizin grafiksel dökümüne ulaşabiliriz. Nasıl olduğuna isterseniz beraber bakalım.

1 – Ana ekran üzerinde bulunan “Total Stores” kutusu seçilir

Power BI tıklama sonrası bizi Mağaza Satış özetine götürecektir. Bu şekilde bir listeleme ile 104 mağazanın toplan 10 tanesini filtreleyebiliriz

2 – Otomatik olarak da doughnut chart üzerinde filtrelenmiş kayıtları görebiliriz .

Ayrıca bu grafiğe tıkladığınızda hemen buble chartta da interaktif olarak filtrelemeler devam edecektir

Sonuç olarak Microsoft Power BI size her türlü dataya erişim imkanı sağlarken interaktif gerçek zamanlı filtrelemeler ilede görsel açıdan sizlere daha efektif ve anlaşılır veri sunmayı hedeflemektedir.

Yukarıdaki örnekler ile alakalı örnek dataları https://powerbi.microsoft.com/en-us/documentation/powerbi-sample-tutorial-connect-to-the-samples/ adresinden elde edebilirsiniz.

Ayrıca tüm veri dosyalarını https://powerbi.microsoft.com/en-us/documentation/powerbi-sample-downloads/ adresinden ister tek tek isterseniz tümünü zipli şekilde indirebilirsiniz.

Microsoft Power BI üzerinde Dashboard’larımızı https://app.powerbi.comüzerinden oluşturmamız gerekmektedir. Power BI web arayüzüne girebilmemiz için Personel veya Kurumsal olarak lisanslama hizmetini almış olmamız gerekmektedir.

Dashboard oluşturmak üzere siteye girdiğimizde eğer sol navgasyon penceresini göremez iseniz bir kere Power BI logosu üzerine tıklamanız yeterli olacaktır.

Bu menüye neden gereksinim duymaktayız; bu menü üzerinde kısa yollarımız ve birden fazla Dashboard oluşturabilmemiz için aksiyon butonları yer aldığından öncelikli olarak bu menünün görünür olmasını sağlamamız gerekmektedir.

Hepberaber buradaki menüyü biraz inceleyerek daha sonrasında dashboard oluşturma işlemine geçelim isterseniz.

Yukarıdaki resimde görünen menüleri sırası ile tanıyallım,

1 – Favoriler : Favori olarak işaretlediğimiz raporlarımız yada dashboardlarımızın listelendiği menü öğesidir.

2 – Show All Content :

Power BI aynı kurum içerisinde birden fazla kullanıcı tarafından düzenlenebildiği gibi görüntülenebilirde. Power BI Desktop, Power BI Web arayüzünde yayınlamak üzere raporlar oluşturduğumuz bir yazılımdır. Show All cotent menüsü de tam burda aslında imdadımıza yetişmektedir.

Menüye bastığımız anda bize ekstra br menü açılarak aslen iki adet seçnek olmakla beraber tümünü göster seçeneği ile beraber 3 adet opsiyon gösterilmektedir.

Bu opsiyonlar My Content sadece sizin tarafınızdan oluşturulan içerik ve raporları göstermektedir. Shared With Me opsiyonu ise kurumunuzda PowerBI kullanan diğer analisist ve personeller tarafından oluşturulan ve sizinle paylaşıma açılmış olaran içerikleri görmenize izin verecektir.

Reports menüsü daha önceden oluşturmuş olduğumuz raporların listelendiği menüdür aynı şekilde Dataset menüsü her türlü verimizin sorgulanmış, düzenlenmiş şekillerinin Power BI içerisinde alınmış ve kullanıma hazır olan şeklidir. Datasetler düzenlenmemiş salt veri şeklinde de saklanabimektedir.

Buraya kadar Power BI web arayüzünün bize sağlamış olduğu ana menüleri tanıdıktan sonra Power BI ile beraber Dashboard oluşturma işlemlerine geçebiliriz.

Yeni bir dashboard elemek için menü üzerinde bulunan artı ( + ) işaretine tıklamamız ve hemen altında açılan kutucuğa da ismini yazmanız yeterlidir.

Dashbordunuz oluşur oluşmaz ana stage dediğimiz çalışmalarınızın listelendiği ekrana ulaşırsınız bu ekranda ise bazı kısa yollar ve içerik ekleyebilmek için araçlar bulunmaktadır. Bunlarada kısa bir göz atmamız faydalı olacaktır.

Add Title

Add Title ekranı dashboard ekranımıza web content, image ,text box ve video eklememiz için gerekli alt yapının Power BI web arayüzünden yapılmasını / eklenmesini sağlayan yardımcı butondur. Genel olarak görünümü aşağıdaki şekildedir. Unutmayalım bulut tabanlı sistemler devamlı gelişmekte olduğundan temel manada ekran yerleşimleri aynı kalabilir ama içeriklerinde iyyileştirme yada eksiltmelere gidilebilir. Şu andaki mevcut ekranımız aşağıdaki gibidir.

Title ekleme içeriklerine bir sonraki yazımızda devam edeceğimizden sadece gerekli olan içeriğin bu menüden eklenebileceği ile diğer butonlarıda tanımaya devam edelim.

Favori

Daha hızlı erişebilmek adına oluşturmuş olduğunuz ana ekranlarınızı favori olarak işaretleyebilirsiniz.

Share / Paylaşım

Bir çoğumuzun Office 365 üzerinden de aşina olacağı bir paylaşım modülünün benzeri Power BI Web arayüzünde de bulunmaktadır.

Bu ekran üzerinden istedğiniz e-posta adresine erişim verebildiğiniz gibi access sekmesinden de bu ana ekranı ( dashboard) direk link ile de paylaşabilirsiniz. Ayrıca paylaştığınız ana ekranı paylaştığınız kişiye mail olarak da bilgilendiren bir yapı söz konusudur.

Duplicate dashboard

Tek tıkla mevcut ayarlarını yapmış olduğunuz ana ekranınızın bir kopyasını oluşturmaya yarayan şiddetle tavsiye edilen bir araçtır. Kullanım amacı olarak ister şablon alma olarak kullanabilirsiniz isterseniz de değişiklik yapmadan önce son şeklini ikinci kopya olarak saklayabilmeniz için kullanabileceğiniz faydalı bir menüdür.

Ayrıca üst sağ menü altında ;

· Print Dashboard

· Refresh Dashboard Tiles

· Set as Featured Dashboard seçenekleri ile de kolay erişilebilirlik ve yenileme işlemlerini hızlıca yapabileceğimiz 3 adet menü daha bulunmaktadır.

Genel olarak Power BI Web arayüzünde dashboard oluşturma ve üzerinde yapabileceğimiz yönetimsel işlemler ile menü araçlarını kısaca sizlere aktarmaya çalıştım. Daha sonraki yazılarımızda bir önceki yazılarımızda anlattığımız veri desenleri ve Adventure Works verileri ile basit raporlar hazırlamaya ve Power BI işlemlerine ufak ufak derinlemesine girmeye devam edeceğiz.

Faydalı olması dileği ile.

SQL Server Microsoft tarafından satılan yazılım ürünleri arasında en pahalı olanıdır ve lisanslaması konusunda en az anlaşılan üründür. Lisanslamanın genel olarak zor olduğunu ve teknik adamlar için sıkıcı bir konu olduğunu söylemek de sanırım yanlış olmaz. Buna rağmen teknik adam ve sistem mimarlarının doğru SQL Server lisanslamasını bilmesi, projelerinde ve çalıştıkları kurumlara maddi anlamda yüksek fayda sağlayacaktır.

SQL Server, sıklıkla ağ üzerinde her ihtiyaç duyulduğunda kurulan ancak yazılım kaynakları yönetimi adına üzerinde fazla düşünülmeyen bir üründür. Microsoft telif hakları kuralları çerçevesinde yazılım kurulumlarınızı incelemek istediğinde de en fazla sürprizin yaşandığı üründür. Çünkü tek bir sunucunun on binlerce dolara mal olabildiği faturaların ortaya çıkması muhtemeldir. Bu tip durumlarla karşılaşmamanız için bu makalede sizlere SQL sunucu lisanslaması ile ilgili bilmeniz gerekenleri anlatıyor olacağım.

Sql Server sürümlerinden başlayarak, elinizdeki mevcut Sql Server’ın değil, olması gereken Sql Server kurulumu ve lisanslaması hakkında bilgiler aktarmaya çalışacağım. Makalede yazılanlar, bilgi amaçlı olup, kesin bilginin “Microsoft Volume Licensing Product Terms” içerisinde olduğunun altını çizmek gerekir. Bu makalede sizlere lisanslama modellerinin yanı sıra, örnek senaryolar ile Sql Server Lisanslaması hakkında bilgiler aktarmaya çalışacağım.

Sql Server Sürümleri:

Sql Server 2014’te 3 ana sürüm bulunmaktadır.

- Enterprise Edition: Kritik iş uygulamaları ve büyük data warehouse için gerekli özelliklere sahip sürümdür. En önemli ayırt edici özellikleri, In-Memory OLTP ve Always On’dur.

- Business Intelligence Edition: İş zekası uygulamaları için uygun olan sürümdür.

- Standart Edition: Temel veritabanı hizmetleri, raporlama ve analitik özelliklere sahip olan sürümdür.

Bu 3 sürüm arasında en kapsamlısı Enterprise Edition’dır. Business Intelligence Edition da Standart Edition’nın özelliklerini kapsamaktadır.

Diğer editionlar ise, Developer ve Express Editionlardır. Developer Edition, production ortamlarında kullanılmayan sadece test amaçlı yazılımcılara Msdn hesabı üzerinden dağıtılan sürümdür.

ÖNEMLİ: Desktop işletim sistemleri üzerinde SQL Server ile ilişkili deneme, uygulama testleri ve SQL Server yetenek testleri yapacaksanız, Developer edition kullanmalısınız. Bu sürüm Enterprise Edition ile aynı yeteneklere sahiptir fakat lisanslama açısından sadece test amaçlı sunulan bir sürümdür. Express ise 10 gb database boyut sınırı ve 1 gb memory kullanan küçük işletmeler için ücretsiz sunulan editiondır. Bu iki edition dışında satışı sadece hosting ve cloud firmalarına yapılan Web edition vardır.

Aşağıdaki tablo, 3 ana edition arasındaki özelliklerin farklarını bizlere göstermektedir:

SSL – 1

Sql Server Editionlarının kapasite limitleri de aşağıdaki tabloda gösterilmiştir.

SSL – 2

Kapasite limitasyonun detaylı hesaplaması için aşağıdaki linki ziyaret ediniz;

https://msdn.microsoft.com/en-us/library/ms143760(v=sql.130).aspx

Sql Server Lisansı Nasıl Satın Alınır?:

Sql Server lisansı satın almanın birden çok yöntemi vardır. Satın alma yöntemi dediğimiz, satış kanalınızdan talep edeceğiniz Full Packaged Product (FPP) satın alınması veya donanım ile birlikte önceden yüklenmiş bir şekilde Sql lisansı satın alınmasıdır.

Paket ve donanım seçeneklerinin dışında, Software Assurance (Yazılım Güvencesi) kapsamında farklı seçenekler bulunmaktadır. Bu seçenekler, Open Value, Open Value Subscription, Enterprise Agreement (EA), Enterprise Subscription Agreement (ESA) ve Server and Cloud Enrollment (SCE) seçenekleridir. Bu seçenekler Microsoft ile müşteri arasında yapılan anlaşmalara göre şekillenmektedir. Sql Server için temel olan FPP veya Open adı altında satın alınan lisanslardır.

Satın alma yöntemlerinlerde hangi seçeneklerin kullanıldığı aşağıdaki tabloda gösterilmiştir. Bu tablo Sql Server 2014 için hazırlanmış olup, diğer mevcut versiyonlar ve yeni çıkacak Sql Server 2016 için farklılık gösterebilir.

SSL – 3

Sql Server Lisanslama Modelleri:

Sql Server 2014 ile birlikte, Microsoft müşterilerine lisanslama modelleri için farklı seçenekler sunmuştur. Server+CAL lisanslama modeli, kullanıcı sayısı kadar User Cal lisansı alınarak daha az maliyetle Sql Server’ın lisanslamasını sağlamaktadır. Büyük yapılarda kullanıcı sayısı arttıkça User Cal lisanslaması yerine core-based tercih edilerek işlemci çekirdek sayısına göre lisanslama yapılmaktadır. Bu lisanslama modelinde kullanıcı sayısının limiti yoktur.

Lisanslama modelleri ile ilgili seçeneklerin sunulduğu özet tablo

SSL – 4

Tabloda ilk dikkatimizi çeken, Enterprise lisanslama da sadece Core-based seçeneği vardır. Hem core-based hem de Server+CAL olan tek edition Standart editiondır.

Core-Based Lisanslama:

Sql Server’ın çalıştığı server başına yapılan lisanslamadır. Fiziksel veya sanal ortamlarda kurulan Sql Server’lar için farklılık göstermektedir. Server+CAL lisanslama modeline göre, kullanıcı sayısı limiti yoktur. Kullanıcı sayısı arttığında, ilave CAL lisans almasını gerektirmeyen bir lisanslama modelidir.

Core-based modelinde, ihtiyaçlar doğrultusunda Sql core lisansı alınarak Sql Server’da büyüme gerçekleştirebilir. En fazla karışıklığın olduğu ve dolayısı ile en fazla hata yapılan lisanslama modelidir. Temel sebebi, fiziksel ve sanal ortamlarda core faktörün devreye girmesiyle hata yapılmaktadır.

Core-based lisanslamada, fiziksel server, fiziksel işlemci, fiziksel çekirdek (core), sanal işlemci ve Hyper-Thread kavramlarının iyi anlaşılması gerekmektedir. Lisanslama sırasında bu kavramlar çokça karıştırılmaktadırlar.

SSL – 5

Physical Server – Fiziksel sunucu üzerine Windows işletim sistemi direkt kurulabildiği gibi, hypervisor ile de sanal sistem üzerine de kurulmaktadır.

Physical Processor – Sunucu üzerinde bulunan fiziksel işlemci soketlerinden her birine verilen isimdir.

Physical Core – Fiziksel işlemcideki, fiziksel çekirdeklerin her birine verilen isimdir.

Virtaul Cpu vCpu – Sanal işlemci olarak geçer ve en çok karıştırılan kavramlardandır. Fiziksel çekirdeklerin sanal ortamdaki işlemci sayıları vCpu olarak tabir edilir.

Hyper-Thread – Fiziksel çekirdeklerin yazılım ile x2 çekirdek olarak artar.

Yukardaki kavramları anlattıktan sonra, fiziksel işletim sistemi üzerine kurulan Sql Server’ın lisanslamasından bahsedelim. Eğer Sql Server bir fiziksel işletim sistemi üzerine kuruldu ise, bu fiziksel sunucuda bulunan tüm fiziksel çekirdekler kadar lisanslanma gerekmektedir. Bir başka deyişle fiziksel sunucudaki fiziksel cpu’ların tüm fiziksel çekirdekleri toplanarak, toplam alınacak Core-based lisans sayısı ortaya çıkar. Sanal sistemler ile fiziksel sistemlerin lisanslamasının en büyük farkı budur.

Core-based lisanslar ikili paketler halinde satılır ve fiziksel cpu başına en az 4 tane alınması gerekmektedir. Toplam alınacak lisans sayısı ikiye bölünerek hesaplaması yapılır. Fiziksel sunucunuzda iki adet fiziksel cpu’nuz olduğunda bu fiziksel cpu’ların da en az 4 fiziksel çekirdeğe sahip olması gerekmektedir. Burada en çok yapılan hata, iki adet fiziksel cpu bulunan bir sunucuya 3 paket x 2 = 6 yani 6 adet core lisans alınmasıdır. Hâlbuki 4 paket x 2 = 8 yani toplamda 4 core pack alınması gerekmektedir.

Yukardaki şekil SSL – 5’e göre nasıl bir lisans almalıyız bunu hesaplayalım. 2 adet Intel Xeon işlemcimiz ve bu işlemcilerin her birinde 6 fiziksel çekirdeğimiz var. Sunucuda toplam 12 fiziksel çekirdek var ve fiziksel sisteme olan kurulu Sql Server’lar için core factor 1’dir. 12 fiziksel core x 1 (core factor) = 12 core lisansa ihtiyaç vardır. Lisanslar 2’li paketler halinde satıldığı için 6 x 2 core pack yani 6 core pack satın alınması gerekmektedir.

Cpu Core factor tablosu aşağıdaki gibidir, Amd işlemcilerde 0,75 katsayısına sahiptir.

SSL – 6

Per Core lisanslama ile ilgili detaylı pdf’i aşağıdaki linkten indirebilirsiniz

https://www.microsoft.com/en-us/licensing/learn-more/brief-licensing-by-cores.aspx

Per Core lisanslama modelinin uygun olduğu koşullar şu şekildedir;

- Sql Server 2014 Enterprise, Sql Server 2012 Parallel Data Warehouse veya Sql Server 2014 Web editionlarından birinin yüklü olması gereklidir.

- Sql Server’ı kullanan kullanıcıların ve clientların kolayca sayılamadığı sistemler için uygundur.

- Server+CAL lisanslama maliyetinin daha yüksek çıktığı durumlarda Per Core lisanslaması kullanılmalıdır.

Önemli not: Fiziksel sistemlere kurulan Sql Server’larda hyper-threading teknolojisinin getirdiği core sayıları dikkate alınmamaktadır. Örnekteki 6 core fiziksel işlemcinin HT özelliği açık olduğunda, işletim sistemi bunu 12 core olarak görmektedir, fakat fiziksel Per Core lisanslamada fiziksel çekirdek sayısı ne ise ona göre lisanslanır ve HT özelliğinden gelen core sayıları dikkate alınmaz.

Server+CAL Lisanslama:

Sql Server yazılımının, sunucu başına ve kullanıcı erişimi başına lisanlandığı modeldir. Client access license dediğimiz CAL lisansı bir yazılım değildir. Kullanıcıların veya cihazların Sql Server’e erişmek için kullandıkları lisanslama modelidir. CAL lisanslaması Device CAL ve User CAL olarak ikiye ayrılmaktadır.

SSL – 7

Bu lisanslama tipinde, hem Sql Server tarafı hem de kullanıcı tarafı lisanslanmaktadır. Sql Server bir adet, kullanıcı tarafı ise kullanıcı sayısına göre lisanslanmaktadır. Çok fazla kullanıcı ve cihaz sayısına sahip firmalar için bu lisanslamanın maliyeti daha fazla olacağından core-based lisanslama önerilmektedir.

Her fiziksel sunucu için bir adet Sql Server lisansı alınması gereken bu modelde, blade sunucular için durum farklıdır. Aynı şase üzerinde olan her bir blade sunucu ortak kaynak kullansa bile her bir sunucu için ayrı ayrı Sql Server lisansı alınması gerekmektedir.

Sql Server’a erişen her kullanıcının Sql Server versiyonu ile aynı lisansı veya daha yeni versiyonu alması gerekmektedir. Örneğin, Sql Server 2014 için Sql Server 2012 CAL lisansı kullanılamaz ve Sql Server 2014 CAL lisansı alınması gerekmektedir.

Server+CAL lisanslama modeli, Sql Server Business Intelligence Edition ve Sql Server Standart Edition’larda geçerli olan lisanslama modelidir. Enterprise Edition sunucuların Server+CAL lisanslama modeli içerisinde kullanılması için Volume Licensing anlaşmasındaki downgrade hakkı ile önceki versiyonlara downgrade yapılarak kullanılabilmektedir.

Sanal Ortamlarda Sql Server Lisanslaması:

Sanal ortamlardaki Sql Server lisanslaması en çok karıştırılan konulardan biridir. Sql Server lisanslaması sanal ortamlarda esneklik getirmiştir. Fiziksel sunularda fiziksel çekirdek sayılarına müdahale edilemediği için, Sql Server lisanslamasında ne kadar fiziksel çekirdek var ise o kadar lisanslanmaktaydı. Sanal ortamlarda ise fiziksel çekirdeklerin yerini sanal çekirdekler aldığından, sanal makinaların çekirdek sayıları istek doğrultusunda değiştirelebilmektedir. Bu esneklik Sql Server lisanslamasınıda daha kolay bir hale getirmiştir.

Aşağıdaki örnekte, 2 sanal çekirdekten oluşan 2 farklı işletimi sistemi üzerine kurulmuş, 2 farklı Sql Server bulunmaktadır.

SSL – 8

Sanal makinaların lisanslamasında en az 4 çekirdek ve her bir sanal çekirdeğin toplam lisans adedine eklenmelidir. Aşağıdaki örnekte 2, 4 ve 6 sanal çekirdek olan Sql Server’ların lisansları bulunmaktadır.

SSL – 9

Yukardaki örnekte dikkat çeken nokta, VM 1 de 2 sanal çekirdek olmasına rağmen 4 çekirdek lisanslamasının yapılması gerekmektedir.

Sanal ortamlarda Hyper-Threading özelliği kapalı ise lisanslama, her bir sanal çekirdeğin toplamı üzerinden yapılır. Hyper-Threading özelliği açık ise bir fiziksel çekirdek, sanal ortamda 2 sanal çekirdek olarak gözükecektir. Böyle bir durumda sanal çekirdek sayısına değil, fiziksel çekirdek sayısının toplamına bakılır ve Hyper-Threading özelliğinden gelen sanal çekirdekler lisanslamada yarıya bölünerek hesaplanır.

Sanal ortamlar için, maksimum kapasitede çalışacak bir sunucu için örnek bir senaryo üzerinden gidelim. Bir fiziksel sunucumuz var ve bu fiziksel sunucumuza 6 tane Sql Server kuracağız. Sunucumuzun özellikleri, çift soket Cpu, her bir fiziksel Cpu’da 6 adet fiziksel çekirdek olsun. Toplamda 12 adet fiziksel çekirdek Sql Server 2014 Enterprise core-based lisansına ilave olarak Software Assurance yapıldığında, bu host üzerine sınırsız sayıda sanal makina ve Sql Server kurulabilmektedir. Sanal makialarda Hyper-Threading özelliği açılarak, istenilen miktarda sanal çekirdek kullanılabilir. Software Assurance anlaşması bitine kadar bu şekilde kullanılabilmektedir ve lisansların geçerli olması için tekrardan SA anlaşması yapılması gerekmektedir.

SSL – 10

High Availability Sql Server’larda Lisanslama:

Sql Server sunucusu bir sorun yaşayıp erişelemez olduğu durumlarda, diğer replika denen Sql Server suncusunun devreye girdiği senaryoların geneline High Availability denmektedir. HA yapısında, mirroring, log shipping faiolver clustering ve Always On seçenekleri bulunmaktadır. Bu yapıda en az iki Sql Server sunucu bulunduğundan, lisanslama maliyeti de en az iki katına çıkmaktadır.

Failover yapılarında genel olarak bilinmesi gereken her iki Sql Server’ın da Software Assurance kapsamında lisanslanmasının gerekliliğidir. Ancak, ikinci sunucu pasif modda ve bu sunucuya clientlar erişemiyor ise, ikinci sunucu için Sql lisansına gerek yoktur. Replike olan sunucu sadece failover durumunda devereye alınmak üzere olan bir sunucu olarak pasif modda çalışmaktadır. Burada dikkat edilmesi gereken Always On yapısında, replike sunucunun readable olmaması gerekmektedir. Always On kurulu olan yapılarda, genellikle replike sunucular raporlama için kullanılmaktadır. Bu gibi durumlarda replike sunucu primary sunucu gibi lisanslanmak durumundadır. Replike olan pasif sunucudan yedekleme de yapılmamalıdır. Eğer pasif moddaki Sql Server’dan yedekleme yapılırsa, bu sunucunun da lisanslaması gerekmektedir.

SSL – 11

Pasif sunucu eğer cloud da ise, pasif mod da olsa dahi SSL – 11 deki örneğe göre 12 core lisanslaması gerekmektedir.

Pasif mod daki Sql Server’ın lisansa ihtiyaç duymaması, sadece 1 adet ile sınırlıdır. İkinci replike Sql Server olan bir yapıda, 1. Replike sunucu lisansdan muhaf olur, fakar 2. Replike sunucu core saıyısı kadar lisanslanmalıdır. İkinci olan replike sunucu pasif dahi olsa Software Assurance kapsamına girmediği için lisanslanması gerekmektedir. Bu yapıda 1 adet primary, 2 adet de secondary Sql Server bulunmaktadır.

SSL – 12

Pasif sunucu devreye girdiğinde, aktif sunucudaki Sql lisansları Software Assurance’de bulunan Licence Mobility özelliği ile pasif sunucuya geçmiş olur. Yani, pasif sunucu devreye girdi diye yeni lisans almaya gerek yoktur.

AlwaysOn Availibility grupları için Sql Server Enterprise lisansı gerekmektedir. Sekiz Sql Server’a kadar desteği olan AlwaysOn gruplarında, iki sunucu senkron yapıda çalışmaktadır (Sql Server 2016’da senkron çalışan sunucu sayısı 3’e çıkartılmıştır). Secondary sunucular, primary sunucunun yükünü hafifletmek için, raporlamada ve yedeklemede kullanılmaktadır. Bu sebeple AlwaysOn gruplarındaki secondary sunucular readable olduğunda, lisanslanması gerekmektedir.