Zmiana serwera, na którym działa baza danych Subiekta GT, wymaga odpowiedniego przygotowania i przeprowadzenia migracji, aby nie utracić historii sprzedaży i dokumentów.

Na czym polega ta usługa

Usługa obejmuje przygotowanie bazy danych do migracji, jej przeniesienie na nowy serwer oraz sprawdzenie poprawności działania po zakończonym procesie.

Dla kogo ma sens

Usługa jest przydatna dla firm zmieniających serwer, na którym działa baza danych Subiekta GT.

Ile to trwa

Migracja bazy danych mieści się z reguły w standardowym czasie do 3 dni.

Warunki

Diagnoza wstępna i wycena są bezpłatne, a usługa objęta jest gwarancją do 12 miesięcy.

Rola relacyjnej bazy danych Microsoft SQL Server w systemie Subiekt GT

System sprzedaży i magazynu Subiekt GT opiera swoje działanie na relacyjnym silniku bazodanowym Microsoft SQL Server (oprogramowaniu odpowiedzialnym za zarządzanie danymi, ich przetwarzanie oraz zabezpieczanie transakcji). Każdy podmiot (czyli pojedyncza firma zarejestrowana w systemie) posiada dedykowaną strukturę składającą się z dwóch podstawowych plików: pliku danych z rozszerzeniem MDF (głównego magazynu tabel, dokumentów, kartotek kontrahentów i cenników) oraz pliku dziennika transakcji z rozszerzeniem LDF (rejestrującego wszelkie operacje przed ich trwałym zapisaniem). Prawidłowe przeniesienie tych zasobów decyduje o integralności danych finansowo-magazynowych oraz stabilności pracy wszystkich stanowisk handlowych w przedsiębiorstwie.

Podczas migracji kluczowe znaczenie ma zachowanie zgodności parametrów instancji bazodanowej. Należy do nich między innymi kolacja znaków (reguła określająca sposób sortowania i porównywania liter w bazie danych), która w standardowej konfiguracji dla systemów linii InsERT GT powinna przyjmować wartość Polish_CI_AS (kolacja polska, niewrażliwa na wielkość liter, wrażliwa na znaki akcentowane). Niewłaściwe ustawienie parametrów silnika na nowej maszynie prowadzi do problemów z poprawnym wyświetlaniem polskich znaków diakrytycznych, błędów podczas wyszukiwania asortymentu oraz uniemożliwia przeprowadzanie przyszłych aktualizacji schematu bazy danych.

Główne scenariusze zmiany serwera bazy danych

Przeniesienie środowiska bazodanowego Subiekta GT realizowane jest w zróżnicowanych okolicznościach infrastrukturalnych. Do najczęstszych wariantów należą:

Przejście z komputera roboczego na dedykowany serwer – w wielu mniejszych przedsiębiorstwach baza danych instalowana jest początkowo na zwykłym komputerze jednego z pracowników (tak zwanym komputerze-matce). Wraz ze wzrostem liczby dokumentów oraz stanowisk sprzedażowych rośnie obciążenie sprzętu, co wymusza przeniesienie danych na dedykowaną jednostkę serwerową lub komputer o podwyższonej niezawodności pracujący pod kontrolą systemu Windows Server.
Wymiana wysłużonego sprzętu serwerowego – planowa modernizacja parku maszynowego, w ramach której dotychczasowy serwer fizyczny zostaje zastąpiony nową platformą sprzętową z szybkimi dyskami półprzewodnikowymi oraz wydajniejszymi kontrolerami pamięci RAM.
Migracja do środowiska wirtualnego – przeniesienie instancji bazy danych na maszynę wirtualną działającą pod nadzorem hiperwizora (oprogramowania do wirtualizacji, takiego jak Hyper-V lub Proxmox), co ułatwia zarządzanie zasobami oraz tworzenie migawek całego systemu.
Aktualizacja wersji silnika bazodanowego – przejście ze starszych, niewspieranych wersji Microsoft SQL Server (na przykład wersji 2008, 2012 czy 2014) na nowsze edycje (takie jak SQL Server 2019 lub 2022), co pozwala na zachowanie zgodności z nowymi aktualizacjami pakietu InsERT GT oraz podniesienie poziomu bezpieczeństwa danych.
Przejście z wersji bezpłatnej SQL Server Express na edycję Standard – darmowa wersja silnika posiada sztywny limit wielkości pojedynczej bazy danych wynoszący 10 GB oraz ograniczenia w wykorzystaniu pamięci operacyjnej i rdzeni procesora. Gdy baza przedsiębiorstwa osiąga ten próg, konieczne staje się wdrożenie płatnej edycji silnika i pełna migracja danych.

