Systemy CRM i ERP skupiają dziś większość codziennej pracy firmy — od zamówień po kontakt z klientem. Ich nagła niedostępność w środku dnia roboczego zatrzymuje pracę całych działów naraz.

Pierwsza godzina

System przestaje odpowiadać, wyświetla błąd połączenia z bazą danych, albo działa wolno do granic używalności. Czasem problem dotyczy wszystkich pracowników jednocześnie, czasem tylko części stanowisk.

Co sprawdzamy w pierwszej kolejności

Stan serwera hostującego system i bazę danych.
Połączenie sieciowe między stanowiskami a serwerem.
Obciążenie bazy danych — czy nie doszło do zablokowania przez zbyt duże zapytanie.
Ewentualną awarię po stronie dostawcy, jeśli system działa w chmurze.

Co robimy

Diagnoza priorytetowo lokalizuje warstwę odpowiedzialną za problem — sieć, serwer czy samą bazę danych. W zależności od wyniku wykonywany jest restart usług, naprawa bazy danych lub kontakt z dostawcą systemu przy awariach po jego stronie.

Ile to trwa

Diagnoza to zwykle jedna wizyta realizowana priorytetowo ze względu na skalę przestoju.

Warunki

Diagnoza komputera stacjonarnego door-to-door kosztuje 200 zł i wlicza się w cenę naprawy. Dojazd na terenie Warszawy i okolic jest bezpłatny, a naprawa objęta jest gwarancją do 12 miesięcy.

Warianty problemu i ich źródła techniczne

Niedostępność systemu klasy ERP (Enterprise Resource Planning — planowanie zasobów przedsiębiorstwa) lub CRM (Customer Relationship Management — zarządzanie relacjami z klientami) rzadko wynika z pojedynczej, uniwersalnej przyczyny. W środowiskach produkcyjnych opartych na takich rozwiązaniach jak Comarch ERP Optima, InsERT GT i nexo (w tym Subiekt, Rewizor, Gratyfikant), WAPRO ERP czy Sage Symfonia, awaria przybiera różne formy techniczne w zależności od architektury wdrożenia.

Pierwszym wariantem jest całkowity brak odpowiedzi silnika bazy danych, najczęściej Microsoft SQL Server lub PostgreSQL. W takim scenariuszu usługa bazodanowa zostaje zatrzymana przez system operacyjny z powodu wyczerpania wolnej przestrzeni na wolumenie dyskowym serwera. Pliki bazodanowe składają się z pliku głównego (MDF — główny plik danych przechowujący tabele i indeksy) oraz pliku dziennika transakcji (LDF — plik rejestrujący wszystkie operacje zapisu i modyfikacji przed ich utrwaleniem). Jeśli baza pracuje w pełnym modelu odzyskiwania (Full Recovery Model), a kopie dziennika transakcji nie są wykonywane regularnie, plik LDF rozrasta się do momentu zapełnienia całego dysku, co wymusza automatyczne zatrzymanie silnika bazodanowego w celu ochrony spójności danych.

Drugim wariantem są blokady transakcyjne i zjawisko zakleszczenia (deadlock — stan, w którym dwa lub więcej procesów bazodanowych wzajemnie blokuje dostęp do zasobów, oczekując na zwolnienie blokady przez drugi proces). Gdy użytkownik uruchamia złożone zestawienie magazynowe lub generuje wielomiesięczny raport finansowy bez odpowiednich indeksów, silnik bazodanowy zakłada blokadę wyłączną na całe tabele. Inne stanowiska robocze próbujące zapisać pojedynczy dokument sprzedaży lub zaktualizować kartotekę kontrahenta zostają zawieszone w kolejce oczekiwania, co z perspektywy pracowników wygląda jak całkowite zamrożenie programu.

