ERP i bazy danych
Administracja
bazami danych MS SQL
Baza danych to najcichszy element infrastruktury — działa latami bez skargi, aż pewnego dnia zatrzymuje produkcję. Zajmujemy się nią, zanim to nastąpi: kopie, indeksy, plan konserwacji i realne testy odtworzenia.
Cztery rzeczy, których nikt nie ruszał od wdrożenia
Administracja MS SQL sprowadza się w praktyce do czterech obszarów: indeksów, statystyk, planu konserwacji i kopii zapasowych. W większości firm, do których wchodzimy, przynajmniej dwa z nich nie były dotykane od dnia wdrożenia systemu — czasem sprzed dziesięciu lat.
Indeksy są pofragmentowane, bo nikt nie ustawił zadania, które by je przebudowywało. Statystyki są nieaktualne, więc silnik wybiera złe plany wykonania i to samo zapytanie raz trwa sekundę, a raz minutę. Plan konserwacji albo nie istnieje, albo został skonfigurowany kreatorem i robi rzeczy, których nikt nigdy nie sprawdził.
Kopie zapasowe to osobna historia. Najczęstsze ustawienie, jakie widzimy, to pełny backup raz na dobę zapisywany na ten sam dysk, na którym stoi baza. W razie awarii dysku albo szyfrowania przez ransomware tracisz jednocześnie dane i kopię — czyli wszystko.
- Przebudowa i reorganizacja indeksów według stopnia fragmentacji
- Aktualizacja statystyk, żeby plany wykonania miały sens
- Plan konserwacji dopasowany do okien serwisowych firmy
- Kopie pełne, różnicowe i dziennika transakcji w rozsądnym rytmie
- Kopia poza serwerem produkcyjnym — warunek, nie opcja
- Monitoring wolnego miejsca, kolejek i długich zapytań
Skąd biorą się wolne operacje
Kiedy firma mówi „system zwolnił", rzadko chodzi o cały system. Zwykle wolne są dwie–trzy konkretne operacje: zamknięcie miesiąca, generowanie raportu albo inwentaryzacja. Reszta działa normalnie i właśnie dlatego problem tak długo nie jest zgłaszany.
Zaczynamy od pomiaru, a nie od zgadywania. Sprawdzamy, które zapytania zajmują najwięcej czasu procesora i najwięcej odczytów z dysku, i dopiero na tej podstawie decydujemy, co poprawić. Zdarza się, że jedno źle napisane zapytanie w raporcie uruchamianym raz dziennie obciąża serwer bardziej niż cała reszta pracy razem.
Najtańsza optymalizacja to zwykle uporządkowanie indeksów i statystyk — nie wymaga wymiany sprzętu ani zmian w aplikacji, a potrafi skrócić czas krytycznych operacji o połowę. Dopiero gdy to nie wystarczy, rozmawiamy o mocniejszym serwerze albo o zmianach w samym systemie.
Sprawdź, ile trwa najcięższa operacja po przebudowie indeksów. W kilku firmach zaplanowana wymiana serwera okazała się niepotrzebna — wystarczyło uporządkowanie tego, co już było.
Kopia, której nikt nie odtworzył, nie jest kopią
To zdanie powtarzamy przy każdym wdrożeniu, bo praktyka jest bezlitosna. Backup wykonuje się co noc, plik ma poprawny rozmiar, zadanie kończy się sukcesem — i to wystarcza, żeby wszyscy czuli się bezpiecznie. Aż do dnia, w którym trzeba go użyć.
Robimy więc próbne odtworzenie na osobnym środowisku i mierzymy, ile realnie trwa powrót do pracy. Ta liczba jest znacznie ważniejsza niż sam fakt posiadania kopii, bo od niej zależy, ile firma straci przy awarii: godzinę czy dwa dni.
Przy okazji ustalamy dwie rzeczy, o które nikt nie pyta wcześniej: ile danych możecie stracić w najgorszym przypadku i jak długo produkcja może stać. Odpowiedzi na te pytania decydują o tym, czy wystarczy kopia dobowa, czy trzeba dołożyć kopie dziennika transakcji co kwadrans.
Dostępy i bezpieczeństwo
Bardzo częsty obraz: wszyscy pracują na koncie z uprawnieniami administratora, hasło jest wspólne i nie zmieniało się od wdrożenia, a serwer bazy jest dostępny z internetu na domyślnym porcie. Każdy z tych punktów osobno jest ryzykowny, a razem tworzą sytuację, w której jedno przypadkowe kliknięcie kończy się szyfrowaniem danych.
Porządkujemy uprawnienia według zasady najmniejszych potrzebnych praw, zamykamy dostęp z zewnątrz albo ograniczamy go do konkretnych adresów i wprowadzamy szyfrowanie kopii. To zwykle kilka godzin pracy, które usuwają większość realnego ryzyka.
Monitoring, czyli ostrzeżenie zamiast awarii
Większość awarii bazy zapowiada się z wyprzedzeniem — pod warunkiem, że ktoś patrzy. Kończące się miejsce na dysku, rosnący czas wykonania stałych operacji, narastające kolejki i błędy w dzienniku zdarzeń to sygnały widoczne na kilka dni przed tym, jak system stanie.
Ustawiamy monitoring, który zgłasza te rzeczy zanim staną się problemem, i ustalamy, kto ma dostawać powiadomienie. To ostatnie bywa pomijane, a bez tego alert trafia na skrzynkę, do której nikt nie zagląda.
Dla kogo pracujemy
Najczęściej są to firmy produkcyjne i handlowe z systemem magazynowym opartym o MS SQL: Subiekt, Insoft, WAPRO, Comarch albo rozwiązanie branżowe pisane na zamówienie. Wspólny mianownik jest zawsze ten sam — baza urosła przez lata, a nikt nie miał czasu się nią zająć.
Obsługujemy zarówno serwery stojące w firmie, jak i te w chmurze. Pracujemy zdalnie, a przy awariach krytycznych także poza standardowymi godzinami — bo zmiana nocna nie może czekać do rana, a inwentaryzacja robiona w sobotę nie zaczeka do poniedziałku.
Pan Jakub jest bardzo profesjonalny i znacznie ułatwił mi prowadzenie firmy.
Wersje, licencje i limity, o które nikt nie pyta
MS SQL występuje w kilku wariantach, a różnice między nimi bywają dotkliwe dopiero po latach. Wersja Express jest darmowa, ale ogranicza rozmiar pojedynczej bazy i ilość pamięci, z której silnik może skorzystać. Firma rośnie, baza dobija do limitu i system zaczyna zachowywać się dziwnie — bez żadnego wyraźnego komunikatu o przyczynie.
Sprawdzamy więc na starcie, na jakiej wersji stoi system, jak blisko limitów jesteście i czy przejście na wariant płatny w ogóle ma sens. Czasem taniej jest odchudzić bazę i zostać przy Expressie, a czasem odwrotnie — koszt licencji zwraca się w pierwszym miesiącu skróconych zamknięć.
Osobna sprawa to wersja samego silnika. Systemy z lat, które nie dostają już poprawek bezpieczeństwa, stoją w wielu firmach do dziś. Migracja bywa prostsza, niż się wydaje, ale wymaga sprawdzenia zgodności z aplikacją ERP — i tego nigdy nie robi się na produkcji bez wcześniejszego testu.
Współpraca
Jak to wygląda krok po kroku
Przegląd stanu
Sprawdzamy wersje, rozmiary, indeksy, kopie i to, co realnie obciąża serwer. Nic nie zmieniamy bez uzgodnienia.
Zabezpieczenie
Najpierw kopie i uprawnienia — dopiero potem optymalizacja. Odwrotna kolejność bywa kosztowna.
Optymalizacja
Indeksy, statystyki, plan konserwacji i poprawki najcięższych zapytań.
Opieka
Monitoring, cykliczne przeglądy i wsparcie przy awariach.
Pytania
Zanim zapytasz
Większość nie. Przebudowę indeksów i konserwację planujemy w oknach serwisowych, zwykle nocnych. Jeśli coś wymaga przestoju, mówimy o tym wcześniej i ustalamy termin.
Wersja darmowa ma limity rozmiaru bazy i wykorzystania pamięci. Sprawdzamy, czy jesteście blisko tych limitów — bo osiągnięcie ich objawia się właśnie spowolnieniem, które trudno wyjaśnić.
Tak, i to najpilniejszy rodzaj zgłoszenia. Ważne, żeby nie próbować napraw na oryginale — pierwszym krokiem zawsze jest zabezpieczenie stanu obecnego.
Tak — zobacz wsparcie systemów ERP, Insert i Insoft.
Powiązane usługi
Co jeszcze może się przydać
Twoje miasto
Bazy danych MS SQL w Twoim mieście
Dla każdego z tych miast mamy osobną stronę z lokalnym rynkiem, cenami i przykładami — a nie ten sam tekst z podmienioną nazwą.
Sprawdźmy, w jakim stanie jest Twoja baza
Przegląd zaczyna się od kilku pytań o wersję, rozmiar i sposób robienia kopii. Napisz — odpowiemy, czy jest się czym martwić.