SQL SERVER CANNOT CONNECT TO VMI PROVIDER HATASI

SQL Server 2017 kurulumundan sonra Configuration Manager’I açmaya çalışırken aşağıdaki gibi bir hata ile karşılaştığınız taktirde problem çözmek için neler yapmanız gerektiğine değineceğiz;

VMI nedir sorusunda kısaca “WMI (Windows Management Instrumentation); Windows işletim sistemlerinde hemen hemen her nesnenin kontrol edilebilmesini sağlayan, işletim sistemindeki operasyonları ve yönetim işlevlerini gerçekleştirebilen bir teknolojidir.” Diyebiliriz.

Peki bu VMI bağlantısı ya da izni neyse durumunu nasıl halledebiliriz.

Öncelikle C:\Program Files (x86)\Microsoft SQL Server\140\Shared adresi altında bulunan sqlmgmproviderxpsp2up.mof dosyasını bulun. Ardından CMD’yi yönetici olarak çalıştırın. Ve komut satırından dosyanın bulunduğu Shared kalsörüne kadar giriş yapın.

Giriş yaptıktan sonra komut satırına “mofcomp sqlmgmproviderxpsp2up.mof” yazıp Enter’a basın.

Işlemler sona erdiğinde artık SQL Server Configuration Manager’a erişim sağlayabilirsiniz.

 

SQL SERVER’DA SİSTEM VERİTABANLARININ FARKLI KLASÖRE TAŞINMASI

SQL Server’da çok tercih ya da gerek duyulan bir işlem olmasa da herhangi bir durumda sistem veritabanların taşınması istenebilir. Kullanıcı veritabanları backup-restore, copy database, attach/deattach, veri tabanının scriptini çıkarma yollarıyla farklı alanlara taşınabilirken sistem veritabanları için böyle bir şansımız yoktur maalesef ve SQL Server Management Studio’da kesinti yapmadan bu işlemi gerçekleştirme durumumuz da yoktur. Bu nedenle böyle bir işlem gerekliliği durumunda kesintinin en az kayba sebep olacağı bir zaman dilimini seçmeniz en iyisi olur.

Model, msdb ve tempdb aynı yöntemle taşınabilirken Master veritabanının taşınma yöntemi farklıdır. Öncelikle Model, msdb ve tempdb taşıma biçimini ele alalım;

Kurulum esnasında mdf ve ldf dosyalarımız standart bir adreste tutulsa da güncel adresi bulmak için aşağıdaki kodu çalıştırabiliriz;

SELECT name, physical_name  FROM sys.master_files

 

WHERE database_id = DB_ID(N’model’);

Böylece veritabanımızın .mdf ve .ldf dosyalarının nerede ve hangi isimle tutulduğunu öğrenmiş olduk.

Bir soranki adımımızda sistem veritabanlarımızı taşıyacağımız klasörü belirten scripti çalıştırıyoruz;

Burada her dosya için bu işlemi yapmanız gerekir taşımak istediğiniz tüm veritabanlarının .mdf ve .ldf dosyalarını belirtmeniz gerekmektedir. Biz örnek amaçlı sadece Model very tabanı için işlem yapacağız.

 
USE master;

 

GO

 

ALTER DATABASE model

 

MODIFY FILE (NAME = modeldev, FILENAME = ‘C:\Taşıma Klasörü\model.mdf’);

 

GO

 

ALTER DATABASE model

 

MODIFY FILE (NAME = modellog, FILENAME = ‘C:\Taşıma Klasörü\modellog.ldf’);

 

GO

Ek olarak; dosyaları taşıdığınız yeni klasöre SQL Server’ın erişim yetkisi olup olmadığını da kontrol etmenizde fayda var bunun için klasöre sağ tıklayıp özelliklerden Security kısmında Edit diyip ardından Add diyerek erişim izni işlemini yapabilirsiniz.

 

Aşağıda dosyalarımızın bulunduğu güncel adresi tekrar kontrol ettik.

Çalıştırdığımız kod ile sistem veri tabanı dosyalarımızın yeni adresini belirttikten sonra SQL Server Configuration Manager’den SQL server servisimizi Stop ediyoruz.

Dosyaları yeni bölüme taşımadan SQL Server’I açmaya çalıştığımızda aşağıdaki hata ile karşılaşırız. Taşıdığınız halde böyle bir sorun ile karşılaşıyorsanız SQL Server erişim yetkisini tekrar kontrol edip tam yetki verip vermediğinize göz atın.

Bir sonraki adım olarak taşımak istediğimiz modeldev.mdf ve modellog.ldf dosyalarını belirttiğimiz klasörümüze taşıyoruz. Burada dosyaları kesip yapıştırmak yerine kopyalayıp yapıştırmanızı öneririm her ihtimale karşı herhangi bir problemde dosyalarda bir sorun yaşamamak için.

Dosyaları klasöre taşıdıktan sonra SQL Server servisimizi tekrar Start diyip çalıştırıyoruz. Böylece model veri tabanımızın yeni adresini SQL Server’da konfigüre etmiş olduk.

 

Şimdi sıra Master veritabanımızı taşıma işleminde geldi

 

Bunun için SQL Server Configuration Manager’a giriyoruz ardından servisler kısmında SQL Server(MSSQLSERVER)’a sağ tıklayıp Properties’e giriyoruz buradan da Startup Parameters bölümüne tıklıyoruz.

Burada master veritabanının .mdf ve .ldf dosyalarının olduğu adres bulunuyor –e ile başlayan kısım ise SQL Server’ın ERRORLOG’larının bulunduğu dosya olduğu için onunla ilgili bir işlemde bulunmuyoruz.

Master veritabanının da dosyalarını model veritabanıyla aynı yere taşımak istiyorum bu nedenle Update bölümünde .mdf dosyası için adresi aşağıdaki gibi değiştiriyorum ve Update butonuna basıp güncellemeyi gerçekleştiriyorum;

-dC:\Taşıma Klasörü\master.mdf

Aynı işlemi .ldf dosyası için de uyguluyorum;

-lC:\Taşıma Klasörü\mastlog.ldf

.ldf için de Update dedikten sonra bu ekranda OK diyor ve ardından SQL Server servisimizi STOP duruma getiriyoruz.

Servisi durduktan sonra master.mdf ve masterlog.ldf dosyalarımızı belirtmiş olduğumuz C:\Taşıma Klasörü adresine taşıyoruz burada da Copy – Paste yapalım ve işlem bittikten sonra Servisimizi START diyip tekrar açalım.

Master veritabanı için dosya adreslerini sorguladığımızda aşağıdaki sonuçla işlemlerimizin sorunsuz tamamlandığını görebiliriz.

SQL SERVER JOB-SCHEDULE VE DB MAİL OLUŞTURMA

 

SQL serverda belirlediğimiz kriterler çerçevesinde otomatize etmek istediğimiz ya da belli tarihte tek seferlik de olsa çalışmasını istediğimi işlemler için JOB oluştururuz. Job’lar ile sql serverda diğer Jobları durdurmak ya da çalıştırmaya kadar istediğiniz çoğu işlemi gerçekleştirebilirsiniz. Biz de bu yazımızda Job oluşturmayı ve Job’ın Schedule, Alert özelliklerini ve  Database Mail konfigürasyonlarını anlatmaya çalışacağız.

 

JOB OLUŞTURMA

SQL serverda Joblar Agent altında çalıştığı için Job oluşturmak ya da oluşturmuş olduğumuz Joblarımızın çalışması için Agent servisinin çalışıyor olması gerekmektedir. Agent altında Jobs sekmesine sağ tıklayıp New Job dediğimiz zaman karşımıza aşağıdaki gibi bir Job olujşturma ekranı gelecektir

 

Bu ekranda yapmamız gereken öncelikle oluşturacağımız Job’a bir isim vermek, verdiğiniz isimlerin yapacağınız işi tanımlar bir başlıkta olması daha sonar Job ile ilgili bir durumda size yardımcı olacaktır.

Bir altındaki bölümde bu Job’ın sahibini seçiyoruz burada da eğer devamlı çalışacak bir Job oluşturuyorsanız ve önemliyse Owner’ın bir local user olması ya da en azından kolay kolay Disable etme gereği duyulmayacak bir user olması daha iyi olacaktır çünkü oluşturduğunuz Jobın Ownerı Disable olduğunda ya da silindiğinde ilgili Job artık çalışmayacaktır ta ki siz yeni bir Owner tanımlayana kadar. Bir sonraki bölümde Jobın dahil olduğu kategoriyi seçiyoruz ben genelde herhangi bir kategoriye dahil olmayan local amaçlı bir job oluşturuyorum siz ihtiyaçlarınıza göre farklı tercihlerde bulunabilirsiniz, Description kısmında da dilerseniz oluşturduğunuz Jobın neler yaptığına dair bilgiler ekleyebilirsiniz ki daha sonra siz ya da sizden sonra gelecek kişiler bu Jobların ne işe yaradığını daha rahat anlayabilsin.

Step bölümünde ise aşağıda bulunan New butonuna tıkladığınızda karşınıza yukarıdaki ekran gelecektir. New Step ekranında da öncelikle bizden bir Step ismi istenmektedir. Tek Job içinde birden fazla Step oluşturacaksak burada Step isimlerini de anlaşılır bir şey olarak belirlemek faydalı olacaktır. Type kısmında ne tür bir kod çalıştırma seçeneği istediğimizi sorar burada PoweShell gibi Cmd gibi seçenekler de bulunmaktadır, ihtiyacınıza göre seçme şansınız bulunmaktadır. Biz Tsql kısmını kullanacağız. Run As seçeneğinin Tsql için bir gerekliliği yok o yüzden Disable durumda görünüyor. Database kısmında da oluşturacağımız Stepteki işlemlerin hangi database’I baz alarak çalışacağını belirtiyoruz default olarak master db seçilidir. Command bölümünde de çalıştırılmasını istediğimiz kod bloğunu yazıyoruz.

Advenced kısmında bize bazı ekstra seçenekler sunuuyor On success action kısmında Step bittiği taktirde yapılacak işlemi belirliyoruz default olarak Go to next step bulunuyor eğer başka stepler varsa sıradaki Step’I çalıştırıyor, başka step olmadığı taktirde herhangi bir hata vermez. Retry Attempts: kısmında Step hata aldığı taktirde kaç kez tekrar çalıştırmayı denesin istiyorsak onu belirtiyoruz, Retry interval kısmında da her çalıştırma arasında kaç dakika olmasını istediğimizi belirtiyoruz buna göre 4’e 5 yaparsak Step ilk hatayı aldıktan 5 dakika sonra tekrar çalışacak ve tekrar hata alması durumunda maksimum 4 defa çalıştırmayı tekrar edecektir.

On failure action: kısmında da step hata aldıktan sonra ne yapsın sorusuna cevap veriyoruz ve hata raporu oluşturmasını belirtiyoruz. Output File kısmında oluşturulacak raporların nerede depolanmasını istediğimizi belirtiyoruz diskte herhangi bir alanda seçebiliriz. Sonraki seçeneklerde çıktının bir tabloya eklenmesi ya da historye eklenmesini isteyebiliriz.

Bir sonraki adım olan Schedule kısmında oluşturacağımız Jobın hangi durumlarda hangi tarihlerde ne zaman başlayıp ne zamana kadar çalışacağı gibi seçenekleri belirliyoruz. Schedule kısmında New butonuna tıkladığınzıda karşınıza aşağıdaki gibi bir ekran gelir;

