Rozwiązywanie problemów z baza danych MSSQL w programach księgowych

Problemy z bazą danych MSSQL są jedną z najczęstszych przyczyn awarii programów księgowo-magazynowych zgłaszanych do naszego serwisu. Ich skutki mogą być różne: program nie uruchamia się, stanowiska robocze tracą połączenie z serwerem, zapis dokumentu kończy się błędem albo aplikacja działa bardzo wolno. W wielu przypadkach sam komunikat programu nie wskazuje jednoznacznie, czy przyczyną jest serwer SQL, sieć, system Windows, konfiguracja stanowiska czy uszkodzenie danych.

Programy takie jak Comarch ERP Optima, enova365, Symfonia ERP czy WF-Mag opierają się na silniku Microsoft SQL Server, a jego awarie lub błędna konfiguracja bezpośrednio uniemożliwiają pracę w programie. Do najczęstszych problemów należą: zatrzymana usługa SQL Server, brak połączenia sieciowego z instancją bazy, uszkodzona baza danych po nieprawidłowym zamknięciu systemu oraz przekroczenie limitu rozmiaru bazy w wersji Express.

Przed rozpoczęciem naprawy warto ustalić, czy problem występuje na wszystkich komputerach, czy tylko na jednym stanowisku. Jeżeli program nie działa również na komputerze pełniącym funkcję serwera, przyczyny należy szukać przede wszystkim w usłudze SQL Server, systemie operacyjnym, dysku lub samej bazie. Jeżeli problem dotyczy wyłącznie jednej stacji roboczej, bardziej prawdopodobna jest błędna konfiguracja połączenia, problem z siecią lokalną, zaporą albo profilem użytkownika.

Zatrzymana lub niedostępna usługa

Sprawdzamy status usługi SQL Server w konsoli usług systemu Windows, weryfikujemy logi zdarzeń pod kątem przyczyny zatrzymania (często jest to brak miejsca na dysku systemowym lub błąd po aktualizacji systemu) oraz konfigurujemy usługę tak, by uruchamiała się automatycznie przy starcie komputera.

W środowiskach, w których używana jest instancja nazwana, trzeba sprawdzić nie tylko główną usługę SQL Server, ale także SQL Server Browser. Jej zatrzymanie może powodować problemy z odnalezieniem instancji przez program, szczególnie gdy konfiguracja korzysta z nazwy serwera i instancji zamiast ze stałego portu. Sama obecność usługi na liście nie oznacza jeszcze, że działa prawidłowo. Znaczenie ma również konto, na którym jest uruchomiona, uprawnienia do katalogów baz oraz poprawność ścieżek do plików danych i logów.

Przyczyną zatrzymania usługi może być także pełny dysk, uszkodzenie plików systemowych, błąd podczas aktualizacji, nieprawidłowa zmiana konfiguracji lub nagłe odłączenie zasilania. W logach SQL Server można znaleźć informacje o problemach z otwarciem plików MDF i LDF, braku uprawnień, błędach odczytu dysku oraz nieudanym uruchomieniu bazy. Nie należy wielokrotnie uruchamiać usługi bez analizy komunikatu, ponieważ może to utrudnić ustalenie kolejności zdarzeń.

Jeżeli usługa nie startuje, przed próbą naprawy wykonujemy kopię dostępnych plików baz danych oraz sprawdzamy stan nośnika. W przypadku podejrzenia awarii dysku dalsza praca na tej samej instalacji może pogłębić uszkodzenia. Szczególnej ostrożności wymagają sytuacje, w których serwer działa, ale baza pozostaje w stanie Recovery Pending, Suspect lub Emergency. Każdy z tych stanów wymaga innego postępowania i nie powinien być ignorowany.

Problemy sieciowe

Jeśli baza danych znajduje się na serwerze, a program nie łączy się z niej ze stacji roboczej, sprawdzamy konfigurację protokołów SQL Server (TCP/IP musi być włączony), ustawienia zapory sieciowej (port 1433 oraz usługa SQL Server Browser na porcie UDP 1434) oraz poprawność nazwy instancji SQL wpisanej w konfiguracji programu.

