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.

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.

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

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.

Ö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.

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.