Obsługa transakcji FILESTREAM

Transakcje FILESTREAM obejmują zarówno dane w tabeli, jak i powiązane pliki na dysku, zachowując ich spójność.

Jak transakcja FILESTREAM łączy rekord tabeli z plikiem

Obsługa transakcji FILESTREAM dotyczy mechanizmu programu Microsoft SQL Server, w którym zawartość dużego obiektu binarnego jest przechowywana w systemie plików, natomiast w tabeli pozostaje powiązany z nią rekord. Kolumna przeznaczona do takiego przechowywania ma typ varbinary(max) FILESTREAM. SQL Server zarządza relacją między wierszem tabeli a plikiem, dlatego operacja na danych nie sprowadza się do niezależnego skopiowania pliku do wybranego katalogu.

Transakcja obejmuje zmianę danych relacyjnych oraz odpowiadającego im obiektu FILESTREAM. Jeżeli transakcja zostanie zatwierdzona, SQL Server zachowuje zgodność rekordu i pliku. Jeżeli zostanie wycofana, zmiany wykonane w ramach tej transakcji nie powinny pozostać jako częściowo zapisany stan aplikacji. Dzięki temu nie powstaje sytuacja, w której tabela wskazuje nową wersję danych, a plik zawiera jeszcze poprzednią zawartość albo nie został zapisany prawidłowo.

Uczestnictwo dostępu strumieniowego w transakcji

Typowy odczyt lub zapis wartości FILESTREAM może odbywać się za pośrednictwem instrukcji Transact-SQL, ale SQL Server udostępnia także interfejs strumieniowy dla aplikacji systemu Windows. Funkcja OpenSqlFilestream pozwala otworzyć uchwyt do danych zapisanych poza standardowym buforem operacji T-SQL. Nie jest to jednak zwykłe otwarcie ścieżki znalezionej w katalogu danych. Aplikacja musi użyć logicznej ścieżki zwróconej przez SQL Server oraz odpowiedniego kontekstu transakcji.

Kontekst jest pobierany z aktywnej transakcji za pomocą funkcji GET_FILESTREAM_TRANSACTION_CONTEXT(). Następnie aplikacja przekazuje ten kontekst wraz z logiczną ścieżką pliku do OpenSqlFilestream. Otwarty uchwyt pozostaje związany z transakcją, połączeniem i trybem dostępu określonym przez aplikację. Jeżeli transakcja zostanie zakończona przed użyciem uchwytu albo połączenie utraci wymagany stan, operacja strumieniowa może się nie powieść.

W praktyce oznacza to konieczność zachowania właściwej kolejności działań: rozpoczęcia transakcji, pobrania kontekstu, przygotowania ścieżki logicznej, otwarcia strumienia, wykonania odczytu lub zapisu oraz dopiero potem zatwierdzenia albo wycofania transakcji. Błąd w tej sekwencji może wystąpić mimo tego, że sama ścieżka lub kolumna FILESTREAM są poprawnie zdefiniowane.

Commit, rollback i ograniczenia bezpośredniego dostępu

Instrukcje modyfikujące rekord zawierający dane FILESTREAM podlegają regułom transakcji SQL Server. Zatwierdzenie transakcji przez COMMIT oznacza zakończenie operacji jako jednej logicznej całości, natomiast ROLLBACK służy do anulowania zmian. Dla aplikacji istotne jest, aby nie traktować zapisu do systemu plików jako osobnego zadania, które można bezwarunkowo wykonać poza kontrolą SQL Server. Takie podejście może prowadzić do niespójności między metadanymi w tabeli a zawartością zarządzaną przez FILESTREAM.

Pliki należące do magazynu FILESTREAM nie powinny być zmieniane przez standardowe operacje systemu Windows, takie jak bezpośrednia edycja, kopiowanie pod znalezioną ścieżkę fizyczną, zmiana nazwy czy usuwanie. Fizyczna lokalizacja jest elementem wewnętrznej organizacji magazynu i nie zastępuje interfejsu udostępnianego przez SQL Server. Dostęp strumieniowy musi być wykonywany przez mechanizmy FILESTREAM, z użyciem uprawnień, ścieżki logicznej i kontekstu transakcyjnego otrzymanych od silnika.

Podczas analizy problemu należy rozróżnić błąd samej transakcji od błędu konfiguracji funkcji FILESTREAM. Znaczenie mogą mieć między innymi włączona obsługa FILESTREAM na poziomie instancji, konfiguracja dostępu Transact-SQL lub dostępu strumieniowego, istnienie kolumny FILESTREAM oraz prawidłowe powiązanie tabeli z kluczem ROWGUIDCOL. Sama obecność kolumny varbinary(max) nie oznacza jeszcze, że aplikacja korzysta z magazynu FILESTREAM.

Rozpoznawanie problemów z obsługą transakcji FILESTREAM

Diagnostyka powinna rozpocząć się od ustalenia, czy problem pojawia się przy rozpoczęciu transakcji, pobieraniu kontekstu, otwieraniu strumienia, zapisie danych, odczycie czy podczas zatwierdzania. Warto sprawdzić, czy transakcja nadal jest aktywna w chwili wywołania OpenSqlFilestream, czy kontekst pochodzi z tego samego połączenia oraz czy aplikacja nie zamknęła połączenia przed zakończeniem operacji na uchwycie. Należy także zweryfikować, czy użyta ścieżka jest logiczną ścieżką FILESTREAM zwróconą przez zapytanie, a nie ścieżką fizycznego katalogu.

Przy błędach zapisu trzeba sprawdzić, czy aplikacja prawidłowo obsługuje wynik operacji i reakcję transakcji. Niepełny zapis, wyjątek biblioteki klienckiej albo przerwanie połączenia powinny prowadzić do jednoznacznego wycofania transakcji, jeżeli zapis nie może zostać bezpiecznie zakończony. Przy błędach odczytu pomocne jest porównanie identyfikatora rekordu, wartości logicznej ścieżki oraz zakresu transakcji, w którym otwarto strumień.

W środowisku z laptopem lub komputerem PC analiza aplikacji korzystającej z SQL Server może wymagać sprawdzenia sterownika, kodu obsługi wyjątków, uprawnień konta oraz komunikacji z instancją bazy. Naprawa sprzętu nie zastępuje korekty błędnej logiki transakcyjnej, ale diagnostyka komputera może wykazać problemy z dyskiem, pamięcią, systemem plików lub stabilnością połączenia, które przerywają operacje aplikacji.