Burada da öncelikle her adımda istediği gibi bizden schedule için bir isim belirlememizi istiyor. Schedule Type kısmında birkaç farklı seçenek var bunlardan en çok kullanılan Recurring’tir ve bu tarih bazlı yinelenmesini belirtir.  Start automatically when SQL Server Agent starts seçeneğinde Jobın sadece SQL server Agent servisi her Start edildiğinide ya da Restart edildiğinde çalışmasını sağlar. Start whener the CPUs become idle seçeneğinde CPU’da yeteri kadar boş yer bulduğu taktirde çalıştırılması sağlanır. Buradaki CPU’nun ne kadar olacağını kendimiz belirleyebiliyoruz bunun için ilgili Instance’ımızın altındaki Agent’a sağ tıklayıp Properties sekmesine giriyoruz ve Advenced kısmına İdle CPU condition kısmında CPU yüzde kaç boş olduğu ve bu yüzdenin ne kadar süre devam ettiği taktirde CPU odaklı işlemlerin çalışması gerektiğini belirtebiliyoruz. One time kısmında da tek bir tarihte saat dakika ve saniyeye kadar belirlediğimiz bir anda 1 seferliğe mahsus çalışmasını sağlayabiliriz. Başta da belirttimiz giib genelde Recurring seçeneği seçilidir çünkü genelde devamlı çalışacak Joblar oluştururuz tabi istisnalar için diğer seçenekler de bulunmaktadır.

Frequency  bölümünde occurs kısmında oluşturacağımız Jobın Günlük-Haftalık ya da Aylık çalışacağını belirtiyor Recurs every kısmında kaç günde bir çalışacağını seçiyoruz 1 olduğunda hergün çalışacaktır bu Job, Haftalık seçenekte haftanın hangi günlerinde kaç haftada bir çalışmasını istersek ona göre belirtiyoruz. Aylık seçenekte ise her ayın  kaçıncı gününde, kaç ayda bir ya da her ayın kaçıncı haftasında gibi seçenekler belirleyebiliyoruz. Daily frequency kısmında Occurs once at seçeneğinde belirttiğimiz günlerde 1 defaya mahsus çalışacaktır. Occurs every kısmında ise gün içinde kaç saat-dakika ya da saniyede bir çalışmasını istiyorsak ona göre belirleyebilir başlangıç ve bitiş saatlerini de ekleyebiliriz. Bu arada en sık 10 saniyede bir çalıştırabilirsiniz 1 Jobı, daha kısa aralığa SQL server izin vermiyor.

Duration  başlangıç tarihi olarak Job oluşturduğumuz tarih bulunur istersek bunu değiştirebilir ek olarak bitmesini istediğimiz yani Jobın artık çalışmayacağı sınır tarihi de belirtebiliriz. Description bölümünde de belirttiğimiz seçeneklerin tam planını açıklıyor.

 

Alert sekmesinde Jobla ilgili bildirimleri almak istediğimizde takip edeceği işlemleri belirliyoruz. Biz burada bize mail göndermesini isteyeceğiz. Add butonuna tıkladığımızda karşımızda yukarıdaki gibi bir ekran çıkar. Burada da yine öncelikle Alert için bir isim belirlememizi istiyor. Sonraki adımda bunun bir alarm çalışması olduğunu belirtiyoruz. Database name kısmında hangi database için sonuçları alarm olarak göndermek istediğimizi belirtiyoruz. Error number alanına istersek kendimizce anlayacağımız bir hata numarası verebiliriz yada istersek Severity kısmında SQL serverda var olan 25 adet hata mesajından birini seçebiliriz.

Options kısmında ise alarmın bize mail olarak gelmesini ve iletilmesini istediğimiz mesajı ekliyoruz.  Delay between responses alanında kaç dakika veya saniyede bir mailin tekrar gönderilmesi gerektiğini belirtiyoruz, bu durum hata devam ettiği süre içinde geçerli olacaktır.

 

Notifications kımsında 3 sonuçta neler olmasını istediğimizi belirtiyoruz ve biz burada eğer Jobımız hata ile sonuçlanırsa bize mail atılmasını istiyoruz, E-mail bölümünde bizim oluşturduğumuz Database E-Mail konfigüsaryonundaki mailler bulunur biz henüz bir mail grubu oluşturmadığımız için bir seçenek yok birazdan bu konuya da değineceğiz. Diğer seçeneklerde Job olumlu sonuçlandığında ya da hata aldığında veya çalışması tamamlandığında Job silinsin mi ya da sonuç Windows event loglarına eklensin mi tarzı seçeneklere karar verebiliriz. OK dedikten ve Jobımızı oluşturduktan sonra Manual olarak çalıştırıp kontrol etmek istiyorsak oluşturduğumuz Job üstüne sağ tıklayıp Start job at step dememiz yeterli karşımıza çıkan küçük bilgi ekranı Jobımızın çalışmaya başladığını, sonuçlandığını ve bu sonuçlanmanın pozitif ya da negatif sonlandığını gösterir istersek bunu Close’a tıklayarak kapatabiliriz bu Job’ımızın durmasına sebep olmaz sadece o bilgi ekranını kapatır. Job’larımızın çalışma durumlarını kontrol etmek için Job Activity Monitor’ü kullanabiliriz burada çalışma durumunu, son çalışma tarihini ve bir sonraki çalışma tarihi ve daha fazlası gibi bilgileri öğrenebiliriz. Özel olarak bir Job’ın loglarını kontrol etmek istiyorsak da ilgili Job’a sağ tıklayıp View History dememiz yeterli.

Şimdi konusu geçmişken son olarak ele alacağımız Db mail konfigürasyonuna bir göz atalım:

 

 

 

DATABASE MAİL OLUŞTURMA

İlk önce isterseniz SQL konfigürasyonlarından Database Mail konfigürasyonunu Enable duruma getirelim bunun için New Query diyip yeni bir çalışma ekranı başlattıktan sonra SP_CONFIGURE prosedürünü çalıştıralım burada listelenen konfigürasyonlar tam liste olmadığı için önce

sp_configure ‘show advanced options’, 1

GO

reconfigure

GO

Prosedürünü çalıştırıp tüm seçeneklerin listelenmesini istiyoruz, ardından istediğimi değişikliği yapmak için

sp_configure ‘Database Mail XPs’,1

go

reconfigure

go

prosedürünü çalıştırıyoruz burada yaptığımız değişiklik default değeri “0” olan ve Disable  durumda olan özellikleri “1” olarak değiştirip Enable duruma getirmek oldu.

Sql serverda mail oluşturma işlemi Agent servisine ait olmadığı için Agent altında değil Instance altındaki Management sekmesinde bulunur. Database Mail’e sağ tıklayıp Configure Database Mail seçeneğini tıkladığımızda karşımıza gelen ekran bilgi ekranı olduğu için Next diyip ikinci ekrana geçiyoruz ve aşağıdaki gibi bir ekranla karşılaşıyoruz.

Burada bize yeni bir mail konfigürasyonu yapmak istediğimiz, var olan accaount ya da profilleri yönetmek istediğimiz veya tüm konfigürasyonları görmek istediğimize dair hangisini yapmak istediğimizi seçeceğimiz ekran bulunuyor ve biz yeni bir konfigürasyon yapacağımızı belirtip Next diyoruz. Next dedikten sonra Database Mail özelliğini aktif etmek isteyip istemediğimizi soruyor ve biz Ok diyip devam ediyoruz.

 

Sonraki ekranda gelen pencerede bir profil oluşturuyoruz bunun için Profil Name belirttikten sonra bir SMTP Account oluşturacağız ve Add dedikten sonra yukarıdaki ekranla karşılaşıyoruz. İlk olarak oluşturacağımız Account’a bir isim veriyoruz ve dilersek altına da bir açıklama ekliyoruz.

E-Mail Adress: bölümüne yazacağımız E-mail adresimiz SQL  Serverın kullanacağı kaynak mail adresimiz olacak yani göndereceği Mailleri bu hesabı kullanarak mail gönderecek. E-mail adres bölümünü doldurduktan sonra Display name kısmına Profilinizin görünecek ismini belirtiyoruz ve sonraki adımda E-mail adresimizi tekrar giriyoruz. Server name bölümüne smtp.gmail.com yazıyoruz bu bizim belirttiğimiz mail adresimizin gmail olmasından kaynaklı fakat Hotmail/MSN Live/Outlook.com hesaplarından birini kullanacaksanız smtp.gmail.com yerine smtp.live.com yazmanız gerekecektir. Port numarası olarak defaultta 25 gelir fakat bu çoğu mail grubunda engellemelere takılır çünkü dışardan gelen bağlantılara mail adresleri genelde zararlı saldırı tepkisi verir ve 25 portu bu durumda yetersiz kalır bunun için 465 ve 587 portları kullanılabilir en iyi sonuç veren port 587 portu oldu benim için. 587 ve 465 portları genelde SSl istedikleri için alttaki checbox’I onaylayıp SMTP Authentication kısmında ise Basic authentication seçeneğini seçiyoruz ve buraya yukarıda kaynak mail olarak hangi mail adresimizi belirttiysek o mail adresimizi yazıp password alanlarına da o mail adresimizin şifresini giriyoruz. Buradaki düzenlemelerimiz bittikten sonra OK diyip mail adresimizin eklendiğini gördükten sonra Next diyoruz.

Yukarıdaki ekranda bize daha önce eklemiş olduğumuz ve eklemekte olduğumuz tüm mail adreslerini listeler burada üzerinde düzenleme yaptığımız mail adresimizi seçiyoruz ve Default profile kısmında eğer bu mail adresimizin varsayılan adres olarak kullanılmasını istiyorsak No durumdan Yes duruma geçiriyor ve Next diyoruz. Bir sonraki ekran bize maillerimiz hakkında kaç defa gönderilmesi her gönderim arasında ne kadar süre olması ve mailimizin maksimum boyutunun kaç olmasını istediğimize dair seçenekler sunar default durumda gelen seçenekler işinizi göreceği için değişiklik yapmadan Next diyebilir dilerseniz size uygun olabilecek değişiklikler de yapabilirsiniz. Next dedikten sonra son bir bilgi ekranı gelir burada Finish diyip kurulumu başlatıyoruz. Kurulumun tüm adımları Success olduğu durumda konfigürasyonumuz tamamlanmış demek ve artık Close seçeneğine tıklayıp mail gönderme işlemimizi gerçekleştirebiliriz.

Test ekmek için tekrar Management altında bulunan Database Mail bölümüne sağ tıklayıp Send Test E-mail… seçeneğini tıklıyoruz

Database mail profil kısmında kullanmak istedğimiz profili seçiyoruz To bölümünde de maili hangi hesaba göndermek istiyorsak o mail adresini yazıyoruz Subject kısmı mailin başlığı ve Body de mail içeriği olacaktır. To: bölümünü doldurduktan sonra Send Test E-mail’e tıklayıp maili gönderebiliriz. Bazı durumlarda tüm bu düzenlemeleri yapsanız dahi mailleriniz gönderilmiyor olabilir ben bununle bir kez karşılaştığım için işe yaradığını gördüğüm tek çözüm yolunu belirtmek isterim. Mail adresimiz bu erişimi güvenli bulmadığı için belirttiğimiz portlara rağmen yinede erişimi engelliyor olabilir bu yüzden kaynak mail olarak belirttiğimiz adresimizde ufak ama önemli bir değişiklik yapmamız gerekir. Bunun için Mail adresimizden Google Hesabı bölümüne girip Güvenlik bölümü altında bulunan Daha Az Güvenli Uygulama Erişimi seçeneğini Açık hale getirmemiz gerekbilir bu önerilmeyen bir durum olsa da ihtiyacınız olma durumunda kullanabilirsiniz.

 

 

SQL SERVER LOGIN-USER OLUŞTURMA VE YETKİLENDİRME

Merhaba arkadaşlar SQL serverda olmazsa olmazlar listesi oluşturacaksak listenin de olmazsa olmazlarından biri Login kavramıdır. Login ve User oluşturma ve yetkilendirme konusuna geçmeden önce Login ve User arasında nasıl bir fark olduğuna bakalım isterseniz. Kısa cümlesi; Login Instance bazlı User ise Database bazlı kullanıcı oluşturma şeklidir diyebiliriz. Yani Login oluşturduğunuzda bu kullanıcı  Instance’a ait tüm işlemleri ve altındaki tüm databaselere erişebilir ve işlemler yapabilir, ancak User oluşturduğunuzda bu kullanıcı user’ı oluşturduğunuz database üzerinde işlemler yapabilme yetkisine sahip olacaktır. Loginler database üzerinde yetkilere sahip olabilirken User’lar Instance üzerinde yetki sahibi olamazlar.

