BACK UP, RESTORE
Sürekli degisen bir veri tabani ile çalisiyor isek ve bir gün veri tabanimizin bolzulma imkani var ise verilerimizi bir yerde yedeklemek çok anlamlidir.Veri tabani üzerinde backup islemi yaparak,herhangi bir olasi veri tabani bozulmasi durumunda,bu backup’i kullanarak(resore ederek) o an ki verilerimize ulasabiliriz.
Bir kullanicinin veri tabani üzerinde backup yapabilmesi için kullaniciya db_backupoperator rolüne dahil etmemiz yeterli olacaktir.
Full BackUp
Full back up’da bütün veriler extent extent sirasiyla kopyalanir.
BACKUP DATABASE [database name] TO DISK [’\\\\\\\\\\\\\\\\\\directory\\\\\\\\\\\\\\\\\\filename’] WITH INIT
INIT : Eger daha öncesinde bir kopyasi alindi ve böyle bir dosya var ise,üzerine yazilir.
Differential Backup
Differential backup yapilabilmesi için öncelikle full back up yapilmasi gerekmektedir.Saat 6’da full backup yaptim ve 4 saatte bir differential back up yapiyor isem;
6’da bütün verilerin kopyasi elde edilir.
10’da ise,6’dan itibaren degisen extend’ler var ise onlar yenileriyle degistirilir.
14’de ise,6’dan itibaren degisen extend’ler var ise onlar yenileriyle degistirilir.
18’de ise, 6’dan itibaren degisen extend’ler var ise onlar yenileriyle degistirilir.
Yani en son full backup’dan sonra degisen bir seyler var ise,yeni extent’ler kopyalanir.
BACKUP DATABASE [database name] TO DISK [’\\\\\\\\\\\\\\\\\\directory\\\\\\\\\\\\\\\\\\filename’] WITH DIFFERENTIAL
Differential backup,eger full backup yapilir ise gerçeklestirilebilecegini söylemistik.Diffrential backup’da her bir extent’in degisip degismedigi kontrol edilir.veri tabani, her bir extent’in durumunu tutmak için 1 veya 0 kullanir.Eger Full backup alinirsa her bir extent için deger 0 olarak ayarlanir.Yani hiç birinde degisiklik yok denir.Daha sonra bu extent’ler üzerinde bir degisiklik oldugunda bu bit degeri 1 olarak ayarlanir.Ardindan Differential back up alinmak istendiginde,hangi extent’in durumu 1 ise o extent yenisiyle degistirilir.Bir Data Page boyutu 8 KB oldugundan ve 8 KB’da 8192 bit oldugundan,aslinda bir Data Page kullanarak 8192 extent’in durumu tutulmus oluyor.
Transaction Log Backup
Transaction Log Backup,Veri tabaninin Recovery modu Full veya Bulk-Logged oldugu durumlarda alinabilmektedir.Eger Transaction Log backup gerçeklestirmek istiyor iseniz,öncelikle Full backup alinmali ardindan Transaction Log backup alinmalidir.
BACKUP LOG [database name] TO DISK [’\\\\\\\\\\\\\\\\\\directory\\\\\\\\\\\\\\\\\\filename’] WITH INIT
Transaction Log backup’da bir önceki backup’da Log Sequence Number(LSN) nerede kalmis ise oradan baslanir ve açik bir transaction görene kadar devam eder.Açik bir transaction gördügünde ise backup islemi tamamlanir.
Filegroup Backup
Filegroup backup’da veri tabaninin tamamini degilde sadece beliritlen filegroup içerisinde giren verilerin backup’i alinir.
BACKUP DATABASE [database name] FILEGROUP=[filegroupname] TO DISK [’\\\\\\\\\\\\\\\\\\directory\\\\\\\\\\\\\\\\\\filename’]
Differential backup’da oldugu gibi,filegroup’lar üzerinde de differential backup uygulabailir.
BACKUP DATABASE [database name] FILEGROUP=[filegroupname] TO DISK [’\\\\\\\\\\\\\\\\\\directory\\\\\\\\\\\\\\\\\\filename’] WITH DIFFERENTIAL
Mirrored Backups
Simdiye kadar gördügümüz backup’lar ayni anda sadece bir tane kopya islemi yapmaktaydi.SQL Server 2005 ile birlikte ayni anda en fazla 4 olmak sartiyla birden fazla kopyalama islemi yapabiliyoruz.Yalniz yapilan bütün kopyalamalarda,kopyalanan yerin türü ayni olmalidir.DISK’e kopyalanayorsa, hepsi DISK olmalidir.TAPE ise hepsi TAPE olmalidir gibi.
AdventureWorks veri tabaninin 4 kopyasini alalim;
BACKUP DATABASE AdventureWorks TO DISK=’C:\\\\\\\\\\\\\\\\\\Backup\\\\\\\\\\\\\\\\\\AW.bak’
MIRROR TO DISK=’\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\Server1\\\\\\\\\\\\\\\\\\Backup\\\\\\\\\\\\\\\\\\AWMirror1.bak’
MIRROR TO DISK=’\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\Server2\\\\\\\\\\\\\\\\\\Backup\\\\\\\\\\\\\\\\\\AWMirror2.bak’
MIRROR TO DISK=’\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\Server3\\\\\\\\\\\\\\\\\\Backup\\\\\\\\\\\\\\\\\\AWMirror3.bak’
WITH FORMAT
FORMAT: belirtilen yerdeki header’i siler,daha önce alinmis olan backuplari geçerisiz kilar.
Partial Backup
Read only olarak ayarlanmis filegroup’larin backup’inin alinmasi anlamsizdir.Bunu engellemek adina,read only olan filegroup’larin backup’ini alma demek için su komutu kullaniyoruz;
BACKUP DATABASE AdventureWorks READ_WRITE_FILEGROUPS TO DISK=’C:\\\\\\\\\\\\\\\\\\Backup\\\\\\\\\\\\\\\\\\AW.bak’
ÖRNEK : AdventureWorks veri tabani için sirasiyla full/differential/transaction log backup alalim
Product tablosunda;
-- ilk backup aliniyor,orjinal degerler tutuluyor
BACKUP DATABASE AdventureWorks TO DISK=’C:\\\\\\\\\\\\\\\\\\Data\\\\\\\\\\\\\\\\\\AW.BAK’
-- Daha sonra butun urunlerin ListPrice degerini 100 yapiyorum
UPDATE Production.Product SET ListPrice=100
-- Transaction log dosyasinin backup’ini aliyorum.ListPrice=100 diye –
-- yaptigim degisiklik bu log dosyslarinda tutuluyor.
BACKUP LOG AdventureWorks TO DISK=’C:\\\\\\\\\\\\\\\\\\Data\\\\\\\\\\\\\\\\\\AW1.TRN’
-- Daha sonra butun urunlerin ListPrice degerini bu sefer 200 yapiyorum
UPDATE Production.Product SET ListPrice=200
-- Son fullback’tan sonraki degisiklikleri AWDIFF1.BAK içerisinde
-- tutuyorum.Yani bu backup içerisinde ListPrice’lar 200 olarak duruyor.
BACKUP DATABASE AdventureWorks TO DISK=’C:\\\\\\\\\\\\\\\\\\Data\\\\\\\\\\\\\\\\\\AWDIFF1.BAK’ WITH DIFFERENTIAL
-- ListPrice’i 300 yapiyorum
UPDATE Production.Product SET ListPrice=300
-- Tekrar logun backup’ini aliyorum
BACKUP LOG AdventureWorks TO DISK=’C:\\\\\\\\\\\\\\\\\\Data\\\\\\\\\\\\\\\\\\AW2.TRN’
Not: 6 Kasimda veri tabanimin full backup‘ini aldiktan sonra her gün sirasiyla differential backup aliyorum.Dolayisila 10 kasima geldigimde elimde bir tane full backup bir tanede differential backup olacaktir.10 kasimda sistemde bir ariza oldu ve veri tabanini kaybettik.Backup dosyalarini kullanarak 9 kasimdaki verileri elde edebiliriz.Bunun için öncelikle Full backup’i restore edip ardindan 9 kasimdaki differential backup’i restore etmem gerekecektir.
Recovery Models
Simple Recovery: Eger veri tabani recovery modu Simple olarak ayarlandi ise Transaction Log minimum düzeyde tutulur.Yapilan degisiklikle log dosyasinda tutulmaz.Dolayisiyla bir backup dosyasini alip,Log backup’ide bu verilerin üstüne uygulayamazsiniz.Eger veri tabaninizin recovery modunu Simple olarak ayarladi iseniz,ve sistemde bir hata olusur ise,bu durumda sadece en son aldiginiz backup’a göre verileri elde edersiniz.
Simple recovery modunda Transaction Log Backup alamazsiniz.Sadece full ve differential backup alabilirsiniz.Dolayisiyla sistemde olusabilecek hatalari düsünerek çok kisa araliklarla backup almamalisiniz ki performans düsmesin,çok uzun araliklarla da backup almamalisiniz,çünkü elinizde transaction log yoktur,dolayisiyla sistemin ariza vermesi durumunda çok gerilerdeki verileri elde edebilirsiniz.
Full Recovery: Bu modelde,bütün islemler transaction log’da tutulur.Bit hata durumunda öncelikle Full backup dosyasi restore edilir ve transaction log back’i restore edilip beliritlen zamana göre recovery yapilir.verileri belirtilen bir zamana döndürmek bu modelde mümkündür.
Bulk-Load: Full Recovery modu gibidir fakat BULK LOAD islemlerinde log tutma islemi minimum düzeyde yapilir.BULK LOAD islemi sirasinda gerçeklesen bütün islemleri adim adim tutmaz.Dolayisiyla BULK LOAD isleminin tamami bir islemdir.Herhangi bir hata durumunda beliritlen bir zamana dönmek zordur.Transaction log dosyasi BULK LOAD islemlerinde her bir islemi tek tek tutmadigi için öncelikle Full back dosyasi var ise o restore edilir,ardindan varsa differential backup dosyasi restore edilir ve son transaction backup dosyasi restore ve recovery edilir.
Sistemde bir hata olustugu zaman, son ana geri dönebilmek için,sistemin transaction log backup’i alinmalidir.Yalniz bu backup’in alinabilmesi için data file’larda bir problem olmamasi gerekir. Dedigimiz gibi BULK LOAD islemleri için tek tek log tutulmuyordu.Dolayisiyla son olarak bir transaction log backup’i alinamiyorsa,verilerimizin son durumunu elde edemeyiz.
Yukarida backup’ini aldigimiz AdventureWorks veri tabaninda bir hata olustutugnu varsayalim ve restore,recovery islemlerini yapalim.
Ilk haline dönmek için;
RESTORE DATABASE AdventureWorks FROM DISK=’C:\\\\\\\\\\\\\\\\\\Data\\\\\\\\\\\\\\\\\\AW.BAK’ WITH RECOVERY
RECOVERY dedigimizde veri tabani çalismaya baslar,baglantilar yapilabilir,yani normal çalismasini sürdürür.Fakat NORECOVERY olarak belirler isem bu durumda veri tabaninin durumu Restoring’dir ve disariya kapalidir,kullanilamaz.
ListPrice 100 oldugu duruma geri dönmek için;
RESTORE DATABASE AdventureWorks FROM DISK=’C:\\\\\\\\\\\\\\\\\\Data\\\\\\\\\\\\\\\\\\AW.BAK’ WITH NORECOVERY
RESTORE LOG AdventureWorks FROM DISK=’C:\\\\\\\\\\\\\\\\\\Data\\\\\\\\\\\\\\\\\\AW1.TRN’ WITH RECOVERY
ListPrice’in 200 oldugu duruma dönmek için; differential bir backup’i restore edebiliriz.Differential backup,full backup’in üstüne kurulmalidir ve Full back’i NORECOVERY pozisyonunda almak gerekir.
RESTORE DATABASE AdventureWorks FROM DISK=’C:\\\\\\\\\\\\\\\\\\Data\\\\\\\\\\\\\\\\\\AW.BAK’ WITH NORECOVERY
RESTORE DATABASE AdventureWorks FROM DISK=’C:\\\\\\\\\\\\\\\\\\Data\\\\\\\\\\\\\\\\\\AWDIFF1.BAK’ WITH RECOVERY
ListPrice’in 300 oldugu duruma dönmek için;
RESTORE DATABASE AdventureWorks FROM DISK=’C:\\\\\\\\\\\\\\\\\\Data\\\\\\\\\\\\\\\\\\AW.BAK’ WITH NORECOVERY
RESTORE DATABASE AdventureWorks FROM DISK=’C:\\\\\\\\\\\\\\\\\\Data\\\\\\\\\\\\\\\\\\AWDIFF1.BAK’ WITH NORECOVERY
RESTORE LOG AdventureWorks FROM DISK=’C:\\\\\\\\\\\\\\\\\\Data\\\\\\\\\\\\\\\\\\AW2.TRN’ WITH RECOVERY
Validating Backup
Alinan bir backup’in dogru olup olmadigini test etmek için asagidaki komutu kullanabiliriz;
RESTORE VERIFYONLY FROM DISK=’C:\\\\\\\\\\\\\\\\\\Data\\\\\\\\\\\\\\\\\\AW.BAK’
VERI TABANI TASIMA
Veri tabanini bir yerden alip bir yere göç ettirmek istiyor isek,3 seçenegimiz vardir.Bunlardan biri backup-recovery’dir ki onu bir önceki bölüme anlattim.Diger ikisi ise Detach/Attach ve Copy Database seçenekleridir.Simdi isterseniz onlara göz atalim.
Detach/Attach
Mdf dosyalarini detach ettigimizde system tablolarinda bu veri tabanina iliskin kayit silinir ama dosya silinmez.Attach ettigimizde ise,bu veri tabanina iliskin bilgiler system tablolarina kaydedilir.Veriler üzerinde herhangi bir islem yapilmadigi için,islem 1-2 sn sürmektedir.
Bir veri tabanini detach etmek istiyor isek;
EXEC sp_detach_db ’AdventureWorks’
Tekrar Attach etmek için;
CREATE DATABASE AdventureWorks ON
(FILENAME=’C:\\\\\\\\\\\\\\\\\\Data\\\\\\\\\\\\\\\\\\AdventureWorks_Data.mdf’),
(FILENAME=’C:\\\\\\\\\\\\\\\\\\Data\\\\\\\\\\\\\\\\\\AdventureWorks_Log.ldf’)
FOR ATTACH
Copy Database Wizard
Bu sistemde bir wizard araciligiyla verit abani nesnelerinin hepsini bir yerden bir yere tasiyabilrsiniz.Tasima veri tabani düzeyinde oldugu için,veri tabani için kullanilan server bazli veriler (örnegin login),bunlari ayrica tasimamiz gerekmektedir.
ÖRNEK: AdventureWorks veri tabanini baska bir server’a tasiyalim.
1)AdventureWorks veri tabanina sag tikla ve Task->Copy Database seçenegini seç.
2)Sirasiyla Source ve destination serverlari ve kullanilacak authentication modlarini seçelim.SQL Server authentication kullaniyor isek bu durumda kullanici adi ve sifre belirtmeliyiz.
3)Ardindan bize iki seçenek sunacaktir.
a.Use the Detach and Attach method : Bu yöntemde, yukarida anlattigim attch/detach yönetiminde ne yapiliyorsa,SQL Sever bu islemleri kendisi yapar.Kisa süreligine veri tabanini detach eder ki bu veri tabaninin online olmamasi anlamina gelir,kimse bu veri tabanina erisemez.Ardindan detach edilen veri tabani dosyasi diger server’a kopyalanir ve orada da attach islemi yapilir.Islem tamamlandiktan sonra source tarafta, veri tabani tekrar attach edilir ve online durumuna getirilir.Bu yöntem çok hizlidir fakat veri tabaninin kapatilmasini istemiyor isek,diger seçenegi seçmeliyiz. Detach/Attach yapilirken,bir hata olusmasi durumunda detach edilmis source veri tabaninin tekar attach edilip edilmemesini(reattach) hemen altindaki checkbox’da belirleyebiliyoruz.
b.Use the SQL Management Object Method: Bu yöntemde source veri tabanindaki her bir nesnenin scripti olusturulur.Içindeki kayitlarda script seklinde olusturulur.Bu islemleri yapmak için Scripting API’ler kullanilir.Sürekli script olusturularak veri tabaninin kopyasi elde ediledigi için veri tabaninin kapatilmasina gerek yoktur ve kapatilmamaktadir.Yani bu yöntemde veri tabani hep online durumundadir.Yalniz sürekli script olusturulup diger tarafta(destination) bu scriptler çalistirildigindan dolayi hoz açisindan daha yavastir.
4)Ardindan hangi veri tabanlari üzerinde islem yapacagimzii seçiyoruz.Seçerken ya Copy ya da Move seçenegini isaretliyoruz.Copy’de veri tabanin bir kopyasi destination’da da olusturulur. Move’da ise veri tabani Destination server’de olusturulur ve Source server’dan kaldirilir.
5)Daha sonra destination veri tabani için bir isim belirliyoruz.Bunun yaninda dosya isimlerini,bulunacagi path’i de belirleyebiliyoruz.Yine bu sayfada eger,destination server’da ayni isimde bir veri tabani var ise ne yapilacak sorunun cevabini vermek adina,Iki adet radio button vardir.Birincisi seçilir ve eger ayni isimde veri tabani varsa,islem iptal edilir.Ikincisi seçilir ve ayni isimde veri tabani var ise,eskisi drop edilir ve yenisi olusturulur.
6)Daha sonra bu islemin hemen mi yoksa belirtilebilecek bir tarihte mi yapilacak,bu bilgi gelen ekranda seçilir.
a.Run immediately: seçenegi seçilir ise kopyalama aninda yapilir.
b.Schedule: seçilir ise Change schedule diyerek bu islemin beliritlen zaman(lar)da ve yinelenerek yapilmasini saglanabilir.
