Bazy danych Firebird i SQL Server

Najmniej widoczna, najważniejsza część systemu

Użytkownik pracuje z programem, ale wszystkie dane firmy — dokumenty, kartoteki, stany, rozrachunki — leżą w bazie danych. To ona decyduje o szybkości pracy i to jej awaria oznacza rzeczywistą stratę.

Dwa silniki, dwa zestawy zachowań

Firebird spotykamy w mniejszych instalacjach; baza to zwykle jeden plik, łatwy do skopiowania i łatwy do uszkodzenia przy nagłym wyłączeniu komputera. SQL Server pracuje jako usługa, radzi sobie lepiej z większym obciążeniem i wieloma użytkownikami, ale wymaga świadomej konfiguracji: przydziału pamięci, ustawień kopii i utrzymania.

Co robimy przy bazach

• Instalację i konfigurację silnika bazy pod konkretną liczbę stanowisk.
• Naprawy uszkodzonych baz — zawsze na kopii, nigdy na oryginale.
• Kopie zapasowe z harmonogramem, powiadomieniem i próbą odtworzenia.
• Utrzymanie: przebudowę indeksów i aktualizację statystyk.
• Optymalizację wydajności i przeniesienie danych na szybszy nośnik.
• Przenosiny bazy na nowy serwer.

Najczęstsza przyczyna uszkodzeń

Nagłe wyłączenie serwera w trakcie zapisu — zwykle po zaniku napięcia albo przy braku połączenia między zasilaczem awaryjnym a serwerem. Po każdej takiej awarii sprawdzamy właśnie ten element, bo inaczej sytuacja się powtórzy.

Wydajność

Przy bazach danych wąskim gardłem jest niemal zawsze dysk. Przeniesienie bazy na nośnik SSD daje wyraźniejszą różnicę niż jakakolwiek inna pojedyncza zmiana w serwerze.

Zasada przy naprawie

Kopia w obecnym stanie przed jakimkolwiek działaniem. Bez wyjątków.

Różne objawy problemów z bazą danych

Awaria bazy nie zawsze oznacza całkowity brak dostępu do programu. Czasem aplikacja uruchamia się prawidłowo, lecz nie można zapisać nowego dokumentu, otworzyć wybranej kartoteki albo wykonać zestawienia. Innym objawem jest nagłe zamykanie programu podczas wykonywania zawsze tej samej operacji. Taka powtarzalność może wskazywać na problem dotyczący określonego fragmentu danych, ale wymaga to potwierdzenia podczas diagnostyki.

Inny wariant to wyraźne spowolnienie pracy. Dokumenty zapisują się długo, wyszukiwanie kontrahenta trwa znacznie dłużej niż wcześniej, a kilka stanowisk jednocześnie przestaje sprawnie korzystać z programu. Przyczyną może być sam silnik bazy, stan indeksów, czyli struktur przyspieszających wyszukiwanie danych, przeciążenie dysku albo problem z siecią. Podobny efekt daje również program zabezpieczający, który skanuje pliki bazy podczas ich intensywnego używania.

Zdarza się także, że tylko jedno stanowisko nie łączy się z bazą, podczas gdy pozostałe działają poprawnie. Wtedy źródła problemu należy najpierw szukać na tym komputerze lub na jego połączeniu z serwerem. Jeżeli dostępu nie mają wszystkie stanowiska, sprawdzany jest serwer, usługa silnika bazy, sieć oraz miejsce przechowywania danych. Rozróżnienie tych sytuacji ogranicza ryzyko wykonywania niepotrzebnych działań na samej bazie.

Firebird jako plik i działająca usługa

Widoczny plik bazy Firebird nie jest zwykłym dokumentem, który można bezpiecznie kopiować w dowolnym momencie. Gdy użytkownicy pracują w programie, silnik może prowadzić zapis wielu powiązanych informacji. Skopiowanie pliku bez uwzględnienia tego procesu może utworzyć kopię niespójną, mimo że operacja kopiowania zakończy się bez komunikatu o błędzie.

Przed przeniesieniem lub zabezpieczeniem bazy trzeba ustalić, w jaki sposób korzysta z niej aplikacja i czy aktywne są połączenia użytkowników. Istotna jest również zgodność środowiska docelowego z wymaganiami programu firmowego. Samo zainstalowanie dowolnej wersji silnika nie przesądza o tym, że aplikacja połączy się z bazą i będzie prawidłowo zapisywać dane.

Podczas diagnostyki sprawdzany jest nie tylko plik, lecz także stan usługi Firebird, uprawnienia do katalogów, dostępność miejsca na dysku i komunikacja między stanowiskami. Pozwala to odróżnić uszkodzenie danych od błędu konfiguracji. Ma to znaczenie, ponieważ naprawianie poprawnej bazy nie usunie awarii usługi ani blokady połączenia sieciowego.