W pierwszej kolejności ustalamy, czy komputer kliencki widzi serwer w sieci i czy odpowiada właściwa nazwa hosta. Sam dostęp do udziału sieciowego nie potwierdza jeszcze możliwości połączenia z SQL Server, ponieważ baza korzysta z osobnego protokołu i portu. Zdarza się również, że po zmianie routera, adresacji lub nazwy komputera program nadal korzysta ze starej konfiguracji.

Ważnym elementem diagnostyki jest rozróżnienie instancji domyślnej i nazwanej. Dla instancji domyślnej często stosuje się nazwę serwera lub adres IP, natomiast dla instancji nazwanej konieczne jest wskazanie właściwego formatu, na przykład nazwa_serwera\NAZWA_INSTANCJI. Jeżeli SQL Server Browser nie działa albo zapora blokuje zapytania, rozwiązaniem może być skonfigurowanie stałego portu TCP i wpisanie go w konfiguracji połączenia.

Problemy z połączeniem mogą pojawić się po aktualizacji systemu, zmianie programu antywirusowego lub przywróceniu ustawień zapory. Warto sprawdzić reguły zarówno na serwerze, jak i na stacji roboczej. Nie należy jednak wyłączać całej zapory na stałe. Bezpieczniejszym rozwiązaniem jest utworzenie reguł zezwalających na wymagany ruch i ograniczenie ich do właściwego profilu sieci oraz zakresu urządzeń.

Jeżeli połączenie jest niestabilne, a program raz działa, a raz zgłasza błąd, przyczyną może być uszkodzone okablowanie, przeciążony przełącznik, problemy z kartą sieciową lub usypianie urządzenia pełniącego funkcję serwera. W takich przypadkach trzeba obserwować, czy przerwy występują tylko podczas zapisu dokumentów, czy również podczas zwykłego przeglądania danych. Częste rozłączanie w czasie transakcji może prowadzić do błędów i niespójności.

Uszkodzenie bazy danych

Nieprawidłowe zamknięcie systemu, awaria zasilania lub uszkodzenie dysku mogą prowadzić do niespójności bazy danych, objawiającej się błędami przy uruchamianiu programu lub komunikatami o uszkodzonych indeksach. W takich sytuacjach w pierwszej kolejności próbujemy odtworzyć bazę z najświeższej kopii zapasowej; jeśli kopii brak lub jest nieaktualna, wykorzystujemy narzędzia diagnostyczne SQL Server (m.in. polecenie DBCC CHECKDB) do próby naprawy uszkodzonych struktur bazy.

Przed użyciem poleceń naprawczych należy zabezpieczyć aktualny stan bazy. Nawet jeżeli baza nie otwiera się w programie księgowym, jej pliki mogą zawierać dane, których nie da się później odzyskać po pochopnej naprawie. Kopia robocza oraz kopia plików dziennika pomagają zachować możliwość powrotu do wcześniejszego stanu i porównać efekty kolejnych działań.

DBCC CHECKDB służy przede wszystkim do wykrywania błędów spójności. Wynik diagnostyki powinien być dokładnie przeanalizowany, ponieważ nie każdy komunikat oznacza konieczność naprawy. Czasami problem dotyczy wyłącznie indeksów, które można odbudować, a czasami uszkodzone są strony danych lub struktury systemowe. Polecenia z opcją naprawy mogą powodować utratę części informacji, dlatego powinny być stosowane dopiero po sprawdzeniu dostępnych kopii zapasowych i ocenie ryzyka.

Objawem uszkodzenia mogą być także błędy pojawiające się tylko przy określonej operacji, na przykład wystawianiu dokumentu, zamykaniu okresu lub generowaniu raportu. Nie oznacza to automatycznie, że uszkodzona jest cała baza. Przyczyną może być konkretny indeks, tabela, procedura lub problem z uprawnieniami użytkownika. W takiej sytuacji pomocne jest porównanie zachowania programu na innych stanowiskach oraz sprawdzenie logów aplikacji i SQL Server.

Po przywróceniu bazy z kopii zapasowej trzeba zweryfikować jej spójność oraz działanie programu. Należy sprawdzić logowanie użytkowników, dostęp do dokumentów, raporty, numerację, wydruki i integracje z innymi modułami. Sama możliwość uruchomienia programu nie jest wystarczającym potwierdzeniem poprawnego odzyskania danych.

