Microsoft SQL Server w małej firmie: co trzeba wiedzieć

Gdzie to właściwie jest i po co

Program, w którym pracują handlowcy, to tylko warstwa widoczna. Dane (towary, kontrahenci, dokumenty, stany) leżą w bazie na serwerze albo na jednym z komputerów w firmie. Bez niej program nie ma na czym pracować.

Ma to praktyczne konsekwencje. Kopia zapasowa katalogu z programem nie obejmuje danych. Wymiana komputera, na którym stoi baza, wymaga przeniesienia bazy: samo przeinstalowanie programu nie wystarczy.

Warto więc wiedzieć trzy rzeczy: na której maszynie stoi baza, jak się nazywa i kto ma do niej dostęp. Zaskakująco często nikt w firmie tego nie wie.

Spis tego, co firma ma

Zanim zajmie się kopiami i konserwacją, warto spisać podstawowe informacje. Przy awarii albo zmianie wykonawcy ta jedna kartka oszczędza wiele godzin szukania.

• Na którym komputerze lub serwerze działa baza
• Nazwa instancji serwera bazy i jego wersja
• Lista baz i programy, które z nich korzystają
• Gdzie trafiają kopie i kto je sprawdza
• Kto zna hasło administratora bazy
• Firma, która wdrażała program, i kontakt do niej

Wersja bezpłatna a płatna: gdzie leży granica

Microsoft udostępnia bezpłatną wersję bazy, na której działa wiele mniejszych wdrożeń. Ma jednak ograniczenia: wielkość pojedynczej bazy, ilość wykorzystywanej pamięci i liczba rdzeni procesora.

Gdy firma rośnie, baza w pewnym momencie dochodzi do limitu. Objawia się to komunikatem o braku miejsca albo wyraźnym spowolnieniem, gdy dane przestają mieścić się w dostępnej pamięci.

Sprawdzenie, ile miejsca zostało do limitu, zajmuje minutę i warto robić to raz na kwartał. Dojście do granicy w środku sezonu jest kłopotliwe, bo wymaga decyzji o licencji albo archiwizacji danych pod presją czasu.

Kopie zapasowe: najważniejsza rzecz w całym tekście

Kopia bazy różni się od kopii plików. Skopiowanie pliku bazy w trakcie pracy serwera zwykle się nie udaje albo daje plik, z którego nie da się wiarygodnie odtworzyć danych, a odkrywa się to dopiero w momencie awarii.

Poprawna kopia wykonywana jest przez mechanizm samej bazy, zwykle zadaniem uruchamianym w nocy. Powinna trafiać poza serwer, na którym baza działa, i mieć historię co najmniej kilkunastu dni.

Najważniejszy jest jednak test odtworzenia, bo dopiero on pokazuje, czy z kopii da się wrócić do pracy. Raz na kwartał warto odtworzyć ją na maszynie testowej i sprawdzić, czy program na niej wstaje.

Tryb odzyskiwania: ile danych możesz stracić między kopiami

Kopia wykonywana raz na noc oznacza, że awaria w środku dnia zabiera wszystko, co wprowadzono od rana. W wielu firmach to akceptowalne, bo dokumenty da się odtworzyć z papierów albo z poczty. W innych, przy dużej liczbie faktur, zamówień ze sklepu czy przyjęć magazynowych, oznacza to cały dzień pracy do powtórzenia.

Serwer bazy pozwala wybrać tryb pracy, który decyduje, czy da się wrócić do stanu z konkretnej godziny. Tryb prosty ogranicza się do kopii pełnych i różnicowych. Tryb pełny pozwala dodatkowo wykonywać w ciągu dnia kopie dziennika transakcji i odtworzyć bazę do wybranej chwili między nimi.

Wybór trybu warto uzgodnić z informatykiem i z osobą, która wie, ile kosztuje dzień utraconych danych. Tryb pełny bez skonfigurowanych kopii dziennika to prosta droga do zapełnionego dysku, opisanego w dalszej części tekstu.

Gdzie trzymać kopie: dysk, sieć, chmura

Kopia zapasowa ma sens tylko wtedy, gdy przetrwa to, przed czym chroni. Kopia na tym samym dysku co baza nie przetrwa awarii dysku, a kopia w tej samej sieci może zostać zaszyfrowana razem z danymi.

