Obsługa systemu Humansoft HermesSQL

Stabilność bazy przekłada się na pracę całego systemu

System opiera się na serwerowej bazie danych, więc jej stan decyduje o wszystkim: o szybkości pracy, o stabilności i o tym, co się dzieje przy awarii. Diagnoza zaczyna się więc zwykle od serwera bazy, a nie od samego programu.

Co sprawdzamy przy zgłoszeniach

• Obciążenie serwera bazy i przydzieloną mu pamięć.
• Rodzaj nośnika, na którym leży baza — przy bazach danych to wąskie gardło numer jeden.
• Stan indeksów i statystyk.
• Połączenie sieciowe między stanowiskami a serwerem.
• Wykonywanie kopii i ich odtwarzalność.

Utrzymanie bazy

Regularna przebudowa indeksów i aktualizacja statystyk przywracają tempo pracy bez ingerencji w dane. To czynności wykonywane cyklicznie, poza godzinami pracy — a w wielu firmach nie robi ich nikt, bo nikt o nich nie wie.

Kopie zapasowe

Baza serwerowa wymaga kopii wykonywanej narzędziem silnika bazy, a nie zwykłym kopiowaniem pliku. Kopia pliku bazy podczas pracy serwera bywa bezużyteczna — to jedna z częstszych luk, jakie znajdujemy przy przeglądzie.

Uszkodzenia

Najczęściej po nagłym wyłączeniu serwera. Naprawę prowadzimy zawsze na kopii, nigdy na oryginale, a po zakończeniu sprawdzamy zasilanie awaryjne i jego połączenie z serwerem.

Nasz zakres

Infrastruktura, baza i stanowiska. Konfigurację merytoryczną prowadzi firma wdrożeniowa producenta.

Wolne działanie systemu może mieć różne przyczyny

Spowolnienie HermesSQL nie zawsze oznacza uszkodzenie bazy. Jeżeli problem występuje na wszystkich stanowiskach, w pierwszej kolejności sprawdzany jest serwer, jego zasoby, nośnik danych oraz działanie silnika bazy. Znaczenie ma także to, czy w tym samym czasie serwer wykonuje kopię zapasową, skanowanie ochronne albo inne zadanie mocno obciążające dysk.

Gdy wolno działa tylko jedno stanowisko, przyczyny częściej szuka się lokalnie. Sprawdzane są parametry komputera, stan systemu Windows oraz połączenie z siecią firmową. Wąskie gardło, czyli element ograniczający wydajność całego procesu, może znajdować się między stanowiskiem a serwerem, mimo że oba urządzenia osobno pracują prawidłowo.

Inny wariant to spowolnienie występujące wyłącznie podczas określonych operacji, na przykład wyszukiwania danych, przygotowywania zestawienia albo zapisywania dokumentu. Taki objaw wymaga odtworzenia dokładnej sekwencji czynności. Pozwala to odróżnić problem infrastruktury od ustawień programu, uprawnień użytkownika lub konfiguracji merytorycznej pozostającej w zakresie firmy wdrożeniowej.

Przerwane połączenie nie zawsze oznacza awarię programu

Komunikat o utracie połączenia może pojawić się po chwilowej przerwie w sieci, restarcie usługi bazodanowej albo przeciążeniu serwera. Usługa bazodanowa to proces systemowy, który przyjmuje zapytania ze stanowisk i udostępnia zapisane dane. Jej zatrzymanie odcina użytkowników od bazy nawet wtedy, gdy sam serwer nadal odpowiada w sieci.

Przy sporadycznych rozłączeniach analizowana jest nie tylko aplikacja, lecz także przełączniki sieciowe, okablowanie, karta sieciowa i zdarzenia zapisane przez system operacyjny. Dziennik zdarzeń, czyli rejestr komunikatów systemowych, pomaga ustalić, czy przed awarią wystąpił błąd dysku, usługi, sterownika albo zasilania. Diagnoza obejmuje również sprawdzenie, czy problem dotyczy wszystkich użytkowników, wybranego działu czy jednego komputera.

Połączenie bezprzewodowe może zachowywać się poprawnie podczas zwykłego przeglądania stron, a jednocześnie powodować krótkie przerwy zauważalne w programie pracującym z bazą. Dlatego stabilność ocenia się w czasie rzeczywistej pracy, a nie wyłącznie na podstawie pojedynczego testu dostępu do internetu.

Indeksy i statystyki pomagają bazie odnajdywać dane

Indeks bazy danych działa podobnie do uporządkowanego spisu ułatwiającego odnalezienie właściwych rekordów. Rekord to pojedynczy zapis, na przykład pozycja kartoteki lub dokumentu. Wraz z codziennym dopisywaniem, zmianą i usuwaniem informacji struktura indeksów może tracić optymalny układ. Nie oznacza to utraty danych, ale może wydłużać wykonanie części operacji.