Techniczny przebieg procesu migracji krok po kroku

Prawidłowe przeprowadzenie migracji wymaga zachowania ścisłej kolejności działań serwisowych, co eliminuje ryzyko rozbieżności danych lub uszkodzenia struktur relacyjnych:

Krok 1: Weryfikacja integralności wyjściowej bazy danych – przed rozpoczęciem jakichkolwiek prac na starym serwerze wykonuje się procedurę kontrolną przy użyciu polecenia DBCC CHECKDB (instrukcji języka SQL weryfikującej spójność fizyczną i logiczną wszystkich tabel, indeksów oraz alokacji stron w bazie). Wykrycie ewentualnych błędów na tym etapie pozwala na ich naprawę przed przeniesieniem danych.
Krok 2: Całkowite wstrzymanie pracy użytkowników i wykonanie kopii bezpieczeństwa – na czas migracji odłącza się dostęp do bazy dla wszystkich stanowisk klienckich. Następnie tworzona jest pełna kopia zapasowa (plik z rozszerzeniem BAK) przy wykorzystaniu narzędzia Program Serwisowy InsERT GT oraz bezpośrednio przez konsolę SQL Server Management Studio (graficzne środowisko do zarządzania bazami SQL).
Krok 3: Przygotowanie środowiska na serwerze docelowym – instalacja odpowiedniej wersji Microsoft SQL Server z zachowaniem właściwej kolacji, konfiguracją kont systemowych oraz przydziałem pamięci operacyjnej (parametr max server memory określający maksymalną ilość pamięci RAM, jaką może zająć silnik bazy, aby nie doprowadzić do niestabilności systemu operacyjnego).
Krok 4: Odtworzenie bazy danych na nowej instancji – wykonanie operacji odtworzenia (RESTORE) z przygotowanego pliku kopii zapasowej, sprawdzenie uprawnień użytkowników bazy oraz aktualizacja wewnętrznych statystyk i odbudowa indeksów przyspieszających wyszukiwanie informacji.
Krok 5: Konfiguracja połączeń sieciowych i zapory systemowej – włączenie obsługi protokołu TCP/IP w narzędziu SQL Server Configuration Manager, przypisanie standardowego portu nasłuchu (port TCP 1433) oraz uruchomienie usługi SQL Server Browser (odpowiedzialnej za przekazywanie informacji o dostępnych instancjach baz danych na porcie UDP 1434). W zaporze Windows Defender Firewall dodawane są odpowiednie reguły zezwalające na ruch przychodzący.
Krok 6: Rekonfiguracja stanowisk klienckich – zmiana parametrów połączenia w plikach konfiguracyjnych lub oknie logowania programu Subiekt GT na każdym komputerze w sieci lokalnej, ze wskazaniem nowej nazwy sieciowej serwera lub jego stałego adresu IP.
Krok 7: Testy wdrożeniowe i kontrola spójności – próbne logowanie ze stanowisk użytkowników, weryfikacja poprawności wystawiania dokumentów handlowych, sprawdzenie współpracy z urządzeniami fiskalnymi, czytnikami kodów oraz modułami zewnętrznymi.

Błędy popełniane przy próbach samodzielnego przenoszenia bazy danych

Samodzielne próby przeniesienia bazy danych bez odpowiedniego przygotowania technicznego często kończą się przerwaniem ciągłości sprzedaży lub uszkodzeniem struktur informacyjnych. Najczęściej spotykane nieprawidłowości to:

