Tworzenie snapshot-a bazy danych polega na zapamiętaniu aktualnego stanu bazy danych, nie utrudniając ani nie zmieniając innym użytkownikom obrazu oryginalnej bazy danych. Dodatkowo tak utworzona migawka bazy danych nie ma zajmować wiele miejsca na dysku!
Jak więc to się dzieje, że można mieć wgląd do bazy danych z określonego momentu, bez wykowywania specjalnej kopii bazy danych?
Otóż po wydaniu polecenia
CREATE DATABASE AdventureWorks2008_ss ON (NAME= AdventureWorks2008_Data, FILENAME='c:\temp\AdventureWorks2008_Data.ss') AS SNAPSHOT OF AdventureWorks2008;
GO
na dysku powstaje mały plik. Nie zawiera on na początku żadnych danych z bazy danych. Jeżeli ktoś zechce coś z niego przeczytać, to tak na prawdę zostanie skierowany do stron znajdujących się na dysku pod oryginalną lokalizacją bazy danych.
Dopiero kiedy użytkownicy będą zmieniać oryginalne dane w AdventureWorks2008 strony tej bazy danych przed zmodyfikowaniem będą kopiowane do pliku bazy snapshot AdventureWorks2008_ss. Im więcej modyfikacji będzie wykonywanych na oryginale, tym bardziej urośnie plik snapshot.
Kiedy użytkownik pracujący na snapshocie zechce przeczytać dane, to:
- jeżeli dane uległy modyfikacji, to sql server poszuka stron z odpowiednimi informacjami w pliku bazy snapshot
- jeżeli dane nie uległy modyfikacji, to sql server poszuka informacji na stronach oryginalnej bazy danych
Cóż, tak toprzynajmniej wygląda w teorii, bo kiedy utworzyłem plik snapshot dla bazy AdventureWorks2008, to zobaczyłem, że rozmiar snaphota wynosi tyle samo (a nawet więcej) niż rozmiar oryginalnej bazy danych! Cała teoria plików snapshot legła więc w gruzach! Czy aby na pewno? Rzut oka we właściwości pliku snapshota, a okazuje się, że ktoś tutaj kręci:
Size to 196 MB, ale rozmiar na dysku tylko 128 KB. Uff, awięc jednak to prawda, że plik jest mały. Explorator Windows domyślnie pokazuje jednak w kolumnie z rozmiarem rozmiar „Size”, a nie „Size on disk”, stąd początkowe nieporozumienie.
Snapshot bazy danych może być wykorzystywany dokładnie tak samo jak zwykła baza danych:
USE AdventureWorks2008_ss; GO SELECT * FROM HumanResources.Departments; GO
Snapshot ma jeszcze jedną miłą cechę. Na jego podstawie można odtworzyć oryginalną bazę danych do pierwotnego stanu:
USE master; GO RESTORE DATABASE AdventureWorks2008 FROM DATABASE_SNAPSHOT='AdventureWorks2008_ss';
Takie odtwarzanie polega po prostu na wkopiowaniu stron zapamiętanych w pliku snapshot do oryginalnej lokalizacji w początkowej bazie danych.
Jeżeli więc masz do wykonania operację na bazie danych i boisz się, że może coś pójdzie nie tak, jednym z wielu dostępnych rozwiązań jest wykonanie snaphota aktualnie wykorzystywanej bazy danych. Operacja wykona się szybko (nie to co backup), nie zajmie wiele miejsca na dysku, a jeżeli coś zepsujesz szybko możesz wrócić do stanu pierwotnego.
Uwaga – odtwarzanie ze snapshota nie działa, jeżeli baza danych koszyta z grupy plików FILESTREAM. W mojej bazie danych AdventureWorks2008 usunąłem najpierw tabele Production.ProductDocument i Production.Document, a następnie usunąłem grupę plików FILESTREAM.
Więcej o działaniu SNAPSHOT:
http://msdn.microsoft.com/en-us/library/ms187054.aspx
Więcej o plikach SPARSE FILE wykorzystywanych przez SNAPSHOT:
http://msdn.microsoft.com/en-us/library/ms175823.aspx
