Jak cofnąć zmiany w bazie danych MS SQL? Na przykładzie Wapro i Bilansu Otwarcia

Wprowadzenie

Praca z bazami danych to trochę jak balansowanie na linie – wszystko musi być idealnie zsynchronizowane, bo jeden błędny ruch może skończyć się katastrofą. Niestety, błędy się zdarzają, a ich skutki bywają bolesne. Dziś pokażę, jak można wyjść z takiej sytuacji na przykładzie systemu Wapro i funkcji Bilansu Otwarcia.

Problem

Dane w bazie danych pochodzą od 2018 roku, kiedy firma zaczęła korzystać z programu Wapro. Na początku roku planowali przeprowadzić inwentaryzację. Niestety, zamiast użyć funkcji "Remanent", jeden z pracowników przypadkowo wybrał opcję "Bilans Otwarcia". W Wapro taka pomyłka to jak wyczyszczenie całego magazynu i dokumentów handlowych jednym kliknięciem.

Dodajmy do tego fakt, że kopii zapasowych nikt nie robił regularnie, więc o przywróceniu danych z backupu mogłem jedynie pomarzyć. Sytuacja była napięta, ale na szczęście było światełko w tunelu.

Rozwiązanie

Okazuje się, że baza danych programu Wapro przechowuje tzw. log – plik z całą historią zmian. To jak czarna skrzynka w samolocie. Wystarczy właściwe narzędzie, trochę sprytu i można odwrócić niechciane zmiany. W tym przypadku wykorzystałem program https://www.devart.com/dbforge/sql/transaction-log/, który kosztuje około 50 dolarów na miesiąc. Cena może wydawać się wysoka, ale wierzcie mi – warto!

Krok po kroku:

  1. Zrobienie kopii zapasowej
    Tak, wiem, że problem polegał na jej braku, ale w tym momencie zrobienie aktualnej kopii było kluczowe, żebym miał bezpieczną bazę wyjściową na wypadek kolejnych przygód.
  2. Analiza logów bazy danych
    Odpaliłem skanowanie logów. To one zdradzają całą prawdę o tym, co się działo w bazie – każda operacja ma swój znacznik czasowy, więc mogłem namierzyć moment, w którym doszło do feralnego kliknięcia.
  3. Identyfikacja momentu krytycznego
    Znalezienie chwili, w której opcja Bilansu Otwarcia zrobiła spustoszenie, było kluczowe. Na szczęście logi wskazały mi dokładny timestamp.
  4. Generowanie skryptu naprawczego
    Przy pomocy narzędzia wygenerowałem skrypt SQL, który odwrócił wszystkie zmiany wprowadzone od tego momentu. Skrypt działał jak wehikuł czasu dla mojej bazy danych.
  5. Wdrożenie skryptu i testy
    Wykonałem skrypt i sprawdziłem, czy wszystko wróciło na swoje miejsce. Testy pokazały, że baza znów działa jak trzeba.

Ryzyko i wyzwania

Działania tego typu to zawsze spore ryzyko. W bazie danych po takiej operacji mogą zostać różne niespodzianki, np. produkty z niezgodnymi stanami magazynowymi, których nie da się poprawnie wprowadzić. Tym razem jednak kluczowe było co innego – historia sprzedaży. Klienci często chcą zamawiać te same rzeczy, co rok temu, a bez tych danych firma miałaby poważny problem. Dlatego tak bardzo zależało mi na naprawie.

Wnioski

Praca z bazami danych to wyzwanie, ale nawet z pozoru beznadziejne sytuacje można rozwiązać. Oto kilka lekcji, które warto zapamiętać:

  • Backup, backup i jeszcze raz backup: Brak kopii zapasowej to przepis na katastrofę. Lepiej dmuchać na zimne.
  • Znajomość logów transakcji: To twoi najlepsi sprzymierzeńcy, gdy trzeba cofnąć czas.
  • Specjalistyczne narzędzia: Czasem inwestycja w odpowiednie oprogramowanie to jedyna droga, by wyjść na prostą.

Mam nadzieję, że ten artykuł pomoże ci, jeśli kiedykolwiek znajdziesz się w podobnej sytuacji. Pamiętaj – nie ma rzeczy niemożliwych!