Przenoszenie plików MDF i LDF „na gorąco” – kopiowanie plików bazy danych bezpośrednio z dysku przy uruchomionej usłudze SQL Server. Taka operacja prowadzi do powstania niespójnej lub całkowicie uszkodzonej kopii, której nie da się prawidłowo podłączyć na nowym serwerze. Jedyną prawidłową metodą jest wykonanie pełnego backupu logicznego do pliku BAK lub wcześniejsze poprawne odłączenie bazy (operacja DETACH).
Niezgodność wersji w dół (wersja silnika docelowego starsza niż źródłowego) – próba odtworzenia kopii zapasowej wykonanej na nowszym silniku (na przykład SQL Server 2019) na serwerze ze starszą wersją (na przykład SQL Server 2016). Architektura Microsoft SQL Server nie pozwala na takie działanie ze względu na zmiany w strukturze wewnętrznej stron bazy danych.
Zainstalowanie silnika z błędną kolacją – pozostawienie domyślnej kolacji instalatora SQL Server (często SQL_Latin1_General_CP1_CI_AS) zamiast wymaganej Polish_CI_AS. Skutkuje to błędami przy konwersji bazy danych do nowszych wersji programu oraz problemami z alfabetycznym sortowaniem towarów i kontrahentów.
Powstanie osieroconych użytkowników (orphaned users) – odtworzenie bazy na nowej instancji bez zsynchronizowania identyfikatorów SID (unikalnych numerów bezpieczeństwa) pomiędzy kontami logowania serwera a użytkownikami wewnątrz bazy danych, co uniemożliwia zalogowanie się do programu pomimo wpisywania poprawnych haseł.
Pominięcie baz powiązanych i parametrów globalnych – w przypadku korzystania z kilku podmiotów lub modułów dodatkowych zapomnienie o przeniesieniu bazy nadrzędnej lub parametrów archiwizacji, co uniemożliwia zbiorcze zarządzanie programami z linii InsERT GT.
Pozostawienie dynamicznych adresów IP na serwerze – brak przypisania stałego adresu IP serwerowi bazy danych powoduje, że po każdym restarcie routera sieciowego komputery klienckie tracą połączenie z bazą i zgłaszają błąd braku dostępu do serwera.

Kiedy problem z działaniem systemu nie wynika z samej bazy danych

Zgłaszane przez pracowników spowolnienia lub błędy w komunikacji z systemem Subiekt GT nie zawsze oznaczają usterkę samej bazy danych. Warto odróżnić problemy bazodanowe od innych zakłóceń infrastruktury IT:

Niestabilność lokalnej sieci komputerowej – korzystanie z połączeń bezprzewodowych Wi-Fi na stanowiskach stacjonarnych często prowadzi do chwilowych zerwań transmisji pakietów, co system Subiekt GT interpretuje jako błąd krytyczny połączenia z serwerem. W architekturze klient-serwer wymagane jest stabilne połączenie kablowe oparte na sieci Ethernet kategorii 5e lub 6.
Blokady ze strony oprogramowania antywirusowego – programy zabezpieczające skanujące w czasie rzeczywistym ruch sieciowy na porcie 1433 lub pliki bazodanowe potrafią drastycznie obniżyć wydajność operacji magazynowych lub całkowicie zablokować komunikację.
Rozbieżność wersji programu na stanowiskach – sytuacja, w której na serwerze zainstalowano nowszą wersję pakietu InsERT GT i przeprowadzono konwersję bazy, natomiast na komputerach użytkowników pozostawiono starsze pliki wykonywalne programu, co uniemożliwia uruchomienie aplikacji.
Fizyczna degradacja nośnika danych – powolne wczytywanie list towarowych na nowym serwerze może być spowodowane błędami odczytu i zapisu na uszkodzonym dysku twardym, a nie wadliwą strukturą tabel bazy danych.

Często zadawane pytania dotyczące migracji bazy danych Subiekta GT

Czy podczas procedury migracji użytkownicy mogą normalnie wystawiać dokumenty sprzedaży?

W trakcie tworzenia ostatecznej kopii bezpieczeństwa oraz jej wgrywania na nowy serwer praca wszystkich użytkowników w programie Subiekt GT musi zostać wstrzymana. Wszelkie operacje handlowe wykonane w starej bazie po momencie utworzenia backupu nie znalazłyby się na nowym serwerze, co doprowadziłoby do rozbieżności w numeracji dokumentów i stanach magazynowych. Z tego względu właściwy etap przenoszenia danych planuje się zazwyczaj poza standardowymi godzinami pracy przedsiębiorstwa lub w ustalonym oknie technicznym.

Co należy zrobić, gdy baza danych zbliża się do limitu 10 GB w darmowej wersji SQL Server Express?

Wyczerpanie limitu 10 GB w edycji Express powoduje całkowitą blokadę możliwości zapisywania nowych dokumentów i wpisów w systemie. W ramach przygotowania do migracji przeprowadza się analizę wielkości poszczególnych tabel. Jeśli nadmiarowy rozmiar wynika z rozbudowanych tabel śladu rewizyjnego (rejestru zmian wprowadzanych przez użytkowników) lub nagromadzonych logów zdarzeń, możliwe jest wykonanie procedur kompaktowania i czyszczenia zbędnych wpisów w Programie Serwisowym. W przypadku gdy rozmiar wynika z rzeczywistej wielkości kartotek i dokumentów wieloletnich, jedynym trwałym rozwiązaniem podczas migracji jest wdrożenie płatnej edycji Microsoft SQL Server Standard.