Şimdi daha detaylı incelemek için Login ve User oluşturup konularımızı ele alalım.

Login Oluşturma Ve Yetklendirme

Login oluşturma için Instance altındaki Security bölümünde bulunan Login sekmesine sağ tıklayıp New Login dediğimiz zaman karşımıza yeni bir kullanıcı oluşturma ekranı gelecektir. Burada isterseniz öncelikle SQL serverın iki bağlantı çeşidine değinelim.

Windows Authentication:  Sql server windows bağlantısıdır ve bu şekilde giriş yaptığınızda sizden herhangi bir şifre istenmez fakat burada sadece domainde bulunan kullanıcılar için Login oluşturabilirsiniz.

SQL Server Authenticaiton:  Burada istediğiniz tarzda Login oluşturabilirsiniz ancak bu kullanıcı için şifre girmeniz gerekmektedir.

General kısmında başlıca kullanıcı bilgileri girmeniz gereken bölümleri görürsünüz. Burada eğer domainde bulunan bir kullanıcı için SQL serverda kullanıcı oluşturmak isterseniz Login Name bölümündeki Serarch butonunuza tıkladığınızda aşağıda göründüğü gibi bir ekranla karşılaşacaksınız, ilk açıldığında herhangi bir kullanıcı yazılıyor olmayacak siz belirlediğiniz bir domain kullanıcısı ekleyebilirsiniz.

OK dedikten sonra kalan işlemleri bu kullanıcı için gerçekleştireceksiniz.

Biz SQL Server Authentication olarak bir Login oluşturacağız. celal.akay diye bir Login name girdik ve şifremizi belirledik. Altındaki seçeneklerde şifre ile ilgili bir kaç seçenek sunmaktadır. Enforce Password Policy  oluşturacağımız şifrenin sqlde tanımlı Policy yani şifre kurallarına uygun olup olmadığını kontrol eder, enforce password expiration seçeneği zamanı geldiğinde şifre değiştirme gerekliliği oluşturur ve şifresi değiştirilmeyen Loginlerin Disable(pasif) duruma çekilmesini sağlar, bir altındaki seçenekte ise bu kullanıcının ilk giriş yaptığı anda şifresini değiştirmesini ister. Sonraki seçeneklerde ise Login için sql server sertifika oluşturma seçenekleri sunar. Default Database kısmında bu kullanıcı sql servera giriş yaptığında başlangıçta hangi veritabanında karşılanacağını belirler. Default Language kısmında da başlangıç dili belirlenir. Bu dil hata mesajlarının size hangi dille iletileceğini de belirler.

Server Roles kısmına geldiğimiz zaman işte burada oluşturacağımız Login için Instance bazlı yetkiler veriyoruz.

bulkadmin (Bulk Insert Administrator – Çoklu Kayıt Yöneticisi) : Bulk Insert komutuna yetkisi olan

dbcreator (Database Creator – Veritabanı Yöneticisi) : Database oluşturabilme, silebilme, düzenleyebilme yetkisi olan

diskadmin (Disk Administrator – Dosya Yöneticisi) : Disk üzerinde bulunan dosyaları yönetme yetkisi olan

processadmin (Process Administrator – İşlemci Yöneticisi) : SQL Server üzerinde çalışan işlemcileri kontrol etme yetkisi olan.

public (Herkese Kısıtlı Hak) : SQL Server üzerinde  standart ayarlarla giriş yapan herkesin rolüdür. Bu kural ile tüm kullanıcıların kısıtlı hakları vardır. Daha sonra bu kullanıcılara kural değişikliği yapılarak diğer kurallar atanabilir

securityadmin (Security Administrator – Güvenlik Yöneticisi) : Server üzerinde kullanıcıların yetkilerini denetlemek, yönetmek ve şifrelerini sıfırlamak ya da istendiğinde değiştirme yetkisi olan

serveradmin (Server Administrator – Server Yöneticisi) : SQL Server üzerinde yapı ayarları, başlat/durdur/yeniden başlat gibi yetkileri olan.

setupadmin (Setup Administrator) : SQL Server üzerinde farklı bir verştabanı kullanarak işlem yapma yetkisi olan

sysadmin (System Administrator – Sistem Yöneticisi) : En yüksek yetkisi olandır. Sistem üzerinde tüm yetkilere sahiptir.

User Mapping bölümünde oluşturacağımız Loginin hangi veritabanlarına erişiminin ve bu veritabanlarında ne tür yetkilerinin olmasını istediğimizi belirliyoruz. Bu kısımda alt taraftaki seçenekler de Database bazlı rollerdir.

db_owner : Veritabanında en yüksek yetkilidir. Silme, ekleme, düzenleme, başlatma/durdurma gibi yetkileri vardır

db_accessadmin : Veritabanında kullanıcılara veritabanına erişim kural/yetki atayan yöneticidir

db_securityadmin :Veritabanındaki kural/yetkileri yönetir

db_datareader : Veritabanındaki kullanıcıların “SELECT” sorgusunu çalıştırmasına izin verir

db_datawriter : Veritabanındaki kullanıcıların “INSERT , DELETE , UPDATE sorgularını çalıştırmasına izin verir

db_ddladmin : Veritabanındaki kullanıcıların “DDL” komutlarını çalıştırmasına izin verir

db_denydatareader : Veritabanındaki kullanıcıların “SELECT” sorgusunu çalıştırmasını kısıtlar

db_denydatawriter : Veritabanındaki kullanıcıların “INSERT , DELETE , UPDATE sorgularını çalıştırmasını kısıtlar

db_backupoperator : Veritabanının yedeğini alma yetkisi tanımlar.

eğer sadece Public seçeneğini seçerseniz bu kullanıcının ilgili veritabanına erişimi olur fakat herhangi bir işlem yapma yetkisi olmaz.

Status  kısmına geldiğimizde Settings altındaki Grant database bağlantısına izin verirken Deny ise izin vermemeyi temsil eder alt kısımda Disable Loginin tamamen kullanım dışı hale getirilmesi demektir. Bu durumda sadece pasife çekilmiş olur bu kullanıcının silinmesi olarak anlaşılmamalı Enable ise pasif durumdaki kullanıcıyı tekrar aktifleştirmek için kullanılır.

User Oluşturma Ve Yetkilendirme

Daha önce de söylediğimiz gibi Userlar database seviyesinde kullanıcılardır bu nedenle User oluşturmak için ilgili veritabanına sağ tıklayıp New User seçeneğini tıklıyoruz.

Bir sonraki adımda karşımıza oluşturacağımız User için bir ekran gelir ve burada gerekli bilgileri tanımlarız.

Burada User Type kısmında oluşturacağımız User’ı oturum açmak ve veritabanına erişmek için kullanacağımızı belirtiyoruz. User Name kısmında User için bir isim belirliyoruz. Login name kısmında ise bu User’ı bir Login ile ilişkilendirmemiz gerekiyor çünkü daha önce de bahsettiğimiz üzere Userlar veritabanı bazlı ve Loginler Instance bazlı çalıştığı için sql serverda Instance’a bağlanabilmek için Login kullanmamız gerekecek oluşturduğumuz User da tanımladığımız Login üzerinden veritabanına erişim sağlayacak. Her User tek bir Login ile ilişkilendirilebilir. Bu durumda veritabanındaki User ile ilişkilendirdiğiniz Login Instance altında Login’e verdiğiniz ismiyle görünürken veritabanı altında User’a verdiğiniz isimle görünür. Logine verdiğiniz yetkiler User için de geçerli olacaktır. Aynı Login için birden fazla User ile ilişkilendirilebilir, böylece Login için her veritabanında farklı yetkiler verebiliriz. Default Schema kısmında bu User sorgu çalıştırdığında eğer schema belirtmezse default olarak hangisinin tanımlanacağını belirler. Herhangi birşey belirtmezseniz DBO olarak tanımlanır.

 

Owned Schemas  kısmında oluşturduğumuz User’ın hangi şemalar üzerinde yetki sahibi olacağını belirtiyoruz burada rol ve veritabanımızda bulunan schemaların hepsi bulunur. Burada dikkat etmeniz gereken şey eğer Şemalardan birine oluşturduğunuz User’ı yetkili yaparsanız daha sonra bu User’ı silmek istediğinizde hata alacaksınız bu durumla karşılaşmamak için öncelikle silmek istediğiniz Userın hangi şemalarla ilişkili olduğunu User üzerine sağ tıklayıp özelliklerden bakın daha sonra ilgili şemaya yine veritabanı altında bulunan Schemas bölümünden ulaşıp sağ tık özellikler sekmesinden Schema Owner’ı değiştirmeniz gerekir, işlemi gerçekleştirdikten sonra artık ilgili User’ı silebilirsiniz.

Membership  bölümünde User yetkilendirme işlemlerini tanımlıyoruz. Yukarıda bu yetkilerin ne anlama geldiği bilgisin vermiştik.

OK dediğimiz zaman veritabanı bazlı User’ımızı oluşturmuş bulunuyoruz

SQL SERVER BACKUP-RESTORE İŞLEMLERİ

BACKUP İŞLEMİ

 

Merhaba arkadaşlar, Sql server’da Backup işlemleri her ne kadar basit görünse de aslında senaryolar değiştiğinde ve önemli veriler üzerinde düşünüldüğünde hayati öneme sahip bir olay olduğu anlaşılmaktadır. İnternet dökümanlarında Backup ile ilgili fazlaca kaynak bulma şansımız olsa da ben de çorbada benim de karabiberim olsun deyip bu yazıyı yazmaya karar verdim.

Backup işlemine giriş yapmadan önce SQL Server Recovery Model konusuna kısaca değinmemiz gerekir çünkü Backup alma senaryolarımız bu seçenekler çerçevesinde değişebilmektedir.Kullandığınız veri tabanının hangi modelde olduğunu veri tabanı üstüne sağ tıklayıp properties kısmından Options seçeneği altında Recovery Model alanında buabilirsiniz. Sql serverda 3 farklı recovery model vardır;

1- Full : Production ortamlarda genellikle tercih edilen yöntemdir çünkü transaction log tutma konusunda işimize en çok Full recovery model yaramaktadır. Full recovery modelde transaction logların tamamı tutulduğu için herhangi bir problem oluştuğunda ve veri tabanımızda bozulmalar gerçekleştiğinde olayın olduğu son ana ulaşabilmek için transaction loglara kesinlikle ihtiyacımız olacaktır. Full recovery modelde Transaction Loglar manual olarak silinmediği sürece kaybolmazlar.

2- Bulk-Logged: Bulk Logged Recovery Modelde Full Recovery modelden farklı olarak bulk işlmeler dışında tüm işlemler loglanırken herhangi bir bulk işlem yapıldığında tüm işlem için tek bir kayıt log dosyasına yazılır. Bu gibi durumlarda veritabanımızı herhangi bir zamana restore etmek mümkün olmaz.  Bulk Logged Recovery Modelde bulk işlemler tek tek transaction log dosyasına yazılmadığı için Full Recovery modele göre bulk işlemler daha hızlı yapılır. Yani kısacası Bulk işleminden önce backup alınmayan tüm log işlemleri kaybedilir dersek çok yanlış olmasa gerek.

3-Simple: Bilinenin aksine Transaction log ları tutan fakat her checkpoint işleminden sonra transaction logları sildiği için transaction log backup alma şansımızın olmadığı modeldir bu nedenle herhangi bir veri tabanı kayıp senaryosunda istediğimiz ana ulaşma şansımız yoktur.

