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. Program bez niej jest pustą skorupą.

Ma to praktyczne konsekwencje. Kopia zapasowa katalogu z programem nie jest kopią danych. Wymiana komputera, na którym stoi baza, wymaga przeniesienia jej, a nie tylko przeinstalowania programu.

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 odpowiedź brzmi: nikt w firmie 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 większość mniejszych wdrożeń. Ma jednak ograniczenia: wielkość pojedynczej bazy, ilość wykorzystywanej pamięci i liczba rdzeni procesora.

W praktyce oznacza to, że firma rośnie, a baza w pewnym momencie dobija do limitu. Objawia się to komunikatem o braku miejsca albo po prostu 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 to nie to samo co kopia plików. Skopiowanie pliku bazy w trakcie pracy serwera daje zwykle plik uszkodzony, z którego nic się nie odtworzy — a to odkrywa się 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żniejsze jest jednak coś innego: test odtworzenia. Kopia, której nikt nigdy nie próbował przywrócić, jest obietnicą. 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 — 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 osobą, która wie, ile kosztuje dzień utraconych danych, a nie tylko z informatykiem. 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ść. Najwięcej danych traci się nie przez samą awarię, tylko przez pospieszne działania, które ją pogłębiają.

• 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: cztery zadania, o których nikt nie pamięta

Baza wymaga okresowej konserwacji, tak samo jak każde inne urządzenie pracujące codziennie. Bez niej działa dalej, ale coraz wolniej — i nikt nie łączy tego 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 najczęściej pomijany. Zadanie skonfigurowane i niedziałające — 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 dotknął.

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 sama konfiguracja zadań to połowa pracy — 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, a nie 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ć”.

To podejście ma swoją cenę: 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, a nie w pośpiechu.

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, a nie na dysk.

Zapobieganie jest proste: właściwy tryb pracy bazy dopasowany do potrzeb firmy plus regularne kopie, które pozwalają dziennik przycinać. Konfiguracja to 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. Najczęstsze 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 zaczyna decydować o komforcie pracy wszystkich osób w firmie.

Zanim jednak zapadnie decyzja o nowym serwerze, warto sprawdzić bazę. Nierzadko dwa dni pracy nad nią skracają czas wystawienia dokumentu z kilkunastu sekund do jednej — 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, a nie tylko o tej od programu, z którego korzysta się najczęściej. 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ń jest jednym z najczęstszych i najgroźniejszych błędów, jakie spotykamy.

Poprawne rozwiązania to połączenie szyfrowane do sieci firmowej albo praca na pulpicie zdalnym. Oba wymagają konfiguracji, ale żadne nie jest kosztowne — a różnica w bezpieczeństwie jest fundamentalna.

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ć w zamknięciu
• 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, a nie 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 pytanie brzmi: ile czasu zajmie powrót do pracy, gdy wszystkie komputery w firmie zostaną zaszyfrowane? Jeśli odpowiedź nie jest znana, warto ją ustalić teraz, a nie w dniu ataku.

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 nigdy 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

Wymiana serwera to najczęstszy moment, w którym 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 nie tylko dane: także indeksy, konta, zadania i konfigurację. Plus test — uruchomienie systemu na nowym serwerze przed wyłączeniem starego.

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

Najdroższe awarie w małych firmach nie wynikają ze skomplikowanych problemów, tylko z braku wiedzy: 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

Większość rzeczy z tego tekstu da się skonfigurować raz i zapomnieć. Problem polega na tym, że ktoś musi to 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 potrafi odpowiedzieć na pytanie o kopie zapasowe.

Warto też rozważyć okresowy przegląd — raz na pół roku, kilka godzin. 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 nie robi tego nikt.

W firmach z Lublina, Puław czy Zamościa często spotykamy sytuację, w której program wdrażał lokalny partner, 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 regionu pomagamy także na miejscu, zobacz bazy danych MSSQL w Zamościu.

Małe firmy z regionu: typowe znaleziska

Przeglądając bazy w firmach z Lublina, Chełma czy Białej Podlaskiej, najczęściej znajdujemy 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 — zobacz bazy danych MSSQL w Lublinie i w Chełmie.

Minimum, które warto mieć ustawione

Poniżej zestaw, który wystarcza w większości małych firm i chroni przed najczęstszymi kłopotami. Konfiguracja to zwykle jeden dzień pracy jednorazowo.

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 pytania do zadania dziś

Poniższe pytania warto zadać osobie odpowiedzialnej za systemy w firmie. Jeśli na któreś nie ma 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

Trzecie pytanie jest najważniejsze. Kopia, której nikt nigdy nie przywracał, to plik zajmujący miejsce — a nie zabezpieczenie, na którym da się polegać w dniu awarii.