Trzeci wariant dotyczy awarii serwera licencji lub zabezpieczeń sprzętowych. Wiele systemów ERP wymaga stałego kontaktu z usługą weryfikującą uprawnienia stanowiskowe lub fizycznym kluczem sprzętowym USB (klucz HASP/dongle podłączony do serwera). Uszkodzenie portu USB, restart usługi licencjonowania lub zakłócenia w komunikacji sieciowej na dedykowanym porcie sprawiają, że aplikacje klienckie odmawiają uruchomienia, wyświetlając komunikat o braku dostępnych licencji, mimo że baza danych działa prawidłowo.

Czwartym wariantem jest problem z warstwą pośredniczącą i siecią lokalną. W przypadku instalacji klient-serwer aplikacje na końcówkach roboczych komunikują się z serwerem bazodanowym za pośrednictwem określonych portów (np. domyślny port 1433 dla Microsoft SQL Server). Zmiana konfiguracji zapory sieciowej (Windows Defender Firewall) po automatycznej aktualizacji systemu Windows, awaria przełącznika sieciowego (switch) czy błędne działanie serwera nazw domenowych (DNS — system tłumaczący nazwy serwerów na adresy IP) mogą odciąć stacje robocze od bazy danych, mimo że sam serwer funkcjonuje bez zakłóceń.

Błędy przy próbach samodzielnego przywrócenia działania

W sytuacji nagłego przestoju w firmie presja czasu często prowadzi do podejmowania impulsywnych prób naprawy przez personel niemający przygotowania administratorskiego. Działania te mogą przekształcić drobną usterkę konfiguracyjną w poważną awarię niosącą ryzyko utraty danych.

Najpoważniejszym błędem jest twardy reset serwera poprzez przytrzymanie przycisku zasilania lub odcięcie dopływu prądu. Gdy serwer zostaje gwałtownie wyłączony podczas trwającej operacji zapisu transakcji bazodanowej, struktura tabel może ulec uszkodzeniu. Po ponownym uruchomieniu silnik bazy danych podejmuje próbę odzyskania spójności (proces crash recovery). W przypadku przerwanych transakcji baza danych może wejść w stan SUSPECT (stan podejrzenia uszkodzenia, w którym baza jest całkowicie niedostępna) lub RECOVERY PENDING (oczekiwanie na zakończenie procedur naprawczych), co wydłuża przestój z minut do wielu godzin.

Drugim powszechnym błędem jest ręczne usuwanie plików z dysku serwera w celu szybkiego zwolnienia miejsca. Użytkownicy często usuwają pliki tymczasowe, pliki kopii zapasowych lub próbują skasować powiększony plik dziennika transakcji (LDF) przy wyłączonej usłudze. Usunięcie pliku LDF bez uprzedniego prawidłowego odłączenia bazy i wykonania procedury odcięcia dziennika prowadzi do utraty spójności i uniemożliwia ponowne podłączenie pliku MDF.

Trzecim błędem jest pochopne przywracanie starszej kopii zapasowej na aktywną bazę produkcyjną. Jeśli w systemie pojawi się błąd połączenia, wgranie kopii zapasowej z poprzedniego wieczora bez wcześniejszego zabezpieczenia aktualnego stanu bazy danych i logów transakcyjnych powoduje bezpowrotną utratę wszystkich dokumentów, faktur i operacji magazynowych wprowadzonych od rana do momentu awarii.

Czwartym błędem jest masowe, ciągłe uruchamianie aplikacji przez wszystkich pracowników jednocześnie. Gdy serwer bazy danych zmaga się z wysokim obciążeniem procesora lub kolejkowaniem operacji dyskowych, setki ponawianych zapytań o autoryzację pogłębiają zator i uniemożliwiają silnikowi zakończenie procedur porządkowych.

Kiedy brak dostępu nie wynika z awarii bazy danych

Prawidłowe rozpoznanie problemu wymaga odróżnienia awarii samego systemu ERP lub CRM od usterek infrastruktury towarzyszącej. Brak możliwości otwarcia programu często bywa mylony z uszkodzeniem bazy danych, podczas gdy przyczyna leży w innym miejscu środowiska informatycznego.

