Usuwanie nieużywanych danych FILESTREAM

Usuwanie nieużywanych danych FILESTREAM wymaga jednoczesnego zarządzania rekordami w tabeli i plikami na dysku.

FILESTREAM a relacja między rekordem i plikiem

FILESTREAM jest mechanizmem Microsoft SQL Server, który pozwala przechowywać zawartość typu varbinary(max) bezpośrednio w systemie plików, przy zachowaniu kontroli transakcyjnej po stronie bazy danych. Tabela zawiera wówczas rekord opisujący obiekt, natomiast właściwe dane binarne znajdują się w specjalnym kontenerze FILESTREAM przypisanym do bazy. Kolumna FILESTREAM jest powiązana z tabelą przez identyfikator wiersza, a SQL Server zarządza mapowaniem między rekordem i plikiem.

Usunięcie danych FILESTREAM nie polega więc na skasowaniu dowolnego pliku z katalogu kontenera. Najpierw musi zostać prawidłowo zmieniony lub usunięty rekord tabeli, a operacja musi zostać zatwierdzona zgodnie z zasadami transakcji SQL Server. Dopiero później silnik może rozpoznać, że odpowiadający obiekt binarny nie jest już potrzebny. Samo ręczne usunięcie rekordu z tabeli nie powinno być uzupełniane ręcznym kasowaniem plików z kontenera, ponieważ katalog FILESTREAM jest strukturą zarządzaną przez silnik bazy danych.

Jak SQL Server rozpoznaje nieużywany obiekt FILESTREAM

Po usunięciu wiersza albo zastąpieniu zawartości kolumny FILESTREAM stary obiekt może przez pewien czas pozostawać w kontenerze. Nie oznacza to automatycznie błędu ani natychmiastowego wycieku miejsca na dysku. SQL Server musi uwzględnić zatwierdzone transakcje, wersje danych oraz aktywne uchwyty otwarte przez dostęp transakcyjny lub nietransakcyjny. Obiekt jest uznawany za możliwy do usunięcia dopiero wtedy, gdy nie jest już wymagany przez żaden poprawny kontekst odczytu.

Za fizyczne usuwanie takich obiektów odpowiada mechanizm garbage collection FILESTREAM. Działa on w tle i porządkuje dane, których powiązanie z aktualnym stanem bazy zostało usunięte. Opóźnienie między zmianą w tabeli a zwolnieniem miejsca może być normalne, szczególnie przy dużych transakcjach, intensywnym dostępie do plików albo długotrwałych operacjach odczytu. W praktyce należy odróżnić trzy stany: rekord nadal istniejący w tabeli, rekord usunięty lecz oczekujący na bezpieczne sprzątanie oraz obiekt faktycznie usunięty przez proces garbage collection.

Znaczenie mogą mieć również niezatwierdzone lub długo otwarte transakcje. Jeżeli aplikacja odczytuje dane FILESTREAM i utrzymuje otwarty uchwyt, silnik może odłożyć usunięcie fizycznego obiektu do czasu zakończenia korzystania z danych. Dlatego analiza zajętości kontenera powinna obejmować stan transakcji, obciążenie aplikacji oraz sposób, w jaki aplikacja otwiera i zamyka strumienie FILESTREAM.

Bezpieczna kolejność czyszczenia danych

Punktem wyjścia jest ustalenie, które rekordy mają zostać usunięte, oraz wykonanie tej operacji przez SQL Server, z zachowaniem kluczy, ograniczeń i logiki aplikacji. Jeżeli plik ma zostać zastąpiony nową wersją, aktualizacja kolumny FILESTREAM powinna również odbywać się za pośrednictwem instrukcji SQL Server albo oficjalnego interfejsu FILESTREAM. Nie należy modyfikować nazw, przenosić plików ani usuwać elementów bezpośrednio z katalogu danych.

Przed większą operacją warto sprawdzić rozmiar kontenera FILESTREAM, rozmiar bazy, ilość wolnego miejsca oraz rozmiar dziennika transakcji. Usunięcie wielu rekordów w jednej transakcji może powiększyć log i zwiększyć czas potrzebny na późniejsze uporządkowanie obiektów. Z tego powodu w środowiskach produkcyjnych często planuje się usuwanie partiami, z kontrolą czasu trwania transakcji i wpływu na pracę aplikacji. Wielkość partii nie jest uniwersalną stałą; zależy między innymi od rozmiaru obiektów, wydajności dysków, modelu odzyskiwania oraz liczby równoległych operacji.

Po zmianie danych należy poczekać na zakończenie wymaganych odczytów i pracę garbage collection, a następnie ponownie zmierzyć zajętość miejsca. Zmniejszenie rozmiaru plików bazy lub dziennika nie jest tym samym co usunięcie nieużywanych obiektów FILESTREAM. Operacje zmniejszania plików wykonuje się tylko po uzasadnionej analizie, ponieważ częste lub automatyczne shrinkowanie może prowadzić do fragmentacji i pogorszenia wydajności. Nie zastępuje ono prawidłowego zarządzania rekordami ani mechanizmu sprzątania FILESTREAM.

Weryfikacja kontenera i diagnostyka skutków usuwania

Kontrola procesu powinna łączyć informacje z bazy danych i systemu plików. W SQL Server sprawdza się między innymi definicję tabeli, obecność kolumn FILESTREAM, liczbę rekordów, rozmiar przechowywanych danych oraz aktualne transakcje. Po stronie systemu operacyjnego obserwuje się zajętość woluminu, ale nie interpretuje pojedynczych nazw plików jako niezależnych obiektów możliwych do ręcznego porządkowania. Nazwy i układ elementów kontenera są szczegółem implementacyjnym SQL Server.

Jeżeli miejsce nie jest zwalniane, trzeba sprawdzić, czy usunięcie zostało zatwierdzone, czy nie działa długo trwająca transakcja oraz czy aplikacja nie utrzymuje otwartych uchwytów do danych FILESTREAM. Należy także rozróżnić dane usunięte logicznie od danych, które nadal są osiągalne przez rekordy tabeli. Sam wzrost rozmiaru katalogu nie dowodzi jeszcze uszkodzenia. Niepokojące są dopiero niespójności potwierdzone diagnostyką SQL Server, błędy dostępu, problemy z integralnością albo brak możliwości odczytu danych powiązanych z istniejącymi rekordami.

W przypadku komputera wykorzystywanego do pracy z SQL Server diagnostyka powinna obejmować jednocześnie nośnik danych, system plików, konfigurację usługi SQL Server i stan samej bazy. Trzeba zabezpieczyć kopię zapasową oraz nie wykonywać ręcznych operacji w kontenerze FILESTREAM przed ustaleniem przyczyny. Naprawa skutków nieprawidłowego czyszczenia może wymagać odtworzenia danych albo sprawdzenia integralności bazy, dlatego każdą ingerencję poprzedza się identyfikacją zależności między tabelą, transakcją i kontenerem.