SQL Server wymaga kontroli całego środowiska

W SQL Server dane są obsługiwane przez działającą usługę. Dlatego ręczne kopiowanie plików używanej bazy nie zastępuje prawidłowo wykonanej kopii zapasowej. Kopia powinna powstać za pomocą mechanizmu współpracującego z silnikiem, a następnie zostać sprawdzona przez odtworzenie w oddzielnym środowisku. Sam fakt istnienia pliku kopii nie potwierdza jeszcze, że można z niego odzyskać działający system.

Przy problemach z wydajnością oceniane są między innymi obciążenie dysku, dostępna pamięć, aktywność procesora, stan indeksów oraz sposób wykonywania zapytań. Indeks jest strukturą, która pomaga szybciej odnajdywać rekordy bez przeglądania całego zbioru. Jego niewłaściwy stan może spowolnić pracę, ale automatyczna przebudowa wszystkich indeksów bez sprawdzenia sytuacji także nie jest właściwą diagnozą.

Znaczenie ma ponadto wzrost bazy i ilość wolnego miejsca. Brak miejsca na woluminie, czyli wydzielonej przestrzeni dyskowej, może zatrzymać zapis albo uniemożliwić wykonanie kopii. Konfiguracja powinna uwzględniać nie tylko bieżący rozmiar danych, ale również pliki tworzone podczas kopii, aktualizacji oraz prac utrzymaniowych.

Kiedy to nie jest uszkodzenie bazy

Komunikat o braku połączenia nie dowodzi automatycznie, że dane zostały uszkodzone. Taki sam objaw może wystąpić po zatrzymaniu usługi, zmianie nazwy serwera, modyfikacji reguł zapory sieciowej albo utracie dostępu do sieci. Zapora sieciowa to mechanizm kontrolujący, które połączenia mogą przechodzić między komputerami. Jej błędna reguła może zablokować program, mimo że baza pozostaje sprawna.

Problem z logowaniem może wynikać z nieprawidłowego konta, zmienionych uprawnień albo konfiguracji aplikacji. Jeżeli program uruchamia się, ale nie widzi danych z ostatniego okresu, należy również sprawdzić, czy nie został połączony ze starszą kopią lub inną bazą o podobnej nazwie. Pochopne wprowadzanie nowych dokumentów do takiego środowiska może później utrudnić uporządkowanie zapisów.

Nie każda powolna praca jest również problemem silnika. Opóźnienia mogą powodować niestabilne połączenie sieciowe, przeciążony komputer użytkownika, proces tworzenia kopii w godzinach pracy albo zużyty nośnik. Diagnoza obejmuje więc drogę od stanowiska do danych, a nie tylko sam plik lub usługę bazy.

Błędy przy samodzielnej próbie naprawy

Jednym z ryzykownych działań jest wielokrotne uruchamianie programu i ponawianie zapisu po każdym komunikacie o błędzie. Jeżeli baza jest niespójna albo nośnik działa niestabilnie, kolejne próby mogą tworzyć następne zmiany. Bezpieczniej zatrzymać pracę użytkowników, zapisać treść komunikatu i zabezpieczyć aktualny stan danych.

Nie należy zastępować bieżącej bazy przypadkowo znalezioną kopią. Najpierw trzeba ustalić datę i źródło każdego pliku oraz sprawdzić, czy kopia daje się odtworzyć. Plik z najnowszą datą modyfikacji nie zawsze jest właściwym materiałem do odzyskania. Może być pustą kopią, plikiem pomocniczym albo bazą używaną tylko do testów.

Ryzyko powoduje też uruchamianie narzędzi naprawczych bez wcześniejszego wykonania kopii uszkodzonego materiału. Niektóre operacje zmieniają strukturę danych i utrudniają powrót do punktu wyjścia. Dlatego prace wykonuje się na duplikacie, a oryginał pozostaje zabezpieczony. Jeżeli pierwszy sposób odzyskania nie przyniesie oczekiwanego wyniku, można zastosować inną metodę bez utraty materiału źródłowego.

Innym błędem jest przeniesienie pliku na nowy komputer i uznanie, że migracja została zakończona. Program firmowy może wymagać właściwego silnika, ustawień połączenia, sterowników, uprawnień oraz dodatkowych składników. Po przenosinach sprawdza się nie tylko uruchomienie programu, ale też zapis dokumentu, wyszukiwanie, raporty, wydruki i wykonanie kopii zapasowej.

Jak bezpiecznie zaplanować przenosiny bazy

