SQL Server Database Snapshot

Merhabalar ,

Database Snapshot özellikleri SQL 2005 'den itibaren bizlerin kullanımına sunulan çok sevdiğim özelliklerden birisi.
Kısaca DataBase Snapshot , Veri tabanın o anda bir resmini çekmeye benzer. Veri tabanın Snapshot oluşturduğu andan itibaren elimizde read-only bir kopyasını elde etmiş oluruz.
Temel amacı ise Asıl veri tabanımızda ,snapshot oluşturulduğu andan sonra, değiştirilmiş kayıtların orjinal hallerini saklayıp gerektiğinde düzeltmektir.

İsterseniz örnek bir senaryo ile daha iyi anlıyalım, daha sonra da olumlu ve olumsuz yanlarından bahsedelim.

CREATE DATABASE CUSTOMER_SS_CASE1 ON (
NAME = CUSTOMER,
FILENAME = 'C:\SQLDATA\CUSTOMER_SS_CASE1.SS')
AS SNAPSHOT OF CUSTOMER;

Senaryomuz'da Customer veritabanın da önemli değişiklik planlıyoruz. 3 farklı case den oluşan değişikliğin ilk adımında belirtilen dosya altına Veritabanımızın o andaki snapshot'nı aldık.
Şu andan itibaren yapılan tüm update,delete,insert işlemleri öncesinde ,orjinal halleri snapshot database yazılır.
Değişiklikleri başlattık , bazı değişiklikleri devreye aldık ve case1 adımını tamamladık ve bu arada 2. snapshot'ı aldık. fakat istenmeyen bir şey oldu! Ve önemli bazı kayıtları Customer database'den sildik..Bu durumda değişiklikleri başlatmadan önceki case dönmemiz gerekiyor.(case1 sorunsuz geçildiğinden, case2 adımına dönmemiz gerekiyor.)

RESTORE DATABASE CUSTOMER
FROM DATABASE_SNAPSHOT = 'C:\SQLDATA\CUSTOMER_SS_CASE2.SS'

Gördünüz gibi çok daha az zamanda değişiklik öncesine dönmüş olduk.Eğer elimizde snapshot olmasaydı backup'dan en başa dönmemiz gerekiyordu!. Fakat biz case2 adımına dönebildik.

Burada göz ardı edemiyecemiz özellik ,full backup'dan dönmek çok daha uzun sürecekti hemde backup size ile snapshot dosyasının size arasındaki fark olucaktı.

Bu şekilde yapıldan senaryolar'da , belirli periyotlarda alınan Database snapshot'lar oldukça kullanışlı olabilir. Snapshot sadece değişiklik oldunda orjinal veritabanı ile konuştundan, oldukça hızlıdır. Aynı zamanda sparse dosyasına sadece oluşan değişiklikleri yazdığından ,değişikliğe uğrayan veri alanı kadar diskde yer kaplıyacaktır. Backup-Restore işlemine göre daha az masraflıdır.

Olumsuz yanlarına bakarsak, Orjinal Veritabanı ile konuştundan sanpshotdan çekilebilcek data için performans kaybı olucaktır. Sebebi ise değişmemiş datayı gidip okumasıdır. orjinal veri tabanı offlie moda geçtinde snapshot database de aynı şekilde offlie moda geçer.

Şimdilik bu kadar Pusulanı Ayarlamayı unutma :)

Error Msg 3117 The log or differential backup cannot be restored

   Merhaba bu hatayı herhangi bir backup dan restore etmeye çalışırken almış olabilirsiniz. Ben log backup dan restore yapmaya çalışırken aldım. 

   Restore etmeye çalıştığım db FULL RECOVERY ben bunu NORECOVERY çevirmek istediğimde hiç sevmediğim kırmızı çıktı J

Error : Msg 3117, Level 16, State 4 The log or differential backup cannot be restored because no files are ready to rollforward

   Bunun için  fix/workaround solutions olarak full yada diff hangi backup elimizde ise bundan NORECOVERY  modelde restore dönmeliyiz.  

Master DB Restore ve Master DB Taşınması

Merhaba , bu yazımızda Master veri tabanın taşınması hakkında konuşucağız. Oldukça belalı ve risk içeren bir işlem olması sebebi ile son derece dikkatle yapılması gereken bir işlemdir. Peki neden bu yola ihtiyaç duyabiliriz ? Yeni bir sunucuya geçilmesi yada master db in bulunduğu disklerin değiştirilmesi durumlarında olabilir.

Master veri tabanı SQL sunucumuz'un sistem veritabanı dır. Corrupt yada suspect olması durumunda veritabanı sunucusu açılmaz ve tüm sistemin çökmesine sebep olabilir..

Master veritabanının yeniden restore edilmesi için SQL server sunucumuz'un servislerinin durdurulması gereklidir. bunu da SQL Server Configuration Manager yada Windows services' dan yapabiliriz. Anlatacağım örnek de Primary server' dan Master db backup alıp secondary server olarak kabul ettiğim sunucuya restore yapacağız.

Öncesinde Dikkat edilmesi gereken hususlar

• Restore yapılacak disklerin aynı harflerde olması önemlidir. Sebebi ise master db açıldık dan sonra temp db için pathlerini arıcak olmasıdır.
• Yedeklerinin alınması. Önemli bir husus yedek alırken backup değil file taşınması daha doğru olacaktır, hata durumunda backup dan geri dönemeyiz.

Adımları

• Servisler stop edilir.
• Temp db path bilgileri ALTER edilir.
• Single modda servis açılır.
• Komut satırından gereken dosyaya ulaşıldıkdan sonra komut satırına(sqlservr.exe -m) yazıp devam ediyoruz.

Şimdi Master db geri yüklemesini yapabiliriz. Bunun için şu kodlama kullanılabilir.

RESTORE DATABASE master
FROM DISK = N"C:\master.bak" WITH FILE = 1 GO
Bunu query analyzer dan yapıyoruz.
Yada

(Servicesler start edilir)

· SQL Server"ımızı normal modda tekrar başlatalım. Bu şekilde Master sistem veritabanını geri yüklemiş olduk.

· Master db ile gelen (primary serverdan) db ler suspect gelir.

· SQL Error loglardan hataları kontrol edebiliriz.

· Master db restorundan sonra server ismini rename etmek gerekiyor.

EXEC sp_dropserver 'old_name'

go

EXEC sp_addserver 'new_name', 'local'

Go

(Services ‘ler stop-start edilir)

· Msdb db altında sql server rename etmek gerekiyor.

select * from dbo.sysjobs

altın da

USE msdb

GO

update sysjobs

set origination_server 'new_name' where 'old_name'

(servicesler stop-start edilir)