Statystyki opisują rozmieszczenie informacji w tabelach i pomagają silnikowi bazy wybrać sposób realizacji zapytania. Zapytanie to polecenie odczytu lub zmiany danych wysyłane przez program. Gdy statystyki są nieaktualne, serwer może wybrać mniej wydajną drogę dostępu do informacji. Przebudowa indeksów i aktualizacja statystyk powinny być wykonywane świadomie, po sprawdzeniu stanu bazy i dostępnych zasobów.

Nie każda baza wymaga identycznego harmonogramu prac. Znaczenie mają intensywność użytkowania, wielkość zbioru danych i sposób korzystania z systemu. Czynności administracyjnych nie uruchamia się przypadkowo w trakcie normalnej pracy, ponieważ same mogą czasowo obciążyć serwer.

Kopia zapasowa wymaga próby odtworzenia

Samo pojawienie się nowego pliku kopii nie potwierdza jeszcze, że dane można odzyskać. Kopia może być niepełna, uszkodzona albo zapisywana w miejscu, które ulegnie awarii razem z serwerem. Dlatego sprawdzany jest rezultat zadania wykonującego kopię, dostępność miejsca oraz możliwość odtworzenia danych w bezpiecznym środowisku.

Odtworzenie testowe polega na uruchomieniu kopii jako oddzielnej bazy, bez zastępowania danych używanych przez firmę. Pozwala zweryfikować, czy mechanizm archiwizacji rzeczywiście zapewnia materiał do odzyskania systemu. Test przeprowadza się tak, aby nie wpływał na bieżącą pracę i nie powodował przypadkowego połączenia stanowisk z bazą testową.

Istotna jest również separacja kopii, czyli przechowywanie jej niezależnie od podstawowego nośnika. Kopia znajdująca się wyłącznie na tym samym dysku nie chroni przed jego uszkodzeniem. Zakres i sposób przechowywania dobiera się do infrastruktury oraz zasad bezpieczeństwa obowiązujących w firmie.

Co dzieje się po nagłym wyłączeniu serwera

Po zaniku zasilania nie należy wielokrotnie uruchamiać programu na kolejnych stanowiskach i ponawiać zapisu dokumentów. Najpierw warto ustalić, czy serwer działa stabilnie i czy silnik bazy zakończył uruchamianie. Kolejne próby mogą utrudnić rozpoznanie pierwotnego problemu, zwłaszcza gdy nośnik zgłasza błędy.

Prace rozpoczynają się od zabezpieczenia dostępnych danych. Następnie sprawdzana jest spójność bazy, czyli zgodność jej wewnętrznych struktur i powiązań. Dopiero po ocenie stanu można zdecydować, czy wystarczy standardowa procedura przywrócenia działania, czy potrzebne jest odtworzenie kopii.

Zasilacz awaryjny UPS podtrzymuje pracę urządzeń po zaniku energii i może umożliwić kontrolowane zamknięcie serwera. Samo podłączenie serwera do UPS nie kończy jednak konfiguracji. Trzeba również sprawdzić stan urządzenia oraz sposób przekazywania informacji o zaniku zasilania. Dobór, konfiguracja i wymiana UPS mogą zostać objęte obsługą infrastruktury.

Błędy popełniane podczas samodzielnej próby naprawy

Jednym z ryzyk jest kopiowanie aktywnego pliku bazy zwykłym narzędziem systemowym. Serwer może w tym czasie zmieniać dane, dlatego uzyskany plik nie musi przedstawiać spójnego stanu. Bezpieczna kopia powinna powstać za pomocą mechanizmu przeznaczonego dla używanego silnika bazy.

Nie należy usuwać plików uznanych za tymczasowe bez rozpoznania ich roli. Podobnie ryzykowne jest zwalnianie miejsca przez kasowanie starszych kopii bez wcześniejszego potwierdzenia, że istnieje nowsza, sprawdzona i możliwa do odtworzenia wersja.

Kolejnym błędem jest instalowanie przypadkowych narzędzi do automatycznej naprawy lub optymalizacji. Program, który nie uwzględnia budowy danej bazy i zależności między jej elementami, może zmienić pliki albo ustawienia bez możliwości łatwego wycofania operacji. Ostrożności wymaga także przywracanie systemu Windows na serwerze, ponieważ może ono zmienić konfigurację usług bez cofnięcia samych danych biznesowych do zgodnego stanu.

Ręczne modyfikowanie tabel bazy bez uzgodnienia z firmą wdrożeniową również nie jest właściwą drogą. Tabela to struktura przechowująca określony rodzaj informacji. Nawet pozornie prosta zmiana może naruszyć powiązania, których nie widać z poziomu pojedynczego rekordu.

Kiedy źródło problemu znajduje się poza bazą

Jeżeli HermesSQL uruchamia się prawidłowo, lecz nie można wydrukować dokumentu, przyczyną może być konfiguracja drukarki, kolejka wydruku albo sterownik. Sterownik to składnik umożliwiający systemowi Windows komunikację z urządzeniem. W takim przypadku sprawdzana jest konfiguracja drukowania, ale nie jest wykonywana naprawa sprzętowa drukarki.