Dışardan aldığınız bazı Backup dosyaları Simple modda olabilir bu nedenle restore ettikten sonra özelliklerden kontrol edebilir ve isterseniz değiştirebilirsiniz. Sql serverda oluşturduğumuz yeni veri tabanları sistem veritabanımız olan Model veritabanını örnek model olarak kullandığı için yeni bir veritabanı oluşturduğumuzda Model veritabanımız hangi recovery modda ise yeni veritabanımız da aynı modda olacaktır.

 

Full Backup:

Şimdi Backup alma işlemlerine geçiş yapabiliriz. Management studioya giriş yaptıktan sonra Backup almak için Backup işlemini gerçekleştireceğimiz Veri tabanının üstüne sağ tıklayıp Tasks bölümünden Backup seçeneğine tıklıyoruz. Eğer Full ve Differantial backup dışında Transaction log backup alacaksanız yukarıda belirttiğimiz gibi öncelikle veritabanımızın Full recovery modda olduğuna dikkat etmemiz gerekmektedir. Küçük bir not: eğer full backup aldığınızda veritabanı simple modda olsa bile daha sonra log backup almak isterken full moda çekip devam edebilirsiniz, simple modda aldığınız backuplar mundar olmaz, ancak simple moddayken backup seçenekleri arasında Transaction log seçeneğini göremezsiniz.

Tasks kısmından Backup seçeneğini tıkladıktan sonra karşınıza aşağıdaki gibi bir pencere çıkacaktır. Ben örnek olarak AdventreWorks2016 veritabanını kullanıyor olacağım ve görüldüğü üzere Recovery modeli Full durumda. (Backup alma işleminin sadece Full Backup kısmını görsellerle anlatıp Differantial ve Transaction Log backupları sadece yazıyla anlatmaya çalışacağım)

Bu ekranda seçeneklere teker teker değinmeye çalışacağım fakat Copy-only Backup seçeneğini en son anlatacağım çünkü öncelikle backup çeşitlerinin çalışma mantığını anlamamız gerek ki böylece Copy-only backupın asıl amacını öğrenmemiz daha kolay olsun. Database kısmında hangi veritabanının backupını alacağımız görülmektedir burada sağ tık backup işlemini başka veritabanında başlatmış olsak da sonradan veritabanımızı değiştirebilir ve başka bir veritabanı için backup alabiliriz. Alt kısımda veritabanımızın modelini göstermektedir burada değişiklik yapamıyoruz, onun altında backup type seçeneğinde Full, Differantial ve Transaction log seçeneklerinden ihtiyacımız olanı seçiyoruz.

Burada şuna da değinmek istiyorum ki eğer bir Full Backup yedeğiniz yoksa aldığınız Differantial ve Transaction log backuplarınız işe yaramayacaktır çünkü her iki backup Full backup dosyasını takip etmektedir. Bu konuya Differantial ve Transaction log backup seçeneklerinde detaylı değineceğiz.

Backup component kısmında veritabanımızda nelerin backupını almak istediğimizi belirtiyoruz yani bu demek oluyor ki veritabanı için backup alırken bütün veritabanı yedeği dışında istersek oluşturduğumuz File ve Filegrouplarının da backupını alabiliriz. Biz database seçeneği ile veritabanımızın tam backupını alacağımızı belirtiyoruz.

Destination bölümünde alacağımız veritabanı backupını nereye kaydedeceğimizi soruyor disk ve url seçenekleri arasında biz diske kaydetmek istediğimiz için disk seçeneğine tıklıyoruz.

Bir alttaki kısım bize veritabanı yedeğimizin hangi adreste ve hangi isimle kayıt edileceğini göstermektedir. istersek bu adresi remove edip kendimiz yeni bir alan belirtebiliriz ancak bunu yapmazsak orada belirtmiş olduğu adresin üzerine yazıp aynı isimde olan veritabanının üstüne bizim aldığımız backupı yükleyecektir. Eğer aldığınız tüm veritabanı yedeklerinin farklı isimde görünmesini ve ayrı ayrı tutulmasını istiyorsanız buradaki adresi değiştirmeniz gerekmektedir.

Contents seçeneği çoğumuzun pek dokunmadığı, kullanmadığı bir seçenektir

Adres bilgilerini seçtiğimiz veritabanımızı seçip contents seçeneğine tıkladığımızda yukarıda bahsettiğimiz veritabanının daha önceki full backupının üzerine yazma işleminin detaylarına ulaşıyoruz, görselde de görüldüğü üzere veritabanının ilk backupından sonra üzerine yazılan backuplar görülmektedir. Bunu Backup dosyasının ‘İçindekiler’ penceresi olarak düşünebiliriz.

Media Options kısmında bize veritabanımızın backupı şekillendirme konusunda birkaç seçenek daha göstermektedir. Append to the existing backup set seçeneği seçili olduğunuzda aldığınız backup daha önce aldığınız backupın üstüne yazılır yani bir Media Set oluşturur. Bu durum contents seçeneğinde bahsettiğimiz durumu ortaya çıkarır. Ancak bu durum şöyle bir dezavantaja sebep olacaktır diyelim ki ilk aldığınız backup 1 GB boyutunda sonra backup aldığınızda eklenen verilerle veritabanı boyutunuz 1.5 GB olduysa backupı öncekinin üstüne yazdığınızda yeni backup dosyanız 2.5 GB boyutunda olacaktır.

Eğer böyle bir ihtiyacınız yoksa ve backup dosyanızın veritabanınızın şuanki boyutunda olmasını istiyorsanız bir alttaki Overwrite all existing backup set seçeneğini seçebilirsiniz böylece veritabanınızın son hali bir önceki veritabanı backup dosyanızı ezerek gerçek boyutunu oluşturacaktır. Tekrar backup seçeneklerinde contents seçeneğine tıklarsanız artık tek bir backup dosyasının olduğunu görebilirsiniz.

Alttaki media set seçenekleri de daha önce bahsettiğimiz veritabanı backuplarının üst üste alınması ve bir öncekini ezmemesi durumudur bu birkaç bacupın tek dosya içinde barındırılması media set olarak tanımlanmaktadır.

En alttaki Reliability kısmında ise backup alınırken ya da alındıktan sonra yapılması istenen durumları belirler Verify when backup finished seçeneği backup işlemi bittiğinde bu bitimi doğrulamak için kullanılır. Perform checksum before writing to media seçeneği Backup alınmadan önce hata kontrolü yapılmasını sağlar. Continue on error seçeneği ise backup alımında hata olsa bile işlemi bitirmesi istenir

Backup Options kısmına geldiğimizde ilk sırada aldığımız backupa bir isim vermemizi ister sonraki description kısmına istediğimiz açıklamayı yazabiliriz.

Backup set will expire: seçeneği genellikle backupın expire edileceği yani kendini imha edeceği tarihi belirlemek olarak anlaşılsa da aslında öyle değildir, bu seçenek daha önce bahsettiğimiz media set konusu ile alakalı yani eğer bir media setimiz var ise ve veritabanı yedeklerimiz bir öncekini ezmeden üzerine ekleniyorsa burada belirttiğimiz tarih geldiği taktirde artık üstüne ekleme daha önce bu media set içine alınan tüm backupları ezip tek backup olarak oluştur demek anlamına gelir. 0 day yazdığımız taktirde herhangi bir sınır belirtmemiş oluruz.

Compress backup:  Alacağımız backupın sıkıştırılması dolayısıyla diskte çok daha az yer kaplamasını sağlar. Ancak unutulmamalıdır ki bu seçenek seçili olsa bile Sql server önce veritabanının Full backupını alır ve aldığı backupı sıkıştırıp diske yazar yani şöyle ki eğer veritabanınız 2 GB ise ve diskinizde 1 GB yer varsa ” nasılsa MBlere kadar sıkıştıracak” diyerek backup alma şansımız olmuyor çünkü sql server öncelikle 2 GB alana ihtiyaç duyacaktır.

 

Tüm ayarlamaları yaptıktan sonra OK seçeneğine tıkladığımız takdirde backup işlemimizin sonuç bildirimi karşımıza çıkacaktır. SQL serverda beklenmedik zamanlarda Buglarla karşılaştığımız için mümkün olduğu sürece bu tarz işlemlerinizi tüm ayarlamaları yaptıktan sonra SCRİPT seçeneğini tıklayarak işlemin scriptini çıkarıp execute ederek gerçekleştirmenizi tavsiye ederim.

Differantial Backup:

Backup işlemlerinde bir sonraki konumuz olan Differantial backup işlemine geldik. bu backup tipi bizim aldığımız son Full backuptan sonra yapılan işlemlerin backupını alır yani diyelim ki 10 gün önce Full backup aldıysak bugün alacağımız bir Differantial backup 10 gün önceki Full backuptan itibaren Differantial backup aldığımız son ana kadarki değişiklikleri içinde barındıracaktır. Yani bu 10 gün süre boyunca arada başka differantial backup almış olsanız dahi son aldığınız backup aradaki tüm Differantial backupların toplamı olarak tanımlanabilir, bu da demek oluyor ki senaryonuza göre isterseniz öncesinde aldığınız Differantial backup dosyalarınızı silebilirsiniz.

 

Transaction Log Backup:

Transaction Log backup işlemi yine en başında bir Full backup gerektiriyor, alınan Full backuptan sonraki Log backup Full backuptan sonra yapılan işlemlerin Logunu tutar. İlk Transaction Log backuptan sonra alınan her Log backup kendinden önceki Log backuptan sonra yapılan işlemlerin Logunu tutar. Burada sistemi bir zincir olarak düşünüp her Log dosyasını bir halka olarak ele alabiliriz bu da demek oluyor ki herhangi bir halka yani Log backup dosyası kaybolursa sonrasında gelen Log backupların hiçbir anlamı olmayacaktır. Diğer bir konu olarak; Log backuplar Full ve kendinden önceki Log backupları baz aldığı için aldığınız Differantial backuplar iki log arasındaki bağlantıya herhangi bir etki etmeyecek ve Differantial backuptan sonra alınan Transaction Log backup yine Differantial Backuptan önce alınan son Log backup ile kendi arasındaki değişikliklerin kaydını tutacaktır.

 

RESTORE İŞLEMİ

Backup işlemlerimiz bittikten sonra herhangi bir veri kaybı ya da veritabanı bozulması durumunda veritabanımızda istediğimiz duruma gelmek için Restore işlemlerini gerçekleştirebiliriz. Önce Restore işleminin nasıl ve hangi seçenekler çerçevesinde alındığını inceleyelim daha sonra tüm bunları bir örnekle daha iyi anlamak için değerlendiririz.

Öncelikle restore işlemimizi Full Backup Restore işlemini görselerle anlatıp kalan Restore işlemleri yazılı olarak anlatmaya çalışalım. Databases üzerine sağ tık Tasks sekmesinden Restore Database kımsında Full seçeneğini tıklıyoruz karşımıza çıkan ekranda Device seçeneğinde Restore işlemini yapacağımız backup dosyamızı belirten adresi seçiyoruz ve .bak dosyamızı ekliyoruz.

İhtiyacımız olan yani Restore edeceğimiz veritabanını seçtikten sonra karşımızda yukarıdaki gibi bir ekran ve Restore edeceğimiz veritabanının bilgilerini gösteren bir ekran görünüyor olacaktır.

Restore ekranında Files seçeneğine tıkladığımız zaman Restore edeceğimiz veritabanının veri ve log dosyalarının nerede tutulacağını belirten ekran gelmektedir. Burada sizin Sql server’ı kurarken belirttiğiniz default adres gelecektir, isterseniz Relocate all files to folder seçeneği altında bu veritabanınızın dosyaları için farklı bir yol belirtebilirsiniz. Hatta isterseniz veri ve log dosyalarınızı ayrı klasör ya da disklerde saklayabilirsiniz bu performans açısından size fayda sağlayacaktır çünkü veri giriş çıkışlarında disk I\O oranı daha az olacak verilerin diske yazılması ya da diskten okunması daha hızlı olacaktır.

 