Limit wersji Express

Darmowa wersja SQL Server Express ma limit rozmiaru bazy danych (10 GB na bazę w nowszych wersjach). Gdy baza zbliża się do tego limitu, program zaczyna zgłaszać błędy zapisu — rozwiązaniem jest archiwizacja starych danych, optymalizacja bazy lub migracja na płatną wersję Standard bez ograniczeń rozmiaru.

Przekroczenie limitu może być mylące, ponieważ inne bazy na tym samym serwerze mogą nadal działać. Problem dotyczy konkretnej bazy, która osiągnęła maksymalny rozmiar. W logach mogą pojawić się komunikaty o braku miejsca dla obiektu, niemożności powiększenia pliku danych albo nieudanej operacji zapisu. Warto odróżnić ten limit od braku wolnego miejsca na dysku. Są to dwa różne problemy, choć ich objawy mogą wyglądać podobnie.

Analiza rozmiaru powinna obejmować zarówno plik danych, jak i plik dziennika transakcji. Duży plik LDF nie zawsze oznacza, że baza przekroczyła limit danych, ale może wskazywać na nieprawidłowy model wykonywania kopii dziennika, długo trwającą transakcję lub brak regularnej konserwacji. Zmniejszanie plików bez ustalenia przyczyny nie jest uniwersalnym rozwiązaniem i może pogorszyć wydajność.

Archiwizacja danych powinna być wykonana zgodnie z zasadami używanego programu. Nie można po prostu usuwać rekordów bez sprawdzenia zależności między dokumentami, kontrahentami, płatnościami i rozliczeniami. W wielu systemach bezpieczniejszym rozwiązaniem jest zamknięcie starych okresów, utworzenie archiwum za pomocą funkcji programu i pozostawienie wymaganych danych do celów księgowych oraz kontrolnych.

Wolne działanie programu księgowego

Nie każda powolna praca oznacza uszkodzenie bazy. Przyczyną może być brak zasobów serwera, niewystarczająca ilość pamięci, przeciążony dysk, rozbudowane zapytania raportowe albo nieaktualne statystyki i indeksy. Jeżeli problem pojawia się tylko podczas generowania konkretnego zestawienia, warto sprawdzić, czy raport nie obejmuje zbyt dużego zakresu danych lub wielu jednoczesnych operacji.

Na serwerze analizujemy obciążenie procesora, pamięci i dysku, a także wolne miejsce oraz czas odpowiedzi nośnika. Istotne jest ustalenie, czy spowolnienie dotyczy wszystkich użytkowników. Jeżeli tak, należy zbadać wspólne zasoby. Gdy tylko jedno stanowisko działa wolno, przyczyną może być lokalny dysk, profil Windows, oprogramowanie ochronne lub problem z połączeniem sieciowym.

Konserwacja bazy powinna obejmować kontrolę indeksów, statystyk oraz prawidłowości wykonywania kopii zapasowych. Czynności te trzeba planować tak, aby nie zakłócały pracy użytkowników i nie były wykonywane bez sprawdzenia dokumentacji producenta programu księgowego. Równie ważne jest zachowanie wolnego miejsca na dysku, ponieważ SQL Server potrzebuje przestrzeni do tworzenia plików tymczasowych i obsługi transakcji.

Uprawnienia i konfiguracja logowania

Program może nie łączyć się z bazą także wtedy, gdy usługa działa i sieć jest sprawna, ale użytkownik nie ma odpowiednich uprawnień. Dotyczy to zarówno konta używanego przez aplikację, jak i dostępu do plików bazy, katalogów kopii zapasowych oraz zasobów systemu Windows. Po zmianie hasła, konta serwisowego lub polityki bezpieczeństwa wcześniej działające połączenie może przestać być akceptowane.

Sprawdzamy, czy program korzysta z uwierzytelniania Windows, czy z logowania SQL Server, oraz czy wskazany użytkownik ma dostęp do właściwej bazy. Należy unikać przyznawania wszystkim użytkownikom pełnych uprawnień administracyjnych. Konfiguracja powinna zapewniać działanie programu, ale jednocześnie ograniczać ryzyko przypadkowej zmiany lub usunięcia danych.

