Systemy sprzedażowe i księgowe — Subiekt, WAPRO, Comarch — opierają się na wspólnej bazie danych SQL. Jej uszkodzenie potrafi zatrzymać kilka programów jednocześnie, mimo że pozornie są od siebie niezależne.

Objaw

Kilka programów firmowych korzystających z tej samej bazy przestaje działać w tym samym czasie — zgłaszają błąd połączenia, uruchamiają się bardzo wolno albo pokazują niespójne dane, na przykład błędne stany magazynowe czy brakujące dokumenty.

Możliwe przyczyny

Uszkodzenie plików bazy danych po awarii zasilania w trakcie zapisu.
Awaria dysku, na którym przechowywana jest baza.
Rozrośnięta baza bez porządkowania przez lata, prowadząca do błędów wydajnościowych i strukturalnych.
Błąd po nieudanej aktualizacji systemu bazodanowego lub samego programu.
Przekroczony limit rozmiaru bazy w wersjach programów z takim ograniczeniem.

Co robimy

Diagnoza obejmuje sprawdzenie spójności bazy danych i ustalenie zakresu uszkodzenia. W zależności od wyniku wykonywana jest naprawa bazy dostępnymi narzędziami diagnostycznymi albo odtworzenie z ostatniej, sprawnej kopii zapasowej — dlatego tak ważne jest wcześniejsze wdrożenie kopii zapasowych z testami odtwarzania. Przy problemach wydajnościowych wykonywana jest reindeksacja i porządkowanie starych danych, co często przywraca sprawność bez konieczności wymiany sprzętu.

Ile to trwa

Dojazd serwisanta do siedziby firmy realizowany jest w ciągu 1 godziny od zgłoszenia. Czas naprawy zależy od zakresu uszkodzenia bazy — proste przypadki bywają rozwiązywane od ręki, poważniejsze wymagają odtworzenia z kopii i mogą potrwać dłużej.

Co można zrobić samemu, zanim przyjedzie serwisant

Warto zanotować, które konkretnie programy przestały działać i jaki dokładnie błąd wyświetlają, oraz sprawdzić, czy w firmie istnieje aktualna kopia zapasowa bazy danych.

Czego nie robić: nie warto samodzielnie próbować naprawiać bazy danych nieznanymi narzędziami — nieprawidłowa ingerencja może pogłębić uszkodzenie i utrudnić późniejsze odtworzenie.

Warunki

Dojazd na terenie Warszawy i okolic realizowany jest bezpłatnie, całą dobę, bez dopłat za noc, weekend i święta. Naprawy objęte są gwarancją do 12 miesięcy.

Warianty problemu

Nie każde uszkodzenie wspólnej bazy wygląda tak samo, a rozróżnienie wariantu wpływa na dobór metody naprawy. Warto znać kilka najczęstszych postaci tego samego objawu.

Baza lokalna na jednym komputerze. W małych firmach silnik bazy danych (na przykład Microsoft SQL Server w wersji dla mniejszych instalacji lub inny system bazodanowy, na którym oparty jest program) bywa zainstalowany na tym samym komputerze, z którego korzysta kilku pracowników przez sieć lokalną. Awaria tego jednego stanowiska blokuje pracę wszystkich, mimo że fizycznie uszkodzony jest tylko jeden dysk.

Baza na wydzielonym serwerze. W większych firmach silnik bazy danych działa na osobnym serwerze, a stanowiska pracowników łączą się z nim przez sieć. Tutaj przyczyną bywa nie tylko awaria dysku serwera, ale też problem z samą usługą bazodanową — uruchomioną, lecz niereagującą prawidłowo na zapytania programów.

Uszkodzenie logiczne kontra fizyczne. Uszkodzenie logiczne oznacza, że dane na dysku fizycznie są nienaruszone, ale struktura wewnętrzna bazy (na przykład indeksy czy tabele systemowe) jest niespójna — zwykle da się to naprawić narzędziami diagnostycznymi. Uszkodzenie fizyczne dysku to poważniejszy scenariusz, w którym część danych może być bezpowrotnie utracona, a jedynym wyjściem staje się odtworzenie z kopii zapasowej.