Restore işleminin Options kısmında karşımıza yukarıdaki ekran çıkmaktadır. Burada Overwrite the existing database(WITH REPLACE) seçeneği restore ettiğiniz veritabanı zaten var ise yüklediğiniz restore dosyasının var olan veritabanını ezmesini sağlar. İkinci seçenek de tail log backup almasına yardımcı olur. Tail Log backup konusuna yazının devamında değineceğiz. son seçenekte restore işleminde kullanıcıların üzerine yazdığımız veritabanına olan erişimlerini kısıtlamak için kullanılabilir.

Recovery State kısmında ise eğer restore işlemimiz tek adımlık bir işlemse o zaman Restore With Recovey seçeneği ile devam ediyoruz fakat Full backupımızın üzerine Diff veya Tran Log backupları da yükleyeceksek o zaman son adıma kadar gerçekleştirdiğimiz son restore işlemine kadar her seferinde Restore With Norecovery seçeneğini seçiyoruz, bu veritabanımızın Restor modda olduğunu ve işlemin bitmediğini temsil eder ta ki son Log backupı yükleme kısmına geçene kadar son adımda tekrar Restore With Recovery seçeneğinde bırakıp restore işlemini sonlandırıyoruz ve veritabanımızın son haline ulaşmış oluyoruz.

Gelin isterseniz Full Backup, Differantial Backup ve Transaction Log Backup işlemlerini bir örnek üzerinde değerlendirelim ki anlamak daha kolay olsun.

Örneğin; Sisteminiz veritabanınızın önemi dolayısıyla her sabah 07:00’da Full backup ve her yarım saatte bir Transaction Log backup almanızı gerektiriyor ek olarak Öğlen 12:00’da ve gece 22:00’da Differantial Backup alıyorsunuz.

Diyelim ki saat 21:48’de sisteminizde bir arıza oluştu veritabanınıza hiçbir şekilde erişemiyorsunuz ve Backuplar ile veritabanınızı güncel haline getirmeniz gerekiyor; İlk adım zaten olmazsa olmaz dediğimiz Full Backupı yüklemek olacak ve sonra her yarım saatte bir Transaction Log Backup aldığımızı söylemiştik istersek adım adım sırarıyla 21:30’a kadar olan tüm Transaction Log Backupları yükleyebiliriz fakat biz saat 12:00’da Differantial Backup aldığımız için saat 07:00 ile 12:00 arasındaki tüm işlemler zaten bu Backupta kayıtlı olacağı için aradaki Transaction Log backuplarla uğraşmamız gerekmeyecek ancak 12:00 ile 22:00 arasında başka Differantial backup olmadığı ve problemi 21:48’de yaşadığımız için 12:00’dan sonraki tüm Transaction Log Backupları sırasını karıştırmadan ve herhangi birini atlamadan yüklememiz gerekmektedir.

Peki madem her yarım saatte bir Log backup alıyoruz ve problem öncesi son Log backupımız 21:30’da alınmış durumda o zaman 21:30 ile 21:48 arasındaki verilerimiz ne olacak kayıp mı etmiş oluruz diye bir soru sorulabilir. İşte bu evrede karşımıza Tail Log Backup kavramı çıkmaktadır.

Tail Log Backup:   Veritabanımızda herhangi bir sorunla karşılaştığımız zaman aldığımız backuplardan geri dönmek isteriz ve ilk olarak Full backupı restore ederiz Sql server restore işlemine başladığımız zaman bize bu işlem başlatılmadan önce Tail Log Backup alma seçeneği sunar bu da son Log backupımızdan sonra yapılan değişiklikleri kapsayan backup anlamına gelir eğer restore işlemine başlamadan önce son olarak bir Log backup daha alma şansımız olursa o zaman Tail log backupa herhangi bir ihtiyacımız olmaz çünkü zaten veritabanımızın son haline kadar tüm kayıtları yedeklemiş oluruz. Restore işlemine başlarken Options kısmında Tail Log Backup seçeneğini tıklarsak Sql server belirttiğimiz klasöre bir log dosyası daha yazar bu aslında Full- Diff-Tran backuplarımızın tamamının son adımı anlamına gelir yani restore işlemlerinde en son bu dosyayı yükleyip veritabanımızı Recovery moda çekebiliriz.

Copy-Only Backup: Veritabanı için Log backup aldığımızda her backup bir lsn zincirine dahil edilir ve birbirini takip eder bu nedenle restore işleminde herhangi bir Transaction Log backupı eksik bırakma şansımız yoktur çünkü sql server bize lsn zincirinde eksik bir backup olduğu için restore işlemini gerçekleştiremediğini belirtir. bu yüzden eğer acil bir Log veya Full backup ihtiyacımız olursa ve var olan lsn zincirine etki etmek istemiyorsak Copy-only backup alırız. Şöyle düşünelim; bir firmada full ve log backuplar alınıyor biz bu firmaya danışmanlığa gittiğimizde bir log backup alıp işimiz bitince sileceğiz eğer normal tarzda bir log backup alıp sonra işimiz biitnce silersek ileri bir tarihte veritabanında bir problem çıktığında firmanın ilgili veritabanı sadece bizim log backup aldığımız tarihe kadar yüklenebilir ondan sonraki tüm log backuplar işlenemez hale gelecektir. işte böyle bir durumda eğer aldığımız Log yada Full backupımızı Copy-only tarzda alırsak işimiz bittiğinde silsek ya da başka klasöre taşısak dahir sonraki durumarda restore işleminde herhangi bir sorun olmayacaktır.

Redis Nedir ? Nasıl Kullanılır ?

Merhaba arkadaşlar bugün zaman çok ağır geçiyor o zaman bize çok hızlı ve performansı yüksek bir konu lazım deyip Redise sarıldım, Redis için başlıca konulara değinip ardından temel kod satırı veri ekleme çekme silme işlemlerine bakacağız.

Peki kim bu Redis ? nerelerde yaşar, ne içer, geçimini nasıl sağlar, en çok neyden hoşlanırlar, üremeleri nasıl gerçekleşir sorularımıza cevaplar arayalım.

Redis NoSQL veri tabanlarından inmemory olarak çalışan (key-value) bir veri tabanı sistemidir deyip kısaca kim olduğu hakkında küçük bi ipucu verelim peki sadece inmemory mi çalışır diye sorarsanız o zaman hayır cevabını alırsınız çünkü Redis aynı zamanda verilerinizi diskte saklamanıza da olanak sağlar böylelikle istediğiniz zaman verilerinize diskten ulaşabilir veri kaybı yaşamadan işlemlerinizi gerçekleştirebilirsiniz. Redis STRING, HASH, SET, SORTED SET ve LIST gibi veri türlerini destekler.

C, C#, C++, Clojure, Common Lisp, D, Dart, emacs lisp, Erlang, Fancy, Go, Haskell, haXe, Io, Java, Lua, Node.js, Objective-C, Perl, PHP, Pure Data, Python, Ruby, Scala, Scheme, Smalltalk, Tcl. Gibi yazılım dilleri de Redisi destekleyince gittikçe Redis tadına doyulmaz bir hal almaya başladı. Redis resmi olarak Linux ortamında çalışan bir veri tabanı olsa da windows ortamlarda community olarak versiyonu biraz geriden gelse de çalıştırılıyor. Aynı zamanda Azure desteği de bulunmaktadır.

Avantajları

• Senkron çalıştığı için son derece hızlıdır.
• Birçok veri türünü destekler.
• Veriyi hem RAM üzerine hem de ayarlandığınız konfigürasyona göre disk üzerine kaydedebilir.
• Disk üzerine kayıt yaptığı için restart sonrasında aynı verilerle çalışmaya devam eder.
• Son derece aktif bir kullanıcı kitlesine sahiptir.
• Sharding, Cluster, Sentinel, Replication gibi birçok enterprise özelliklere sahiptir

 

Dezavantajları

• Asenkron çalışmadığı için tek instance üzerinde, asenkron alternatiflerin eriştiği performansa erişemeyebilirsiniz.
• Veri boyutunuza göre RAM’e ihtiyacınız olur.
• Relational veritabanlarında olduğu gibi komplex sorguları desteklemez.
• Komplex sorgular için sorgu yapacaksanız, Redis yapısını düzgün kurgulamalısınız.
• Bir transaction hata alırsa geri dönüşü yoktur.

 

Veri Modelleri

Redis’in diğer NoSQL bilgi bankalarından en önemli farklarından birisi, yalnızca String’ler ile sınırlı olmamasıdır. String’lere ek olarak Redis, aşağıdaki veri tiplerini de desteklemektedir:

• Listeler (List)
• Setler (Sets)
• Sıralı Setler (Sorted Sets)
• Komut Çizelgeleri (Hash Tables)
• Atomik İşlemler (Atomic Transactions)

Redis tek birim olarak maksimum 512 MB veriyi saklayabilmektedir.

Kopyalama (Replication)

Redis, yalnızca master-slave kopyalamasını desteklemektedir. Herhangi bir master Redis sunucusu, kendinde bulunan veri güncellendiği anda master sunucuya bağlı olan N kadar slave sunucuda da güncelleme yapar. Bir slave, diğer slave’ler için master durumunda olabilir. Böylece bir çizge (graph) yapısı oluşturulabilmektedir. Ancak, kopyalama yaparken gerekli RAM alanı yüzünden replikasyonla ilgili bazı tartışmalar vardır.

Redis aynı zamanda yayınla/abone ol (publish / subscribe) özelliğini de tam olarak desteklemektedir. Bu sayede bir slave’in istemcisi bir kanala abone olup, master’a yayınlanan tüm mesajları alabilir.

Veri Kalıcılığı (Persistence)

Bilgisayar bilimlerinde “veri kalıcılığı”; verinin, oluşturulduğu işlemden sonra da tutulması özelliğidir. Böyle bir özellik olmasaydı, veri sadece RAM’de bulunabilirdi ve bilgisayarın kapanması gibi RAM’in güç kaybına uğradığı durumlarda kaybolurdu.

Redis normalde tüm veri setlerini RAM’de tutmaktadır. Kalıcılığı sağlamak için ise 2 yöntem kullanılmaktadır. “Snapshotting” adı verilen birinci yöntemde, belirli zamanlarla snapshot’lar alınır ve bunlar diskte saklanır. Diğer yöntemde ise RAM’de tutulan veri setleri diskte de tutulur. İstenirse bu iki yöntem de devre dışı bırakılabilir. Bir başka seçenek de master yerine slave üzerinden kalıcılığı sağlayarak master üzerindeki yükü hafifletmektir.

Güvenlik

Redis, güvenli istemcilerin güvenli ortamlarda Redis’e erişimi üzerinde tasarlanmıştır. Bu, Redis durumunun (instance) internete direkt olarak açılmasının veya bir başka deyişle güvenilmeyen istemcilerin direkt olarak Redis TCP portuna veya UNIX soketine erişmesinin iyi bir fikir olmayacağı anlamına gelmektedir.

Redis, erişim kontrolü (Access Control) protokolünü implemente etmezken, küçük bir kimlik doğrulama katmanı sağlamaktadır. Kimlik doğrulama katmanı aktif hale getirildiğinde Redis, kimlik doğrulamasından geçemeyen hiçbir istemciyi kabul etmez. İstemci “AUTH” komutunun arkasından sunduğu şifre ile kimlik doğrulama yapar. Şifre, sistem yöneticisi tarafından belirlenir ve “Redis.conf” dosyasında açık metin olarak tutulur. Şifrenin kaba kuvvet (brute force) saldırılarına karşı dayanabilecek kadar uzun ve karmaşık olması gerekmektedir. Bu koruma yöntemi, güvenlik duvarı gibi önlemler çökecek olursa, istemcilerin direkt olarak erişmesine mani olmak için kullanılır. Yani, birinci dereceden bir güvenlik önlemi değildir.

Redis, veri şifrelemesini desteklememektedir. Bu yüzden, sadece güvenli istemcilerin veya güvenilen tarafların Redis’e erişimini sağlamak için, SSL gibi ek güvenlik katmanları implemente edilmelidir.