Migrację zaczyna się od rozpoznania obecnego środowiska. Ustalane są używany silnik, sposób połączenia stanowisk, lokalizacja danych, działanie kopii zapasowych i zależności od innych programów. Następnie wykonywana jest zweryfikowana kopia, czyli taka, której odtworzenie zostało praktycznie sprawdzone. Dopiero wtedy przygotowywane jest środowisko docelowe.

Przełączenie powinno nastąpić w chwili, gdy użytkownicy zakończyli pracę i żaden dokument nie jest już zapisywany. Po wykonaniu końcowej kopii uruchamiana jest baza na nowym serwerze, a stanowiska otrzymują właściwą konfigurację połączenia. Kontrola obejmuje dane bieżące i historyczne oraz operacje wymagające zapisu. Stary serwer nie powinien pozostawać aktywnym, równoległym miejscem pracy, ponieważ mogłyby wtedy powstać dwie rozchodzące się wersje danych.

Kopia zapasowa wymaga próby odtworzenia

Harmonogram kopii jest potrzebny, ale sam harmonogram nie wystarcza. Zadanie może przestać działać po zmianie hasła, zapełnieniu dysku, zmianie ścieżki albo aktualizacji środowiska. Dlatego sprawdzany jest rezultat wykonania zadania i możliwość odtworzenia danych. Test powinien odbywać się poza bazą produkcyjną, czyli bazą używaną podczas codziennej pracy.

Kopia przechowywana wyłącznie na tym samym dysku nie zabezpiecza przed awarią tego nośnika. Rozdzielenie danych roboczych i materiału zapasowego zmniejsza ryzyko utraty obu wersji w jednym zdarzeniu. Należy też kontrolować, czy starsze kopie są przechowywane zgodnie z potrzebami firmy i czy sposób zabezpieczenia uwzględnia poufność dokumentów, kartotek i rozrachunków.

Dodatkowe pytania dotyczące Firebird i SQL Server

Czy można dalej pracować po pojawieniu się błędu bazy?

Jeżeli błąd dotyczy zapisu, odczytu dokumentów albo spójności danych, dalszą pracę należy wstrzymać do czasu rozpoznania przyczyny. Warto zachować pełną treść komunikatu i wskazać czynność, przy której wystąpił. Jeżeli problem dotyczy tylko jednego stanowiska, sytuacja może mieć źródło lokalne, ale również wtedy nie należy wykonywać przypadkowych zmian w konfiguracji serwera.

Czy sama kopia pliku Firebird wystarczy?

To zależy od sposobu jej wykonania. Kopiowanie pliku podczas aktywnej pracy użytkowników może nie dać materiału odpowiedniego do odtworzenia. Bezpieczeństwo zapewnia procedura uwzględniająca działający silnik oraz późniejszy test kopii. Ważne jest również zabezpieczenie kilku wersji, aby pojedyncza uszkodzona kopia nie była jedyną możliwością odzyskania danych.

Czy wolny program zawsze wymaga wymiany serwera?

Nie. Najpierw trzeba ustalić, co ogranicza pracę. Przyczyną może być nośnik, sieć, konfiguracja pamięci, stan bazy albo zadanie wykonywane w tle. Dopiero wyniki diagnostyki pozwalają ocenić, czy potrzebna jest zmiana sprzętu. W wielu sytuacjach poprawa konfiguracji lub usunięcie konkretnego wąskiego gardła wystarcza bez wymiany całego serwera.

Czy przeniesienie bazy można wykonać bez zmiany programu firmowego?

Zwykle baza może zostać przeniesiona razem z używanym systemem, jeżeli nowe środowisko spełnia jego wymagania. Trzeba jednak sprawdzić zgodność silnika, ustawień połączenia i składników programu. Migracja nie powinna ograniczać się do skopiowania danych. Jej częścią są testy najważniejszych operacji wykonywanych przez użytkowników.

Co przygotować przed zgłoszeniem problemu?

Pomocne są treść komunikatu, godzina wystąpienia, nazwa wykonywanej operacji oraz informacja, czy problem obejmuje jedno, czy wszystkie stanowiska. Nie trzeba przygotowywać hasła na zapas. Jest ono potrzebne tylko wtedy, gdy bez dostępu do określonego elementu nie da się przeprowadzić diagnostyki, a cel użycia zostanie wcześniej wyjaśniony.

Najpierw zabezpieczenie danych, potem przywracanie pracy

Przy bazach Firebird i SQL Server kolejność działań ma bezpośredni wpływ na możliwość odzyskania informacji. Najpierw zatrzymywane są operacje mogące zmieniać dane i zabezpieczany jest obecny stan. Następnie sprawdzane są baza, silnik, nośnik, sieć i kopie zapasowe. Dopiero na tej podstawie wybierana jest naprawa, odtworzenie albo migracja. Taka kolejność pozwala przywrócić system bez traktowania firmowych dokumentów jako materiału do prób.