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.
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.
Yorumlar
زينب زيادة
zianab zyada