Etiketler: , | Kategoriler: Sql Server Emrah Uslu | 06.10.2011 15:48

 

Bu yazı, sql server için yedekleme ve kurtarma konusunda kendim için tuttuğum notlardan oluştuğu ve fazla düzenleme yapmadan burada paylaştığım için yazıdaki dilden dolayı özür dileyerek başlayayım. 

Ayrıca okumadıysanız serinin ilk iki yazısına bu linklerden ulaşabilirsiniz :

Backup Restore Planlaması - I

Backup Restore Planlaması - II

RESTORE ile RECOVERY KAVRAMLARI KARIŞTIRILMAMALI

- Restore, bir db'i geri getirmek için çalıştırılan sql sorgusudur.

- Recovery ise db'i tutarlı bir duruma getirme sürecidir. Bunun anlamı, commit olmuş transaction'lar diske yazılır, başlamış ama bitmemiş transaction'lar rollback edilir. Sonuçta elde sadece commit olmuş transaction'ların olmasıdır.

- Sql Server her yeniden başlatıldığında recovery işlemi otomatik olarak gerçekleşir. Açılırken sql'in son olarak nasıl kapatıldığı bilinmez : Güç kaynağının kesilmesi, sql'in aşırı yüklenmeden kitlenmesi, makinenin restart edilmesi yada normal bir şekilde durdurulmuş olabilir. Mesela elektrik kesilmesinin ardından sql server yeniden başlarken gerçekleşen recovery sürecinde, tamamlanmış transaction'ların dahil edilir, tamamlanmayanların ise remove edilir.

- Aynı zamanda bir restore işleminin son adımı recovery'dir. Restore komutu, recovery'nin gerçekleşip gerçekleşmeyeceğini içerir. Eğer recovery, o restore işlemi için gerçekleşmezse, bir differential backup yada log backup restore edilebilir. Ancak restore komutu ile birlikte recovery çalıştırılırsa artık yeni bir restore işlemi yapılamaz ve database online konuma getirilir. Burada anlatılanlar, Sql Server Management Studio ile restore işlemi yaparken Options - Recovery State kısmında RESTORE WITH RECOVERY ve RESTORE WITH NORECOVERY olarak görülebilir.


RECOVERY MODELLERİ KARŞILAŞTIRMAK

i) Full Recovery Model

- Bütün data modifikasyonlar��nı tutar.

- En yüksek veri korumayı sağlar

- En büyük log dosyası boyutuna sahiptir.

- Bu modelde bütün backup işlemleri kullanılabilir.

- Birçok OLTP sistem ve iş-kritik uygulamaların db'leri Full Recovery Model'i kullanır; çünkü veri kaybına tahammülleri yoktur.

Not : İlk transaction log backup'ı ancak bir tane full database backup alındıktan sonra alınabilir.

ii) Bulk-Logged Recovery Model

- Bazı db işlemleri, log dosyasında minimum yer kaplar. Bu sayede bu işlemler daha performanslı çalışır.

- Bu işlemlere örnek olarak şu sorgular gösterilebilir : BCP, BULK INSERT, SELECT INTO, CREATE INDEX, ALTER INDEX REBUILD, and DBCC, DBREINDEX.

- Mesela büyük miktarda bir data import s��rasında bütün insert/update işlemlerini loga yazmak yerine yeni gelen extent'lerin yerlerini ve değişen extent'lerin adreslerini loga yazar. Sonuç olarak bu bulk import işlemi daha hızlı çalışır. Ne zaman ki bir transaction log backup alınır, log'a yazılan extent başlangıç ve bitiş noktalarına göre sql server data dosyasına gider ve ilgili datayı transaction log'a yazar.

- Aynı zamanda bu durumda restore işlemi için zamanda istenen tarih/saate geri dönne imkanı yoktur.

- Olası bir data dosyasının zarar görmesi senaryosunda transaction-log'dan restore işlemi yapıldığında bulk işlemin datasını data dosyasından alamayacaktır.

- Full backup ve transaction log backup ardından bulk işlem yapılır ve data dosyası bozulursa bulk işlemden sonrasına geri dönmek mümkün değildir. Tail log backup alınamaz; çünkü data dosyasına ihtiyaç vardır ama data dosyası erişilemez durumdadır. Bu tarz veri kayıplarının önüne geçmek için yapılabilecek olan şey, bulk işlemin arkasından transaction log backup almaktır.

- Database Admin (DBA), Full Recovery Model'daki db'de büyük bir bulk işlem yapmak için kısa süreli db'nin durumunu Bulk-Logged'a çekebilir.

- OLAP db'lerinde bu model tercih edilebilir. Sadece geceleri bulk data aktarımı yapılır ve hemen arkasından bir backup alınır ve gün içinde bir daha değişiklik gerçekleşmez. Böylece data bozulursa eldeki backup'dan geri dönülebilir.

iii) Simple Recovery Model

- Bir işlem, transactionlar log'da, sonraki checkpoint işlemi gerçekleşene kadar saklanır, ardından truncate edilir.

- Transaction log-backup alınmaz. Dolayısıyla transactional replication ,mirroring, log shipping gibi işlemlere izin verilmez.

- Test ve development amaçlı kullanılabilir.

 

BACKUP ve RESTORE İŞLEMLERİ İÇİN GEREKLİ İZİNLER

Backup için minimum

Server role: none

DB role: db_backupoperator

restore için minimum

Server role: dbcreater

DB role: db_owner


RESTORE SÜRECİ

Transaction Mark : begin Transaction komutu ile birlikte With Mark TranName kullanılıp transaction-log'da bir nokta işaretlenebilir ve daha sonra Transaction Log'dan restore yapılırken bu noktanın adını vererek geri dönülebilir.

- Bu bilgi msdb veritabanında logmarkhistory tablosunda durur.


Manuel Recovery

RESTORE DATABASE [TestDb2] WITH RECOVERY

Yukarıdaki sql komutu ile restoring modda olup daha fazla restore yapılmayacak olan db'ler recovery edilip tutarlı hale getirilebilir.

 

Restore with standby

Database'i read-only moda al. Uncomitted transaction'ları geri al (undo). Ancak geri alınan bu transaction'ları bir standby dosyasında sakla. Böylece istediğim zaman bu transaction'ları geri yükleyebileyim.

 

Kaynak : Wrox SQL Server 2008 Administration, MSDN

 

Yorum ekle

biuquote
  • Yorum
  • Canlı önizleme
Loading