FILESTREAM i śledzenie zmian

FILESTREAM i śledzenie zmian opisuje integrację tego mechanizmu z funkcją monitorującą modyfikacje danych w bazie.

FILESTREAM jako część modelu danych SQL Server

FILESTREAM jest funkcją programu Microsoft SQL Server przeznaczoną do przechowywania dużych wartości binarnych poza klasycznymi stronami danych bazy, przy zachowaniu ich powiązania z rekordami tabeli. Kolumna musi mieć typ varbinary(max) z atrybutem FILESTREAM, a tabela zawierająca taką kolumnę musi posiadać kolumnę rowguidcol typu uniqueidentifier z ograniczeniem UNIQUE. Dane są zapisywane w specjalnym kontenerze FILESTREAM, natomiast metadane i relacja z rekordem pozostają obsługiwane przez aparat SQL Server.

Mechanizm udostępnia dwa sposoby dostępu. Aplikacja może używać zwykłych instrukcji Transact-SQL, traktując zawartość jako wartość binarną, albo skorzystać z interfejsu strumieniowego Win32 przez uchwyt uzyskany funkcją PathName(). Dostęp strumieniowy wymaga transakcji FILESTREAM i kontekstu transakcji pobranego funkcją GET_FILESTREAM_TRANSACTION_CONTEXT(). Dzięki temu operacja zapisu pliku i zmiana rekordu opisującego ten plik są objęte spójnością transakcyjną SQL Server.

FILESTREAM nie jest niezależnym systemem kontroli wersji plików. Zmiana zawartości wartości varbinary(max) może oznaczać zastąpienie całego obiektu, zapis fragmentu albo usunięcie wartości, ale SQL Server nie przechowuje automatycznie historii kolejnych wersji jako danych dostępnych dla użytkownika. Informacja o zmianie musi zostać odczytana z mechanizmu śledzenia zmian albo z dodatkowego modelu wersjonowania zaprojektowanego przez aplikację.

Co dokładnie rejestruje change tracking

Change Tracking w SQL Server jest lekkim mechanizmem rejestrowania faktu, że wiersz tabeli został dodany, zmodyfikowany albo usunięty. Po włączeniu śledzenia na poziomie bazy poleceniem ALTER DATABASE ... SET CHANGE_TRACKING = ON trzeba włączyć je również dla konkretnej tabeli. Dla tabeli zawierającej kolumnę FILESTREAM śledzenie dotyczy zmian w wierszu i jego wartościach, a nie niezależnych operacji na systemie plików.

Do odczytu zmian służy funkcja CHANGETABLE(CHANGES ...). Zwraca ona między innymi klucz wiersza, numer wersji zmiany w kolumnie SYS_CHANGE_VERSION, rodzaj operacji w SYS_CHANGE_OPERATION oraz, zależnie od konfiguracji i rodzaju modyfikacji, informację o zmienionych kolumnach w SYS_CHANGE_COLUMNS. Numer wersji można porównywać z poprzednio zapamiętanym punktem synchronizacji pobieranym przez CHANGE_TRACKING_CURRENT_VERSION().

Change Tracking nie przechowuje poprzedniej wartości pliku ani pełnej treści zmodyfikowanego obiektu FILESTREAM. Jeżeli aplikacja wykryje zmianę rekordu, musi ponownie odczytać aktualną wartość z tabeli albo użyć dostępu strumieniowego. Przy operacji usunięcia wiersza można otrzymać informację o kluczu i rodzaju zmiany, lecz nie można oczekiwać, że sam Change Tracking pozwoli odzyskać usuniętą zawartość pliku.

Synchronizacja rekordów zawierających dane FILESTREAM

Typowy proces synchronizacji rozpoczyna się od zapisania przez aplikację wartości wersji zmian, na przykład po pełnym odczycie danych. Przy kolejnym uruchomieniu aplikacja przekazuje ten punkt do CHANGETABLE(CHANGES dbo.NazwaTabeli, @last_sync_version), łączy wynik z tabelą źródłową po kluczu głównym i rozróżnia operacje I, U oraz D. Dla dodania lub modyfikacji pobiera bieżące metadane oraz zawartość FILESTREAM, natomiast dla usunięcia usuwa albo oznacza odpowiedni obiekt po stronie odbiorcy.

W przypadku modyfikacji zawartości pliku należy zachować ostrożność przy interpretacji SYS_CHANGE_COLUMNS. Wynik wskazuje zmianę kolumny w sensie metadanych SQL Server, ale nie opisuje zakresu bajtów, który uległ modyfikacji. Nie można więc na tej podstawie zakładać, że zmienił się tylko określony fragment pliku, ani budować synchronizacji blokowej bez dodatkowego mechanizmu porównywania, sum kontrolnych lub własnych metadanych aplikacyjnych.

Wersja zmiany nie powinna być uznawana za bezterminowy identyfikator historii. SQL Server usuwa stare informacje zgodnie z okresem przechowywania ustawionym dla Change Tracking. Jeżeli proces synchronizacyjny przetrzyma swój punkt kontrolny zbyt długo, wymagane dane mogą zostać oczyszczone. Sytuację można sprawdzać funkcją CHANGE_TRACKING_MIN_VALID_VERSION(). Gdy zapisana wersja jest starsza od minimalnej poprawnej wersji tabeli, bezpieczna synchronizacja przyrostowa nie jest już możliwa i trzeba wykonać ponowny odczyt bazowy.

Granice diagnostyki połączenia FILESTREAM ze śledzeniem zmian

Podczas analizy problemu należy oddzielić trzy warstwy: konfigurację FILESTREAM w instancji SQL Server, strukturę tabeli oraz ustawienia Change Tracking w bazie i tabeli. Sam fakt, że rekord zawiera kolumnę varbinary(max) FILESTREAM, nie oznacza jeszcze, że śledzenie zmian jest aktywne. Należy sprawdzić właściwości bazy, ustawienie śledzenia tabeli, obecność wymaganej kolumny identyfikującej oraz to, czy aplikacja zapisuje i odczytuje dane w ramach prawidłowych transakcji.

W diagnostyce warto porównać numer ostatniej poprawnie przetworzonej wersji z bieżącą wersją zmian i minimalną wersją ważną dla tabeli. Należy również zweryfikować, czy zapytanie synchronizacyjne wykonuje się przed oczyszczeniem wpisów oraz czy połączenie używane do dostępu strumieniowego zachowuje wymagany kontekst transakcji. Błędy wynikające z pominięcia OpenSqlFilestream, nieprawidłowego uchwytu transakcji albo odczytu po zakończeniu transakcji są odrębne od problemów z samym Change Tracking.

Przy ocenie działania systemu trzeba też rozróżnić zmianę metadanych od zmiany treści. Aktualizacja nazwy lub innej kolumny rekordu może wygenerować zdarzenie zmiany, mimo że plik pozostał taki sam. Z kolei modyfikacja wartości FILESTREAM powinna być traktowana jako zmiana danych powiązanych z wierszem, ale informacja zwracana przez Change Tracking nadal nie zawiera poprzedniej zawartości ani szczegółowego dziennika bajtów. Takie rozróżnienie jest konieczne, aby nie uznać samego pojawienia się wpisu w CHANGETABLE za dowód określonego rodzaju zmiany pliku.