Kopie zapasowe i przygotowanie do awarii

Najskuteczniejszą ochroną przed długotrwałą przerwą w pracy jest sprawdzony system kopii zapasowych. Sama obecność pliku kopii nie gwarantuje możliwości odzyskania danych. Należy kontrolować, czy kopie są wykonywane, czy nie kończą się błędem, czy można je odczytać oraz czy obejmują właściwą bazę.

Kopie powinny być przechowywane w sposób ograniczający ryzyko utraty ich razem z serwerem. Warto także ustalić, kto odpowiada za ich kontrolę i jak wygląda procedura odtworzenia. Próba przywrócenia kopii dopiero po awarii często ujawnia problemy z hasłami, ścieżkami, wersją SQL Server albo brakującymi plikami.

Przy zgłoszeniu awarii pomocne są dokładne informacje: treść komunikatu, moment pojawienia się problemu, lista stanowisk, których dotyczy, ostatnie aktualizacje, wcześniejsze restarty oraz informacja o dostępnych kopiach zapasowych. Takie dane ułatwiają rozróżnienie awarii usługi, sieci, konfiguracji i samej bazy, a także pozwalają szybciej dobrać bezpieczną metodę działania.

Najczęstsze pytania dotyczące MSSQL

Czy ponowne uruchomienie komputera może rozwiązać problem?

Restart może pomóc, gdy usługa została chwilowo zablokowana albo system nie zakończył poprawnie aktualizacji. Nie usuwa jednak uszkodzeń bazy, błędów dysku, nieprawidłowych reguł zapory ani problemów z limitem wersji Express. Jeżeli problem powtarza się po każdym uruchomieniu, trzeba znaleźć jego przyczynę zamiast ograniczać się do kolejnych restartów.

Czy można przenieść bazę na inny komputer?

Jest to możliwe, ale wymaga sprawdzenia wersji SQL Server, konfiguracji instancji, uprawnień oraz ustawień programu. Samo skopiowanie pliku bazy bez poprawnego odłączenia, dołączenia lub odtworzenia z kopii może doprowadzić do problemów. Po migracji należy przetestować pracę wszystkich stanowisk i funkcji używanych w firmie.

Co zrobić, gdy nie ma aktualnej kopii zapasowej?

Nie należy wykonywać przypadkowych operacji na oryginalnych plikach. Najpierw trzeba zabezpieczyć ich kopię i ocenić stan bazy oraz nośnika. Dopiero potem można zdecydować, czy możliwe jest odtworzenie danych, naprawa struktur, eksport wybranych tabel lub wykorzystanie starszej kopii. Zakres odzysku zależy od rodzaju uszkodzenia i stanu dostępnych plików.

Praktyczna kolejność diagnostyki

Bezpieczna diagnostyka zwykle zaczyna się od ustalenia zakresu awarii, zebrania komunikatów i sprawdzenia, czy problem występuje lokalnie, czy na wszystkich komputerach. Następnie kontroluje się stan usługi SQL Server, wolne miejsce, logi systemowe i SQL Server, komunikację sieciową oraz konfigurację instancji. Dopiero później analizuje się spójność bazy, limity wersji i wydajność.

ustalenie, których użytkowników i stanowisk dotyczy problem,
sprawdzenie usługi SQL Server oraz SQL Server Browser,
kontrola miejsca na dysku i stanu nośnika,
weryfikacja TCP/IP, portów, zapory i nazwy instancji,
zabezpieczenie dostępnych plików oraz kopii zapasowych,
analiza logów i wyników diagnostyki bazy,
test działania programu po wykonaniu naprawy.

Taka kolejność ogranicza ryzyko pochopnych zmian i pomaga zachować dane w możliwie niezmienionym stanie. W przypadku programów księgowych szczególne znaczenie ma nie tylko przywrócenie uruchamiania aplikacji, ale również potwierdzenie poprawności dokumentów, raportów i zapisów po awarii.

Zgłoszenie naprawy: 22 390 56 49 — telefon czynny całą dobę, siedem dni w tygodniu. Sprzęt odbieramy spod wskazanego adresu w Grodzisku Mazowieckim i okolicy.