To jedno z najbardziej stresujących zgłoszeń, jakie przyjmujemy. W bazie programu handlowego jest cała sprzedaż, magazyn i rozrachunki — czyli materia, z której składa się firma. Dobra wiadomość jest taka, że w większości przypadków da się z tego wyjść, jeżeli nie popełni się błędu w pierwszych minutach.

Najczęstsze przyczyny

Nagłe wyłączenie komputera w trakcie zapisu — zanik prądu, wyłączenie przyciskiem, zawieszenie systemu. To przyczyna numer jeden i dlatego przy komputerach z bazą zasilanie awaryjne traktujemy jako element obowiązkowy.

Druga to problem z dyskiem: uszkodzone sektory pod plikami bazy albo nośnik na wyczerpaniu. Trzecia to zerwane połączenie sieciowe w trakcie operacji zapisu, typowe przy pracy na bazie przez sieć bezprzewodową. Czwarta, rzadsza, to błąd samego programu przy nietypowej operacji.

Pierwszy krok: nie naprawiać oryginału

Zanim uruchomimy jakiekolwiek narzędzie naprawcze, wykonujemy pełną kopię plików bazy w stanie, w jakim są. Narzędzia naprawcze potrafią zapisać zmiany, których nie da się cofnąć, a przy nieudanej próbie zostajemy bez punktu wyjścia.

Ta zasada obowiązuje bez wyjątków, także wtedy — a właściwie zwłaszcza wtedy — gdy firma naciska, bo praca stoi. Piętnaście minut na kopię ratowało już sytuacje, w których pośpiech kosztowałby tydzień.

Co sprawdzamy

Stan dysku, na którym leży baza — bo naprawianie bazy na sypiącym się nośniku nie ma sensu. Dzienniki serwera bazy, które zwykle mówią, co się stało i kiedy. Rozmiar i datę modyfikacji plików bazy. Wreszcie to, czy istnieje kopia i z kiedy pochodzi.

Ostatnie pytanie jest najważniejsze. Jeżeli jest sprawna kopia sprzed kilku godzin, najszybszą drogą bywa odtworzenie jej i ręczne uzupełnienie dokumentów wystawionych po tym czasie. To zwykle szybsze i pewniejsze niż naprawa uszkodzonej bazy.

Naprawa bazy

Gdy kopii nie ma albo jest zbyt stara, próbujemy naprawić bazę narzędziami serwera bazy danych — zawsze na kopii, nigdy na oryginale. Część uszkodzeń da się usunąć bez utraty danych. Część kończy się odzyskaniem większości tabel i utratą ostatnich operacji. Zdarza się też, że baza nie rokuje.

Mówimy o tym wprost i na bieżąco. Nie obiecujemy pełnego odzysku, dopóki nie zobaczymy, co jest w środku, i nie zaczynamy pracy bez powiedzenia klientowi, jakie widzimy szanse.

Ile to trwa

Odtworzenie ze sprawnej kopii to zwykle godzina albo dwie, razem ze sprawdzeniem stanowisk. Naprawa uszkodzonej bazy — od kilku godzin do całego dnia, zależnie od rozmiaru i rodzaju uszkodzenia. Odzyskiwanie z dysku z uszkodzonymi sektorami trwa najdłużej, bo najpierw trzeba wykonać obraz nośnika.

Przy dużych bazach sam czas kopiowania bywa liczony w godzinach i to warto uwzględnić, planując powrót do pracy.

Co potem

Po odtworzeniu sprawdzamy spójność danych razem z osobą, która na programie pracuje — bo tylko ona rozpozna, czy ostatnie dokumenty są na miejscu. Potem zajmujemy się przyczyną: zasilaniem awaryjnym, dyskiem, siecią, kopią.

Kopia jest tu punktem najważniejszym. Ustawiamy ją tak, żeby wykonywała się automatycznie, trafiała poza komputer z bazą i była okresowo sprawdzana przez odtworzenie na osobnym stanowisku. Firma, która przeszła przez uszkodzenie bazy, zwykle nie potrzebuje już przekonywania.

Kiedy dzwonić

Od razu, zanim ktokolwiek zacznie „naprawiać” samodzielnie. Telefon odbieramy całą dobę, także w weekendy i święta, bez dopłat za porę i tryb pilny — a błędy baz mają zwyczaj ujawniać się przy zamykaniu miesiąca, czyli wtedy, gdy pracuje się najdłużej.

Dziennik transakcji i jego rola

Serwery baz danych prowadzą dziennik operacji, który pozwala odtworzyć stan bazy do konkretnego momentu. Przy poprawnie skonfigurowanej kopii można dzięki niemu wrócić nie do wczorajszego wieczoru, lecz do chwili sprzed awarii — a to różnica całego dnia pracy.

