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.