Pierwszym przypadkiem jest usterka lokalnego łącza internetowego lub infrastruktury VPN w firmach wielooddziałowych. Jeśli oddział firmy łączy się z centralną bazą danych przez szyfrowany tunel sieciowy (VPN — Virtual Private Network), zanik połączenia u lokalnego dostawcy internetu uniemożliwia pracę oddziału, podczas gdy centrala pracuje normalnie. W takiej sytuacji restartowanie serwera w centrali jest bezcelowe i powoduje niepotrzebny przestój dla pozostałych pracowników.

Drugim przypadkiem jest problem z czasem systemowym i synchronizacją zegarów (protokół NTP — Network Time Protocol). W środowiskach domenowych opartych na Active Directory, rozbieżność czasu między stacją roboczą a kontrolerem domeny przekraczająca pięć minut powoduje odrzucenie biletów uwierzytelniania Kerberos. Użytkownik nie może zalogować się do systemu ERP przy użyciu konta zintegrowanego z Windows, mimo że baza danych i sieć działają prawidłowo.

Trzecim przypadkiem jest blokada uprawnień na poziomie konta użytkownika. Wielokrotne wprowadzenie błędnego hasła może zablokować konto w samej aplikacji biznesowej lub w systemie operacyjnym stacji roboczej. Problem dotyczy wówczas wyłącznie jednego pracownika, podczas gdy cała reszta zespołu zachowuje pełen dostęp do danych.

Czwartym przypadkiem jest uszkodzenie środowiska uruchomieniowego na komputerze użytkownika. Aplikacje biznesowe wymagają poprawnie działających bibliotek .NET Framework, sterowników ODBC (Open Database Connectivity — standardowy interfejs dostępu do baz danych) lub składników OLE DB. Uszkodzenie tych komponentów w wyniku nieudanej aktualizacji systemu na konkretnym komputerze objawia się błędem komunikacji z bazą danych, mimo pełnej sprawności serwera.

Procedura techniczna przywracania dostępności krok po kroku

Usunięcie awarii systemu biznesowego wymaga metodycznego podejścia, które minimalizuje ryzyko utraty danych i skraca czas przestoju do niezbędnego minimum. Profesjonalna procedura serwisowa realizowana na miejscu obejmuje szereg ściśle określonych kroków weryfikacyjnych.

Pierwszym krokiem jest ocena stanu fizycznego i wirtualnego środowiska serwerowego. Sprawdzane jest obciążenie pamięci operacyjnej RAM, wykorzystanie procesora (CPU) oraz wskaźniki kolejkowania operacji wejścia/wyjścia na macierzy dyskowej (I/O). Weryfikowana jest także ilość wolnego miejsca na wszystkich partycjach systemowych i magazynowych.

Drugim krokiem jest analiza dzienników zdarzeń systemowych (Event Viewer) oraz dzienników błędów silnika bazodanowego (SQL Server Error Log lub logi PostgreSQL). Pozwala to ustalić dokładny kod błędu, który doprowadził do zatrzymania usług lub odrzucania połączeń ze strony stacji roboczych.

Trzecim krokiem jest identyfikacja procesów blokujących. Jeśli silnik bazy danych działa, lecz aplikacje nie odpowiadają, administrator sprawdza aktywne sesje robocze (identyfikatory SPID — Server Process ID). Wykrycie długo trwającej transakcji blokującej pozwala na jej kontrolowane przerwanie bez konieczności restartowania całego środowiska.

Czwartym krokiem jest weryfikacja spójności bazy danych. W przypadku podejrzenia uszkodzenia struktury logicznej lub fizycznej wykonywane są procedury sprawdzające (np. DBCC CHECKDB w środowisku Microsoft SQL Server). Jeśli zostaną wykryte błędy alokacji lub spójności tabel, wdrażana jest odpowiednia procedura naprawcza bazująca na logach transakcyjnych lub kontrolowanej naprawie struktur indeksowych.