Rozsądny układ łączy co najmniej dwa z tych miejsc: kopię w firmie do szybkiego odtworzenia i kopię poza firmą albo odłączoną od sieci na wypadek poważnej awarii. Więcej w artykule o kopiach zapasowych w firmie.

Dzień awarii: co zrobić krok po kroku

W dniu awarii liczy się spokój i kolejność. Wiele danych traci się przez pospieszne działania, które pogłębiają awarię.

• Zatrzymać pracę w programie na wszystkich stanowiskach
• Zabezpieczyć obecny stan bazy i plików, zanim cokolwiek zostanie naprawione
• Ustalić, z której chwili jest ostatnia dobra kopia
• Odtworzyć kopię na osobnej maszynie albo pod inną nazwą i ją sprawdzić
• Dopiero po sprawdzeniu przywrócić pracę użytkowników
• Uzupełnić dokumenty wystawione po ostatniej kopii

Konserwacja: zadania, o których łatwo zapomnieć

Baza wymaga okresowej konserwacji. Bez niej działa dalej, ale coraz wolniej, i rzadko ktoś łączy to z brakiem obsługi.

• Przebudowa indeksów, regularnie, zwykle raz w tygodniu
• Aktualizacja statystyk, na których baza opiera plany zapytań
• Sprawdzenie spójności danych
• Kontrola wielkości dziennika transakcji i jego przycinanie
• Weryfikacja, czy zadania faktycznie się wykonują
• Archiwizacja albo usuwanie danych tymczasowych

Przedostatni punkt jest często pomijany. Zadanie skonfigurowane, które przestało działać, bo zmieniono hasło do konta, na którym się uruchamiało, to sytuacja spotykana regularnie. Baza wygląda na zadbaną, a od roku nikt jej nie konserwował.

Powiadomienia: o nieudanej kopii trzeba wiedzieć tego samego dnia

Zadanie kopii albo konserwacji, które przestało działać, nie daje żadnych objawów. Program pracuje normalnie, użytkownicy niczego nie zauważają, a problem wychodzi dopiero wtedy, gdy kopia jest potrzebna. Dlatego konfiguracja zadań to połowa pracy, a druga połowa to informacja, że się wykonały.

Najprostsze rozwiązanie to wiadomość e-mail wysyłana po każdym nieudanym zadaniu oraz krótki raport raz w tygodniu z listą kopii, ich wielkością i wolnym miejscem na dysku. Ważne, żeby wiadomości trafiały do osoby, która je czyta, zamiast na skrzynkę założoną przy wdrożeniu.

• Powiadomienie o każdej nieudanej kopii i zadaniu konserwacji
• Ostrzeżenie, gdy na dysku z danymi lub kopiami kończy się miejsce
• Tygodniowe podsumowanie z datą ostatniej udanej kopii
• Sygnał, gdy kopia jest wyraźnie mniejsza niż zwykle
• Druga osoba w kopii wiadomości na czas urlopu

Wielkość kopii to często pomijany sygnał. Kopia, która nagle zmalała, może oznaczać, że zadanie zaczęło kopiować inną, pustą bazę, na przykład po zmianie nazwy albo przeniesieniu danych.

Sprawne kopie i powiadomienia przydają się szczególnie przed większymi zmianami, takimi jak przejście na inny program handlowy. O takich decyzjach piszemy w tekście Subiekt GT czy nexo.

Aktualizacje serwera bazy i systemu

Serwer bazy danych dostaje poprawki bezpieczeństwa i błędów tak samo jak system operacyjny. W małych firmach często nie są instalowane latami, bo „działa i lepiej nie ruszać”.

Skutek: znane luki pozostają otwarte, a problemy naprawione przez producenta nadal występują. Instalowanie poprawek nie musi być ryzykowne, jeśli robi się to po wykonaniu kopii, poza godzinami pracy i po sprawdzeniu, czy program handlowy obsługuje daną wersję.

Warto też wiedzieć, do kiedy producent wspiera używaną wersję serwera bazy. Wersja bez wsparcia to sygnał, że migrację trzeba zaplanować z wyprzedzeniem.

Dziennik transakcji: częsta przyczyna nagłego zatrzymania

Baza zapisuje wszystkie operacje w osobnym pliku dziennika. Przy niewłaściwej konfiguracji plik ten rośnie bez ograniczeń, aż zapełni dysk, a wtedy system staje z dnia na dzień.

Objaw jest charakterystyczny: wszystko działało normalnie, a rano program nie pozwala zapisać dokumentu. Komunikat zwykle nie wskazuje wprost przyczyny, więc pierwsze podejrzenie pada na program zamiast na dysk.

