Czy Subiekt GT wspiera backup przy migracji baz danych?

Subiekt GT wspiera backup przy migracji baz danych poprzez standardowe mechanizmy kopii zapasowej SQL Server.

Rola kopii zapasowej w migracji bazy Subiekt GT

Subiekt GT korzysta z relacyjnej bazy danych działającej w środowisku Microsoft SQL Server, dlatego migrację danych można oprzeć na standardowych mechanizmach kopii zapasowej tego silnika. Najczęściej stosuje się pełną kopię zapasową bazy, zapisaną do pliku BAK, a następnie odtworzenie jej na docelowej instancji SQL Server. Taki plik zawiera struktury bazy, tabele, indeksy, dane oraz informacje potrzebne do odtworzenia bazy w stanie z chwili wykonania kopii. Nie jest to zwykłe kopiowanie plików programu ani przenoszenie pojedynczych katalogów z dysku.

Przed wykonaniem kopii należy zamknąć Subiekt GT na wszystkich stanowiskach korzystających z danej bazy. Jest to istotne, ponieważ użytkownicy mogą w tym czasie zapisywać dokumenty, modyfikować kartoteki lub wykonywać operacje magazynowe. SQL Server zapewnia spójność transakcyjną kopii, ale zamknięcie programu ogranicza ryzyko, że migracja rozpocznie się w trakcie pracy użytkowników i obejmie dane z nieoczekiwanego momentu. Po wykonaniu kopii warto sprawdzić, czy plik został utworzony poprawnie oraz czy jego rozmiar i data odpowiadają planowanej operacji.

Wykonanie backupu i odtworzenie na serwerze docelowym

Pełną kopię można przygotować z użyciem narzędzi administracyjnych SQL Server albo polecenia Transact-SQL BACKUP DATABASE. Przykładowa operacja ma postać BACKUP DATABASE [NazwaBazy] TO DISK = N'C:\Backup\NazwaBazy.bak' WITH INIT, CHECKSUM. Nazwa bazy i ścieżka muszą odpowiadać rzeczywistej konfiguracji. Ścieżkę interpretuje system, na którym działa usługa SQL Server, a niekoniecznie komputer administratora uruchamiającego narzędzie. Katalog docelowy musi istnieć, a konto usługi SQL Server musi mieć prawo zapisu.

Na serwerze docelowym plik można odtworzyć poleceniem RESTORE DATABASE. Przy przenoszeniu między komputerami często trzeba wskazać nowe lokalizacje plików danych i dziennika transakcji, korzystając z opcji WITH MOVE. Przed restauracją można użyć RESTORE FILELISTONLY, aby odczytać logiczne nazwy plików zapisanych w kopii. Po odtworzeniu należy sprawdzić stan bazy, wykonać kontrolę dostępności tabel i uruchomić Subiekt GT w konfiguracji wskazującej na nową instancję SQL Server. Samo odtworzenie bazy nie zawsze zmienia ustawienia połączenia zapisane na stanowiskach użytkowników.

Zgodność instancji SQL Server i kontrola spójności danych

Backup i restore nie usuwają wymagań dotyczących zgodności środowiska. Docelowa instancja SQL Server musi obsługiwać format bazy pochodzącej ze źródła. Kopii bazy nie można standardowo odtworzyć na starszej wersji silnika niż wersja, na której ją utworzono. Przed migracją trzeba również ustalić nazwę instancji, sposób uwierzytelniania, dostępne konta użytkowników oraz prawa do bazy. W przypadku SQL Server Express należy uwzględnić ograniczenia konkretnej zainstalowanej wersji, ponieważ limit rozmiaru bazy może mieć znaczenie przy większych zbiorach danych.

Po restauracji kontrola nie powinna ograniczać się do sprawdzenia, czy program się uruchamia. Należy zweryfikować logowanie użytkownika, otwieranie kartotek kontrahentów i towarów, dokumenty sprzedaży, stany magazynowe, rozrachunki oraz wydruki używane w codziennej pracy. Przydatne jest także polecenie DBCC CHECKDB, które służy do sprawdzenia logicznej i fizycznej spójności struktur bazy SQL Server. Przykładowo DBCC CHECKDB (N'NazwaBazy') WITH NO_INFOMSGS może ujawnić problemy, których nie widać podczas prostego uruchomienia aplikacji. Wyniki kontroli należy zachować przed przełączeniem użytkowników na nowe środowisko.

Elementy wymagające osobnego przeniesienia

Kopia bazy obejmuje dane przechowywane w bazie Subiekt GT, ale nie musi zawierać wszystkich elementów znajdujących się poza nią. Osobnej kontroli mogą wymagać pliki załączników, szablony wydruków, eksporty, katalogi robocze oraz konfiguracja stanowisk. Jeżeli dokumenty lub kartoteki odwołują się do plików zapisanych w określonej lokalizacji, po migracji trzeba zachować te ścieżki albo odpowiednio zmienić konfigurację. Należy także upewnić się, że na komputerach klienckich zainstalowano zgodną wersję programu i ustawiono właściwe połączenie z serwerem SQL Server.

Przed rozpoczęciem pracy produkcyjnej warto przeprowadzić próbne odtworzenie na kopii środowiska, a następnie ustalić moment przełączenia i wykonać końcowy backup po zatrzymaniu pracy użytkowników. Oryginalną bazę należy zachować do czasu potwierdzenia poprawności migracji. W przypadku problemów z połączeniem, uprawnieniami, integralnością danych albo konfiguracją stanowisk potrzebna jest diagnostyka obejmująca aplikację, SQL Server i system plików. Takie sprawdzenie pozwala odróżnić błąd samej migracji danych od nieprawidłowej konfiguracji docelowego środowiska.