Awaria silnika bazy a awaria programu klienckiego. Czasem to nie sama baza jest uszkodzona, tylko usługa, która nią zarządza, przestała działać poprawnie po aktualizacji systemu operacyjnego lub zmianie ustawień sieciowych. Objawy — brak połączenia w kilku programach naraz — wyglądają identycznie jak przy uszkodzeniu samych plików bazy, dlatego diagnoza zaczyna się od odróżnienia tych dwóch sytuacji.

Kiedy to NIE jest ta usterka

Kilka sytuacji przypomina uszkodzenie wspólnej bazy, choć ma inną przyczynę i wymaga innego postępowania.

Jeśli przestaje działać tylko jeden program, a pozostałe korzystające z tej samej bazy pracują normalnie, problem częściej dotyczy instalacji konkretnej aplikacji, jej licencji albo pliku konfiguracyjnego — nie samej bazy danych. Jeśli programy „zawieszają się” tylko przy próbie wysłania dokumentu przez internet (na przykład e-faktury albo synchronizacji z Allegro czy BaseLinkerem), a lokalne operacje działają bez zarzutu, przyczyną bywa przerwane połączenie internetowe albo awaria usługi po stronie zewnętrznego dostawcy, nie baza lokalna. Osobną kategorią jest sytuacja, w której programy działają poprawnie, ale drukowanie dokumentów się nie udaje — to zwykle kwestia sterownika drukarki lub jej konfiguracji, a nie bazy danych. Warto też odróżnić spowolnienie wynikające z przeciążenia samego komputera (zbyt wiele otwartych programów, mało wolnej pamięci) od rzeczywistego błędu połączenia z bazą — pierwsze ustępuje po restarcie stanowiska, drugie nie.

Błędy przy próbie naprawy samodzielnie

W obliczu zatrzymanej pracy kilku programów naraz naturalnym odruchem jest szukanie szybkiego rozwiązania na własną rękę. Kilka typowych działań w praktyce pogarsza sytuację zamiast ją naprawiać.

Wielokrotne, gwałtowne restartowanie usługi bazy danych lub całego komputera w trakcie trwającego zapisu potrafi pogłębić uszkodzenie plików, zwłaszcza jeśli pierwotną przyczyną była awaria zasilania. Ręczne usuwanie lub przenoszenie plików bazy w poszukiwaniu „uszkodzonego elementu” bez wiedzy o strukturze konkretnego silnika bazodanowego najczęściej kończy się utratą danych, które wcześniej dało się jeszcze odzyskać. Pobieranie i uruchamianie przypadkowych narzędzi naprawczych znalezionych w internecie bywa ryzykowne — część takich programów nie jest dopasowana do konkretnej wersji silnika bazy i może nadpisać dane w sposób nieodwracalny. Odtwarzanie najstarszej dostępnej kopii zapasowej bez sprawdzenia jej daty prowadzi z kolei do utraty części dokumentów wprowadzonych już po jej wykonaniu — zanim dojdzie do odtworzenia, warto ustalić, która kopia jest najnowsza i faktycznie sprawna.

Dodatkowe pytania klientów

Czy dane wprowadzone tuż przed awarią da się odzyskać?

Zależy od rodzaju uszkodzenia. Przy uszkodzeniu logicznym (struktura bazy niespójna, ale pliki fizycznie nienaruszone) odzyskanie ostatnich zapisów jest często możliwe. Przy fizycznej awarii dysku zakres odzysku zależy od stopnia uszkodzenia nośnika i bywa ograniczony — dlatego regularna, testowana kopia zapasowa pozostaje najpewniejszym zabezpieczeniem.

Czy trzeba wstrzymać pracę wszystkich pracowników na czas naprawy?