Zapobieganie jest proste: właściwy tryb pracy bazy dopasowany do potrzeb firmy i regularne kopie, które pozwalają dziennik przycinać. Konfiguracja to zwykle godzina pracy i rozwiązuje problem na lata.

Wydajność: skąd biorą się spowolnienia

Systemy handlowe zwalniają w przewidywalny sposób, wraz z ilością danych. Częste przyczyny to brakujące indeksy, rozrost tabel z historią operacji i brak konserwacji.

Drugą grupą są zasoby serwera. Baza, która nie mieści się w pamięci operacyjnej, musi znacznie częściej sięgać do dysku i wtedy rodzaj nośnika wpływa na komfort pracy całej firmy.

Zanim jednak zapadnie decyzja o nowym serwerze, warto sprawdzić bazę. Nierzadko kilka dni pracy nad bazą wyraźnie skraca czas wystawiania dokumentów. Szerzej we wpisie o bazie, która zwalnia.

Stanowiska i sieć: gdy baza jest zdrowa, a program i tak się zawiesza

Program handlowy wymienia z bazą dużo krótkich zapytań. Każda przerwa w połączeniu, nawet bardzo krótka, może skończyć się zawieszeniem okna, komunikatem o utracie połączenia albo przerwanym zapisem dokumentu. Z bazą wszystko jest wtedy w porządku, ale użytkownik tego nie wie.

Częstym winowajcą jest sieć bezprzewodowa. Laptop przy magazynie ze słabym sygnałem albo stanowisko na zapleczu za dwiema ścianami to typowe miejsca, z których przychodzą zgłoszenia o zrywanym połączeniu.

• Stanowiska stacjonarne podłączone kablem, zwłaszcza przy kasie i w magazynie
• Stały adres serwera bazy, żeby program nie gubił go po restarcie urządzeń sieciowych
• Wyjątki w zaporze sieciowej ustawione tylko dla sieci firmowej
• Oszczędzanie energii karty sieciowej wyłączone na stanowiskach z programem
• Sprawdzone urządzenia sieciowe zamiast przypadkowych rozgałęziaczy dokładanych latami

Rozróżnienie jest proste: jeśli problem dotyczy jednego lub dwóch stanowisk, zwykle winna jest sieć albo komputer. Jeśli wszystkich jednocześnie, trzeba zajrzeć do bazy i serwera. Przy firmach z kilkoma lokalizacjami dochodzi łącze między biurami i wtedy praca na pulpicie zdalnym, opisana niżej, zwykle sprawdza się lepiej niż szybsze łącze.

Baza na serwerze wirtualnym i w chmurze

Coraz więcej małych firm przenosi serwer z bazą do maszyny wirtualnej albo do chmury. Rozwiązuje to problem starego sprzętu pod biurkiem, ale wymaga przemyślenia kilku rzeczy.

Najważniejsze to wydajność dysków i opóźnienia połączenia. Program handlowy, który wymienia z bazą wiele małych zapytań, może działać wolno, gdy baza jest daleko od stanowisk. Wtedy lepiej sprawdza się praca na pulpicie zdalnym niż bezpośrednie połączenie z biura.

Warto też ustalić, kto odpowiada za kopie. Dostawca chmury dba o działanie infrastruktury, ale kopie samej bazy i test ich odtworzenia nadal pozostają zadaniem firmy albo jej opiekuna IT.

Kilka programów na jednym serwerze bazy

W wielu firmach na tym samym serwerze bazy działa kilka programów: sprzedażowy, księgowy, kadrowy, a czasem jeszcze integracja ze sklepem. Każdy z nich ma własną bazę, ale wszystkie dzielą te same zasoby.

Przy wersji bezpłatnej serwera bazy ograniczenie pamięci dotyczy całej instancji, więc kilka rosnących baz szybciej odczuwa jej brak. Warto wiedzieć, która baza zajmuje najwięcej i która operacja obciąża serwer w godzinach pracy.

Przy kopiach i odtwarzaniu trzeba pamiętać o wszystkich bazach, także tych od rzadziej używanych programów. Zapomniana baza kadrowa wychodzi zwykle dopiero przy awarii.

Dostęp zdalny i praca poza biurem

Systemy handlowe rzadko są przystosowane do pracy przez internet bezpośrednio. Udostępnienie bazy na zewnątrz bez zabezpieczeń to częsty i bardzo groźny błąd.