Redis’te bazı spesifik komutlar devre dışı bırakılabilir veya bu komutların isimleri tahmin edilemeyecek şekilde değiştirilebilir.

Genel olarak denilebilir ki Redis, maksimum güvenlik için değil, maksimum performans ve basitlik üzerine tasarlanmıştır.

Evet Redis çok hızlı peki neden bu kadar hızlı diye sorarsanız o zaman bunu bir örnekle cevaplamak sanırım daha açıklayıcı olur. Bu durumda size Pipelining özelliğinden bahsedeceğiz;

Pipelining

Diyelim ki cafede garson olarak çalışıyorsunuz ve kalabalık bir arkadaş grubu gelip masaya oturdu hep beraber sipariş verdiler 10 çay 5 kola 8 soda 3 pasta derken düğün menüsü çıktı, her bir müşterinin siparişi için tekrar tekrar mutfağa gitmeniz epey bir zaman ve performans kaybı olacağından tüm siparişleri büyük bir servis masasına koyup götürdükten sonra mutfağa tek gidişle tüm siparişleri almış ve masalara dağıtmış olursunuz işte Redis tam olarak bunu yapıyor Pipelining özelliği ile istediğiniz verilerin tamamını tek bir masaya(Pipe) koyup tek seferde size getirdiği için aynı işlem için defalarca getir götür yapmadan hızlıca işlemlerinizi gerçekleştiriyor aynı zamanda performans açısından da çok iyi bir avantaj sağlıyor.

Ama gelin görün ki Redis de diğer NoSQL veri tabanı sistemleri gibi karmaşık sorgulara cevap vermekten kaçınıyor yani relation dblerde bana pazar günü şu saatler arasında kola isteyen müşterilerimin bana ne kadar kazandırdığını getir bana derseniz buna cevap alamazsınız,

Bana pazar günü siparişlerini getir.

Bana şu saatler arasındaki siparişleri getir.

Bana kola olan siparişleri getir.

Bana kazancı getir.

şeklinde teker teker talepte bulunmak gerekiyor.

Redis Kurulumu ve Kullanımı

Kurulum için yapmanız gereken tek ey ” https://github.com/MSOpenTech/redis/releases ” adresinden kurulum dosyasını indirmek, ardından ilk olarak redis-server.exe programını çalıştırıp Redis serverı aktif hale getireceksiniz bu işlemi yaptıktan sonra aynı klasör içindeki redis-cli.exe eklentisini çalıştırdığınız zaman da artık Redis veri tabanı sistemini kullanabilir veri tabanlarınızı oluşturabilirsiniz, redisin default veri tabanı oluşturma sayısı 16 adettir siz bunu bazı değişikliklerle arttırabilirsiniz fakat ben yeterli olacağını düşünüyorum.

İnsert, Select, Update, Delete ve Temel işlemleri

Kullanımı çok basit demiştik demediysek de şimdi demiş olalım insert işlemi için SET komutunu kullanmanız yeterli “SET keyadi değer” şeklinde yazıp enter dediğiniz zaman SET komutundan sonra ilk kelimeniz key ikinci kelimeniz ise bu keye atadığınız value olacaktır

INSERT(SET-MSET) ve SELECT(GET-MGET)

yukerda da gördüğünüz üzere onay aldığınız zaman verinizin eklendiğini anlarsınız.

Eklediğimiz verileri görmek için ise GET komutunu kullanmak yeterli olur “GET anahtaradi” o anahtarımızın içindeki veriyi bize döndürecektir.

Peki her seferinde tek anahtar tek değer girmek istemiyorsanız sürekl SET yazmaktan bıktım diyorsanız o zaman yardımınıza MSET(Multiset) komutu yetişecektir. o zaman sırasıyla ilk kelime key ikincisi value olarak varsayıp arada boşluklarla veri girişinizi yapabilirsiniz örneğin;

Böylece tek MSET komutu ile dört key ve bu keylerin value girişlerini yapmış olduk

set dedikten sonra verileri görmek için get kullandığımıza göre MSET için de MGET kullanmamız mantıklı olmaz mıydı sizce ? o zaman bakalım Redis programcıları bizden çok mu daha komplex düşünmüş;

Evet bizi yormamayı tercih etmişler. Görüldüğü üzere MGET komutundan sonra görmek istediğimiz key isimlerrini yazmamız yeterli oluyor.

UPDATE(SET)

Hadiii amaa yanlış veri girdik ben bir de Update işlemi ile mi uğraşıcam yaa nasıl yazılıyor ki bu Update işlemi dediğinizi duyar gibi değilim ama muhtemelen düşünmüşsünüzdür. O zaman biraz daha kurcalayalım da bozalım tüm veri tabanını bakalım nerde tutturucaz derken aslında işlemin çok basit olduğunu öğrenmek çok utandırırdı bizi çünkü Update işlemi için hangi anahtarın içindeki değeri değiştirmek istiyorsak yine SET komutu ile anahtarımızın adını ve yeni değerimizi yazmamız yeterli olacaktır ve evet bu kadar basit.

Şekilde gösterdiğine göre artık içimiz rahatlamış olmalı kolaylıkla Update işlemlerimizi yapalım artık o zaman.

RENAME

Her veri tabanı sisteminde olduğu için Redis modayı bozmamak adına olmalı ki ihtiyacımız olur diye hani biz hep fikir değiştiren anlık tercihler yapan insanlar olduğumuz için Anahtarımızın adını değiştirmek istediğimiz zaman kullanım için RENAME komutunu bize sunmuş bunun için RENAME yazdıktan sonra adını değiştirmek istediğimiz anahtarımızı ve ardından vermek istediğimiz yeni anahtar adını yazmamız yeterli olacaktır.

DELETE(DEL)

Delete işlemi de gayet basit bir şekilde sadece DEL komutunun ardından silmek istediğimiz anahtar adını yazarak yapabileceğimiz bir işlem; aşağıda işlem yapılmış ve arama sonucunda dönen (nil) ifadesi SQL de olan null gibi böyle bir anahtarın olmadığını belirtiyor.

LİSTE(LPUSH-RPUSH)

O zaman liste tanımlamak istediğimizde ne yapmamız gerekiyor diye bir bakalım çünkü benim canım tek bir anahtara birden fazla değer girmek istedi yok öyle bir anahtar bir değer deyip yan gelip yatmak işveren olmanın gerekliliğini yerine getirip az besleyip çok yüklenelim bunun için iki  komutumuz var biri LPUSH bu komut ile ekleyeceğiniz veri listenin ilk verisi olur yani baştan ekler RPUSH ise listenize sondan ekleme yapar veriniz listenin sonuna eklenir. Listemizdeki verileri listelemek için de LRANGE komutunu kullanmak yeterli olacaktır tabi bir liste olduğu için listemizin başlangıç değeri ve bitiş değerini belirtip bu sıradaki verileri görmek istiyorum diye de belirtelim ki anahtar dedik köle değil. Örnek;

LPOP-RPOP

Dediler ki bir yerde PUSH varsa POP da olur o zaman deneyelim dedik baktık ve gerçekten varmış o zaman yapalım ve ne işe yarıyor görelim diye de atladık hemen, öğrendik ama iki adet verimizi de kaybettik çünkü LPOP yazdığımız zaman listemizin en başındaki elemanı RPOP yazdığımız zaman da listemizin en sonundaki elemanı çıkarıyor neyse ki PUSH ile veri eklemeyi biliyoruz. Örneğin;

LSET

Normal Update işlemimizi yapmıştık peki listeye bir Update işlemini nasıl yaparız diye sorarsak cevap aşağıda duruyor. LSET komutu ile hangi anahtardaki kaçıncı indexi hangi değerle değiştirmek istediğimizi belirtmemiz yeterli oluyor.

 

SQL Stored Procedure

Merhaba Arkadaşlar,

Bugünkü yazımda sizlere veritabanın (database) da olması gereken en önemli özelliği yani stored procedure anlatacağım.Store procedure dilimizde “saklı alt yordam” veya “saklı işlem grubu” olarakta ifade edilmektedir. Stored procedure’lerin en önemli özellikleri database server’ın içinde saklanmalarıdır.Derlenmesi için başlangıçta çalışır ve daha sonraki kullanımlarda derlenmez. Buda bize artı zaman kazandırır  ve  iyi bir performans sunar. Stored procedure’ler C,C#, java ya da başka programlama dillerindeki fonksiyonlar gibi parametreler içermektedir. Bir özelliği daha ise  oluşturulacak bir procedure’ün içinde declare, set, if ,try catch gibi deyimlerinde kullanılmasıdır. Eğer bir veritabanı ile uğraşıyorsanız kesinlikle işlerinizi stored procedure ile halletmenizi öneriyorum.

Stored procedurelerin kullanıldığı başlıca alanlar :

• Tablodan veri çekme
• Tablodan veri silme
• Tabloya veri ekleme
• Tablodaki veriyi güncelleme

Örneklerle Stored Procedure’n mantığı ve işlevi daha iyi oturacaktır.

•  İlk olarak alt yordamın  söz dizim (syntax) şekli 2 türlü yazılabilir :

CREATE PROCEDURE [Procedure İsmi]

(

– -girilecek parametre değerleri buraya yazılıcak

)

WITH  { RECOMPILE | ENCRYPTION }

AS

BEGIN

         – -BEGIN END Kullanılması zorunlu degildir.

END

—————————————————–

CREATE PROC [Procedure İsmi]

(

– -girilecek parametre değerleri buraya yazılıcak

)

AS

• With ile beraberinde yazılan ifadeler  { RECOMPILE | ENCRYPTION }
  • RECOMPILE  ifadesi Stored procedure her çalıştırmada (execute) yeniden derlenecek anlamına gelir.
  • ENCRYPTION  ifadesi  yazılan kodun şifrelenmesidir. Şifrelenmiş kodu sadece o prosedürü yaratan ve system admin olan görebilir.

•  Alt yordamın söz diziminide öğrendikten sonra sık kullanılan veri ekleme prosedürünü yazalım :

Şirkete yeni bir çalışan alındığında, bu çalışanı rahatlıkla eklemek istiyoruz.

–

CREATE PROC SP_CalisanEkle
(
@CalisanID nchar(5),  - -Parametleri oluştururken başına @ İşareti

koyulur ve bitişik olarak hangi işleve yarıyacaksa onun 

hatırlatacak isim girilir daha sonra veri tipi yazılarak 

bir sonraki parametreye geçilir.

@CalisanIsim nvarchar(40),

@CalisanSoyisim nvarchar(40),

@CalisanTelefon nvarchar(10),

@CalisanAdres nvarchar(100),

@CalisanNotlari nvarchar(100),

@CalisanDugumTarihi DATETIME

)

WITH ENCRYPTION

AS
IF EXISTS(SELECT * FROM dbo.CalisanlarinTablosu WHERE  CalisanID=@CalisanID)
BEGIN
PRINT 'Sistemde id numarası mevcuttur!'
END
ELSE
BEGIN
INSERT INTO dbo.CalisanlarinTablosu VALUES (@CalisanID,@CalisanIsim,

@CalisanSoyisim,@CalisanTelefon,@CalisanAdres,@CalisanNotlari,

@CalisanDogumTarihi)

END

-------------------------------------------------------

 