Błąd widoczny tylko na koncie jednej osoby może wynikać z uprawnień lub ustawień użytkownika. Jeśli natomiast wszystkie programy na komputerze działają wolno, źródłem problemu może być system operacyjny, nośnik albo niedobór zasobów stanowiska. Z kolei brak dostępu do wspólnych zasobów firmowych, niezależny od HermesSQL, wskazuje częściej na problem sieci lub serwera.

Nie każda niezgodność na dokumencie jest usterką techniczną. Ustawienia księgowe, magazynowe, handlowe i sposób działania procesów firmowych należą do konfiguracji merytorycznej. Takie zgłoszenie powinno być prowadzone przez firmę wdrożeniową producenta, a obsługa informatyczna może równolegle sprawdzić, czy infrastruktura i baza działają poprawnie.

Jak przygotować informacje do diagnozy

Pomocne jest zapisanie dokładnej treści komunikatu oraz czynności wykonywanej bezpośrednio przed jego pojawieniem się. Warto wskazać, czy sytuacja dotyczy wszystkich stanowisk, czy tylko jednego, oraz czy powtarza się przy każdym uruchomieniu tej samej operacji. Zrzut ekranu może ułatwić rozpoznanie problemu, o ile nie zawiera danych, których nie należy udostępniać.

Nie trzeba z góry przekazywać hasła. Jest ono potrzebne tylko wtedy, gdy bez odpowiedniego dostępu nie można wykonać uzgodnionej czynności, a powód zostaje wcześniej wyjaśniony. Na życzenie możliwe jest bezpłatne NDA, czyli umowa o zachowaniu poufności. Naprawy i prace administracyjne nie są przekazywane podwykonawcom.

Obsługa może odbyć się podczas wizyty serwisanta w firmie albo w trybie door-to-door, w którym kierowca odbiera sprzęt i zwraca go po zakończeniu prac. Wizyta serwisanta obejmuje bezpłatny dojazd, natomiast wykonana praca jest płatna niezależnie od wyniku. Wybór trybu zależy od tego, czy problem można bezpiecznie diagnozować na miejscu i czy sprzęt współpracuje z pozostałą infrastrukturą firmy.

Dodatkowe pytania dotyczące HermesSQL

Czy wolne działanie jednego raportu oznacza konieczność wymiany serwera?

Nie. Najpierw trzeba ustalić, czy problem wynika z zasobów serwera, stanu indeksów, sposobu wykonania zapytania czy konfiguracji samego raportu. Wymiana sprzętu bez diagnozy może nie przynieść poprawy, jeżeli źródło spowolnienia znajduje się w sieci albo konfiguracji programu.

Czy kopię bazy można sprawdzić bez zatrzymywania firmy?

Taką weryfikację planuje się tak, aby nie naruszyć bieżącej bazy. Kopia jest odtwarzana oddzielnie, a test nie powinien kierować użytkowników do środowiska kontrolnego. Szczegóły zależą od infrastruktury i sposobu wykonywania archiwizacji.

Czy po awarii wystarczy ponownie uruchomić serwer?

Ponowne uruchomienie może przywrócić dostęp, ale nie potwierdza spójności danych ani usunięcia przyczyny. Po nagłym wyłączeniu warto sprawdzić dzienniki systemowe, stan nośnika, bazę oraz działanie zasilania awaryjnego. Szczególnie istotne jest to wtedy, gdy awaria powtarza się albo pojawiają się błędy zapisu.

Czy można objąć obsługą także komputery użytkowników?

Tak. Zakres może obejmować serwer, sieć, bazę oraz stanowiska z systemem Windows. Dzięki temu można prześledzić cały tor komunikacji między aplikacją a danymi. Ustawienia merytoryczne HermesSQL pozostają po stronie firmy wdrożeniowej producenta.

Czy konieczny jest dostęp do danych firmy?

Zakres dostępu ogranicza się do tego, co jest niezbędne do wykonania uzgodnionych prac. W wielu przypadkach wystarczają informacje techniczne, dzienniki zdarzeń i parametry infrastruktury. Jeżeli analiza bazy jest konieczna, zasady dostępu i cel czynności są ustalane przed rozpoczęciem pracy.

Od objawu w HermesSQL do przyczyny w infrastrukturze

Skuteczna obsługa systemu wymaga rozdzielenia trzech obszarów: działania infrastruktury, kondycji bazy oraz konfiguracji merytorycznej programu. Dopiero takie rozpoznanie pozwala uniknąć przypadkowych zmian i skupić się na elemencie, który rzeczywiście powoduje spowolnienie, rozłączenie albo błąd. Zgłoszenia dotyczące Warszawy oraz powiatów warszawskiego zachodniego, legionowskiego, nowodworskiego, wołomińskiego, mińskiego, otwockiego, piaseczyńskiego, pruszkowskiego i grodziskiego są obsługiwane z dojazdem. Kontakt telefoniczny pod numerem22 378 48 90 pozwala ustalić objawy i właściwy tryb dalszej diagnostyki.