Piątym krokiem jest sprawdzenie komunikacji sieciowej i konfiguracji portów. Weryfikowane jest działanie usługi SQL Server Browser, dostępność portu nasłuchującego oraz prawidłowość rozpoznawania nazw sieciowych przy użyciu poleceń diagnostycznych.

Szóstym krokiem jest kontrolowane wznowienie pracy. Po ustabilizowaniu serwera i usunięciu źródła awarii następuje próbne zalogowanie z pojedynczego stanowiska administratora, weryfikacja poprawności zapisu danych testowych, a następnie stopniowe udostępnianie systemu pozostałym użytkownikom.

Działania profilaktyczne zapobiegające awariom oprogramowania biznesowego

Utrzymanie bezawaryjnej pracy systemów ERP i CRM wymaga wdrożenia stałych procedur konserwacyjnych, które eliminują źródła potencjalnych problemów zanim doprowadzą one do paraliżu przedsiębiorstwa.

Podstawowym elementem profilaktyki jest wdrożenie wielopoziomowego planu kopii zapasowych (backup). W środowiskach produkcyjnych standardem jest wykonywanie pełnej kopii zapasowej bazy danych raz na dobę, kopii różnicowych co kilka godzin oraz kopii dziennika transakcji co kilkanaście lub kilkadziesiąt minut. Taki układ pozwala na przywrócenie stanu bazy danych do niemal dowolnego punktu w czasie (Point-in-Time Recovery) przy minimalnej stracie wprowadzonych danych w razie awarii sprzętowej.

Równie istotna jest cykliczna konserwacja baz danych. Obejmuje ona regularną reindeksację (odbudowę i reorganizację pofragmentowanych indeksów), aktualizację statystyk optymalizatora zapytań oraz monitorowanie przyrostu wolumenów dyskowych. Utrzymanie indeksów w należytym stanie zapobiega powstawaniu wąskich gardeł wydajnościowych i eliminuje ryzyko powstawania blokad transakcyjnych podczas intensywnej pracy wielu użytkowników.

Warto zadbać także o zabezpieczenie zasilania. Serwery bazodanowe oraz kluczowe urządzenia sieciowe powinny być podłączone do zasilaczy awaryjnych UPS (Uninterruptible Power Supply — urządzenie zapewniające podtrzymanie zasilania z akumulatorów podczas przerw w dostawie prądu). Odpowiednio skonfigurowany UPS z modułem komunikacyjnym pozwala na bezpieczne, automatyczne zamknięcie bazy danych i wyłączenie serwera w sytuacji przedłużającego się braku zasilania, chroniąc pliki przed uszkodzeniem strukturalnym.

Często zadawane pytania techniczne

Czy po nagłej awarii serwera utracone zostaną dokumenty wystawione tuż przed zatrzymaniem systemu?

Wszystkie transakcje, które zostały poprawnie zatwierdzone (operacja COMMIT) i zapisane w dzienniku transakcji, pozostają bezpieczne. Nowoczesne relacyjne bazy danych spełniają standard ACID (zbiór właściwości gwarantujących niezawodność: atomowość, spójność, izolacja i trwałość transakcji). Oznacza to, że po wznowieniu pracy silnika baza automatycznie wycofuje operacje niedokończone i utrwala wszystkie operacje ukończone. Utracie mogą ulec jedynie te dane, których wprowadzanie było w toku i nie zostało sfinalizowane kliknięciem zapisu przed momentem zatrzymania systemu.

Dlaczego system działa na jednym stanowisku, a na pozostałych wyświetla błąd połączenia?

Taka sytuacja zazwyczaj wskazuje na to, że sam silnik bazy danych funkcjonuje prawidłowo, a problem leży w warstwie sieciowej, konfiguracji zapory lub sposobie adresowania serwera. Stanowisko działające może łączyć się bezpośrednio po lokalnym adresie IP lub znajdować się na tej samej maszynie co serwer bazy danych. Na pozostałych komputerach przyczyną może być awaria lokalnego przełącznika sieciowego (switch), zmiana reguł zapory Windows Defender Firewall blokująca port 1433, błąd konfiguracji serwera DNS lub wygaśnięcie poświadczeń użytkownika w domenie.