SP_CalisanEkle prosedüründe If exist() komutunu ve begin end işlevlerini görebilmek için oluşturulmuştur. IF EXIST() , bize exist() bölümünde oluşturulan kod içinde bir  değer varsa ” True ” olur ve ilk “begin end” bloguna girip sistemde aynı calısan numarasına ait baskasının olduğunu söyler. Eğer sistemde aynı id numarasına ait bir calısan bulunmadıysa, yeni çalışan else bloğuna girip ekleniyor. Eğer tek bir satırdan oluşuyorsa kodunuz Begin End bloğunu yazmak zorunda değilsiniz. BEGIN END bloğu programlama dillerindeki süslü parantezlerdir (scope) { }. Stored Procedureleri çalıştırmak için oluştutulan method adının önüne EXEC  ya da EXECUTE komutları yazılabilir. Örneğin: EXEC SP_CalisanEkle ‘CLL47’,‘Celal’,‘Akay’,‘05523631111’,‘24 sokak  Sefakoy / Istanbul’,‘calıskan insan’,‘1994-02-28 ‘ EXECUTE SP_CalisanEkle ‘CLL47’,‘Celal’,‘Akay’,‘05523631111’,‘24 sokak  Sefakoy / Istanbul’,‘calıskan insan’,‘1994-02-28 ‘ Alt yordamı çalıştırmak için bir seçeneğiniz daha var o da exec ya da execute komutları yazmadan sadece prosedürünüzün adını yazıp gereken parametreleri doldurmaktır. SP_CalisanEkle ‘CLL47’,‘Celal’,‘Akay’,‘05523631111’,‘24 sokak  Sefakoy / Istanbul’,‘calıskan insan’,‘1994-02-28 ‘

• Stored Procedurelerde önceden hazırlanmış olan alt yordamın üzerinde değişikliklerde yapılabilir. Oluşturduğumuz SP_CalisanEkle procedure’ne ek olarak çalışanların hangi program dillerini bildiklerinide ekleyelim ayrıca eğer yeni çalışanın yaşı 30’dan büyükse  firmadaki projelerin denetimine katılacakların listesinede (tabloya) eklensin. Proje denetmen tablosuda 4 özellikli bir tablodur. Sonuç olarak burada istenen ek programlama dili bilgisi, bizim esas tablomuzda da bu değişikliğin yapılmış olduğunu gösterir ve buna göre tekrar alt yordamın düzeltilmesi istenir. Değişiklikleri kaydetmek içinALTER komutunu kullanıyoruz .Bunun için yapılan değişiklikler aşadaki gibidir.

 

ALTER PROC SP_CalisanEkle
(
@CalisanID nchar(5),

@CalisanIsim nvarchar(40),

@CalisanSoyisim nvarchar(40),

@CalisanTelefon nvarchar(10),

@CalisanAdres nvarchar(100),

@CalisanNotlari nvarchar(100),

@CalisanDugumTarihi DATETIME,

@CalisanProgDilleri nvarchar(100)
)

WITH ENCRYPTION

AS
IF EXISTS(SELECT * FROM dbo.CalisanlarinTablosu WHERE  CalisanID=@CalisanID)
BEGIN
PRINT 'Sistemde id numarası mevcuttur!'
END

ELSE

BEGIN

IF (30 <= DATEPART(yyyy,GETDATE())-DATEPART(yyyy,@CalisanDogumTarihi))

BEGIN

INSERT INTO dbo.ProDenetmenTablosu VALUES

(@CalisanID,@CalisanIsim,@CalisanSoyisim,@CalisanTelefon)

INSERT INTO dbo.CalisanlarinTablosu VALUES (@CalisanID,@CalisanIsim,

@CalisanSoyisim,@CalisanTelefon,@CalisanAdres,@CalisanNotlari,

@CalisanDogumTarihi,@CalisanProgDilleri)

END

ELSE

BEGIN

INSERT INTO dbo.CalisanlarinTablosu VALUES (@CalisanID,@CalisanIsim,

@CalisanSoyisim,@CalisanTelefon,@CalisanAdres,@CalisanNotlari,

@CalisanDogumTarihi,@CalisanProgDilleri)

END

END

•  Son olarakta oluşturulan stored procedure silmek için değişiklik yaparken kullanılan komutun yerineDROP komutu konulup, sistemdeki prosedürü ortadan kaldırabilirsiniz. Şunu unutmamak gerekir ki oluşturulan stored procedurelerin encryption özelliği var ise sadece sistem admin ve o procedure yapan kişi silebilir.

DROP PROC SP_CalisanEkle

MongoDB Nedir ?

MongoDB nedir ? sorusuna cevap vermeden önce muhtemelen NoSQL nedir ? sorusuna cevap vermek daha iyi olacaktır zira MongoDB bir NoSQL veri tabanı sistemidir.

NoSQL nedir ?

Genel olarak MongoDB üzerinde duracağımız içinNoSQL konusuna bilgi olması amaçlı değinmek istiyorum. NoSQL adı ” Not Only SQL” den gelmektedir yani sadece SQL değil, ne demek bu ? RDBMS sistemlerden farklı bir yapıda olduğunu anlatıyor aslında, bunun en büyük göstergesi de ilişkisel olmayan veri tabanları olmalarıdır desek yanlış olmaz. RDBMS sistemleri ACID(Atomicity  Consistency Isolation  Durability) kurallarına uymak zorundadır yani bir RDBMS veritabanı sistemi aynı anda tüm bu kuralları yerine getirmek zorundadır fakat NoSQL sistemlerde böyle bir zorunluluk bulunmuyor NoSQL sistemler benim daha performanslı olmamı sana daha hızlı işlem yaptırmamı istiyorsan biraz nazımı da çekip bazı kurallarda bana tolerans göstereceksin diyor adeta, NoSQL göreceli olarak senaryonuza bağlı olarak RDBMS sistemlerden çok daha performanslı çalışabilir fakat güvenlik ve veri bütünlüğü konusunda şuan için RDBMSlerden daha geride bulunuyorlar.

 

NoSQL vertabanı çeşitleri

Döküman (Document) tabanlı: Bu sistemlerde bir kayıt döküman olarak isimlendirilir. Dökümanlar genelde JSON formatında tutulur. Bu dökümanların içerisinde sınırsız alan oluşturulabilir. MongoDB, CouchDB, Bigtable, DynamoDB HBase, Cassandra ve Amazon SimpleDB bunlara örnektir.

Anahtar / Değer (Key / Value) tabanlı: Bu sistemlerde anahtara karşılık gelen tek bir bilgi bulunur. Yani kolon kavramı yoktur. Azure Table Storage, MemcacheDB ve Berkeley DB bunlara örnektir.

Grafik (Graph) tabanlı: Diğerlerinden farklı olarak verilerin arasındaki ilişkiyi de tutan, Graph theory modelindeki sistemlerdir. Neo4J, FlockDB bunlara örnektir.

Bazı kaynaklarda döküman tabanlı veritabanı sistemlerinden bazıları Kolon tabanlı olarak da gösterilmektedir. Bizim değineceğimiz MongoDB veritabanı sistemi de Döküman tabanlı sistemler arasında yer almaktadır.

Burada değinmek istediğim bir diğer konu olarak CAP teoremini biraz anlatmakta fayda var böylelikle sistem farklılıkları biraz daha net anlaşılmış olacaktır.

Consistency(Tutarlılık) : Verilerin çıkan sonuçla olan tutarlılık derecesi

Availability(Kullanılabilirlik) : Sistemin aynı anda bir kaç kullanıcı tarafından kullanılabilir olma durumu

Partition-Tolerance(Bölme): Verilerin parçalara ayrılarak işleme sokulma durumu

Aşağıdaki şekilde hangi veritabanlarının hangi şartları sağladığını daha iyi şekilde anlayabiliriz. Bu durumda MongoDB bize Tutarlılık ve Verilerin bölümlendirilmesi açısından olanak sağladığını göstermektedir.

Aşağıdaki şekilde ise herhangi bir özelliği kullanamadığımızda kullanıcıların nasıl bir sistem ile karşı karşıya olduğunu göstermektedir.

MONGODB

MongoDB NoSql veri tabanı sistemlerinin Doküman tabanlı sistemlerinden biridir. Veriler JSON\BSON formatında saklanır.

Peki JSON ve BSON nedir ?

JSON verilerin XML benzeri formatta ama daha da sıkıştırılmış ve boyutu daha küçültülmüş halde tutulmasıdır. Böylelikle boyutun küçülmesinin yanında işlem hızı da daha iyi seviyede olmaktadır.

BSON ise JSON verilerin encode edilmiş halidir yani bir kademe daha sıkıştırılmış hali olarak da düşünülebilir.

MongoDB ye dönecek olursak MongoDB de veriler belirli ID’ler tanımlanarak tutulmaktadır ve bu sayede sorgulamalarda yüksek performans göstermektedir.

Diğer NoSql sistemlere oranla daha zengin bir sorgulama diline sahiptir.

Veriler yatay ölçeklendirme ile yedeklenebildiği için kullanılabilirlik oranı oldukça yüksektir.

MongoDB NoSql veri tabanlarının doküman tabanlı veri tabanlarından biridir ve en çok tercih edilen veri tabanları arasında bulunmaktadır. MongoDB’yi diğer NoSql veri tabanlarından ayıran kendine has bazı özellikleri vardır. Bunlar;

Sorgu(query) desteği. Pekçok NoSQL çözümü veriye sadece anahtarlar(key) üzerinden erişme olanağı sağlarken, MongoDB istenilen alanlar ve belirli aralıklara(range query) göre, ayrıca düzenli ifadelerle(regular expression) de sorgulama imkanı sunuyor.

İkincil(secondary) index desteği. İstenilen alanlara göre sorgulama yanı sıra, bu alanları secondary index olarak tanımlayabilmek. Bu Sqlde kullanılan non-clustered index olarak da düşünülebilir.

MongoDB Altyapısı

Aggregation: Dağınık halde bulunan verileri toplayıp gruplandırmak ve bunlar üzerinden gerekli işlemleri yapmak.

Map-Reduce desteği: Böl gönder, topla gönder. Burada kullanıcının sisteme yüklediği veriler mapperlar ile parçalara bölünür ve gerekli alanlara dağıtılır, bu sayede işlemler daha hızlı yapılır ve sistemin her alanına aktarılan yük dahada azaltılmış olur, sistem tarafından gerekli işlemler yapıldıktan sonra bu veriler Reducer’lar ile tekrar bir araya getirilir ve kullanıcıya aktarılır.

Text Search: MongoDB içerisinde bir metin arama desteği bulunmaktadır. Bunun için bir string ifadeyi $text fonksiyonunu kullanarak arayabilirsiniz. Bana sorarsanız mongodb’nin en güzel özelliklerinden biri de budur istediğiniz zaman hiç bir zorluk yaşamadan bir metin arayabilir ve bulabilirsiniz bu işlemi RDBMS sistemlerde MsSQLde yapmak için Full text search özelliğini kullanmak gerek bazen bunun için taklalar atmanız bile gerekebiliyor.

Data Models: MongoDB’nin veri tutma biçimi Sqlden farklı bir halde bulunmaktadır. Bir dizi içerisinde string ve integer ifade bulunabilir. Bu özellikte RDBMS sistemlerden fark olarak düşünebileceğimiz bir özellik.

Indexes: MongoDB de indexler birkaç şekilde tanımlanabilir. Bunlar;

–Single Field

–Compound Index

–Multikey Index   

–Geospatial Index

–Text Index

–Hashed Index

Replication: MongoDB’nin herhangi bir server hatası durumunda kendini güvenceye alması. RDBMS sistemlerdeki Disaster Recovery’ler benzeri olarak da düşünülebilir. Ana sunucunun her hangi bir sorunla karşılaşması tehlikesine karşın yedek sunucular ile verilerin yedeklenmesi ve ana sunucuda sorun gerçekleştiğinde yedek sunucunun ana sunucu görevini üstlenip veri kayıplarını engellemesi için gerekli bir özelliktir.

Master-Slave Replication desteği: Yazma ve okuma işlemlerini ayrı sunuculara yönlendirebilme. Replication özelliğinin bir alt özelliği olarak da düşünülebilir. Yine aynı şekilde ana sunucu ve yedek sunucular oluşturulabilir. Burada ek olarak yazma ve okuma işlemleri ayrı sunuculardan yapılabilir böylelikle sunucular üzerindeki trafik ve yük azaltılacağından performans açısından önemli bir artış daha sağlanabilir.