Poprawne rozwiązania to połączenie szyfrowane do sieci firmowej albo praca na pulpicie zdalnym. Oba wymagają konfiguracji, ale żadne nie jest kosztowne, a bezpieczeństwo rośnie wyraźnie.

Warto też ograniczyć uprawnienia. Konto używane przez program nie musi mieć pełnych praw administracyjnych do bazy, a w wielu wdrożeniach ma, bo tak było najprościej przy instalacji.

• Port bazy wystawiony bezpośrednio do internetu
• Konto programu z pełnymi uprawnieniami administracyjnymi
• To samo hasło do bazy używane od lat, znane byłym pracownikom
• Brak szyfrowanego połączenia przy pracy zdalnej
• Kopie zapasowe przechowywane na tym samym dysku co baza

Kopie bazy, o których nikt nie pamięta

Poza oficjalnymi kopiami w firmie krążą zwykle kopie nieoficjalne. Plik bazy przekazany firmie wdrożeniowej do sprawdzenia błędu, kopia na laptopie informatyka do testów, eksport kontrahentów do arkusza dla handlowca, baza na nośniku z czasu przeprowadzki serwera.

Każda taka kopia zawiera pełne dane firmy: klientów, ceny, marże, często dane osobowe. Nikt jej nie zabezpiecza, bo nikt nie traktuje jej jak czegoś ważnego. Serwer bywa dobrze chroniony, a te same dane leżą bez żadnej ochrony na zgubionym pendrivie albo w skrzynce pocztowej z załącznikiem sprzed lat.

• Bazę przekazywać do serwisu przez bezpieczne połączenie, a nie jako załącznik e-mail
• Uzgadniać z wykonawcą, kiedy usunie otrzymaną kopię
• Do testów używać kopii ze zmienionymi danymi klientów, gdy to możliwe
• Nośniki z kopiami szyfrować i przechowywać pod zamknięciem
• Raz w roku ustalić, kto ma u siebie jakąkolwiek kopię bazy

Ten sam porządek dotyczy starych serwerów i komputerów. Dysk z wycofanej maszyny, na której kiedyś stała baza, powinien zostać bezpiecznie wyczyszczony albo zniszczony, zanim trafi do szafy lub na sprzedaż.

Zaszyfrowanie danych: jak chronić bazę i kopie

Złośliwe oprogramowanie szyfrujące dane szuka plików w całej sieci firmy, także plików baz i kopii zapasowych. Jeśli kopie są dostępne z tego samego komputera co dane, zostaną zaszyfrowane razem z nimi.

Podstawą ochrony są kopie, do których zainfekowany komputer nie ma dostępu: odłączone od sieci, przechowywane poza firmą albo w usłudze, która nie pozwala ich nadpisać. Do tego ograniczone uprawnienia kont i aktualne systemy.

Najważniejsze jest ustalenie, ile czasu zajmie powrót do pracy, gdy wszystkie komputery w firmie zostaną zaszyfrowane. Jeśli tego nie wiadomo, warto to ustalić teraz, przed atakiem.

Konta i hasła do bazy

W wielu instalacjach wszystkie programy łączą się z bazą tym samym kontem administratora, z hasłem ustawionym przy wdrożeniu i od tamtej pory niezmienionym. Hasło znają poprzedni informatycy, firma wdrożeniowa i czasem pracownicy.

Porządek polega na osobnych kontach dla programów, z uprawnieniami ograniczonymi do potrzebnych baz, i na silnym haśle administratora przechowywanym w bezpiecznym miejscu. Zmianę trzeba przeprowadzić ostrożnie, bo programy muszą dostać nowe dane logowania.

Warto też wyłączyć konta, których nikt nie używa, i sprawdzić, czy serwer bazy nie przyjmuje połączeń spoza sieci firmowej.

Przenoszenie bazy na nowy serwer

Przy wymianie serwera często coś idzie nie tak. Typowe błędy: przeniesienie samych danych bez indeksów, pominięcie zadań konserwacyjnych, zapomnienie o kontach i uprawnieniach.

Skutek bywa opóźniony. System działa, ale od tamtej pory jest wolniejszy, a kopie przestały się wykonywać, bo zadanie zostało na starej maszynie. Odkrywa się to zwykle przy pierwszej awarii.

