FILESTREAM i dostęp zdalny

FILESTREAM i dostęp zdalny opisuje ograniczenia i wymagania dotyczące korzystania z tego mechanizmu spoza sieci lokalnej.

FILESTREAM w architekturze SQL Server

FILESTREAM to mechanizm silnika Microsoft SQL Server przeznaczony do przechowywania dużych obiektów binarnych, takich jak dokumenty, obrazy lub pliki multimedialne, poza typowymi stronami danych bazy, przy zachowaniu powiązania z rekordem tabeli. Wykorzystuje się do tego kolumnę typu varbinary(max) oznaczoną atrybutem FILESTREAM. Dane są zapisywane w specjalnym kontenerze należącym do grupy plików FILESTREAM, a SQL Server zarządza ich integralnością, transakcjami i relacją z wierszem tabeli.

Pliki znajdujące się w kontenerze FILESTREAM nie są zwykłymi dokumentami przeznaczonymi do otwierania przez wpisanie ścieżki w Eksploratorze Windows. SQL Server przechowuje je w zarządzanej strukturze katalogów i nie wolno modyfikować jej bezpośrednio. Dostęp do zawartości odbywa się przez zapytania SQL albo przez specjalny interfejs strumieniowy Win32 o nazwie OpenSqlFilestream. Takie rozdzielenie zapobiega pominięciu kontroli transakcyjnej i uszkodzeniu powiązań między tabelą a plikami.

Warunki dostępu spoza sieci lokalnej

Zdalny dostęp FILESTREAM wymaga włączenia odpowiedniego poziomu dostępu na instancji SQL Server. Ustawienie filestream_access_level ma trzy podstawowe wartości: 0 wyłącza FILESTREAM, 1 pozwala na dostęp przez Transact-SQL, a 2 włącza również dostęp strumieniowy przez system plików, w tym obsługę klientów zdalnych. Konfiguracja jest wykonywana na poziomie instancji, dlatego sama obecność kolumny FILESTREAM w tabeli nie oznacza jeszcze gotowości do połączeń z innych komputerów.

Oprócz poziomu dostępu trzeba skonfigurować udział FILESTREAM dla instancji oraz zapewnić komunikację sieciową z komputerem, na którym działa SQL Server. Zdalny klient korzysta z protokołu SMB i musi mieć możliwość dotarcia do odpowiedniego udziału sieciowego, zwykle przez port TCP 445. Zapora systemowa, reguły sieciowe, segmentacja sieci albo filtracja ruchu mogą zablokować ten etap niezależnie od poprawności samej bazy. Istotne jest także użycie prawidłowej nazwy serwera i udziału FILESTREAM, ponieważ nie należy zastępować ich bezpośrednią ścieżką do katalogu kontenera.

Transakcja, ścieżka logiczna i OpenSqlFilestream

Typowy odczyt strumieniowy rozpoczyna się od pobrania z tabeli wartości PathName() dla konkretnego rekordu oraz kontekstu transakcji zwracanego przez funkcję GET_FILESTREAM_TRANSACTION_CONTEXT(). Następnie aplikacja przekazuje te dane do OpenSqlFilestream, zamiast samodzielnie konstruować ścieżkę systemową. Operacja otwarcia pliku jest związana z transakcją SQL Server, dzięki czemu silnik może kontrolować spójność odczytu lub zapisu w czasie korzystania z uchwytu systemowego.

Transakcja musi pozostać aktywna przez czas wymagany przez operację strumieniową. Zakończenie jej przed zamknięciem uchwytu, użycie nieaktualnego kontekstu albo przekazanie ścieżki z innego rekordu może spowodować niepowodzenie otwarcia. Aplikacja powinna również poprawnie obsługiwać tryb odczytu i zapisu, limit czasu oraz zamykanie uchwytu. Dostęp zdalny nie omija autoryzacji SQL Server ani kontroli systemu Windows: konto aplikacji musi mieć uprawnienia do rekordu w bazie, a mechanizm dostępu musi przejść również przez reguły uwierzytelniania i autoryzacji wymagane dla udziału FILESTREAM.

Diagnostyka błędów połączenia FILESTREAM

Diagnostykę warto rozpocząć od sprawdzenia poziomu filestream_access_level, konfiguracji udziału FILESTREAM oraz statusu usługi SQL Server. Następnie należy rozdzielić problem bazy od problemu sieciowego: zapytanie wykonywane lokalnie może działać, podczas gdy klient zdalny nie osiąga udziału SMB albo otrzymuje odmowę uwierzytelnienia. Weryfikacji wymagają także nazwa instancji, nazwa udziału, rozwiązywanie nazwy hosta, reguły zapory i możliwość połączenia z portem TCP 445.

Jeżeli błąd pojawia się dopiero przy OpenSqlFilestream, należy sprawdzić, czy aplikacja pobiera PathName() i kontekst transakcji w tej samej sesji oraz czy przekazuje aktualny kontekst do funkcji. Nie należy naprawiać problemu przez nadawanie szerokich praw do katalogu kontenera ani przez ręczne kopiowanie plików w jego strukturze. W praktyce takie działania omijają model bezpieczeństwa SQL Server i mogą doprowadzić do niespójności. Przy diagnostyce komputera i oprogramowania analizuje się więc jednocześnie konfigurację instancji, przebieg transakcji, uprawnienia konta oraz warstwę SMB odpowiedzialną za dostęp zdalny.