Sharding desteği: Büyük ölçekli verilerin sunucular arasında paylaştırılması özelliği. MongoDB de performansın en öncelikli konu olduğundan bahsetmiştik bu nedenle bazen veriler çok büyük boyutlara ulaştığında tek bir sunucu artık bizim için yetersiz bir hal alabilir bu nedenle yeni sunucular ile yatay büyümeye giderek veriler bu sunuculara dağıtılır ve yük azaltılmış olur.

 

Yatay(Horizontal) – Dikey(Vertical) büyüme

NoSQL sistemler ve MongoDB yatay Büyüme ile RDBMS sistemler Dikey büyüme ile büyüme işlemi yapar demiştik peki nedir bu büyüme çeşitleri;

Dikey büyüme: Sunucu özelliklerini arttırma. Burada elimizde bulunan mevcut sunucunun özellikleri(CPU, Memory, Disk vb.) arttırılır. Bu bi açıdan her konuda çok maliyetli olabilir ve bir sunucunun özelliklerinini ne kadar arttırabilirsiniz ki ? eğer küçük veriler üzerinden çalışıyorsanız belki orta ölçekli bir sunucu işinizi görebilir fakat çok büyük verilere sahip sistemler düşünüldüğünde dikey büyüme aşırı bir uğraş ve maliyet gerektirebilir.

Yatay büyüme: Sunucu arttırma. Bu işlemde ise mevcut sunucunuz üzerinde herhangi bir değişiklik ve özellik arttırımı yapmakla uğraşmadan aynı özelliklerde ya da ihtiyaç doğrultusunda farklı özelliklerde bir sunucuyu daha sunucunuza bağlayarak ihtiyacınızı giderebilirsiniz. Google’lın sunucu dünyasına baktığımızda yatay büyüme ile sunucularını arttırdığını görebiliriz.

 

Sql’de ve MongoDB’de tanımlama farklılıkları da aşağıdaki gibidir.

 

Şimdi isterseniz MongoDB yi iki tane NoSQL veritabanı sistemi olan Cassandra ve CouchDB ile karşılaştıralım kısaca;

Cassandra

Cassandra da NoSql bir veri tabanı sistemi olup Facebook ve Apache tarafından geliştirilen açık kaynak kodlu bir veri tabanı sistemidir. Burada da veriler JSON ve XML olarak tutulmaktadır. Büyük dağıtık verilerin depolanması için MongoDB ve diğer NoSql veri tabanları gibi tercih edilen veri tabanı sistemlerinden biridir.

CouchBase

Couchdb NoSQL tabanlı, verileri JSON formatında tutan , MapReduce indeksleri için JavaScript ve kendi API’si için HTTP kullanan, Erlang ile yazılmış open source bir veritabanı sistemidir.

Aşağıdaki görselde üç Databasede yapılan %50 okuma ve %50 yazma işlemi baz alınmış ve saniyede yapılan işlem sayısı verilmiştir.

Buradaki görselde ise bu işlemlerin yapılış sırasında performans sürekliliği gözlemlenmiştir. Bakıldığı zaman iki veri tabanında işlem uzadıkça bir süre sonra işlemi gerçekleştirme süresi artmakta ve performansta yavaşlama olmaktadır fakat MongoDB sürekli aynı performans ile çalışmaya devam etmektedir.

Yine bir işlemde %95 okuma ve %5 yazma işleminde MongoDBnin saniye bazında daha fazla işlem yaptığını görebiliriz.

Aynı şekilde performans sürekliliğini de hiç hiç kaybetmemektedir.

 

 

MongoDB Kurulumu ve Kullanımı

Öncelikle https://www.mongodb.com/download-center?jmp=nav  adresinden size uygun MongoDB sürümünü indirmeniz gerekiyor. Kurulum esnasından bazı bilgisayarlarda C: diskine bir data klasörü açmanız istenir istersenin önceden bunu hazırlayabilirsiniz çünkü verileriniz burada tutulacaktır. Ardından Command Prompt’tan (CMD) mongoDB klasörü altındaki “mongod”u çalıştırın.

 

bunu çalıştırdıktan sonra aşağıdaki mesajı aldığınızda sistem server bağlantısının oluşturulduğunu belirtmektedir.

 

Ardından yeni bir CMD sekmesi açarak aynı klasör altındaki “mongo”yu çalıştırıyoruz.

Connection to: test mesajı sistemin artık her türlü işlemi yapmaya hazır olduğunu belirtiyor bundan sonra istediğimiz işlemleri yapabiliriz.

MongoDBde yeni bir veritabanı oluşturmak için “use db_adi”

db_adi = istediğiniz database adı

komutunu yazmanız yeterli olur eğer yazdığınız isimde bir veritabanınız bulunuyorsa sistem otomatik olarak bunu kullanıma alır ve yaptığınız değişiklikler o veritabanına yansır fakat o isimde bir veritabanı yoksa aynı kod satırı veri tabanınızı oluşturur. Eğer veri tabanını oluşturursanız fakat içine herhangi bir veri atmazsanız veritabanlarınızı listelediğinizde bu veri tabanı liste içinde yer almaz

“show dbs” ile var olan veritabanlarınızı listeleyebilirsiniz.

Yukarıdaki şekilde de görebilirsiniz normalde “yeniveritabani” adında bir veritabanımız yok ve biz bunu oluşturuyoruz fakat içine herhangi bir veri girmediğimiz için listeleme esnasında bunu göremiyoruz.  Şimdi içine bir Collection ekleyelim;

burada “db.yenicollection.insert” komutu ile yine aynı şekilde olmamasına rağmen yeni bir collection oluşturmuş ve bunun içine veri eklemiş olduk. Veritabanlarımızı listelediğimizde ise artık “yeniveritabani” adlı veritabanımızı görebiliriz.

kullanmakta olduğunuz veri tabanınızdaki collectionları görmek içinde “show collections” demeniz yeterli olacaktır.

İnsert işlemi

db.kolonadi.insert({ad:”celal”,soyad:”akay”}) basit bir insert işlemi için syntax bu şekilde olmaktadır bir veri tabanında kolona eklediğiniz veri sayısı eşit olmak zorunda değil biz burda ad ve soyad adında iki key ekledik bir sonraki işlemde daha fazla keye sahip bşr veri eklersek de herhangi bir sorun olmaz fakat RDBMS işlemler bunu kabul etmez ilk başta tablomuzda kaç kolon belirttiysek o kolon sayısı kadar veri ekleyebiliriz.

yukarıda da gördüğünüz gibi sorunsuz bir şekilde aynı collectiona istediğimiz kadar keye sahip yeni bir veri ekleyebiliriz.

Bir diğer insert işlemi olarak Sqlden farklı olarak tek key içerisine birden fazla bilgi girebilirsiniz, örneğin bir çalışan bilgisi girdiğinizde çalışanınıza ait birkaç adet mail ya da birkaç adet telefon olabilir bunların tamamını tek key içerisine girebilir başka bir alanda tutma zorunluluğundan kurtulabilirsiniz;

Öte yandan eklediğimiz verilere sistem otomatik olarak bir ID veriyor demiştik bunu biz istersek kendimiz tanımlayabiliyoruz. Örnek olarak aşağıdaki görsele bakabilirsiniz;

 

 

Select işlemi

Select işlemi için “db.collectionadi.find()” yazmamız yeterli olur bu durumda o collection içerisindeki tüm verilerimiz listelenecektir.

Eğer verilerimiz düzenli okunur bir şekilde gelsin istersek “db.collectionadi.find().pretty()” yazdığımız taktirde veriler  bize Json formatında dönecektir ve okunurluluğu artacaktır.

 

Update işlemi

MongoDB’de Update işlemi de oldukça basit bir syntax’a sahip burada Sqlden farklı bir yazım olmasıyla beraber işlem sırası da farklıdır çünkü Sql de önce hangi değerin atanacağı belirtilir sonrasında hangi şartı sağlayan verilere bu değerin atanacağı belirtilir, MongoDBde ise önce şart söylenir ardından atanacak değer belirtilir. Yazım şekli ve sonucu alttaki şekildedir;

 

Delete işlemi

“db.collectionadi.remove({})” kod satırı yazdığınız collection içindeki tüm verileri silmek için kullanılabilir fakat siz belli bir şarta bağlı olarak veri silmek isterseniz o zaman remove parantezinin içine şartınızı belirtmeniz gerekir. şöyleki;

 

MongoDB için herhangi bir management tool isterseniz de size öneri olarak Robomongo’yu kullanmanızı tavsiye ederim kullanımı kolay ve ihtiyaçlarınıza cevap vereceğini düşünüyorum. Örnek ekran görüntüsü; 

SQL Row Number

SQL Row Number kullanımı oldukça kolay ve ihtiyaç durumunda oldukça yararlı bir metodtur, row number metodu tablonuz içerisindeki satırların kaçıncı sıradaki satır olduğunu belirleme konusunda kullanabileceğiniz bir metodtur ancak Over() metodu ile kullanılması gerekir ve kullanımı şu şekildedir;

 

SELECT row_number() over(order by veriID) AS index, * FROM tabloAdi

SQL Server: İndex Yapısı ve Çeşitleri(Clustered, Nonclustered)

-Clustered(Kümelenmiş) İndeks: Kümelenmiş indeks yapısında olan tablolardaki kayıtlar, fiziksel olarak indeksleme alanına göre dizilmiş şekildedir. Bu yapılanma dengeli ağaç(B-Tree) yapısına sahiptir. Kümelenmiş indeks oluşturulurken asıl verilerin olduğu veri sayfasına(data page) göstergeleri(pointer) kullanarak ulaşılmasına gerek kalmaz.  Çünkü kümelenmiş indeks gerçek verilerin sahip olduğu veri sayfaları üzerinden elde edilmiştir. Bu şekilde bir kümelenmiş indeks tarandığında ulaşılan yer verinin kendisidir. Yapılan taramalarda hızlı bir sonuç alınır. Eğer bir tabloda anahtar değer(primary key) varsa bu bir kümelenmiş indeks yapısıdır. Bir tablo üstünde bir kümelenmiş indeks tanımlanabilir. Bu nedenle tablo üzerinde yapılacak sorgular gözden geçirilip hangi sorguya göre aranacağına karar verilmelidir. Kümelenmiş indeks ya artan ya da azalan sırada olmalıdır.

-“Nonclustered”  İndeks: Bir veri yapısında kümelenmiş indeks oluşturulduktan sonra farklı bir alan üzerinden tekrar indeksleme yapılmak isteniyorsa “nonclustured” indeks kullanılır ve veri sayfalarının dışında bunun için tekrar bir dengeli ağaç yapısı oluşturulur. Herhangi bir arama yapıldığında ilk önce dengeli ağaçtaki indeksler taranır  ve bu ağaç üzerindeki  düğümün(node) gösterdiği veri sayfasına  gösterge vasıtasıyla gidilir. Bu şekilde istenilen veriler elde edilmiş olur. Nonclustered indekste verilere direk erişilemez. Elde edilen indeksleme yapısına erişmek için kümelenmiş indeks yapısı kullanılmış olur. Verileri herhangi bir alana göre sıralandığında erişim kümelenmiş indeks üzerinden anahtar değer  referans alınarak yapılır. Bu nedenle “nonclustered” indeks zaman ve performans kaybına neden olabilir. “nonclustered” indeks bir tabloda en fazla 249 adet oluşturulabilir.

-Tek(Unique) İndeks: İndeksteki indeksleme alanı olarak seçilen sütundaki verilerin tekrar kullanılmaması için bu yapı kullanılır. Veriye erişim hızını arttırır. Bu indeksleme çeşidi kümelenmiş ve “nonclustered” indeksler üzerinde kullanılabilir.

CREATE UNIQUE INDEX [indexadi] ON [dbo].[tabloAdi]
(
[kolonAdi] ASC
)

CREATE NONCLUSTERED INDEX [indexAdi] ON [dbo].[kolonAdi]
(
[kolonAdi] ASC
)