FILESTREAM i ADO.NET

FILESTREAM i ADO.NET opisuje wykorzystanie tego zestawu klas do odczytu i zapisu danych przechowywanych w tym mechanizmie.

FILESTREAM w SQL Server: dane binarne poza stronami bazy

FILESTREAM jest funkcją aparatu SQL Server przeznaczoną do przechowywania dużych wartości binarnych typu varbinary(max) w systemie plików NTFS, przy zachowaniu ich logicznej przynależności do tabeli i transakcji bazy danych. Kolumna FILESTREAM musi mieć typ varbinary(max) FILESTREAM, a tabela musi zawierać kolumnę ROWGUIDCOL typu uniqueidentifier z indeksem unikatowym. SQL Server przechowuje metadane i relacje w bazie, natomiast właściwą zawartość binarną umieszcza w zarządzanym kontenerze FILESTREAM.

Mechanizm nie jest zwykłym katalogiem, do którego aplikacja może zapisywać pliki za pomocą dowolnych operacji systemu Windows. Kontener FILESTREAM jest zarządzany przez SQL Server, dlatego bezpośrednia modyfikacja jego zawartości z poziomu systemu plików może naruszyć spójność danych. Dostęp do wartości może odbywać się przez instrukcje Transact-SQL, tak jak do innych danych binarnych, albo przez interfejs strumieniowania Win32. Ten drugi wariant ogranicza konieczność przenoszenia całego dużego obiektu przez pamięć procesu lub standardowy bufor wyników.

Rola ADO.NET w wyborze ścieżki dostępu

ADO.NET pełni tutaj funkcję warstwy komunikacyjnej między aplikacją a SQL Server. Obiekt SqlConnection otwiera połączenie, SqlCommand wykonuje zapytania, a SqlDataReader pozwala odczytywać wynik. Przy dostępie T-SQL aplikacja może pobierać kolumnę FILESTREAM jak wartość varbinary(max). Dla dużych obiektów istotne jest sekwencyjne odczytywanie danych, na przykład z użyciem CommandBehavior.SequentialAccess, ponieważ ogranicza to wymagania pamięciowe po stronie klienta. Metody czytnika, takie jak GetBytes, umożliwiają kopiowanie kolejnych fragmentów do bufora.

ADO.NET może również pobrać specjalny identyfikator ścieżki logicznej FILESTREAM za pomocą funkcji PathName(). Sama ścieżka nie wystarcza jednak do otwarcia strumienia. Aplikacja musi uzyskać z SQL Server kontekst transakcji zwracany przez GET_FILESTREAM_TRANSACTION_CONTEXT(), a następnie przekazać ścieżkę, kontekst i tryb dostępu do obiektu SqlFileStream. W zależności od używanego środowiska .NET typ ten jest dostępny w przestrzeni nazw związanej z typami SQL Server. ADO.NET nie zastępuje tego obiektu, lecz dostarcza połączenie, transakcję oraz dane potrzebne do rozpoczęcia strumieniowania.

Transakcja, SqlFileStream i zapis danych

Strumieniowanie FILESTREAM przez SqlFileStream musi być powiązane z aktywną transakcją SQL Server. Typowy przepływ obejmuje rozpoczęcie transakcji na połączeniu, wykonanie zapytania zwracającego PathName() oraz kontekst transakcji, otwarcie obiektu SqlFileStream, wykonanie operacji odczytu lub zapisu metodami strumienia, zamknięcie strumienia i zatwierdzenie transakcji. Jeżeli transakcja zostanie wycofana, zmiany wykonane przez strumień nie powinny zostać uznane za zatwierdzone dane tabeli. Z tego powodu aplikacja musi kontrolować kolejność operacji i obsługiwać wyjątki przed decyzją o wykonaniu Commit.

Przy zapisie przez T-SQL można przekazać dane jako parametr binarny, ale dla dużych obiektów może to oznaczać dodatkowe kopiowanie danych w warstwie klienta i protokole komunikacyjnym. Ścieżka strumieniowania pozwala przekazywać zawartość porcjami, jednak nadal obowiązują reguły SQL Server dotyczące transakcji i uprawnień. Kod powinien zamykać SqlDataReader, SqlFileStream, SqlCommand oraz SqlConnection w sposób gwarantujący zwolnienie zasobów także po błędzie. Szczególnej uwagi wymagają przerwane transfery, częściowo wykonany zapis oraz sytuacja, w której aplikacja utraci połączenie przed zatwierdzeniem transakcji.

Diagnostyka błędów FILESTREAM i ADO.NET

Analizę problemu warto rozpocząć od ustalenia, którą ścieżkę wykorzystuje aplikacja: T-SQL z odczytem varbinary(max) czy strumieniowanie Win32 przez SqlFileStream. Dla pierwszej ścieżki należy sprawdzić typ kolumny, rozmiar parametrów, sposób odczytu czytnika i czas wykonywania zapytania. Dla drugiej trzeba zweryfikować, czy PathName() wskazuje istniejący rekord FILESTREAM, czy kontekst transakcji pochodzi z tej samej transakcji oraz czy strumień został otwarty przed jej zakończeniem. Błąd wynikający z pominięcia kontekstu transakcji nie jest równoważny problemowi z samym plikiem.

W środowisku diagnostycznym należy także rozdzielić błędy ADO.NET od błędów konfiguracji FILESTREAM w SQL Server. Pomocne jest rejestrowanie rodzaju operacji, identyfikatora rekordu, rozmiaru przesyłanych danych, momentu rozpoczęcia transakcji oraz wyniku zatwierdzenia, bez zapisywania całej zawartości binarnej w logu. Warto sprawdzić, czy aplikacja nie próbuje używać ścieżki FILESTREAM po zamknięciu transakcji, czy nie pozostawia otwartych strumieni oraz czy nie miesza połączenia i transakcji należących do różnych obiektów ADO.NET. Przy diagnostyce komputera lub laptopa można ocenić działanie aplikacji klienckiej, sterownika i lokalnego środowiska uruchomieniowego, natomiast semantyka przechowywania FILESTREAM pozostaje właściwością SQL Server.