Sensowna migracja obejmuje więc dane, indeksy, konta, zadania i konfigurację, a do tego test, czyli uruchomienie systemu na nowym serwerze przed wyłączeniem starego.

Dokumentacja: jedna kartka, która oszczędza dni

Kosztowne awarie w małych firmach często wynikają z braku wiedzy, a nie ze skomplikowanych problemów: nikt nie wie, gdzie są kopie, jak nazywa się instancja ani kto ma hasło.

Wystarczy prosty dokument aktualizowany przy każdej zmianie: spis z początku artykułu, harmonogram kopii i zadań konserwacyjnych, data ostatniego testu odtworzenia i kontakt do osób, które pomagają w awarii.

Dokument powinien być dostępny także wtedy, gdy serwer nie działa, na przykład w wersji papierowej albo w bezpiecznym miejscu poza siecią firmową.

Kiedy warto sięgnąć po pomoc z zewnątrz

Wiele rzeczy z tego tekstu da się skonfigurować raz i potem tylko kontrolować. Ktoś musi to jednak zrobić, a w małej firmie zwykle nie ma kto.

Sensowne momenty na zewnętrzną pomoc: przy wdrożeniu systemu, przy wymianie serwera, po zauważeniu spowolnienia i wtedy, gdy nikt nie wie, jak wyglądają kopie zapasowe.

Warto też rozważyć okresowy przegląd raz na pół roku. To wystarcza, żeby wyłapać rozrost bazy, niedziałające zadania i zbliżający się limit wersji bezpłatnej, zanim staną się problemem.

Kto za co odpowiada: firma, wdrożeniowiec i opiekun IT

W małej firmie przy bazie danych pracują zwykle trzy strony: firma wdrożeniowa programu, osoba lub firma zajmująca się komputerami i sama firma. Każda zakłada, że kopie i konserwacja są po stronie którejś z pozostałych. W efekcie bywa, że nikt tego nie robi.

Często program wdrażała jedna firma, a komputerami zajmuje się ktoś inny. Wystarczy jedno spotkanie i krótka notatka, żeby każdy wiedział, gdzie kończy się jego zakres.

W małej firmie opiekunem rzadko jest ktoś na etacie. Plusy i minusy obu rozwiązań opisujemy w artykule outsourcing IT czy etat. Firmom z południowej części województwa pomagamy także na miejscu, zobacz bazy danych MSSQL w Zamościu.

Małe firmy: typowe znaleziska

Przy przeglądach baz w małych firmach powtarzają się te same rzeczy: kopie zapisywane na dysku serwera, zadania konserwacyjne, które przestały działać po zmianie hasła, i bazy zbliżające się do limitu wersji bezpłatnej.

Drugą grupą są serwery pod biurkiem, które od lat pracują bez zasilania awaryjnego, oraz bazy dostępne z internetu, bo ktoś kiedyś potrzebował pracy z domu.

Przeglądy i porządkowanie baz prowadzimy dla firm z regionu. Szczegóły: bazy danych MSSQL w Lublinie i w Chełmie.

Minimum, które warto mieć ustawione

Poniżej zestaw, który zwykle wystarcza w małej firmie i chroni przed typowymi kłopotami. Jednorazowa konfiguracja to zwykle jeden dzień pracy.

Przegląd co pół roku: lista kontrolna

Raz na pół roku warto przejść krótką listę kontrolną. Zajmuje kilka godzin i pozwala wyłapać problemy, zanim zatrzymają firmę.

• Test odtworzenia kopii na osobnej maszynie
• Wielkość baz i zapas do limitu wersji serwera
• Historia wykonania zadań konserwacyjnych i kopii
• Wolne miejsce na dyskach i stan dysków
• Poprawki systemu i serwera bazy
• Konta z dostępem do bazy i ich uprawnienia
• Aktualność dokumentacji

Cztery rzeczy do sprawdzenia dziś

Poniższe kwestie warto omówić z osobą odpowiedzialną za systemy w firmie. Jeśli w którejś brakuje odpowiedzi, wiadomo, od czego zacząć.

• Na której maszynie stoi baza i kto ma do niej dostęp
• Kiedy ostatnio wykonała się kopia i gdzie fizycznie leży
• Kiedy ostatnio ktoś próbował ją odtworzyć
• Ile miejsca zostało do limitu, jeśli używamy wersji bezpłatnej

Trzeci punkt jest najważniejszy. Na kopii, której nikt nie przywracał, trudno polegać w dniu awarii.