Katalog danych FILESTREAM

Katalog danych FILESTREAM to lokalizacja systemu plików przechowująca duże obiekty binarne powiązane z bazą.

Rola katalogu danych FILESTREAM w SQL Server

Katalog danych FILESTREAM jest zarządzaną przez Microsoft SQL Server lokalizacją systemu plików, w której przechowywane są wartości kolumn typu varbinary(max) oznaczonych atrybutem FILESTREAM. Mechanizm ten pozwala przechowywać duże dane binarne, takie jak dokumenty, obrazy, nagrania lub archiwa, poza standardowymi stronami danych bazy, a jednocześnie utrzymywać ich powiązanie z rekordami SQL Server. W tabeli pozostaje identyfikator wiersza oraz logiczna wartość binarna, natomiast właściwa zawartość może znajdować się w kontenerze FILESTREAM na woluminie NTFS.

Katalog nie jest zwykłym folderem przeznaczonym do ręcznego składowania plików. Tworzy się go podczas definiowania grupy plików FILESTREAM, na przykład przez użycie klauzuli CONTAINS FILESTREAM w instrukcji CREATE DATABASE albo ALTER DATABASE. SQL Server zapisuje w metadanych bazy informację o lokalizacji kontenera i sam kontroluje znajdujące się w nim obiekty. Każdy plik w katalogu ma wewnętrzne powiązanie z konkretnym wierszem tabeli, dlatego nazwa pliku i struktura podkatalogów nie powinny być traktowane jako publiczny interfejs aplikacji.

Budowa kontenera i wymagania systemu plików

Kontener FILESTREAM należy do grupy plików FILESTREAM przypisanej do konkretnej bazy danych. W definicji bazy można wskazać wiele takich grup, a każda z nich może mieć własny kontener. W praktyce lokalizacja powinna znajdować się na woluminie NTFS, ponieważ obsługa danych FILESTREAM korzysta z funkcji systemu plików i mechanizmów transakcyjnych SQL Server. Katalog musi być pusty w momencie tworzenia kontenera i nie powinien zawierać plików utworzonych przez użytkownika ani przez inną bazę danych.

Po utworzeniu kontenera SQL Server buduje w nim wewnętrzne podkatalogi. Ich układ, nazwy oraz identyfikatory nie są przeznaczone do ręcznej interpretacji ani modyfikowania. Nie wolno przenosić plików, zmieniać ich nazw, usuwać pustych katalogów ani kopiować zawartości metodą przeznaczoną dla zwykłych folderów. Taka ingerencja może spowodować niespójność między systemem plików a metadanymi bazy. Kontener powinien mieć odpowiednią ilość wolnego miejsca, a jego wolumin musi być objęty monitoringiem pojemności, ponieważ zapełnienie dysku może zatrzymać zapisy nowych obiektów.

Konfiguracja FILESTREAM obejmuje zarówno poziom instancji SQL Server, jak i poziom konkretnej bazy. W SQL Server Configuration Manager można włączyć dostęp FILESTREAM dla instancji, a następnie włączyć wymagane opcje bazy za pomocą sp_configure i RECONFIGURE, zależnie od używanego trybu dostępu. Dostęp do danych przez system plików wymaga również skonfigurowania udziału FILESTREAM. Samo istnienie katalogu na dysku nie oznacza jeszcze, że aplikacja może korzystać z danych za pośrednictwem ścieżki systemowej.

Dostęp transakcyjny i ochrona spójności danych

Odczyt danych FILESTREAM może odbywać się przez standardowe zapytanie T-SQL albo przez strumieniowy dostęp Win32. Przy dostępie systemem plików aplikacja używa funkcji OpenSqlFilestream. Zanim zostanie otwarty uchwyt do danych, aplikacja pobiera z SQL Server logiczną ścieżkę dostępu, zwykle na podstawie funkcji PathName(), oraz odpowiedni kontekst transakcji zwrócony przez GET_FILESTREAM_TRANSACTION_CONTEXT(). Dzięki temu SQL Server może powiązać operację na uchwycie systemowym z transakcją obejmującą rekord w bazie.

Nie należy otwierać plików FILESTREAM przez bezpośrednie ścieżki systemu Windows, nawet jeśli administrator widzi je w Eksploratorze plików. Prawidłowa ścieżka logiczna zawiera elementy kontrolowane przez SQL Server, a dostęp jest weryfikowany przez mechanizm bazy i uprawnienia użytkownika. Operacje zapisu, aktualizacji i usuwania powinny być wykonywane w ramach właściwej transakcji. Przerwanie transakcji, utrata połączenia lub niepoprawne zamknięcie uchwytu może pozostawić operację niedokończoną, ale mechanizmy SQL Server mają wtedy za zadanie wycofać zmianę zgodnie z regułami transakcyjności.

W tabeli używającej FILESTREAM wymagany jest klucz główny, a kolumna FILESTREAM musi mieć właściwość ROWGUIDCOL oraz unikatowy indeks. SQL Server wykorzystuje identyfikator GUID wiersza do jednoznacznego powiązania rekordu z obiektem przechowywanym w kontenerze. Podczas diagnostyki należy więc sprawdzać definicję tabeli, grupę plików, stan bazy, konfigurację instancji oraz błędy SQL Server, a nie tylko zawartość katalogu. Ręczne znalezienie pliku na dysku nie jest wiarygodnym sposobem ustalenia, do którego rekordu należy dany obiekt.

Kopia zapasowa, przenoszenie i diagnostyka kontenera

Katalog danych FILESTREAM jest częścią bazy danych z punktu widzenia kopii zapasowej i odtwarzania. Kopia bazy SQL Server obejmuje dane FILESTREAM należące do odpowiednich grup plików, dlatego nie powinno się zastępować backupu bazy niezależnym kopiowaniem folderu. Przy odtwarzaniu trzeba zachować zgodność między bazą, grupami plików FILESTREAM i ich lokalizacjami docelowymi. Zmiana dysku lub ścieżki powinna być wykonana procedurą administracyjną SQL Server, na przykład przez właściwe operacje przenoszenia plików bazy i późniejsze sprawdzenie stanu bazy.

Podstawowa diagnostyka obejmuje sprawdzenie, czy baza jest online, czy grupa plików FILESTREAM jest dostępna oraz czy ścieżka kontenera odpowiada konfiguracji zapisanej w bazie. Pomocne są widoki katalogowe SQL Server, między innymi sys.database_files i sys.filegroups, a także informacje z dziennika błędów SQL Server i Podglądu zdarzeń systemu Windows. Warto kontrolować wolne miejsce, stan woluminu NTFS, uprawnienia usługi SQL Server oraz poprawność działania udziału FILESTREAM, jeżeli aplikacja korzysta z dostępu Win32.

Objawy problemu mogą obejmować błędy odczytu lub zapisu kolumn FILESTREAM, nieudane operacje OpenSqlFilestream, niedostępność bazy po przeniesieniu plików albo różnice między oczekiwanym a rzeczywistym rozmiarem danych. Nie należy naprawiać takich sytuacji przez usuwanie plików z katalogu. Bezpieczne postępowanie polega na zatrzymaniu niekontrolowanych operacji zapisu, wykonaniu kopii diagnostycznych, sprawdzeniu metadanych i backupów oraz użyciu udokumentowanych poleceń SQL Server. W środowisku produkcyjnym każdą zmianę lokalizacji lub konfiguracji trzeba poprzedzić testem odtwarzania i potwierdzeniem, że aplikacja nadal uzyskuje dostęp do danych w ramach transakcji.