Czy do zdiagnozowania i usunięcia awarii systemu ERP konieczne jest udostępnienie haseł administratora?

Domyślnie diagnostyka i prace naprawcze wykonywane są bez konieczności poznawania prywatnych haseł użytkowników czy głównych haseł domenowych. Weryfikacja stanu usług, restart procesów, analiza logów systemowych oraz optymalizacja przestrzeni dyskowej mogą być realizowane w obecności osoby wyznaczonej w firmie lub z poziomu dedykowanych kont technicznych o precyzyjnie ograniczonych uprawnieniach. Jeżeli specyfika problemu wymaga bezpośredniego dostępu do konta bazy danych (np. użytkownika 'sa' w Microsoft SQL Server), procedury realizowane są transparentnie na oczach klienta.

Co oznacza stan bazy danych opisany jako SUSPECT i jak się go usuwa?

Stan SUSPECT oznacza, że silnik bazy danych podczas startu wykrył uszkodzenie pliku danych (MDF) lub pliku dziennika (LDF) i nie był w stanie przeprowadzić procedury automatycznego odzyskiwania spójności. Baza w tym stanie jest całkowicie niedostępna dla użytkowników. Procedura naprawy polega na przełączeniu bazy w tryb awaryjny (EMERGENCY), w którym możliwy jest odczyt struktur, a następnie wykonaniu szczegółowej diagnostyki spójności poleceniem DBCC CHECKDB. W zależności od charakteru uszkodzeń naprawia się powiązania logiczne, odbudowuje indeksy lub przywraca bazę z najświeższej spójnej kopii zapasowej wraz z dograniem transakcji z zachowanego pliku LDF.

Jak zabezpieczyć ciągłość pracy magazynu i sprzedaży na wypadek przyszłych problemów z siecią?

W celu ograniczenia skutków lokalnych awarii sieciowych stosuje się redundancję kluczowych elementów infrastruktury. Obejmuje to instalację zdublowanych połączeń sieciowych, zastosowanie przełączników zarządzalnych z obsługą protokołu STP (Spanning Tree Protocol — protokół zapobiegający powstawaniu pętli w sieci ethernetowej) oraz wydzielenie osobnej podsieci VLAN (Virtual Local Area Network — wirtualna sieć lokalna) dla ruchu bazodanowego. Dodatkowo w oddziałach oddalonych warto rozważyć wdrożenie rozwiązań pracy terminalowej (Remote Desktop Services / RDP), gdzie aplikacja biznesowa uruchamiana jest bezpośrednio na serwerze, a przez sieć przesyłany jest jedynie obraz pulpitu, co znacząco zmniejsza wrażliwość systemu na chwilowe wahania parametrów łącza.

Przywracanie stabilnej ciągłości operacyjnej oprogramowania biznesowego

Nagła niedostępność centralnego oprogramowania do zarządzania przedsiębiorstwem paraliżuje procesy sprzedażowe, logistyczne i księgowe. Skuteczne usunięcie takiej awarii wymaga precyzyjnej identyfikacji wąskiego gardła — od weryfikacji sprzętowej pamięci i dysków, przez analizę rejestrów zdarzeń i struktur relacyjnych, aż po optymalizację reguł sieciowych. Dojazd serwisanta bezpośrednio do siedziby firmy na terenie Warszawy lub powiatów podwarszawskich pozwala na natychmiastową ocenę stanu serwera i infrastruktury LAN w miejscu jej rzeczywistej pracy, co zapewnia najszybsze i bezpieczne dla spójności danych wznowienie działania systemów ERP i CRM.

22 378 48 09

Nagła utrata dostępu do systemu CRM lub ERP w środku dnia pracy