Czy po zmianie serwera bazy danych konieczna jest ponowna aktywacja licencji programu Subiekt GT?

Dane licencyjne oraz numery aktywacyjne podmiotu są zapisane bezpośrednio w strukturze tabel bazy danych i powiązane z numerem NIP przedsiębiorstwa. Prawidłowo odtworzona baza danych na nowym serwerze zachowuje pełne informacje o wykupionych licencjach stanowiskowych oraz licencjach na moduły dodatkowe (takie jak niebieski, zielony czy czerwony PLUS dla InsERT GT). Po zakończeniu migracji nie ma konieczności ponownego wprowadzania kodów licencyjnych, o ile nie nastąpiła równoległa zmiana danych podmiotu gospodarczego.

Jakie zabezpieczenia należy wdrożyć na nowym serwerze po zakończeniu migracji?

Samo przeniesienie bazy nie kończy procesu zabezpieczania środowiska. Na nowym serwerze konfiguruje się automatyczny harmonogram wykonywania codziennych kopii bezpieczeństwa przy wykorzystaniu wbudowanego narzędzia Harmonogram zadań Windows lub agenta SQL Server Agent (dostępnego w pełnych wersjach silnika bazy). Wygenerowane pliki kopii zapasowych powinny być automatycznie transferowane na niezależny nośnik zewnętrzny lub serwer pamięci sieciowej NAS (Network Attached Storage), co zabezpiecza firmę przed utratą danych w razie awarii sprzętowej samego serwera.

Czy migracja bazy Subiekta GT przenosi również dane z innych programów linii InsERT GT?

Tak, programy wchodzące w skład linii InsERT GT (w tym program finansowo-księgowy Rewizor GT, system księgi przychodów i rozchodów Rachmistrz GT, system kadrowo-płacowy Gratyfikant GT oraz system zarządzania relacjami z klientami Gestor GT) współdzielą tę samą strukturę bazy danych danego podmiotu. Przeniesienie bazy na nowy serwer bazy danych automatycznie migruje wszystkie powiązane moduły i informacje księgowe, kadrowe oraz handlowe.

Optymalizacja i konfiguracja środowiska bazodanowego po przeniesieniu

Po fizycznym przeniesieniu bazy i pomyślnym podłączeniu stanowisk handlowych przeprowadza się czynności optymalizacyjne, które gwarantują płynną pracę systemu przy dużym obciążeniu:

Ustawienie limitów pamięci operacyjnej – domyślna instalacja silnika Microsoft SQL Server nie posiada ograniczenia alokacji pamięci RAM, co może prowadzić do zajęcia wszystkich dostępnych zasobów i spowolnienia pracy samego systemu operacyjnego serwera. Ustalenie parametru max server memory na poziomie rezerwującym odpowiednią ilość pamięci dla systemu Windows zapewnia stabilność całej jednostki.
Konfiguracja automatycznego rozrostu plików (Autogrowth) – ustawienie odpowiednich przyrostów wielkości pliku bazy danych MDF oraz pliku dziennika LDF w stałych megabajtach zamiast wartości procentowych, co zapobiega powstawaniu nadmiernej fragmentacji logicznej na dysku serwera.
Wdrożenie planów konserwacji (Maintenance Plans) – cykliczne zadania obejmujące reorganizację i odbudowę indeksów, aktualizację statystyk optymalizatora zapytań oraz sprawdzanie spójności logicznej struktur. Procedury te zapobiegają degradacji wydajności bazy przy wieloletnim przyroście dokumentów.
Weryfikacja komunikacji z urządzeniami peryferyjnymi – kontrola poprawności działania sterowników urządzeń zewnętrznych, w tym drukarek fiskalnych podłączonych lokalnie lub sieciowo przez serwery portów szeregowych, wag kalkulacyjnych oraz czytników kodów kreskowych.

Bezpieczna zmiana infrastruktury serwerowej dla ciągłości sprzedaży

Prawidłowe przeprowadzenie migracji bazy danych Subiekta GT przy zmianie serwera stanowi fundament bezpiecznego funkcjonowania procesów handlowych, magazynowych i rozliczeniowych w firmie. Precyzyjne zachowanie procedur archiwizacji, zgodności kolacji językowej, konfiguracji sieciowej portów SQL oraz optymalizacji parametrów serwera eliminuje ryzyko przestojów w obsłudze klientów i gwarantuje pełną spójność historii transakcji od pierwszego uruchomienia systemu na nowej maszynie.

22 378 48 09

Subiekt GT — migracja danych przy zmianie serwera bazy danych