Warunkiem jest właściwy tryb pracy bazy i kopia obejmująca również dziennik. Sprawdzamy to przy wdrożeniu, bo domyślne ustawienia bywają najprostsze, a nie najbezpieczniejsze.

Miejsce na dysku

Zapełniony dysk pod bazą jest jedną z najczęstszych przyczyn nagłego zatrzymania pracy. Baza nie ma gdzie zapisać danych i przestaje przyjmować dokumenty, a komunikat bywa mylący. Częstą przyczyną jest niekontrolowany przyrost dziennika transakcji przy braku regularnej kopii.

Ustawiamy powiadomienie o kończącym się miejscu i regularne porządkowanie. To zapobiega awarii, która wygląda groźnie, a wynika z zaniedbania.

Praca na kopii bazy

Przy sprawdzaniu, czy dane da się odzyskać, nigdy nie pracujemy na oryginale. Odtwarzamy bazę pod inną nazwą na tym samym albo osobnym serwerze i tam prowadzimy naprawy. Dopiero po potwierdzeniu, że wynik jest poprawny, podmieniamy ją na produkcyjną.

Dzięki temu nieudana próba nic nie kosztuje poza czasem, a firma zachowuje możliwość powrotu do stanu zastanego.

Weryfikacja danych po odtworzeniu

Sprawdzenie, czy baza się otwiera, to za mało. Razem z osobą pracującą na programie sprawdzamy ostatnie dokumenty, stany magazynowe i rozrachunki — bo tylko ona rozpozna, czy czegoś brakuje.

Ustalamy też, które dokumenty trzeba wprowadzić ponownie, jeśli odtworzenie cofnęło stan o kilka godzin. Lista spisana od razu jest znacznie pewniejsza niż odtwarzana z pamięci po tygodniu.

Przyczyna, nie tylko skutek

Po przywróceniu pracy zajmujemy się tym, co doprowadziło do uszkodzenia: zasilaniem awaryjnym, stanem dysku, siecią przy pracy wielostanowiskowej i sposobem zamykania programu przez zespół. Uszkodzenie bazy powtarza się, jeśli przyczyna zostaje nietknięta.

Najczęściej wystarczają dwie zmiany: urządzenie podtrzymujące zasilanie i połączenie stanowisk kablem zamiast sieci bezprzewodowej.

Kopie w kilku pokoleniach

Jedna kopia nadpisywana codziennie nie chroni przed uszkodzeniem, którego nikt nie zauważył od razu. Jeżeli baza była uszkodzona wczoraj, dzisiejsza kopia zawiera już ten sam problem. Dlatego przechowujemy kilka pokoleń — dzienne z ostatniego tygodnia i tygodniowe z ostatnich miesięcy.

Zajmuje to więcej miejsca, ale przy bazach programów handlowych jest to jedyny układ dający realne bezpieczeństwo.

Ile trwa powrót do pracy

Ze sprawnej kopii — zwykle godzina albo dwie razem ze sprawdzeniem stanowisk. Przy naprawie uszkodzonej bazy — od kilku godzin do całego dnia. Przy odzyskiwaniu z dysku z uszkodzonymi sektorami — dłużej, bo najpierw powstaje obraz nośnika.

Podajemy realny termin od razu, zamiast obiecywać szybciej i przesuwać. Telefon odbieramy całą dobę, a błędy baz mają zwyczaj ujawniać się przy zamykaniu miesiąca.

Co powiedzieć zespołowi w trakcie awarii

Przy uszkodzeniu bazy najgorsze jest to, że pracownicy próbują dalej pracować, zapisując dokumenty „na boku”, w arkuszach albo na kartkach. Potem trzeba to wszystko odtworzyć, często bez pewności, co zostało już wprowadzone.

Dlatego pierwszą rzeczą, o którą prosimy, jest ustalenie jednego miejsca na dokumenty wystawiane w czasie awarii i wyznaczenie osoby, która wprowadzi je po przywróceniu pracy. To pięć minut ustaleń, które oszczędza dzień porządkowania.

Kto może podjąć decyzję w trakcie awarii

Przy uszkodzeniu bazy decyzje trzeba podejmować szybko: czy odtwarzamy z kopii sprzed kilku godzin i tracimy dokumenty wystawione po niej, czy próbujemy naprawić i ryzykujemy dłuższy przestój. To decyzja biznesowa, nie techniczna, i musi ją podjąć ktoś z firmy.

Dlatego ustalamy osobę decyzyjną na początku współpracy. Bez tego naprawa czeka, aż ktoś odbierze telefon, a każda godzina zwłoki kosztuje.

Powiązane teksty