załączenie bazy danych

Załączenie bazy danych to podłączenie jej plików do instancji poleceniem CREATE DATABASE ... FOR ATTACH.

Na czym polega załączenie bazy danych w SQL Server

Załączenie bazy danych w Microsoft SQL Server polega na podłączeniu istniejących plików bazy do uruchomionej instancji tego silnika. Operację wykonuje się wtedy, gdy pliki zostały wcześniej odłączone od innej instancji, przeniesione w obrębie środowiska albo odzyskane z nośnika, a administrator chce ponownie udostępnić zawartą w nich bazę. Typowa baza SQL Server składa się z głównego pliku danych z rozszerzeniem .mdf, dodatkowych plików danych .ndf oraz pliku dziennika transakcji .ldf. Sama obecność pliku MDF nie zawsze wystarcza do prawidłowego odtworzenia kompletnej struktury, ponieważ baza może korzystać z wielu plików danych i więcej niż jednego pliku dziennika.

Załączenie nie jest tym samym co utworzenie pustej bazy poleceniem CREATE DATABASE nazwa. Podczas attach SQL Server odczytuje metadane zapisane w istniejących plikach, sprawdza ich spójność oraz rejestruje bazę w katalogu instancji. Przykładowe polecenie ma postać CREATE DATABASE [Sklep] ON (FILENAME = 'D:\Dane\Sklep.mdf'), (FILENAME = 'D:\Dane\Sklep_log.ldf') FOR ATTACH;. Nazwa bazy podana w poleceniu może być inna niż nazwa katalogu, ale pliki muszą tworzyć logicznie spójny zestaw należący do tej samej bazy.

Pliki, ścieżki i warunki wykonania operacji

Przed wykonaniem załączenia trzeba ustalić, jakie pliki należą do bazy i gdzie znajdują się na dysku widzianym przez serwer SQL Server. Ścieżka użyta w klauzuli FILENAME jest interpretowana przez komputer, na którym działa usługa SQL Server, a nie przez stację roboczą administratora uruchamiającego SQL Server Management Studio. Jeżeli konsola działa na innym komputerze, wskazanie lokalnego dysku administratora nie udostępni pliku instancji. Pliki powinny znajdować się w katalogu, do którego konto usługi SQL Server ma prawo odczytu i zapisu, zwłaszcza gdy silnik musi zaktualizować dziennik transakcji lub wykonać operacje naprawcze.

Najbezpieczniej jest znać pełną listę plików zapisanych w bazie. Można ją odczytać poleceniem RESTORE FILELISTONLY tylko dla kopii zapasowej, natomiast dla istniejących plików MDF i LDF administrator zwykle korzysta z informacji pochodzących z poprzedniej instancji, dokumentacji albo narzędzi SQL Server przeznaczonych do identyfikacji plików. W przypadku odłączonej bazy wymagane są zazwyczaj wszystkie pliki danych i dziennika. Jeżeli plik dziennika został utracony, SQL Server może w określonych sytuacjach próbować utworzyć nowy dziennik przy użyciu wariantu FOR ATTACH_REBUILD_LOG, ale nie jest to uniwersalny zamiennik odzyskiwania. Taka operacja wymaga, aby baza była prawidłowo zamknięta i nie miała aktywnych, niezatwierdzonych transakcji; w przeciwnym razie może zakończyć się błędem albo utratą danych.

Sprawdzanie zgodności i typowe komunikaty błędów

SQL Server musi mieć możliwość otwarcia plików i odczytania ich wewnętrznych informacji. Istotna jest zgodność wersji silnika: baza utworzona w nowszej wersji SQL Server nie może zostać bezpośrednio załączona do starszej wersji. Po pomyślnym przeniesieniu bazy do nowszego wydania może zostać podniesiony jej poziom wewnętrznej zgodności, dlatego powrót do starszego silnika nie jest wtedy prostą operacją attach. Załączenie plików nie usuwa również problemów wynikających z uszkodzenia stron danych, niespójnego dziennika lub niepełnej kopii zestawu plików.

Częstą przyczyną niepowodzenia jest brak uprawnień systemu plików. Konto usługi SQL Server powinno mieć dostęp do każdego wskazanego pliku oraz do katalogu, w którym znajdują się dane. Błąd może również wynikać z zajęcia pliku przez inną instancję, błędnej ścieżki, braku pliku NDF albo próby załączenia bazy, która nie została wcześniej poprawnie odłączona. Przed zmianami warto zachować kopię wszystkich plików i nie nadpisywać oryginałów. Po wykonaniu operacji należy sprawdzić stan bazy w widoku sys.databases, przejrzeć dziennik SQL Server oraz wykonać kontrolę spójności poleceniem DBCC CHECKDB. Kontrola nie naprawia automatycznie każdego problemu, ale pozwala ustalić, czy załączone pliki opisują spójną bazę.

Attach nie przenosi wszystkich elementów zależnych od instancji. Loginy, zadania SQL Server Agent, poświadczenia, konfiguracja usług, uprawnienia na poziomie serwera oraz niektóre ustawienia nie są przechowywane wyłącznie w plikach bazy. Po podłączeniu mogą więc wystąpić osierocone użytkowniki bazodanowe, czyli użytkownicy zapisani w bazie bez odpowiadającego im loginu w instancji. Ich obsługę trzeba przeprowadzić osobno, zgodnie z konfiguracją konkretnego środowiska. Załączenie powinno być traktowane jako operacja administracyjna wymagająca weryfikacji, a nie jako metoda zastępująca regularne kopie zapasowe.

Bezpieczny przebieg podłączenia bazy

Praktyczny przebieg zaczyna się od identyfikacji źródła plików, ustalenia ich kompletności oraz sprawdzenia, czy baza była odłączona poleceniem sp_detach_db albo inną obsługiwaną procedurą. Następnie należy skopiować pliki do docelowego katalogu, nadać odpowiednie uprawnienia kontu usługi i przygotować polecenie CREATE DATABASE ... FOR ATTACH z właściwymi ścieżkami. Operację wykonuje się na docelowej instancji SQL Server przy użyciu konta mającego uprawnienia pozwalające na tworzenie baz. Po zakończeniu trzeba sprawdzić, czy baza jest online, czy wszystkie pliki zostały wykryte oraz czy aplikacja może odczytywać i zapisywać dane.

Jeżeli celem jest migracja działającej bazy, preferowaną metodą jest zwykle kopia zapasowa i odtworzenie, ponieważ ten sposób obejmuje kontrolowany zapis stanu bazy oraz pozwala jawnie wskazać pliki i opcje odtwarzania. Attach ma zastosowanie przede wszystkim wtedy, gdy dostępny jest właściwy zestaw plików i zachodzi uzasadniona potrzeba bezpośredniego podłączenia ich do instancji. W środowisku diagnostycznym po operacji warto wykonać test zapytania, sprawdzić rozmiary plików, przeanalizować komunikaty silnika i potwierdzić działanie procedury backupu. Dzięki temu można odróżnić samo poprawne zarejestrowanie bazy od rzeczywistej gotowości do dalszej pracy.