SQL Server 2005 ile gelen yeniliklerden biri olan “database snapshot”, veritabanının herhangi bir andaki salt-okunur kopyasının alınmasıdır. Bu işlemin normal kopyalamadan farkı sadece değişiklik yapılmış kayıtları fiziksel olarak almasıdır. İstemcilerden snapshot’a bir istek geldiği zaman sorgulanan kayıt değişmişse sorgunun sonucu snapshot’tan gelir değişmemişse orijinal veritabanından gelir. Snapshot’un normal kopyalama gibi veritabanını olduğu gibi fiziksel kopyalamamsı kopyalama sürecinin daha hızlı olmasını ve daha az kaynak harcamasını sağlamaktadır. Snapshot’un temel amacı değişmiş kayıtların orijinal hallerini saklayıp gerektiğinde düzeltmektir. İstemci sorgularının doğrudan snapshot üzerinden yapılması değişmemiş kayıtlar için ana veritabanına gidip gelindiği için performans sorunu yaşatacaktır.
Snapshot’ların normal kopyalamadan diğer farkı da bunların ana veritabanına bağlı yaşamalarıdır. Ana veritabanı erişilemez olduğu durumda ona bağlı snapshot’lar da erişilmez olur. Aynı zamanda snapshot, doğrudan peer to peer transactional replikasyon gibi çalışmadığı için bir failover çözümü (high availability) olarak kullanılamaz. Database Snapshot, SQL Server 2005 Enterprise Edition ve üst sürümler tarafından desteklenmektedir ve snapshot üzerinden bir backup alınamaz. Son not olarak snapshot’un FAT32 dosya sistemi ve RAW partition’lar üzerinde oluşturulamayacağını da yazıp snapshot’un nasıl oluşturulacağını bakalım.
Database snapshot oluşturmak için T-SQL’de aşağıdaki gibi basit bir komut yapısı kullanılır.
CREATE DATABASE Kaynak_ss_20080115 ON ( NAME = Kaynak, FILENAME = 'C:\Kaynak_20080115.ss') AS SNAPSHOT OF Kaynak;
Bu script, 15/01/2008 tarihi itibariyle Kaynak veritabanının fotoğrafını çekip C:\Kaynak_20080115.ss dosyasını aktarır. Snapshot nihayetinde bir database olduğu için management studio içerisinde diğer databaseler üzerinde gezindiğimiz gibi bunun üzerinde de gezinebilir. Oluşturulmuş snapshot’lar Databases bölümündeki “Database Snapshots” bölümünde listelenir.
Şu an itibariyle snapshot dosyasının içeriği boş durumdadır. Aşağıdaki gibi snapshot üzerinde bir sorgulama yaptığımızda otomatik olarak orijinal veritabanından okunma yapmış oluruz.
SELECT * FROM Kaynak_ss_20080115.dbo.Musteri
Snapshot bir ve daha fazla sparse file (seyrek dosyas) kullanır. Sparse file NTFS’in bir özelliği olup sadece veri yazılan kısımlarının diskte yer kapladığı dosyadır. Yani sparse file başlangıçta herhangi bir data içermez ve henüz data için disk üzerinde herhangi bir yer kaplamaz. Snapshot’un bağlı olduğu orijinal veritabanı ne kadar çok güncellenirse sparse file o kadar büyümeye başlar. MSDN’den alınmış aşağıdaki şekilde bu süreci göstermektedir.
Herhangi bir geri dönme durumunda snapshot ile orijinal database’i JOIN edip orijinal database’i update edebiliriz. Tanımlı bir snapshot’tan doğrudan restore işlemini yapmak için aşağıdaki tanım kullanılır.
RESTORE DATABASE Kaynak FROM DATABASE_SNAPSHOT= 'Kaynak_ss_20080115'
Eğer bu işlem esnasında “Database cannot be reverted. Either the primary or the snapshot names are improperly specified, all other snapshots have not been dropped, or there are missing files.” hatası oluşursa restore edilecek snapshot dışındaki snapshotların silinmesi gerekir.
Snapshot’u silmek için DROP komutu kullanılır.
DROP DATABASE
Snapshot’ların kendine özgü üst-veri (metadata) bilgisi bulunmaz. Orijinal veritabanına ait üst-veri bilgileri taşırlar. Nitekim herhangi bir snapshot veritabanının veri ve log dosyalarını sorguladığımızda o snapshot’un bağlı olduğu orijinal veritabanının bilgileri gelir.
USE
Önceki yazıda ifade ettiğimiz gibi database mirroring’de yedek sunucunun NORECOVERY modunda olması bir dezavantaj olarak karşımıza çıkmaktadır. Fakat mirroring ile birlikte snapshot’un kullanılması yedek sunucunun readonly olarak hizmet vermesini sağlar.