Podczas omawiania procesu tworzenia nowej bazy danych z ustawieniami domyślnymi wspomnieliśmy krótko o tzw. grupach plików (ang. filegroups). Domyślnie nowa baza danych tworzona jest z wykorzystaniem dwóch plików fizycznych: pliku wierszy danych (.MDF) oraz pliku dziennika transakcji (.LDF), dla których w oknie tworzenia nowej bazy danych lub w ramach odpowiedniego zapytania T-SQL z grupy zapytań CREATE określamy wartości rozmiaru początkowego, wartości automatycznego przyrostu oraz ich docelowe lokalizacje.
Pliki dziennika transakcji nigdy nie należą do żadnej grupy plików (wartość Not Applicable w kolumnie Filegroup), natomiast plikom wierszy bazy danych (pliki typu ROWS Data) przypisywana jest domyślnie grupa plików PRIMARY. Tym samym każda baza danych zawsze składa się z co najmniej jednego pliku danych, należącego do co najmniej jednej grupy plików. Dla większości baz danych o niewielkiej liczbie wierszy i stosunkowo niskiej złożoności takie ustawienie będzie zapewne w pełni wystarczające, jednak w pozostałych przypadkach będziemy raczej dążyć do rozłożenia zawartych w bazie informacji na kilka odrębnych plików fizycznych, z możliwością ich rozmieszczenia na osobnych nośnikach danych w celu podniesienia przepustowości odczytu. Jasne jest, że po takim podziale bazy pliki te muszą pozostawać ze sobą w relacji, aby baza mogła nadal poprawnie funkcjonować jako całość. Do tego, a także w kilku dodatkowych celach, służą właśnie grupy plików.
Czym jest grupa plików?
Grupa plików to najzwyczajniej w świecie prosty kontener logiczny, który niczym folder w obrębie systemu plików grupuje w systemie SQL Server pliki o podobnym charakterze lub przeznaczeniu. Pierwszy utworzony plik bazy danych należy domyślnie do grupy podstawowej PRIMARY, przez co nazywany jest on często plikiem podstawowym (ang. primary file), charakteryzującym się rozszerzeniem .MDF. Możemy na to również spojrzeć z drugiej strony i powiedzieć, że grupa podstawowa (ang. primary group) jest grupą plików zawierającą plik podstawowy. Plik ten przechowuje oczywiście wprowadzane do bazy rekordy danych, ale zawiera on również odpowiednie metadane umożliwiające pełną inicjalizację bazy danych, a także wskaźniki do pozostałych plików należących do tej samej bazy danych. Jeśli w obrębie wybranej bazy danych poza plikiem podstawowym zdefiniujemy sobie jakiekolwiek dodatkowe pliki danych, wówczas będziemy je nazywać plikami drugorzędnymi (ang. secondary files), które w systemie plików otrzymywać będą rozszerzenie .NDF (w przypadku wszystkich typów plików rozszerzenia nie mają większego znaczenia i możemy je dowolnie zmieniać). Pliki drugorzędne mogą być częścią zarówno dowolnej drugorzędnej grupy plików, jak i grupy podstawowej.
W systemie SQL Server grupy plików stanowią podstawowe i dosyć ważne zagadnienie, jako że wiele operacji na bazie danych zamiast bezpośrednio na pojedynczych plikach danych może być lub jest wykonywanych właśnie na grupach plików. Przykładowo takie obiekty jak tabele i indeksy tworzone i przechowywane są na poziomie poszczególnych grup plików zamiast wprost w zawartych w nich plikach danych, a ze względu na automatyczny sposób organizacji poszczególnych plików w tychże kontenerach logicznych nie mamy kontroli nad tym, w którym konkretnie pliku dany obiekt się fizycznie znajduje. Co więcej, istnieje bardzo duże prawdopodobieństwo, że obiekt taki zostanie odpowiednio rozproszony po wszystkich plikach w danej grupie plików, tak aby rozkład danych był jak najbardziej równomierny. Tak więc jeśli pliki te miałyby różne rozmiary, wówczas dane zostałyby rozdzielone tak, aby największy plik otrzymał odpowiednio większą ilość danych. Wszystko to odbywa się w pełni automatycznie z wykorzystaniem dedykowanego algorytmu rozkładu obciążenia.
Rodzaje i zastosowanie grup plików
W systemie SQL Server istnieją w zasadzie cztery rodzaje grup plików, z których każda ma nieco inny charakter i realizuje inny cel. Do grup tych zaliczamy podstawową grupę plików PRIMARY, drugorzędne grupy plików, grupy plików FILESTREAM oraz grupę plików dla obiektów (tabel) zoptymalizowanych pod kątem pamięci.
Jako że w artykule tym rozmawiać będziemy jedynie o dwóch pierwszych typach grup plików do przechowywania rekordów (wierszy) danych, możemy powiedzieć, że w obu przypadkach grupy te są kontenerami logicznymi do kolekcjonowania dwóch lub więcej plików wierszy. Jak pamiętamy, każdy taki plik (czy to plik podstawowy czy plik drugorzędny) składa się z tzw. zakresów (ang. extent), będących zbiorami 8 stron danych. Każda strona (ang. page) to z kolei 8 KB danych (8096 bajtów danych + 96 bajtów nagłówka), co daje łącznie 64 KB na zakres oraz 16 zakresów na każdy megabajt danych. Interesujące jest również to, że o ile system SQL Server potrafi sprawnie manipulować danymi na poziomie stron, to już odczyt danych z dysku odbywa się wyłącznie na poziomie zakresów.
To, w jaki sposób będziemy korzystać z dostępnych grup plików i dzielić za ich pomocą bazę na odrębne jednostki, zależeć będzie głównie od tego, co chcemy osiągnąć. Jeśli szczególnie zależy nam na podniesieniu wydajności, najczęściej używane i łączone tabele o dużej liczbie wierszy możemy przykładowo rozdzielić na osobne pliki w tej samej grupie plików, po czym umieścić je na osobnych dyskach. Nie będziemy wtedy jednak mieli żadnej kontroli nad tym, gdzie dokładnie znajdują się konkretne dane, gdyż te będą równomierne rozkładane w obrębie wszystkich plików w grupie. Kolejny sposób to rozbicie bazy na kilka odrębnych grup plików, z których każda umieszczona będzie na osobnej jednostce LUN, co powinno nam zagwarantować nieco większą wydajność niż poprzednie rozwiązanie z uwagi na możliwość równoległego skanowania tabel.
Jeśli z kolei interesują nas zagadnienia w zakresie sporządzania kopii zapasowych i przywracania danych, warto wówczas pamiętać, że SQL Server umożliwia wykonywanie tych operacji nie tylko na poziomie plików lub na całej bazy danych, ale również na zdefiniowanych przez nas grupach plików. Poprzez umieszczenie najbardziej krytycznych danych w osobnych grupach plików będziemy mogli skorzystać z dobrodziejstw przywracania fragmentarycznego, czyli przywracania bazy danych w poszczególnych fazach, poczynając od danych najważniejszych, a kończąc na danych, które są najmniej istotne dla naszego biznesu. Również wykonywanie kopii zapasowych może być dzięki temu sprawniejsze, jako że odpowiednie grupy plików możemy backupować niezależnie w różnych terminach, a że będą one zawierać tylko część informacji z bazy, operacja ta trwać będzie znacznie krócej niż w przypadku tworzenia kopii całej bazy danych.
Zarządzanie grupami plików
Liczbę i lokalizacje plików bazy danych, ich cechy oraz przynależność do poszczególnych grup plików możemy sobie zaplanować i skonfigurować już na etapie tworzenia nowej bazy danych. Jeśli jednak dobrane przez nas parametry okażą się w przyszłości nieprawidłowe lub niewystarczające i już po skonfigurowaniu bazy danych zajdzie potrzeba ich modyfikacji, będziemy mogli to zrobić bezpośrednio z poziomu strony Files okna dialogowego Właściwości bazy danych. Z poziomu tej strony możemy nie tylko dodać nowe pliki do istniejącej grupy plików, ale również rozszerzyć lub zmniejszyć te pliki.
Dodawanie plików do grupy plików
Jeśli w miarę rozrostu baza danych zaczyna powoli zbliżać się do maksimum dostępnych dla niej zasobów magazynowych, do odpowiednich grup plików możemy dodać nowe pliki danych, rozmieszczone na dodatkowych magazynach danych lub odrębnych jednostkach LUN. Po kliknięciu przycisku Add możemy sprecyzować nazwę dla nowego pliku, określić dla niego docelową grupę plików, której częścią ma zostać (te tworzone są na stronie Filegroups bieżącego okna właściwości), a także zdefiniować jego wartości rozmiaru początkowego, wartości automatycznego rozrostu oraz fizyczną lokalizację docelową.
To samo możemy oczywiście osiągnąć za pomocą stosownego polecenia modyfikacji danych T-SQL, którego składnia wygląda następująco:
ALTER DATABASE [NazwaBazyDanych]
ADD FILE (NAME = N'NazwaPlikuDanych', FILENAME = N'D:\BAZA\NazwaPlikuDanych.ndf', SIZE = 5120KB, FILEGROWTH = 1024KB)
TO FILEGROUP [PRIMARY];
GO
Należy jednak pamiętać, że po dodaniu do grupy nowych, pustych plików będą one wypełniane danymi jako pierwsze do momentu pełnego zrównoważenia rozkładu danych w obrębie tej grupy.
Rozszerzanie plików
Rozmiar początkowy (Initial size) oraz rozmiar automatycznego rozrostu (Autogrowth) każdego pliku danych w bazie powinniśmy sobie dobrze zaplanować. Jeśli wartości te będą zbyt duże w stosunku do rzeczywistej ilości danych, wówczas możemy przez długi czas niepotrzebnie marnować zarezerwowane miejsce na dysku, którego być może nawet nigdy nie wykorzystamy. Jeśli natomiast wartości te będą zbyt małe, jak ma to miejsce w przypadku wartości domyślnych, wówczas pliki te w miarę pozyskiwania nowych danych rozszerzać się będą zbyt często, co z uwagi na liczne blokady na plikach zakładane w trakcie ich rozszerzania obniżać będzie wydajność bazy danych. Oczywiście każdy plik możemy w dowolnej chwili rozszerzyć ręcznie z poziomu strony Files w oknie Właściwości bazy danych, jak również z wykorzystaniem poniższego polecenia modyfikacji danych T-SQL:
ALTER DATABASE [NazwaBazyDanych]
MODIFY FILE (NAME = N'NazwaPlikuDanych', SIZE = 20480KB, FILEGROWTH = 8192KB);
GO