Programy korzystające z uszkodzonej bazy pozostają niedostępne do zakończenia naprawy lub odtworzenia z kopii — to wynika z samej natury usterki, nie z decyzji serwisu. Inne zadania na tych samych komputerach, niezwiązane z bazą, mogą być w tym czasie wykonywane normalnie.

Co jeśli w firmie nie ma aktualnej kopii zapasowej bazy?

Naprawa jest wtedy wykonywana bezpośrednio na uszkodzonych plikach bazy dostępnymi narzędziami diagnostycznymi, bez możliwości odtworzenia z kopii. Zakres odzyskanych danych zależy w takiej sytuacji od stopnia uszkodzenia. Po naprawie warto wdrożyć mechanizm regularnych kopii zapasowych z okresowym testem odtwarzania, żeby kolejna awaria nie oznaczała ryzyka utraty danych.

Czy uszkodzenie bazy może się powtórzyć po naprawie?

Jeśli pierwotną przyczyną była awaria zasilania, ryzyko nawrotu ogranicza zastosowanie zasilacza awaryjnego (UPS), który pozwala bezpiecznie zamknąć programy przy zaniku prądu. Jeśli przyczyną było zestarzenie się dysku, po naprawie warto rozważyć jego wymianę — sama naprawa bazy nie usuwa fizycznej przyczyny usterki nośnika.

Czy to dotyczy też baz przechowywanych na serwerze NAS?

Tak, jeśli firma trzyma bazę danych na serwerze NAS (sieciowym urządzeniu do przechowywania danych) zamiast na zwykłym komputerze, mechanizm awarii jest analogiczny — uszkodzenie plików bazy lub dysku w takim urządzeniu również zatrzymuje pracę wszystkich programów, które się z nią łączą. Diagnoza i naprawa obejmują wtedy również samo urządzenie NAS.

Czy dalsze korzystanie z programów po pojawieniu się błędu jest bezpieczne?

Nie zaleca się dalszej pracy w programach zgłaszających błąd połączenia z bazą lub pokazujących niespójne dane, nawet jeśli częściowo się otwierają. Zapisywanie kolejnych dokumentów w takim stanie potrafi utrwalić niespójność — na przykład dokument zapisze się z błędnym numerem albo zdubluje pozycję magazynową — a to komplikuje późniejszą naprawę. Bezpieczniej zamknąć programy i poczekać na diagnozę.

Znaczenie momentu reakcji

Czas, jaki upływa między pierwszym błędem a zgłoszeniem awarii, ma znaczenie dla zakresu możliwej naprawy. Uszkodzenie logiczne bazy, które w pierwszej godzinie ogranicza się do pojedynczej tabeli czy indeksu, przy dalszym korzystaniu z programów — zwłaszcza przy próbach ręcznej naprawy opisanych wyżej — może rozszerzyć się na kolejne elementy struktury. To samo dotyczy awarii dysku: pracujący, uszkadzający się nośnik z każdą kolejną operacją zapisu zwiększa ryzyko utraty dodatkowych danych. Z tego względu zgłoszenie awarii od razu po zauważeniu pierwszych błędów w kilku programach naraz, zamiast prób samodzielnego obejścia problemu, zwiększa szanse na pełne odzyskanie danych.

Wspólna baza jako pojedynczy punkt awarii

Kilka pozornie niezależnych programów księgowych i sprzedażowych, które nagle przestają działać razem, to w praktyce jeden problem, nie kilka osobnych. Baza danych stanowi tu wspólny mianownik — jej stan decyduje o tym, czy Subiekt, WAPRO czy Comarch w ogóle wystartują. Dlatego diagnoza zaczyna się zawsze od bazy, a nie od pojedynczych programów, i dlatego kopia zapasowa bazy jest tu ważniejsza niż kopia samych plików programu.

22 378 48 09

Uszkodzona baza SQL — gdy przestaje działać kilka programów naraz