St.AnGeR
Document Visor..
6.1. Bir Yedekleme Stratejisine Sahip Olma
6.2. Düzenli Olarak Yedek Alma
6.3. SQL Server'ı Yedekleme
6.4. Master Veritabanının Değişiminden Sonra
6.5. Backup Sırasında Sınırlanan Aktiviteler
6.6. Permanent Backup Files Yaratma
6.7. BackupDatabase ifadesinin kullanımı nasıldır ?
6.8. BACKUP ifadesinin kullanımı
6.9. FORMAT seçeneğinin kullanımı
6.10. SQL Server'ın Yedeklerini ve SQL Server'ın Olmayan Yedekleri Saklama
6.11. Yedekleme Methodları
6.12. SQL Server Transaction Log'u Nasıl Yedekler
6.13. NO_TRUNCATE Seçeneğinin Kullanımı
6.14. Bir Veritabanı Dosyası veya FileGroup Yedeği Yapma
6.15. Backup Stratejisi Tasarlama
6.16. Full Database ve Transaction Log Backup Stratejisi
6.17. Differantial Backup Stratejisi
6.18. Veritabanı Dosyalarını veya Filegruplarını Yedekleme Stratejisi
6.19. Performans Etmenleri
6.20. Tavsiye edilen uygulamalar
Veri Kaybını Engelleme
Veri kaybı sistem yöneticilerinin karşılaştığı en önemli sorunlardan biridir.
Bir Yedekleme Stratejisine Sahip Olma
Veri kaybını minimize etmek için ve kaybolan veriyi geri almak için bir yedekleme stratejisine sahip olmak gerekir. Veri, donanım veya yazılım başarısızlıkları nedeniyle veya aşağıdaki nedenler yüzünden kaybedilebilir.
! DELETE ifadesinin tesadüfi kullanımı
! UPDATE ifadesinin tesadüfi kullanımı örneğin; WHERE yancümleciği UPDATE ile kullanılmazsa.
! Yıkıcı virüsler
! Sel, deprem gibi doğal Felaketler
! Hırsızlık
Bir yedekleme stratejisine sahip olunursa, veriyi açarken harcanacak zaman ve veri kaybı minimize edilebilir. Verilerin güvenliği için yedekleme startejisi iyi belirlenmelidir. Yedekleme stratejisi tasarım, tamamlama, otomatikleştirme, ve yedeği test etme zamanına bağlıdır. Veri kaybı tamamiyle önlenemese bile, zararı minimize etmek için bir yedekleme stratejisi belirlenmeli. Yedekleme stratejisi tasarlanırken, sistemin kötü duruma düşebileceği uygun zaman miktarı göz önüne alınmalı.
Düzenli Olarak Yedek Alma
Kullanıcı veritabanları yedeklenirken aşağıdaki adımlar göz önüne alınır.
ü Sistem online transaction processing (OLTP) ortamındaysa veritabanı sık sık yedeklenebilir.
ü Eğer sistem küçük aktivitelere sahip ise veritabanı daha az sıklıkta yedeklenebilir.
ü SQL Server güncellenmediğinde, yedekler tasarlanmalı.
SQL Server Yedekleme
Kullanıcılar veritabanı ile çalışırken, SQL Server veritabanını yedeklemeye izin verir. SQL Server yedekleme işlemi dinamiktir. Kullanıcı bir veritabanını yedeklerken, SQL Server aşağıdakileri yedekler.
v Şema ve Dosya Yapısı
v Veri
v Transaction Log dosyalarının bölümleri
Yedeklenen transaction log bölümleri, yedekleme işleminin başlamasından beri olan veritabanı aktivitelerini içerir.
SQL Server orjinal dosyaların yerini kaydeder ve yedeği açma sırasında, bu yedekleri orjinal yerlerine yeniden yaratır.
SQL Server Dinamik Yedekleme İşi
SQL Server bir veritabanını yedeklediği zaman aşağıdakileri icra eder:
1. Veritabanını kontrol eder ve eski aktif transaction log kaydının, log sıra no’sunu kaydeder.
2. Diskleri doğrudan okuyarak, bütün sayfaları yedekleme ünitesine yazar
3. Log sıra no’sunun tuttuğu tüm transaction log kayıtlarını yazar.
Yedekleme ve Yedekleri Yerleştirme
SQL Server’da bir veritabanını yedeklemek için, kimin yedek almaya izni olduğunu ve yedekelerin nereye yerleştirileceğini belirlemek gerekir. Transact –SQL ifadelerini ve SQL Server Enterprise Manager‘I çalıştırarak veritabanı yedeklenebilir.
Yedekleri Kim Yapabilir
Aşağıdaki rol üyelerinin veritabanı yedekleme izni vardır:
§ Sysadmin fixed server rolü
§ Db_owner fixed veritabanı rolü
§ Db_backupoperator fixed veritabanı rolü
Eklenen rollere de yedek alabilmeleri için izin verilebilir.
Yedekler Nereye Yerleştirilir
SQL Server hard disk dosyasına, teybe, veya Named Pipe’ yedekleme yapar.
q Disk dosyaları (lokal veya network) yedekleri yerleştirmek için kullanılan ortak mediadır.
q Bir teybe yedek alındığı zaman, teyp sürücüsü SQL Server’a lokal olarak bağlanmış olmalı.
q Kullanıcıların third-party software package’lerini yedeklemelerine ve açmalarına izin vermek için, SQL Server, Named Pipe’a yedek almayı sağlar.
Veritabanlarını Yedekleme Zamanı
Veritabanlarını yedekleme sıklığı iş ortamına bağlıdır. SQL Server yedeklemesi, dinamik olmasına rağmen bazı aktiviteler yedek alma işlemleri sırasında gerçekleşmez.
Sistem Veritabanlarını Yedekleme
Sistem veritabanları, SQL Server ve tüm kullanıcı veritabanlarını hakkındaki önemli bilgileri tutar. Böylece, bunlar değiştiği zaman sistem veritabanları düzenli olarak yedeklenmeli.
Master Veritabanının Değişiminden Sonra
Master veritabanı, SQL Server üzerinde bulunan tüm veritabanları hakkındaki bilgileri içerir. Kullanıcı tanımlı nesneler yaratıldığında, master veritabanı yedeklenmeli. Bu, master veritabanına bir zarar geldiğinde kullanıcı veritabanlarını kolayca açmaya olanak sağlar.
Master veritabanı built edildikten ve açıldıktan sonra, diğer sistem veritabanı yedekleri açılabilir ve varolan kullanıcı veritabanlarının yedeği referans edilebilir.
Note: Kullanıcı veritabanlarına referans sağlayan master veritabanının yedeği olmadan, Mssql7\Binn\rebuildm.exe çalıştırılarak sistem veritabanlarının tamamı rebuild edilmeli. Bu yararlı program bir parça olarak tüm sistem veritabanlarını rebuild eder.
Belirli ifadeler veya sistem stored procedure’lar çalıştırılacağı zaman, SQL Server master veritabanını otomatik olarak değiştirir. Bu yüzden; aşağıdakileri çalıştırılacağı zaman, master veritabanının yedeğini almak gerekir.
] Veritabanını silen, yaratan, değiştiren CREATE DATABASE, ALTER DATABASE, veya DROP DATABASE ifadeleri
] Transaction log’u değiştiren sp_logdevice sistem stored procedure’I
] Serverları ekleyen veya kaldıran sp_addserver, sp_dropserver ve sp_addlinkedserver sistem stored procedure’I
Msdb Veritabanının Değişiminden Sonra
Msdb değiştirildikten sonra yedeği alınmalı; çünkü Msdb SQL Server Agent tarafından kullanılan joblar, alertler, ve operatorler hakkındaki bilgileri içerir. Eğer msdb veritabanının geçerli yedeği yoksa, bir sistem başarısızlığında bütün sistem veritabanlarını rebuid etmeli ve daha sonra herbir jobu, alerti, ve operatorü yeniden yaratmalı.
Model Veritabanının Değişiminden Sonra
Model veritabanı değiştirilirse, tüm yeni kullanıcı veritabanlarında geçerli konfigurasyonu sağlamak için model veritabanı yedeklenmeli. Master ve msdb veritabanları rebuid edildiğinde, tüm kullanıcı veritabanlarının da rebuild edilmesinden dolayı model veritabanındaki değişiklikler kaybedilir. Sistem başarısızlıklarında model veritabanının yedeği açılabilir.
Kullanıcı Veritabanlarını Yedekleme
Bir veritabanı ve index yaratıldıktan sonra ve girişi sağlayamayan işlemler çalıştırıldığında
Yedekleme yapılabilir.
Veritabanlarını Yaratıldıktan Sonra
Bir veritabanı yaratıldıktan veya veriyle yüklendikten sonra yedeklenmeli. Full database yedeği olmadan, transaction log yedekleri açılamaz; çünkü transaction logların kullanılmış olduğu bölüme sahip olmak gerekir.
İndexler Yaratıldıktan Sonra
Bir index yaratıldığı zaman veritabanı yedeklenmeli. Bir index yaratıldıktan sonra, yapılan yedekleme veri ve index yapılarını içeren yedek dosyaları oluşturur.
Bir index yarattıktan sonra, sadece transaction log yedeklenirse ve gelecekte transaction log açılırsa (restore), SQL Server index’I rebuild etmeli. İndex’I yeniden yaratmak için harcanan zaman, full database backup’I açarken harcanan zamandan daha uzun olabilir.
Note: Transaction log sadece yaratılmış indexi kaydeder, sayfa değişikliklerini değil.
Transaction Log Silindikten Sonra
BACKUP LOG WITH TRUNCATE_ONLY ifadesi kullanılarak transaction log silindikten sonra, veritabanı yedeklenmeli. Bu ifade çalıştırıldıktan sonra transaction log, veritabanı aktivitelerini içermez ve değişiklikleri geri almak için kullanılmaz.
Girişi Sağlanamayan İşlemler İcra Edildikten Sonra
Transaction log’a kaydedilemeyen işlemler, girişi sağlanamayan (nonlogged) işlemler olarak adlandırılır. Aşağıdaki, girişi sağlanamayan işlemler tarafından yapılan değişiklikler, geri alınamayabilirler.
· BACKUP LOG WITH NO_LOG ifadesi. SQL Server bir yedek kopyası yapmadan, transaction logun aktif olmayan bölümünü kaldırır.
· WRITETEXT ve UPDATETEXT ifadesi. SQL Server text sütunlarındaki veriyi değiştirir ve bu aktiviteleri transaction log içine kaydetmez. WITH LOG seçeneği ile bu aktiviteler transaction log’a yazılabilir.
· SELECT INTO ifadesi ve bulk copy programı.
Girişi sağlanamayan (nonlogged) işlemler icra edildikten sonra bir veritabanı yedeklenmeli; çünkü bir veritabanı yedeği açılırken sistem başarısız olursa, transaction log, veritabanını tamamiyle açamaz.
Backup Sırasında Sınırlanan Aktiviteler
Veritabanı aktif iken yedekleme yapılabilir. Aşağıdaki hareketler yedek almaya engel olurlar.
z CREATE DATABASE ve ALTER DATABASE ifadesi ile veritabanı yaratma ve veritabanını değiştirme
Note: Otomatik büyüme yedek alma işlemi sırasında meydana gelmez.
z İndexleri yaratma
z Girişi sağlamayan işlemleri ve SELECT INTO, WRITETEXT, ve UPDATETEXT ifadelerini icra etme
Aşağıdaki aktiviteler yedek alma işlemi ile uyuşmazlar.
z Bu aktivitelerden biri progress içindeyken yedekleme alınırsa, yedekleme işlemi durur.
z Eğer bir yedek progress içindeyse ve kullanıcı bu aktiviteleri çalıştırmaya kalkışırsa, SQL Server bu aktiviteleri yerine getirmez.
Yedekleme
Bir yedek alırken ilk önce yapılması gereken, yedeği içerecek yedek dosyaları (permanent veya temporary) oluşturmak. SQL Server, kullanıcılara uygun yedekleme metodları sağlar.
Permanent Backup Files Yaratma
Yedek oluşturmadaki ilk adım yedekleme dosyaları yaratmaktır. Yedekleme işlemi için kullanılmadan önce yaratılan yedekleme dosyası permanent backup file olarak adlandırılır. Ayrıca permanent backup file, backup devices olarak adlandırılır.
Permanent Backup Files Niçin Yaratılır
Yedekleme dosyaları yeniden kullanılmak istenirse, permanent backup files yaratılmalı. Bu işlem, sp_addumpdevice sistem stored procedure ile veya SQL Server Enterprise Manager kullanılarak yapılabilir.
sp_addumpdevice Sistem Stored Procedure’ının Kullanımı
Bu çalıştırılırsa; permanent backup files, bir disk üzerine veya teyp üzerine veya Named Pipe’a yaratılır. permanent backup files yaratılırken aşağıdaki adımlar göz önüne alınmalı.
v SQL Server, master veritabanının sysdevices sistem tablosuna, mantıksal ve fiziksel isimler yaratır.
v Yedek dosyalarının mantıksal ve fiziksel isimleri belirtilmeli
v Bir veritabanı için 32’ye kadar yedek dosyası yaratılabilir.
Syntax sp_addumpdevice {‘device_type’} [,’logical_name’] [,’physical_name’]
[,{{controller_type]} |’device_ststus’}}
]
Where device_type is {DISK | TAPE | PIPE}
Örnek: Aşağıdaki örnek hard disk üzerinde permanent backup files yaratır.
USE master
EXEC sp_addumpdevice ‘disk’, ‘mybackupfile’,
‘C:\MsSQL7\Backup\Mybackupfile.bak’
Temporary Backup Files Yaratma
Permanent backup files yaratma tercih edilirken, varolan bir permanent backup file belirtilmeden
BACKUP DATABASE ifadesi ile temporary backup files yaratılabilir.
Temporary Backup Files Niçin Yaratılır
Yedekleme dosyalarının yeniden kullanılacağı planlanmamışsa, temporary backup files yaratılabilir.
BACKUP DATABASE İfadesinin Kullanımı
Temporary backup files, BACKUP DATABASE ifadesi veya SQL Server Enterprise Manager ile yaratılabilir. SQL Server temporary file oluşturarak, yedekleme işleminin sonuçlarını buraya yerleştirir.
Geçici yedekleme dosyası oluşturulurken aşağıdakiler yapılmalı
Ì Media ( disk, teyp, veya Named Pi0pe) tipi belirtilmeli
Ì Path ve dosya adı belirtilmeli
Syntax BACKUP DATABASE {database_name | @database_name_var}
TO <backup_file> [,…n]
WHERE < backup_file > is:
{{backup_file_name | @backup_file\nam\evar} | { DISK | TAPE | PIPE } =
{‘temp_backup_file’ | @temp_backup_file_var}
Örnek: Aşağıdaki örnek bir disk üzerinde Temporary backup files yaratır ve Temporary backup files içne master veritabanı yedeklenir.
USE master
BACKUP DATABASE northwind TO DISK = ‘C:\Temp\Mycustomers.bak’
Yedekleri Yerleştirmek için Çoklu Yedekleme Dosyalarını Kullanma
SQL Server aynı anda çoklu yedekleme dosyalarına yazabilir.
Çoklu Yedekleme Dosyaları Üzerine Yedekleri Yerleştirme
Çoklu dosyalara yedekleme,yedekleme zamanını düşürür. Örneğin, bir yedekleme işlemi bir teybi normalde 4 saatte dolduruyor ise ikinci bir yedekleme teybi eklense bu süre iki saate düşer.
Syntax BACKUP DATABASE {database_name | @database_name_var}
TO <backup_file> [,…n]
[WITH
[[,] NAME= {backup_set_name | @backup_set_name_var}]
]
WHERE <backup_file> is:
{backup_file_name | @backup_file_name_var} |
{ DISK | TAPE | PIPE } = {‘temp_backup_file’ | @temp_backup_file_var}
Yedekleri yerleştirmek için çoklu dosyalar kullanıldığı zaman aşağıdaki adımları göz önüne almak gerekir.
¯ Tek bir yedekleme işleminde kullanılan bütün aygıtlar, aynı media tipinde (teyp, disk) olmalı. Tek bir backup media set’I için disk ve teyp aygıtları karıştırılamaz. Bir media, bir yada daha fazla yedek setini içeren dosya takımıdır.
¯ Yedek seti yaratılırken, permanent ve temporary dosyalar birlikte kullanılabilir.
¯ Yedek seti üyesi olarak bir dosya tanımlanırsa, dosyalar daima birlikte kullanılmalı.
¯ Dosyalar yeniden formatlanmadıkça, yedekleme işlemi için yedek setinin sadece bir üyesi kullanılamaz.
¯ Yedekleme setinin bir üyesi yeniden formatlanırsa, yedekleme setinin diğer üyelerinin içinde yer alan veri geçersizdir ve kullanılamaz.
Örneğin yedekleme seti iki dosya üzerinde yaratılmışsa, aynı yedekleme setini içeren yedekleme işlemleri, bu aynı iki dosyayı iyi bir şekilde kullanır. Ek yedekler bu iki dosyaya eklenebilir. Eğer başka bir veritabanını yedeklemek için bu dosyalardan sadece biri kullanılmak isteniyorsa, dosya yeniden formatlanmalı.
NAME Seçeneğinin Kullanımı
NAME seçeneği, yedekleme setinin ismini belirtir. Veritabanını yedekleme için çoklu dosyalar kullanılıyorsa, NAME seçeneği kullanılmalı. Bu seçenek, çoklu dosyaları başka bir yedek seti üyesi ile birleştirir.
Yedekleme seti yaratıldıktan ve adlandırıldıktan sonra, gelecek yedekleme işlemleri için backup set yeniden kullanılabilir. İsimler 128 karaktere kadar olmalı.
BACKUP İfadesinin Kullanımı
Yedekleme işlemleri, SQL Server Enterprise Manager, Yedekleme Sihirbazı veya Transact-SQL ile yapılabilir.
Syntax BACKUP DATABASE { database_name | @database_name_var }
TO <backup_file> [,…n]
[WITH
[[,] FORMAT]
[[,] {INIT | NOINIT}]
[[,] RESTART]
]
INIT veya NOINIT Seçeneğini Belirleme
Bir veritabanı yedeklenirken, yedek dosyasına ekleneceği veya üzerine yazılacağı belirlenmeli.
¤ NOINIT seçeneği kullanılırsa, SQL Server bir yedeği, varolan yedekleme dosyasına veya yedek setine ekler. (Sonuna ekler)
¤ INIT seçeneği kullanılırsa, SQL Server varolan herhangi bir veriyi yedekleme seti üzerine yazar ama başlık bilgisini tutar.
Aşağıdakiler gerçekleşirse yedekleme işlemi başarısızlığa uğrar ve veri, üzerine yazılmaz.
q Backup device üzerinde belirtilen EXPIREDATE seçeneği hala sona ermemişse
q NAME seçeneğinde belirlenen backup_set_name parametresi yedekleme aygıtı üzerindeki backup_set_name parametresine uymuyorsa.
q Önceden adlandırılan backup setin bir üyesi üzerine yazılmaya kalkışılırsa. SQL Server, dosyanın backup setin bir dosyası olup olmadığını denetler.
FORMAT Seçeneğinin Kullanımı
Yedekleme dosyasının içeriğinin üzerine yazmak için kullanılır.
ü Yeni media header, bu yedekleme işlemi için kullanılan tüm dosyalar üzerine yazılır.
ü SQL Server, varolan media’nın ve yedekleme dosyasının içeriklerinin her ikisinin de üzerine yazar.
ü FORMAT seçeneği dikkatli kullanılmalı. Media setindeki sadece bir yedek dosyasını formatlama yedekleme setini kullanılamaz duruma getirir.
Örneğin; Varolan yedekleme setinin bir parçasını içeren tekli teyp yeniden formatlanırsa yedekleme setinin tamamı kullanılamaz hale gelir.
RESTART Seçeneğinin Kullanımı
Yedekleme işlemini yeniden başlatmak için kullanılır. BACKUP ifadesi RESTART seçeneği ile çalıştırılarak yedekleme işlemi başlatılabilir.
Bir Teyp Aygıtına Yedek Alma
Teypler ucuz ve geniş depolama alanı sağladıkları için elverişlidirler. Teybe yedekleme yapılırken teyp sürücüsü SQL Server’a lokal olarak bağlanmalı.
Teyp Etiketi Üzerine Yedekleme Bilgisini Kaydetme
Bir teybe yedek alındığı zaman, SQL Server aşağıdaki yedek bilgilerini teyp etiketi üzerine kaydeder
· Veritabanı ismi
· Zaman
· Tarih
· Yedeğin tipi
SQL Server’ın Yedeklerini ve SQL Server’ın Olmayan Yedekleri Saklama
SQL Server Microsoft Tape Format olarak adlandırılan standart backup formatını kullanır. Sonuç olarak; Her iki yedek tipi de aynı teybe yedeklenebilir.
SQL Server yedekleri farklı backup set’leri olarak veya diğer client’lar tarafından üretilen backup set’leri olarak birarada bulunabilir. SQL Server yedeklerinin ve WinNT yedeklerinin her ikisi de aynı teyp üzerinde bulunabilir.
Teyp Seçeneklerini Belirleme
UNLOAD
Yedekleme tamamlandıktan sonra, SQL Server teybi otomatik olarak geri sarar ve teybi yüklemez. Bu seçenek default olarak gelir.
NOUNLOAD
Yedekten sonra teybin otomatik olarak geri sarması ve teybi yüklememesi istenmiyor ise seçilir.
BLOCKSIZE
FORMAT, SKIP, INIT seçenekleriyle teyp üzerine yazılırsa (overwrite), bu seçenek fiziksel blok boyutunu değiştirmek için kullanılır. Bir teybe yedekleme yapılırken, SQL Server uygun bir blok boyutu belirler. BLOCKSIZE seçeneği seçilerek blok boyutu da belirlenebilir.
FORMAT
Yedekleme için kullanılan bütün dosyalar üzerine başlık yazmak için kullanılır. SQL Server tüm header’ları ve yedekleri dosyalar üzerine yazar. Header, MEDIANAME ve MEDIADESCRIPTION seçeneklerinde bulunan bilgileri içerir. FORMAT seçeneğini kullanma, INIT, SKIP seçenekleri anlamına gelir ki bu seçenekleri belirtmeye gerek yoktur.
SKIP
Header’ları atlamak için kullalnılr. SQL Server, teyp aygıtları üzerinde varolan ANSI teyp etiketlerini göz ardı eder. Teybin ANSI etiketi, teybin dolum tarihi hakkındaki uyarı bilgisini sağlar.
NOSKIP
SQL Server’ın ANSI teyp etiketlerini okuması istenmiyorsa bu seçenek kullanılır. SQL Server ANSI teyp etiketlerini default olarak okur.
Yedekleme Methodları
SQL Server, farklı bir çok yedekleme methodu sunmuştur.
Full Database Backup Yapma
Eğer veritabanı read-only ise, full database backups veri kaybını önlemek için yeterli olabilir. Full database backups alındığı zaman SQL Server:
¤ Aktiviteleri yedekler.
¤ Transaction log’daki onaylanmamış transactionları yedekler.
Örnek: Aşağıdaki örnek; mantıksal ismi nwndbac olan permanent backup files’ı yaratır ve full database backups’ı icra eder.
USE master
EXEC sp_addumpdevice ‘disk’, ‘nwndbac’,
‘C:\MyBackupdir\Nwndbac.bak’
BACKUP DATABASE northwind TO nwndbac
Örnek: Aşağıdaki örnek; nwndbac dosyasına full database backups’ı yapar ve dosya üzerinde bulunan önceki yedeklerin üzerine yazar.
BACKUP DATABASE northwind TO nwndbac WITH INIT
Örnek: Aşağıdaki örnek; temporary backup disk file yaratır ve bu dosyaya full database backup işler.
BACKUP DATABASE northwind TO
DISK = ‘D:\Temp\Mytempbackup.bak’
Differantial Backup Yapma
Değişmiş veritabanının yedeğini açmak için gerekli olan zamanı, minimize etmek için differantial backup yapılmalı. Bu full database backup yapılmışsa kullanılabilir. Differantial backup’ta SQL Server:
Y Son full database backup’tan beri değiştirilen veritabanı veritabanı bölümlerini yedekler.
Y Differantial backup sırasında yer tutan aktiviteyi yedekler.
Differantial backup yapılırken aşağıdaki adımlar göz önüne alınmalı:
v Son full database backup’tan beri belirli bir row farklı zamanlarda değiştirilmişse, Differantial backup row’un sadece son değerini içerir. Bu, row hakkındaki tüm değişiklikleri içeren transaction log’dan farklıdır.
v Yedekleme zamanı minimize edilebilir; çünkü yedek setleri, full backups’dakilerden daha küçüktür ve transaction log’ların işlenme zorunluluğu yoktur.
Syntax BACKUP DATABASE {database_name | @database_name_var}
TO <backup_file> [,…n]
[WITH
[[,]DIFFERENTIAL]
]
Örnek: Aşağıdaki örnek; temporary backup file üzerinde differantial backup yaratır.
BACKUP DATABASE northwind TO
DISK=’D:\Mydata\Mydiffbackup.bak’
WITH DIFFERENTIAL
Transaction Log Yedeği Yapma
Veritabanı değişikliklerini kaydetmek için transaction loglar yedeklenir. Transaction loglar, full database backup yapılırken yedeklenirler:
q En azından bir kere full database backup yapmadıkça, transaction log’un yedeği alınmaz.
q Uygun veritabanı yedeği olmadan transaction loglar’ın yedekleri açılamaz.
SQL Server Transaction Log’u Nasıl Yedekler
Transaction Log yedeklendiği zaman, SQL Server:
(a) BACKUP LOG ifadesini çalıştırarak Transaction log’u yedekler.
(b) Transaction log’u, transaction log’un aktif bölümünün başlangıcına kadar kısaltır. Transaction log’un aktif bölümü, eski açılan transaction noktasında başlar ve transaction log sonuna kadar devam eder
(c) Transaction logun aktif olmayan bölümündeki bilgiyi atar ve disk alanını düzeltir.
Syntax BACKUP LOG {database_name | @database_name_var}
TO <backup_file> [,…n]
[WITH
[[,] {INIT | NOINIT}]
[[,] [NAME = {backup_set_name | @backup_set_name_var}]
Örnek: Aşağıdaki örnek; permanent transaction log backup file yaratır ve northwind veritabanının transaction logunu yedekler.
USE master
EXEC sp_addumpdevice ‘disk’, ‘nwndbaclog’,
‘D:\MsSQL7\Backup\Nwndbaclog.bak’
BACKUP LOG northwind TO nwndbaclog
NO_TRUNCATE Seçeneğinin Kullanımı
Veritabanı dosyaları zarara uğrarsa veya kaybolursa, veritabanı NO_TRUNCATE seçeneğiyle yedeklenmeli. Bu seçenek, tüm veritabanı aktivitelerini yedeklemek için kullanılır. SQL Server:
· Veritabanına ulaşılamasa bile transaction logun tamamını kaydeder
· Onaylanmış işlemlerin Transaction log’unu temizlemez.
· Sistem başarısızlığa uğradığında veriyi yeniden elde etmeye izin verir.
Veritabanı açılacağı zaman, veriyi geri elde etmek için NO_TRUNCATE seçeneği ile yaratılan transaction log backup uygulanır.
Transaction Log’u Temizleme
Transaction logları temizlemek için BACKUP LOG ifadesiyle, TRUNCATE_ONLY ve NO_LOG seçenekleri kullanılır. Transaction log’u makul boyutta tutmak için düzenli olarak yedeklenmeli.
ü Transaction Log dolu ise, kullanıcı veritabanlarını güncelleyemez ve sistem başarısızlığa uğradığında tamamiyle veritabanını açamaz. Transacion log, ya full database backup alınarak ve veri kaydedilerek ya da transaction log kısaltılarak temizlenmeli
ü Transaction log yedeğini alma, transaction logun çoğunluğunu kısaltamazsa, transaction log içinde açılan eski bir transaction’a sahip olmak gerekir.
TRUNCATE_ONLY Seçeneği
Transaction log’u temizlemek istiyorsak ve verinin yedek bir kopyasını tutmak istemiyorsak; TRUNCATE_ONLY seçeneğini kullanabiliriz. SQL Server yedek kopyasını almadan, aktif olmayan log parçasını siler. Bu durum, transaction log’un kullandığı alanı boşaltır.
Ñ Full database backup yapmadan önce, TRUNCATE_ONLY seçeneği kullanılarak, transaction log temizlenebilir.
Ñ Transaction log’da kayıtlı olan değişiklikler yeniden elde edilemez. Hemen BACKUP DATABASE ifadesi çalıştırılmalı.
Ñ Aynı statement içinde TRUNCATE_ONLY ve NO_LOG seçeneklerinin her ikiside kullanılamaz.
Ñ Transaction log 100 percent dolu ise, transaction log NO_LOG seçeneğiyle yedeklenmeli.
Syntax BACKUP LOG {database_name | @database_name_var}
TO <backup_file> [,…n]
[WITH {TRUNCATE_ONLY | NO_LOG | NO_TRUNCATE} ]
Örnek: Aşağıdaki örnek; yedek kopyası almadan, transaction logun aktif olmayan parçasını kaldırmak için BACKUP ifadesini kullanır.
BACKUP LOG northwind WITH TRUNCATE_ONLY
NO_LOG Seçeneği
Transaction log’daki disk alanı yeterli değilse ve TRUNCATE_ONLY seçeneği çalıştırılamıyorsa bu seçenek kullanılır. SQL Server yedek kopyası yaratmadan, transaction logun aktif olmayan parçasını siler. Bu durum transaction log’da boş alan yaratır.
Note: Transaction log içinde kayıtlı olan değişiklikler yeniden elde edilemez. Bu yüzden hemen BACKUP DATABASE ifadesi çalıştırılmalı.
Örnek: Aşağıdaki örnek; yedek kopya yaratmadan full transaction logun aktif olmayan parçasını kaldırmak için BACKUP LOG ifadesini kullanır.
BACKUP LOG northwind WITH NO_LOG
trunc.log on chkpt. Seçeneğini Ayarlama
Bir checkpoint oluştuğunda, veritabanına bütün onaylanmış işlemleri yazmak için bu seçenek true ‘ya a0yarlanır. Bu seçenek transaction logu otomatik olarak kısaltır. Bu ayar true yapıldığında transaction log yedeklenmez.
Bir Veritabanı Dosyası veya Filegrup Yedeği Yapma
Filegruplar bir yada daha fazla veritabanı dosyaları içerir. SQL Server, dosyaları veya filegrupları yedeklediği zaman,
Ñ Sadece FILE veya FILEGROUP seçeneği ile belirlenen veritabanı dosyalarını yedekler.
Ñ Tüm veritabanı yerine belirli veritabanı dosyalarını yedeklemeye izin verir.
Veritabanı dosyası veya filegrup yedekleri yapıldığı zaman:
q Mantıksal dosyalar veya filegruplar belirtilmeli.
q Transaction log yedekleri alınmalı
q Tüm veritabanı dosyalarının veya filegrupların düzenli olarak yedeklenmesi için herbir dosyayı düzenli olarak yedeklemek gerekir.
q 16 dosya veya filegruba kadar belirtilir
Syntax BACKUP DATABASE {database_name | @database_name_var}
[<file_or_filegroup> [,…m]] TO <backup_file> [,…n]]
Where <file_or_filegroup> is:
{FILE=logical_file_name | FILEGROUP = logical_filegroup_name}
Örnek: Bu örnek; bir veritabanı filegrubunun Order2 dosyasını yedekler. Phoneorders veritabanı 3 dosya içerir: Orders1, Orders2, Orders3. Transaction log, Orderlog dosyasına depolanır. Bu yedek dosyaları zaten var: Orderbackup1, Orderbackup2, Orderbackup3 ve Orderbackuplog
BACKUP DATABASE phoneorders
FILE=orders2 TO orderbackup2
BACKUP LOG phoneorders TO orderbackuplog
Veritabanı Dosyalarını veya Filegruplarını Yedekleme Üzerine Sınırlamalar
Çoklu dosyalar veya filegruplar içeren bir veritabanı yedeklendiği zaman, index yaratılmışsa tek parça olarak farklı veritabanı dosyaları birarada yedeklenmeli.
Tek Parça Olarak Indexleri ve Tabloları Yedekleme
Bir index yaratıldığı zaman, transaction loglar sadece yaratılan bir indexi ve indexi yaratmak için kullanılan sayfaların listesini kaydeder. Veritabanı açıldığı (restore) zaman bu transaction log uygulanırsa, SQL Server CREATE INDEX ifadesini çalıştırır ve orjinal index sayfalarını kullanır.
Index ve Tablo Aynı Filegrup Üzerinde Yaratılır
Bir index ve ana tablo bir filegrup içinde yaratılırsa, bütün veritabanı tek parça olarak yedeklenmeli.
Index ve Tablo Farklı Filegrup Üzerinde Yaratılır
Bir index, bir filegrup üzerinde yaratılırsa ve ana tablo başka bir filegrup üzerinde yaratılırsa herbir filegrup tek parça olarak yedeklenmeli.
Örneğin; contact veritabanı üç filegrup içerir. Filegrup1 customer tablosunu içerir ve customer tablosu üzerindeki indexler Filegrup2 ve Filegrup3 içinde yaratılmış. Bu durumda 3 filegrup da tek bir parça olarak yedeklenmeli.
Backup Stratejisi Tasarlama
Full Database Backup Stratejisi
Konu ile İlgili Uygulama
Aşağıdaki durumlar sağlanırsa full database backups alınır.
Ñ Veritabanı küçükse. Küçük veritabanını yedekleme süresi makuldür.
Ñ Veritabanı az sayıda veritabanı değişikliğine sahipse veya sadece okunabilir yani read-only ise. Full database backups oluşturma, uygun veri setinin tamamını tutar.
Transaction Log Dolu Olursa
Full database backups stratejisi tamamlanırsa, Transaction log sonunda dolar. Transaction log dolarsa, SQL Server, transaction log silinene kadar diğer veritabanı aktivitelerini engelleyebilir.
· Transaction log periyodik olarak temizlenmeli.
· Transaction log’un boyutunu minimize etmek için trunc.log on chkpt. seçeneği true’ya ayarlanmalı.
Bu seçenek işaretlendiğinde, bir checkpoint meydana geldiği zaman ve transaction log otomatik olarak kısaltıldığı zaman bütün onaylanmış işlemler veritabanına yazılır. Transaction log, son Full database backups’dan beri yapılan değişiklikleri içermez.
Uyarı: trunc.log on chkpt. seçeneği true’ya ayarlanırsa, transaction log yedeklenmez ve bu seçenek, sistem başarısızlığa uğradığında veritabanını açmada yardımcı olur.
Strateji Örneği 1
Veritabanını açmada ele alınacak adımlar aşağıda sıralanmıştır.
v Veritabanı 10 MB veri içerir.
v Full database backups işleminin tamamlanması çok az dakika sürer.
v Veritabanı çoğunlukla karar desteği için kullanılır ve her gün biraz olarak değiştirilir.
v Veritabanına yapılan günlük değişikliklerin kayıp olma olasılığı kabul edilebilirdir. Bu değişiklikler kolayca yeniden yaratılabilirler.
v Sistem admistrator, log boyutlarını denetlemek veya transaction log üzerinde bakım yapmak istemez.
v Transaction log, değişiklikleri kaydetmek için kullanılmaz ve sistem başarısızlıklarında veritabanını açmak için kullanılmaz.
v Full database backups her gün saat 18:00’da yapılır.
v Veritabanı saat 10:00’da bozulur.
İşlemi Düzeltme
Veritabanını düzeltmek için, bozulmuş veritabanı versiyonu üzerine önceki akşam saat 18:00’deki Full database backup yazılarak düzenleme yapılır.
Bu yöntem, son Full database backup’tan beri yapılan tüm veri değişikliklerinin kaybı ile sınırlıdır.
Strateji Örneği 2
Veritabanını açmada ele alınacak adımlar aşağıda sıralanmıştır. Varsayalım ki veritabanı, aşağıdakiler hariç yukarıdaki örnekteki ile benzerdir.
Ñ Veritabanı hergün biraz değiştirilir. (Ama Örnek 1 dekinden daha sık değiştirilir.)
Ñ Sistem yöneticisi, transaction log’da yeterli alan olmasını sağlar.
Ñ Trunc.log on chkpt. Seçeneği false’a ayarlanır. Sistem başarısızlığa uğrarsa, transaction log, son Full database backup’tan beri yapılan değişiklikleri kaydeder ve veritabanını düzeltmek veya yeniden açmak için kullanılır.
Ñ Transaction log, veritabanından farklı bir fiziksel aygıt üzerine yerleştirilir.
Ñ Full database backup her gün saat 18:00’da yapılır. Transaction log yedekleri düzenli olarak alınmazlar ama peiyodik olarak temizlenirler.
İşlemi Düzeltme
Veritabanını düzeltmek için aşağıdaki adımlar takip edilebilir.
1) Herhangi bir veriyi kısaltmadan transaction log’u yedekleme.
2) Bozulmuş veritabanı versiyonu üzerine, önceki akşam saat 18:00’deki dolu veritabanı yedeği yazılarak düzenleme yapılır.
3) Adım1’de yaratılan transaction log yedeğini açma ve veritabanını düzeltme.
Bu yöntem, transaction log zarara uğramazsa, önceki akşam yedeğinden beri yapılan değişiklikleri yeniden elde etmek için kullanılır.
Oldukça büyük derecede potansiyel veri kaybı olursa, periyodik transaction log yedeklerini içeren tamamlanmış bir yedekleme stratejisi göz önüne alınmalı.
Full Database ve Transaction Log Backup Stratejisi
Dolu veritabanı yedeklemesine ek olarak; Full database backup’lar arasında oluşan tüm veritabanı aktivite kayıtlarına sahip olmak için, transaction log yedeklenmeli. Bu ortak yedekleme stratejisidir.
Full database ve transaction log backup stratejisi tamamlandığı zaman, en yeni Full database backuptan bir veritabanı yeniden kurulabilir yani yenilenebilir ve daha sonra, son Full database backup’tan beri yaratılan transaction log yedeklerinin tümü uygulanır.
Sık değişen veritabanları için Full database ve transaction log backup stratejisi uygulanır.
Strateji Örneği
Veritabanını açmada ele alınacak adımlar aşağıda sıralanmıştır.
i. Veritabanı ve transaction loglar, farklı fiziksel media üzerindeki, farklı dosyalarda depolanır.
ii. Full database backup hergün saat 18:00’de yapılır.
iii. Transaction log yedekleri her gün saat 9:00’da, 12:00’de ve 15:00’de yapılır.
iv. Veritabanını içeren fiziksel ortam, saat 13:30’da zarara uğrar.
İşlemi Düzeltme
Veritabanını düzeltmek için aşağıdaki adımlar takip edilebilir.
A. Mümkünse transaction log’u yedekle. Bunun için WITH NO_TRUNCATE seçeneğini kullan.
B. Önceki akşam 18:00’de yaratılan Full database backup’ı restore et.
C. 9:00 ve 12:00’de yaratılan bütün transaction logları kullan.
D. Kurma (Restore) başlangıcında yaratılan transaction log yedeğini kullan.
Differantial Backup Stratejisi
Differantial backup stratejisi tamamlanırken, transaction log yedekleri kadar iyi bir Full database backup dahil edilmeli. Diferansiyel yedekler, son Full database backup’tan beri değişen veritabanı bölümünü içerir. Differantial yedeklemede, SQL Server:
¨ Differantial log yapıldığı zaman transaction logları tutmaz. Böylece transaction loglar periyodik olarak yedeklenmeli.
¨ Veritabanını düzeltmek için son Differantial yedeği geri alınmak istenebilir. Son Differantial backup son Full database backup’tan beri yapılan değişiklikleri içerir.
Veritabanı zarara uğrarsa, düzeltme zamanını düşürmek için bu strateji kullanılır. Geniş çkolu transaction log’ları uygulama yerine, son Full database backup’tan beri yapılan değişiklikleri uygulamak için Differantial backup kullanılabilir.
Strateji Örneği
Veritabanını açmada ele alınacak adımlar aşağıda sıralanmıştır.
q Full database backup haftada bir kere yapılır. Son Full database backup Pazar günü 1:00’de yapılmıştı.
q Differantial backup her iş günü sonunda yapılır. Differantial backup Pazartesi ve salı günleri saat 18:00’de yapılmıştı.
q Transaction log yedekleri, iş günü (8:00’den 17:00’ye) boyunca her saat yapılır. Transaction log yedeği Çarşamba 8:00’de ve 9:00’da yapılmıştı.
q Veritabanı Çarşamba günü saat 9:30’da bozuldu.
İşlemi Düzeltme
Veritabanını düzeltmek için aşağıdaki adımlar takip edilebilir.
I. Mümkünse transaction log’u yedekle. Bunun için WITH NO_TRUNCATE seçeneğini kullan.
II. Pazar 1:00’de yaratılan Full database backup’ı restore et.
III. Salı 18:00’de yaratılan Differantial backup’ restore et. Bu yedek dosyası en sonki Differantial backup’tır ve Pazar günü 1:00’de Full database backup’tan beri yapılan tüm değişiklikleri içerir.
IV. Çarşamba saat 8:00 ve 9:00’da yaratılan transaction log yedeklerini kullan.
V. Veri uyumunu sağlamak için Restore işleminin (Adım1) başında yaratılan transaction log yedeğini kullan.
Veritabanı Dosyalarını veya Filegruplarını Yedekleme Stratejisi
Bir veritabanı dosyası veya filegrup yedekleme stratejisi tamamlandığı zaman, stratejinin gereği olarak transaction log yedeklenmeli.
Bu teknik full database backup’a alternatif olarak zaman duyarlılığı sunar. Örneğin; full database backup almak için sadece 1 saat varsa (Normalde 4 saat sürer), veri uyumluluğu sağlanarak, her gece dosyalar tek tek yedeklenebilir.
Strateji Örneği
Veritabanını açmada ele alınacak adımlar aşağıda sıralanmıştır.
v Veritabanındaki veri File1, File2 ve File3 olarak bölünür.
v Full database backup her hafta yapılır. Son Full database backup Pazartesi 1:00’de yapılmıştı.
v Seçilen dosyalar her gün saat 1:00’de düzenli olarak yedeklenir.
ü File1, Salı 1:00’de yedeklendi.
ü File2, Çarşamaba 1:00’de yedeklendi.
ü File3, Perşembe 1:00’de yedeklendi.
v Transaction log yedekleri her gün saat 12:00 ve 18:00’de yapılır.
v Perşembe 8:00’de File2’nin fiziksel ortamı zarara uğrar.
İşlemi Düzeltme
Veritabanını düzeltmek için aşağıdaki adımlar takip edilebilir.
i. Mümkünse transaction log’u yedekle. Bunun için WITH NO_TRUNCATE seçeneğini kullan.
ii. Çarşamba saat 1:00’de yaratılan File2 yedeğini restore et.
iii. Çarşamba saat 1:00’de yaratılan bütün transaction log yedeklerini kullan (apply).
iv. Veriyi düzeltmek için, restore işleminin başlangıcında tümtransaction logları kullan. Bu File2’deki dosyaları veritabanındaki ile uyumlu hale getirir.
Performans Etmenleri
Veritabanları yedeklendiği zaman, SQL Server’ın performansını etkileyen işler aşağıda incelenmiştir.
q Çoklu fiziksel aygıtlara yedekleme yapma, tekli fiziksel aygıtlara yedekleme yapmaktan daha hızlı. Paralel olarak her bir yedekleme aygıtına veri yazarak, çoklu yedekleme aygıtlarının avantajlarını sağlar.
q Yedekleme zamanı fiziksel aygıtın hızına bağlıdır. Teyp aygıtları, disk aygıtlarından daha yavaştır.
q Veritabanı yedeklendiği zaman raslantısal aktiviteler minimize edilir. SQL Server’daki raslantısal aktiviteler, yedekleme zamanını etkiler.
Tavsiye Edilen Uygulamaları
ü Veri kaybını minimize etmek ve kayıp veriyi kolayca elde etmek için yedekleme stratejisine sahip ol. Yedekleme stratejisine sahip isen, veriyi restore ederken harcanacak zaman ve veri kaybı azaltılabilir.
ü Sistem veritabanları değiştikten sonra yedeklerini al. Hatırlarsak; sistem stored procedure’larını çalıştırarak sistem veritabanlarını değiştirebiliriz.
ü Veritabanı aktivitesi yavaş olduğunda, yedekleme işlemlerini tasarla. Veritabanı aktif olduğunda yedekleme yapabilmene rağmen, birkaç işlem yedekleme işlemini engelleyebilir.
ü Yedekleme dosyalarını yeniden kullanmak için, permanent backup files yarat ve veritabanı yedekleme task’ını otomatikleştir.
VLDB’yi (very large databases – çok geniş veritabanları), yedekleme zamanı kazanmak için veritabanı dosyasını veya filegrubunu yedekle. VLDB gereğinden fazla zaman istiyorsa, özel dosyaları periyodik olarak yedekle.
6.2. Düzenli Olarak Yedek Alma
6.3. SQL Server'ı Yedekleme
6.4. Master Veritabanının Değişiminden Sonra
6.5. Backup Sırasında Sınırlanan Aktiviteler
6.6. Permanent Backup Files Yaratma
6.7. BackupDatabase ifadesinin kullanımı nasıldır ?
6.8. BACKUP ifadesinin kullanımı
6.9. FORMAT seçeneğinin kullanımı
6.10. SQL Server'ın Yedeklerini ve SQL Server'ın Olmayan Yedekleri Saklama
6.11. Yedekleme Methodları
6.12. SQL Server Transaction Log'u Nasıl Yedekler
6.13. NO_TRUNCATE Seçeneğinin Kullanımı
6.14. Bir Veritabanı Dosyası veya FileGroup Yedeği Yapma
6.15. Backup Stratejisi Tasarlama
6.16. Full Database ve Transaction Log Backup Stratejisi
6.17. Differantial Backup Stratejisi
6.18. Veritabanı Dosyalarını veya Filegruplarını Yedekleme Stratejisi
6.19. Performans Etmenleri
6.20. Tavsiye edilen uygulamalar
Veri Kaybını Engelleme
Veri kaybı sistem yöneticilerinin karşılaştığı en önemli sorunlardan biridir.
Bir Yedekleme Stratejisine Sahip Olma
Veri kaybını minimize etmek için ve kaybolan veriyi geri almak için bir yedekleme stratejisine sahip olmak gerekir. Veri, donanım veya yazılım başarısızlıkları nedeniyle veya aşağıdaki nedenler yüzünden kaybedilebilir.
! DELETE ifadesinin tesadüfi kullanımı
! UPDATE ifadesinin tesadüfi kullanımı örneğin; WHERE yancümleciği UPDATE ile kullanılmazsa.
! Yıkıcı virüsler
! Sel, deprem gibi doğal Felaketler
! Hırsızlık
Bir yedekleme stratejisine sahip olunursa, veriyi açarken harcanacak zaman ve veri kaybı minimize edilebilir. Verilerin güvenliği için yedekleme startejisi iyi belirlenmelidir. Yedekleme stratejisi tasarım, tamamlama, otomatikleştirme, ve yedeği test etme zamanına bağlıdır. Veri kaybı tamamiyle önlenemese bile, zararı minimize etmek için bir yedekleme stratejisi belirlenmeli. Yedekleme stratejisi tasarlanırken, sistemin kötü duruma düşebileceği uygun zaman miktarı göz önüne alınmalı.
Düzenli Olarak Yedek Alma
Kullanıcı veritabanları yedeklenirken aşağıdaki adımlar göz önüne alınır.
ü Sistem online transaction processing (OLTP) ortamındaysa veritabanı sık sık yedeklenebilir.
ü Eğer sistem küçük aktivitelere sahip ise veritabanı daha az sıklıkta yedeklenebilir.
ü SQL Server güncellenmediğinde, yedekler tasarlanmalı.
SQL Server Yedekleme
Kullanıcılar veritabanı ile çalışırken, SQL Server veritabanını yedeklemeye izin verir. SQL Server yedekleme işlemi dinamiktir. Kullanıcı bir veritabanını yedeklerken, SQL Server aşağıdakileri yedekler.
v Şema ve Dosya Yapısı
v Veri
v Transaction Log dosyalarının bölümleri
Yedeklenen transaction log bölümleri, yedekleme işleminin başlamasından beri olan veritabanı aktivitelerini içerir.
SQL Server orjinal dosyaların yerini kaydeder ve yedeği açma sırasında, bu yedekleri orjinal yerlerine yeniden yaratır.
SQL Server Dinamik Yedekleme İşi
SQL Server bir veritabanını yedeklediği zaman aşağıdakileri icra eder:
1. Veritabanını kontrol eder ve eski aktif transaction log kaydının, log sıra no’sunu kaydeder.
2. Diskleri doğrudan okuyarak, bütün sayfaları yedekleme ünitesine yazar
3. Log sıra no’sunun tuttuğu tüm transaction log kayıtlarını yazar.
Yedekleme ve Yedekleri Yerleştirme
SQL Server’da bir veritabanını yedeklemek için, kimin yedek almaya izni olduğunu ve yedekelerin nereye yerleştirileceğini belirlemek gerekir. Transact –SQL ifadelerini ve SQL Server Enterprise Manager‘I çalıştırarak veritabanı yedeklenebilir.
Yedekleri Kim Yapabilir
Aşağıdaki rol üyelerinin veritabanı yedekleme izni vardır:
§ Sysadmin fixed server rolü
§ Db_owner fixed veritabanı rolü
§ Db_backupoperator fixed veritabanı rolü
Eklenen rollere de yedek alabilmeleri için izin verilebilir.
Yedekler Nereye Yerleştirilir
SQL Server hard disk dosyasına, teybe, veya Named Pipe’ yedekleme yapar.
q Disk dosyaları (lokal veya network) yedekleri yerleştirmek için kullanılan ortak mediadır.
q Bir teybe yedek alındığı zaman, teyp sürücüsü SQL Server’a lokal olarak bağlanmış olmalı.
q Kullanıcıların third-party software package’lerini yedeklemelerine ve açmalarına izin vermek için, SQL Server, Named Pipe’a yedek almayı sağlar.
Veritabanlarını Yedekleme Zamanı
Veritabanlarını yedekleme sıklığı iş ortamına bağlıdır. SQL Server yedeklemesi, dinamik olmasına rağmen bazı aktiviteler yedek alma işlemleri sırasında gerçekleşmez.
Sistem Veritabanlarını Yedekleme
Sistem veritabanları, SQL Server ve tüm kullanıcı veritabanlarını hakkındaki önemli bilgileri tutar. Böylece, bunlar değiştiği zaman sistem veritabanları düzenli olarak yedeklenmeli.
Master Veritabanının Değişiminden Sonra
Master veritabanı, SQL Server üzerinde bulunan tüm veritabanları hakkındaki bilgileri içerir. Kullanıcı tanımlı nesneler yaratıldığında, master veritabanı yedeklenmeli. Bu, master veritabanına bir zarar geldiğinde kullanıcı veritabanlarını kolayca açmaya olanak sağlar.
Master veritabanı built edildikten ve açıldıktan sonra, diğer sistem veritabanı yedekleri açılabilir ve varolan kullanıcı veritabanlarının yedeği referans edilebilir.
Note: Kullanıcı veritabanlarına referans sağlayan master veritabanının yedeği olmadan, Mssql7\Binn\rebuildm.exe çalıştırılarak sistem veritabanlarının tamamı rebuild edilmeli. Bu yararlı program bir parça olarak tüm sistem veritabanlarını rebuild eder.
Belirli ifadeler veya sistem stored procedure’lar çalıştırılacağı zaman, SQL Server master veritabanını otomatik olarak değiştirir. Bu yüzden; aşağıdakileri çalıştırılacağı zaman, master veritabanının yedeğini almak gerekir.
] Veritabanını silen, yaratan, değiştiren CREATE DATABASE, ALTER DATABASE, veya DROP DATABASE ifadeleri
] Transaction log’u değiştiren sp_logdevice sistem stored procedure’I
] Serverları ekleyen veya kaldıran sp_addserver, sp_dropserver ve sp_addlinkedserver sistem stored procedure’I
Msdb Veritabanının Değişiminden Sonra
Msdb değiştirildikten sonra yedeği alınmalı; çünkü Msdb SQL Server Agent tarafından kullanılan joblar, alertler, ve operatorler hakkındaki bilgileri içerir. Eğer msdb veritabanının geçerli yedeği yoksa, bir sistem başarısızlığında bütün sistem veritabanlarını rebuid etmeli ve daha sonra herbir jobu, alerti, ve operatorü yeniden yaratmalı.
Model Veritabanının Değişiminden Sonra
Model veritabanı değiştirilirse, tüm yeni kullanıcı veritabanlarında geçerli konfigurasyonu sağlamak için model veritabanı yedeklenmeli. Master ve msdb veritabanları rebuid edildiğinde, tüm kullanıcı veritabanlarının da rebuild edilmesinden dolayı model veritabanındaki değişiklikler kaybedilir. Sistem başarısızlıklarında model veritabanının yedeği açılabilir.
Kullanıcı Veritabanlarını Yedekleme
Bir veritabanı ve index yaratıldıktan sonra ve girişi sağlayamayan işlemler çalıştırıldığında
Yedekleme yapılabilir.
Veritabanlarını Yaratıldıktan Sonra
Bir veritabanı yaratıldıktan veya veriyle yüklendikten sonra yedeklenmeli. Full database yedeği olmadan, transaction log yedekleri açılamaz; çünkü transaction logların kullanılmış olduğu bölüme sahip olmak gerekir.
İndexler Yaratıldıktan Sonra
Bir index yaratıldığı zaman veritabanı yedeklenmeli. Bir index yaratıldıktan sonra, yapılan yedekleme veri ve index yapılarını içeren yedek dosyaları oluşturur.
Bir index yarattıktan sonra, sadece transaction log yedeklenirse ve gelecekte transaction log açılırsa (restore), SQL Server index’I rebuild etmeli. İndex’I yeniden yaratmak için harcanan zaman, full database backup’I açarken harcanan zamandan daha uzun olabilir.
Note: Transaction log sadece yaratılmış indexi kaydeder, sayfa değişikliklerini değil.
Transaction Log Silindikten Sonra
BACKUP LOG WITH TRUNCATE_ONLY ifadesi kullanılarak transaction log silindikten sonra, veritabanı yedeklenmeli. Bu ifade çalıştırıldıktan sonra transaction log, veritabanı aktivitelerini içermez ve değişiklikleri geri almak için kullanılmaz.
Girişi Sağlanamayan İşlemler İcra Edildikten Sonra
Transaction log’a kaydedilemeyen işlemler, girişi sağlanamayan (nonlogged) işlemler olarak adlandırılır. Aşağıdaki, girişi sağlanamayan işlemler tarafından yapılan değişiklikler, geri alınamayabilirler.
· BACKUP LOG WITH NO_LOG ifadesi. SQL Server bir yedek kopyası yapmadan, transaction logun aktif olmayan bölümünü kaldırır.
· WRITETEXT ve UPDATETEXT ifadesi. SQL Server text sütunlarındaki veriyi değiştirir ve bu aktiviteleri transaction log içine kaydetmez. WITH LOG seçeneği ile bu aktiviteler transaction log’a yazılabilir.
· SELECT INTO ifadesi ve bulk copy programı.
Girişi sağlanamayan (nonlogged) işlemler icra edildikten sonra bir veritabanı yedeklenmeli; çünkü bir veritabanı yedeği açılırken sistem başarısız olursa, transaction log, veritabanını tamamiyle açamaz.
Backup Sırasında Sınırlanan Aktiviteler
Veritabanı aktif iken yedekleme yapılabilir. Aşağıdaki hareketler yedek almaya engel olurlar.
z CREATE DATABASE ve ALTER DATABASE ifadesi ile veritabanı yaratma ve veritabanını değiştirme
Note: Otomatik büyüme yedek alma işlemi sırasında meydana gelmez.
z İndexleri yaratma
z Girişi sağlamayan işlemleri ve SELECT INTO, WRITETEXT, ve UPDATETEXT ifadelerini icra etme
Aşağıdaki aktiviteler yedek alma işlemi ile uyuşmazlar.
z Bu aktivitelerden biri progress içindeyken yedekleme alınırsa, yedekleme işlemi durur.
z Eğer bir yedek progress içindeyse ve kullanıcı bu aktiviteleri çalıştırmaya kalkışırsa, SQL Server bu aktiviteleri yerine getirmez.
Yedekleme
Bir yedek alırken ilk önce yapılması gereken, yedeği içerecek yedek dosyaları (permanent veya temporary) oluşturmak. SQL Server, kullanıcılara uygun yedekleme metodları sağlar.
Permanent Backup Files Yaratma
Yedek oluşturmadaki ilk adım yedekleme dosyaları yaratmaktır. Yedekleme işlemi için kullanılmadan önce yaratılan yedekleme dosyası permanent backup file olarak adlandırılır. Ayrıca permanent backup file, backup devices olarak adlandırılır.
Permanent Backup Files Niçin Yaratılır
Yedekleme dosyaları yeniden kullanılmak istenirse, permanent backup files yaratılmalı. Bu işlem, sp_addumpdevice sistem stored procedure ile veya SQL Server Enterprise Manager kullanılarak yapılabilir.
sp_addumpdevice Sistem Stored Procedure’ının Kullanımı
Bu çalıştırılırsa; permanent backup files, bir disk üzerine veya teyp üzerine veya Named Pipe’a yaratılır. permanent backup files yaratılırken aşağıdaki adımlar göz önüne alınmalı.
v SQL Server, master veritabanının sysdevices sistem tablosuna, mantıksal ve fiziksel isimler yaratır.
v Yedek dosyalarının mantıksal ve fiziksel isimleri belirtilmeli
v Bir veritabanı için 32’ye kadar yedek dosyası yaratılabilir.
Syntax sp_addumpdevice {‘device_type’} [,’logical_name’] [,’physical_name’]
[,{{controller_type]} |’device_ststus’}}
]
Where device_type is {DISK | TAPE | PIPE}
Örnek: Aşağıdaki örnek hard disk üzerinde permanent backup files yaratır.
USE master
EXEC sp_addumpdevice ‘disk’, ‘mybackupfile’,
‘C:\MsSQL7\Backup\Mybackupfile.bak’
Temporary Backup Files Yaratma
Permanent backup files yaratma tercih edilirken, varolan bir permanent backup file belirtilmeden
BACKUP DATABASE ifadesi ile temporary backup files yaratılabilir.
Temporary Backup Files Niçin Yaratılır
Yedekleme dosyalarının yeniden kullanılacağı planlanmamışsa, temporary backup files yaratılabilir.
BACKUP DATABASE İfadesinin Kullanımı
Temporary backup files, BACKUP DATABASE ifadesi veya SQL Server Enterprise Manager ile yaratılabilir. SQL Server temporary file oluşturarak, yedekleme işleminin sonuçlarını buraya yerleştirir.
Geçici yedekleme dosyası oluşturulurken aşağıdakiler yapılmalı
Ì Media ( disk, teyp, veya Named Pi0pe) tipi belirtilmeli
Ì Path ve dosya adı belirtilmeli
Syntax BACKUP DATABASE {database_name | @database_name_var}
TO <backup_file> [,…n]
WHERE < backup_file > is:
{{backup_file_name | @backup_file\nam\evar} | { DISK | TAPE | PIPE } =
{‘temp_backup_file’ | @temp_backup_file_var}
Örnek: Aşağıdaki örnek bir disk üzerinde Temporary backup files yaratır ve Temporary backup files içne master veritabanı yedeklenir.
USE master
BACKUP DATABASE northwind TO DISK = ‘C:\Temp\Mycustomers.bak’
Yedekleri Yerleştirmek için Çoklu Yedekleme Dosyalarını Kullanma
SQL Server aynı anda çoklu yedekleme dosyalarına yazabilir.
Çoklu Yedekleme Dosyaları Üzerine Yedekleri Yerleştirme
Çoklu dosyalara yedekleme,yedekleme zamanını düşürür. Örneğin, bir yedekleme işlemi bir teybi normalde 4 saatte dolduruyor ise ikinci bir yedekleme teybi eklense bu süre iki saate düşer.
Syntax BACKUP DATABASE {database_name | @database_name_var}
TO <backup_file> [,…n]
[WITH
[[,] NAME= {backup_set_name | @backup_set_name_var}]
]
WHERE <backup_file> is:
{backup_file_name | @backup_file_name_var} |
{ DISK | TAPE | PIPE } = {‘temp_backup_file’ | @temp_backup_file_var}
Yedekleri yerleştirmek için çoklu dosyalar kullanıldığı zaman aşağıdaki adımları göz önüne almak gerekir.
¯ Tek bir yedekleme işleminde kullanılan bütün aygıtlar, aynı media tipinde (teyp, disk) olmalı. Tek bir backup media set’I için disk ve teyp aygıtları karıştırılamaz. Bir media, bir yada daha fazla yedek setini içeren dosya takımıdır.
¯ Yedek seti yaratılırken, permanent ve temporary dosyalar birlikte kullanılabilir.
¯ Yedek seti üyesi olarak bir dosya tanımlanırsa, dosyalar daima birlikte kullanılmalı.
¯ Dosyalar yeniden formatlanmadıkça, yedekleme işlemi için yedek setinin sadece bir üyesi kullanılamaz.
¯ Yedekleme setinin bir üyesi yeniden formatlanırsa, yedekleme setinin diğer üyelerinin içinde yer alan veri geçersizdir ve kullanılamaz.
Örneğin yedekleme seti iki dosya üzerinde yaratılmışsa, aynı yedekleme setini içeren yedekleme işlemleri, bu aynı iki dosyayı iyi bir şekilde kullanır. Ek yedekler bu iki dosyaya eklenebilir. Eğer başka bir veritabanını yedeklemek için bu dosyalardan sadece biri kullanılmak isteniyorsa, dosya yeniden formatlanmalı.
NAME Seçeneğinin Kullanımı
NAME seçeneği, yedekleme setinin ismini belirtir. Veritabanını yedekleme için çoklu dosyalar kullanılıyorsa, NAME seçeneği kullanılmalı. Bu seçenek, çoklu dosyaları başka bir yedek seti üyesi ile birleştirir.
Yedekleme seti yaratıldıktan ve adlandırıldıktan sonra, gelecek yedekleme işlemleri için backup set yeniden kullanılabilir. İsimler 128 karaktere kadar olmalı.
BACKUP İfadesinin Kullanımı
Yedekleme işlemleri, SQL Server Enterprise Manager, Yedekleme Sihirbazı veya Transact-SQL ile yapılabilir.
Syntax BACKUP DATABASE { database_name | @database_name_var }
TO <backup_file> [,…n]
[WITH
[[,] FORMAT]
[[,] {INIT | NOINIT}]
[[,] RESTART]
]
INIT veya NOINIT Seçeneğini Belirleme
Bir veritabanı yedeklenirken, yedek dosyasına ekleneceği veya üzerine yazılacağı belirlenmeli.
¤ NOINIT seçeneği kullanılırsa, SQL Server bir yedeği, varolan yedekleme dosyasına veya yedek setine ekler. (Sonuna ekler)
¤ INIT seçeneği kullanılırsa, SQL Server varolan herhangi bir veriyi yedekleme seti üzerine yazar ama başlık bilgisini tutar.
Aşağıdakiler gerçekleşirse yedekleme işlemi başarısızlığa uğrar ve veri, üzerine yazılmaz.
q Backup device üzerinde belirtilen EXPIREDATE seçeneği hala sona ermemişse
q NAME seçeneğinde belirlenen backup_set_name parametresi yedekleme aygıtı üzerindeki backup_set_name parametresine uymuyorsa.
q Önceden adlandırılan backup setin bir üyesi üzerine yazılmaya kalkışılırsa. SQL Server, dosyanın backup setin bir dosyası olup olmadığını denetler.
FORMAT Seçeneğinin Kullanımı
Yedekleme dosyasının içeriğinin üzerine yazmak için kullanılır.
ü Yeni media header, bu yedekleme işlemi için kullanılan tüm dosyalar üzerine yazılır.
ü SQL Server, varolan media’nın ve yedekleme dosyasının içeriklerinin her ikisinin de üzerine yazar.
ü FORMAT seçeneği dikkatli kullanılmalı. Media setindeki sadece bir yedek dosyasını formatlama yedekleme setini kullanılamaz duruma getirir.
Örneğin; Varolan yedekleme setinin bir parçasını içeren tekli teyp yeniden formatlanırsa yedekleme setinin tamamı kullanılamaz hale gelir.
RESTART Seçeneğinin Kullanımı
Yedekleme işlemini yeniden başlatmak için kullanılır. BACKUP ifadesi RESTART seçeneği ile çalıştırılarak yedekleme işlemi başlatılabilir.
Bir Teyp Aygıtına Yedek Alma
Teypler ucuz ve geniş depolama alanı sağladıkları için elverişlidirler. Teybe yedekleme yapılırken teyp sürücüsü SQL Server’a lokal olarak bağlanmalı.
Teyp Etiketi Üzerine Yedekleme Bilgisini Kaydetme
Bir teybe yedek alındığı zaman, SQL Server aşağıdaki yedek bilgilerini teyp etiketi üzerine kaydeder
· Veritabanı ismi
· Zaman
· Tarih
· Yedeğin tipi
SQL Server’ın Yedeklerini ve SQL Server’ın Olmayan Yedekleri Saklama
SQL Server Microsoft Tape Format olarak adlandırılan standart backup formatını kullanır. Sonuç olarak; Her iki yedek tipi de aynı teybe yedeklenebilir.
SQL Server yedekleri farklı backup set’leri olarak veya diğer client’lar tarafından üretilen backup set’leri olarak birarada bulunabilir. SQL Server yedeklerinin ve WinNT yedeklerinin her ikisi de aynı teyp üzerinde bulunabilir.
Teyp Seçeneklerini Belirleme
UNLOAD
Yedekleme tamamlandıktan sonra, SQL Server teybi otomatik olarak geri sarar ve teybi yüklemez. Bu seçenek default olarak gelir.
NOUNLOAD
Yedekten sonra teybin otomatik olarak geri sarması ve teybi yüklememesi istenmiyor ise seçilir.
BLOCKSIZE
FORMAT, SKIP, INIT seçenekleriyle teyp üzerine yazılırsa (overwrite), bu seçenek fiziksel blok boyutunu değiştirmek için kullanılır. Bir teybe yedekleme yapılırken, SQL Server uygun bir blok boyutu belirler. BLOCKSIZE seçeneği seçilerek blok boyutu da belirlenebilir.
FORMAT
Yedekleme için kullanılan bütün dosyalar üzerine başlık yazmak için kullanılır. SQL Server tüm header’ları ve yedekleri dosyalar üzerine yazar. Header, MEDIANAME ve MEDIADESCRIPTION seçeneklerinde bulunan bilgileri içerir. FORMAT seçeneğini kullanma, INIT, SKIP seçenekleri anlamına gelir ki bu seçenekleri belirtmeye gerek yoktur.
SKIP
Header’ları atlamak için kullalnılr. SQL Server, teyp aygıtları üzerinde varolan ANSI teyp etiketlerini göz ardı eder. Teybin ANSI etiketi, teybin dolum tarihi hakkındaki uyarı bilgisini sağlar.
NOSKIP
SQL Server’ın ANSI teyp etiketlerini okuması istenmiyorsa bu seçenek kullanılır. SQL Server ANSI teyp etiketlerini default olarak okur.
Yedekleme Methodları
SQL Server, farklı bir çok yedekleme methodu sunmuştur.
Full Database Backup Yapma
Eğer veritabanı read-only ise, full database backups veri kaybını önlemek için yeterli olabilir. Full database backups alındığı zaman SQL Server:
¤ Aktiviteleri yedekler.
¤ Transaction log’daki onaylanmamış transactionları yedekler.
Örnek: Aşağıdaki örnek; mantıksal ismi nwndbac olan permanent backup files’ı yaratır ve full database backups’ı icra eder.
USE master
EXEC sp_addumpdevice ‘disk’, ‘nwndbac’,
‘C:\MyBackupdir\Nwndbac.bak’
BACKUP DATABASE northwind TO nwndbac
Örnek: Aşağıdaki örnek; nwndbac dosyasına full database backups’ı yapar ve dosya üzerinde bulunan önceki yedeklerin üzerine yazar.
BACKUP DATABASE northwind TO nwndbac WITH INIT
Örnek: Aşağıdaki örnek; temporary backup disk file yaratır ve bu dosyaya full database backup işler.
BACKUP DATABASE northwind TO
DISK = ‘D:\Temp\Mytempbackup.bak’
Differantial Backup Yapma
Değişmiş veritabanının yedeğini açmak için gerekli olan zamanı, minimize etmek için differantial backup yapılmalı. Bu full database backup yapılmışsa kullanılabilir. Differantial backup’ta SQL Server:
Y Son full database backup’tan beri değiştirilen veritabanı veritabanı bölümlerini yedekler.
Y Differantial backup sırasında yer tutan aktiviteyi yedekler.
Differantial backup yapılırken aşağıdaki adımlar göz önüne alınmalı:
v Son full database backup’tan beri belirli bir row farklı zamanlarda değiştirilmişse, Differantial backup row’un sadece son değerini içerir. Bu, row hakkındaki tüm değişiklikleri içeren transaction log’dan farklıdır.
v Yedekleme zamanı minimize edilebilir; çünkü yedek setleri, full backups’dakilerden daha küçüktür ve transaction log’ların işlenme zorunluluğu yoktur.
Syntax BACKUP DATABASE {database_name | @database_name_var}
TO <backup_file> [,…n]
[WITH
[[,]DIFFERENTIAL]
]
Örnek: Aşağıdaki örnek; temporary backup file üzerinde differantial backup yaratır.
BACKUP DATABASE northwind TO
DISK=’D:\Mydata\Mydiffbackup.bak’
WITH DIFFERENTIAL
Transaction Log Yedeği Yapma
Veritabanı değişikliklerini kaydetmek için transaction loglar yedeklenir. Transaction loglar, full database backup yapılırken yedeklenirler:
q En azından bir kere full database backup yapmadıkça, transaction log’un yedeği alınmaz.
q Uygun veritabanı yedeği olmadan transaction loglar’ın yedekleri açılamaz.
SQL Server Transaction Log’u Nasıl Yedekler
Transaction Log yedeklendiği zaman, SQL Server:
(a) BACKUP LOG ifadesini çalıştırarak Transaction log’u yedekler.
(b) Transaction log’u, transaction log’un aktif bölümünün başlangıcına kadar kısaltır. Transaction log’un aktif bölümü, eski açılan transaction noktasında başlar ve transaction log sonuna kadar devam eder
(c) Transaction logun aktif olmayan bölümündeki bilgiyi atar ve disk alanını düzeltir.
Syntax BACKUP LOG {database_name | @database_name_var}
TO <backup_file> [,…n]
[WITH
[[,] {INIT | NOINIT}]
[[,] [NAME = {backup_set_name | @backup_set_name_var}]
Örnek: Aşağıdaki örnek; permanent transaction log backup file yaratır ve northwind veritabanının transaction logunu yedekler.
USE master
EXEC sp_addumpdevice ‘disk’, ‘nwndbaclog’,
‘D:\MsSQL7\Backup\Nwndbaclog.bak’
BACKUP LOG northwind TO nwndbaclog
NO_TRUNCATE Seçeneğinin Kullanımı
Veritabanı dosyaları zarara uğrarsa veya kaybolursa, veritabanı NO_TRUNCATE seçeneğiyle yedeklenmeli. Bu seçenek, tüm veritabanı aktivitelerini yedeklemek için kullanılır. SQL Server:
· Veritabanına ulaşılamasa bile transaction logun tamamını kaydeder
· Onaylanmış işlemlerin Transaction log’unu temizlemez.
· Sistem başarısızlığa uğradığında veriyi yeniden elde etmeye izin verir.
Veritabanı açılacağı zaman, veriyi geri elde etmek için NO_TRUNCATE seçeneği ile yaratılan transaction log backup uygulanır.
Transaction Log’u Temizleme
Transaction logları temizlemek için BACKUP LOG ifadesiyle, TRUNCATE_ONLY ve NO_LOG seçenekleri kullanılır. Transaction log’u makul boyutta tutmak için düzenli olarak yedeklenmeli.
ü Transaction Log dolu ise, kullanıcı veritabanlarını güncelleyemez ve sistem başarısızlığa uğradığında tamamiyle veritabanını açamaz. Transacion log, ya full database backup alınarak ve veri kaydedilerek ya da transaction log kısaltılarak temizlenmeli
ü Transaction log yedeğini alma, transaction logun çoğunluğunu kısaltamazsa, transaction log içinde açılan eski bir transaction’a sahip olmak gerekir.
TRUNCATE_ONLY Seçeneği
Transaction log’u temizlemek istiyorsak ve verinin yedek bir kopyasını tutmak istemiyorsak; TRUNCATE_ONLY seçeneğini kullanabiliriz. SQL Server yedek kopyasını almadan, aktif olmayan log parçasını siler. Bu durum, transaction log’un kullandığı alanı boşaltır.
Ñ Full database backup yapmadan önce, TRUNCATE_ONLY seçeneği kullanılarak, transaction log temizlenebilir.
Ñ Transaction log’da kayıtlı olan değişiklikler yeniden elde edilemez. Hemen BACKUP DATABASE ifadesi çalıştırılmalı.
Ñ Aynı statement içinde TRUNCATE_ONLY ve NO_LOG seçeneklerinin her ikiside kullanılamaz.
Ñ Transaction log 100 percent dolu ise, transaction log NO_LOG seçeneğiyle yedeklenmeli.
Syntax BACKUP LOG {database_name | @database_name_var}
TO <backup_file> [,…n]
[WITH {TRUNCATE_ONLY | NO_LOG | NO_TRUNCATE} ]
Örnek: Aşağıdaki örnek; yedek kopyası almadan, transaction logun aktif olmayan parçasını kaldırmak için BACKUP ifadesini kullanır.
BACKUP LOG northwind WITH TRUNCATE_ONLY
NO_LOG Seçeneği
Transaction log’daki disk alanı yeterli değilse ve TRUNCATE_ONLY seçeneği çalıştırılamıyorsa bu seçenek kullanılır. SQL Server yedek kopyası yaratmadan, transaction logun aktif olmayan parçasını siler. Bu durum transaction log’da boş alan yaratır.
Note: Transaction log içinde kayıtlı olan değişiklikler yeniden elde edilemez. Bu yüzden hemen BACKUP DATABASE ifadesi çalıştırılmalı.
Örnek: Aşağıdaki örnek; yedek kopya yaratmadan full transaction logun aktif olmayan parçasını kaldırmak için BACKUP LOG ifadesini kullanır.
BACKUP LOG northwind WITH NO_LOG
trunc.log on chkpt. Seçeneğini Ayarlama
Bir checkpoint oluştuğunda, veritabanına bütün onaylanmış işlemleri yazmak için bu seçenek true ‘ya a0yarlanır. Bu seçenek transaction logu otomatik olarak kısaltır. Bu ayar true yapıldığında transaction log yedeklenmez.
Bir Veritabanı Dosyası veya Filegrup Yedeği Yapma
Filegruplar bir yada daha fazla veritabanı dosyaları içerir. SQL Server, dosyaları veya filegrupları yedeklediği zaman,
Ñ Sadece FILE veya FILEGROUP seçeneği ile belirlenen veritabanı dosyalarını yedekler.
Ñ Tüm veritabanı yerine belirli veritabanı dosyalarını yedeklemeye izin verir.
Veritabanı dosyası veya filegrup yedekleri yapıldığı zaman:
q Mantıksal dosyalar veya filegruplar belirtilmeli.
q Transaction log yedekleri alınmalı
q Tüm veritabanı dosyalarının veya filegrupların düzenli olarak yedeklenmesi için herbir dosyayı düzenli olarak yedeklemek gerekir.
q 16 dosya veya filegruba kadar belirtilir
Syntax BACKUP DATABASE {database_name | @database_name_var}
[<file_or_filegroup> [,…m]] TO <backup_file> [,…n]]
Where <file_or_filegroup> is:
{FILE=logical_file_name | FILEGROUP = logical_filegroup_name}
Örnek: Bu örnek; bir veritabanı filegrubunun Order2 dosyasını yedekler. Phoneorders veritabanı 3 dosya içerir: Orders1, Orders2, Orders3. Transaction log, Orderlog dosyasına depolanır. Bu yedek dosyaları zaten var: Orderbackup1, Orderbackup2, Orderbackup3 ve Orderbackuplog
BACKUP DATABASE phoneorders
FILE=orders2 TO orderbackup2
BACKUP LOG phoneorders TO orderbackuplog
Veritabanı Dosyalarını veya Filegruplarını Yedekleme Üzerine Sınırlamalar
Çoklu dosyalar veya filegruplar içeren bir veritabanı yedeklendiği zaman, index yaratılmışsa tek parça olarak farklı veritabanı dosyaları birarada yedeklenmeli.
Tek Parça Olarak Indexleri ve Tabloları Yedekleme
Bir index yaratıldığı zaman, transaction loglar sadece yaratılan bir indexi ve indexi yaratmak için kullanılan sayfaların listesini kaydeder. Veritabanı açıldığı (restore) zaman bu transaction log uygulanırsa, SQL Server CREATE INDEX ifadesini çalıştırır ve orjinal index sayfalarını kullanır.
Index ve Tablo Aynı Filegrup Üzerinde Yaratılır
Bir index ve ana tablo bir filegrup içinde yaratılırsa, bütün veritabanı tek parça olarak yedeklenmeli.
Index ve Tablo Farklı Filegrup Üzerinde Yaratılır
Bir index, bir filegrup üzerinde yaratılırsa ve ana tablo başka bir filegrup üzerinde yaratılırsa herbir filegrup tek parça olarak yedeklenmeli.
Örneğin; contact veritabanı üç filegrup içerir. Filegrup1 customer tablosunu içerir ve customer tablosu üzerindeki indexler Filegrup2 ve Filegrup3 içinde yaratılmış. Bu durumda 3 filegrup da tek bir parça olarak yedeklenmeli.
Backup Stratejisi Tasarlama
Full Database Backup Stratejisi
Konu ile İlgili Uygulama
Aşağıdaki durumlar sağlanırsa full database backups alınır.
Ñ Veritabanı küçükse. Küçük veritabanını yedekleme süresi makuldür.
Ñ Veritabanı az sayıda veritabanı değişikliğine sahipse veya sadece okunabilir yani read-only ise. Full database backups oluşturma, uygun veri setinin tamamını tutar.
Transaction Log Dolu Olursa
Full database backups stratejisi tamamlanırsa, Transaction log sonunda dolar. Transaction log dolarsa, SQL Server, transaction log silinene kadar diğer veritabanı aktivitelerini engelleyebilir.
· Transaction log periyodik olarak temizlenmeli.
· Transaction log’un boyutunu minimize etmek için trunc.log on chkpt. seçeneği true’ya ayarlanmalı.
Bu seçenek işaretlendiğinde, bir checkpoint meydana geldiği zaman ve transaction log otomatik olarak kısaltıldığı zaman bütün onaylanmış işlemler veritabanına yazılır. Transaction log, son Full database backups’dan beri yapılan değişiklikleri içermez.
Uyarı: trunc.log on chkpt. seçeneği true’ya ayarlanırsa, transaction log yedeklenmez ve bu seçenek, sistem başarısızlığa uğradığında veritabanını açmada yardımcı olur.
Strateji Örneği 1
Veritabanını açmada ele alınacak adımlar aşağıda sıralanmıştır.
v Veritabanı 10 MB veri içerir.
v Full database backups işleminin tamamlanması çok az dakika sürer.
v Veritabanı çoğunlukla karar desteği için kullanılır ve her gün biraz olarak değiştirilir.
v Veritabanına yapılan günlük değişikliklerin kayıp olma olasılığı kabul edilebilirdir. Bu değişiklikler kolayca yeniden yaratılabilirler.
v Sistem admistrator, log boyutlarını denetlemek veya transaction log üzerinde bakım yapmak istemez.
v Transaction log, değişiklikleri kaydetmek için kullanılmaz ve sistem başarısızlıklarında veritabanını açmak için kullanılmaz.
v Full database backups her gün saat 18:00’da yapılır.
v Veritabanı saat 10:00’da bozulur.
İşlemi Düzeltme
Veritabanını düzeltmek için, bozulmuş veritabanı versiyonu üzerine önceki akşam saat 18:00’deki Full database backup yazılarak düzenleme yapılır.
Bu yöntem, son Full database backup’tan beri yapılan tüm veri değişikliklerinin kaybı ile sınırlıdır.
Strateji Örneği 2
Veritabanını açmada ele alınacak adımlar aşağıda sıralanmıştır. Varsayalım ki veritabanı, aşağıdakiler hariç yukarıdaki örnekteki ile benzerdir.
Ñ Veritabanı hergün biraz değiştirilir. (Ama Örnek 1 dekinden daha sık değiştirilir.)
Ñ Sistem yöneticisi, transaction log’da yeterli alan olmasını sağlar.
Ñ Trunc.log on chkpt. Seçeneği false’a ayarlanır. Sistem başarısızlığa uğrarsa, transaction log, son Full database backup’tan beri yapılan değişiklikleri kaydeder ve veritabanını düzeltmek veya yeniden açmak için kullanılır.
Ñ Transaction log, veritabanından farklı bir fiziksel aygıt üzerine yerleştirilir.
Ñ Full database backup her gün saat 18:00’da yapılır. Transaction log yedekleri düzenli olarak alınmazlar ama peiyodik olarak temizlenirler.
İşlemi Düzeltme
Veritabanını düzeltmek için aşağıdaki adımlar takip edilebilir.
1) Herhangi bir veriyi kısaltmadan transaction log’u yedekleme.
2) Bozulmuş veritabanı versiyonu üzerine, önceki akşam saat 18:00’deki dolu veritabanı yedeği yazılarak düzenleme yapılır.
3) Adım1’de yaratılan transaction log yedeğini açma ve veritabanını düzeltme.
Bu yöntem, transaction log zarara uğramazsa, önceki akşam yedeğinden beri yapılan değişiklikleri yeniden elde etmek için kullanılır.
Oldukça büyük derecede potansiyel veri kaybı olursa, periyodik transaction log yedeklerini içeren tamamlanmış bir yedekleme stratejisi göz önüne alınmalı.
Full Database ve Transaction Log Backup Stratejisi
Dolu veritabanı yedeklemesine ek olarak; Full database backup’lar arasında oluşan tüm veritabanı aktivite kayıtlarına sahip olmak için, transaction log yedeklenmeli. Bu ortak yedekleme stratejisidir.
Full database ve transaction log backup stratejisi tamamlandığı zaman, en yeni Full database backuptan bir veritabanı yeniden kurulabilir yani yenilenebilir ve daha sonra, son Full database backup’tan beri yaratılan transaction log yedeklerinin tümü uygulanır.
Sık değişen veritabanları için Full database ve transaction log backup stratejisi uygulanır.
Strateji Örneği
Veritabanını açmada ele alınacak adımlar aşağıda sıralanmıştır.
i. Veritabanı ve transaction loglar, farklı fiziksel media üzerindeki, farklı dosyalarda depolanır.
ii. Full database backup hergün saat 18:00’de yapılır.
iii. Transaction log yedekleri her gün saat 9:00’da, 12:00’de ve 15:00’de yapılır.
iv. Veritabanını içeren fiziksel ortam, saat 13:30’da zarara uğrar.
İşlemi Düzeltme
Veritabanını düzeltmek için aşağıdaki adımlar takip edilebilir.
A. Mümkünse transaction log’u yedekle. Bunun için WITH NO_TRUNCATE seçeneğini kullan.
B. Önceki akşam 18:00’de yaratılan Full database backup’ı restore et.
C. 9:00 ve 12:00’de yaratılan bütün transaction logları kullan.
D. Kurma (Restore) başlangıcında yaratılan transaction log yedeğini kullan.
Differantial Backup Stratejisi
Differantial backup stratejisi tamamlanırken, transaction log yedekleri kadar iyi bir Full database backup dahil edilmeli. Diferansiyel yedekler, son Full database backup’tan beri değişen veritabanı bölümünü içerir. Differantial yedeklemede, SQL Server:
¨ Differantial log yapıldığı zaman transaction logları tutmaz. Böylece transaction loglar periyodik olarak yedeklenmeli.
¨ Veritabanını düzeltmek için son Differantial yedeği geri alınmak istenebilir. Son Differantial backup son Full database backup’tan beri yapılan değişiklikleri içerir.
Veritabanı zarara uğrarsa, düzeltme zamanını düşürmek için bu strateji kullanılır. Geniş çkolu transaction log’ları uygulama yerine, son Full database backup’tan beri yapılan değişiklikleri uygulamak için Differantial backup kullanılabilir.
Strateji Örneği
Veritabanını açmada ele alınacak adımlar aşağıda sıralanmıştır.
q Full database backup haftada bir kere yapılır. Son Full database backup Pazar günü 1:00’de yapılmıştı.
q Differantial backup her iş günü sonunda yapılır. Differantial backup Pazartesi ve salı günleri saat 18:00’de yapılmıştı.
q Transaction log yedekleri, iş günü (8:00’den 17:00’ye) boyunca her saat yapılır. Transaction log yedeği Çarşamba 8:00’de ve 9:00’da yapılmıştı.
q Veritabanı Çarşamba günü saat 9:30’da bozuldu.
İşlemi Düzeltme
Veritabanını düzeltmek için aşağıdaki adımlar takip edilebilir.
I. Mümkünse transaction log’u yedekle. Bunun için WITH NO_TRUNCATE seçeneğini kullan.
II. Pazar 1:00’de yaratılan Full database backup’ı restore et.
III. Salı 18:00’de yaratılan Differantial backup’ restore et. Bu yedek dosyası en sonki Differantial backup’tır ve Pazar günü 1:00’de Full database backup’tan beri yapılan tüm değişiklikleri içerir.
IV. Çarşamba saat 8:00 ve 9:00’da yaratılan transaction log yedeklerini kullan.
V. Veri uyumunu sağlamak için Restore işleminin (Adım1) başında yaratılan transaction log yedeğini kullan.
Veritabanı Dosyalarını veya Filegruplarını Yedekleme Stratejisi
Bir veritabanı dosyası veya filegrup yedekleme stratejisi tamamlandığı zaman, stratejinin gereği olarak transaction log yedeklenmeli.
Bu teknik full database backup’a alternatif olarak zaman duyarlılığı sunar. Örneğin; full database backup almak için sadece 1 saat varsa (Normalde 4 saat sürer), veri uyumluluğu sağlanarak, her gece dosyalar tek tek yedeklenebilir.
Strateji Örneği
Veritabanını açmada ele alınacak adımlar aşağıda sıralanmıştır.
v Veritabanındaki veri File1, File2 ve File3 olarak bölünür.
v Full database backup her hafta yapılır. Son Full database backup Pazartesi 1:00’de yapılmıştı.
v Seçilen dosyalar her gün saat 1:00’de düzenli olarak yedeklenir.
ü File1, Salı 1:00’de yedeklendi.
ü File2, Çarşamaba 1:00’de yedeklendi.
ü File3, Perşembe 1:00’de yedeklendi.
v Transaction log yedekleri her gün saat 12:00 ve 18:00’de yapılır.
v Perşembe 8:00’de File2’nin fiziksel ortamı zarara uğrar.
İşlemi Düzeltme
Veritabanını düzeltmek için aşağıdaki adımlar takip edilebilir.
i. Mümkünse transaction log’u yedekle. Bunun için WITH NO_TRUNCATE seçeneğini kullan.
ii. Çarşamba saat 1:00’de yaratılan File2 yedeğini restore et.
iii. Çarşamba saat 1:00’de yaratılan bütün transaction log yedeklerini kullan (apply).
iv. Veriyi düzeltmek için, restore işleminin başlangıcında tümtransaction logları kullan. Bu File2’deki dosyaları veritabanındaki ile uyumlu hale getirir.
Performans Etmenleri
Veritabanları yedeklendiği zaman, SQL Server’ın performansını etkileyen işler aşağıda incelenmiştir.
q Çoklu fiziksel aygıtlara yedekleme yapma, tekli fiziksel aygıtlara yedekleme yapmaktan daha hızlı. Paralel olarak her bir yedekleme aygıtına veri yazarak, çoklu yedekleme aygıtlarının avantajlarını sağlar.
q Yedekleme zamanı fiziksel aygıtın hızına bağlıdır. Teyp aygıtları, disk aygıtlarından daha yavaştır.
q Veritabanı yedeklendiği zaman raslantısal aktiviteler minimize edilir. SQL Server’daki raslantısal aktiviteler, yedekleme zamanını etkiler.
Tavsiye Edilen Uygulamaları
ü Veri kaybını minimize etmek ve kayıp veriyi kolayca elde etmek için yedekleme stratejisine sahip ol. Yedekleme stratejisine sahip isen, veriyi restore ederken harcanacak zaman ve veri kaybı azaltılabilir.
ü Sistem veritabanları değiştikten sonra yedeklerini al. Hatırlarsak; sistem stored procedure’larını çalıştırarak sistem veritabanlarını değiştirebiliriz.
ü Veritabanı aktivitesi yavaş olduğunda, yedekleme işlemlerini tasarla. Veritabanı aktif olduğunda yedekleme yapabilmene rağmen, birkaç işlem yedekleme işlemini engelleyebilir.
ü Yedekleme dosyalarını yeniden kullanmak için, permanent backup files yarat ve veritabanı yedekleme task’ını otomatikleştir.
VLDB’yi (very large databases – çok geniş veritabanları), yedekleme zamanı kazanmak için veritabanı dosyasını veya filegrubunu yedekle. VLDB gereğinden fazla zaman istiyorsa, özel dosyaları periyodik olarak yedekle.