Aktualizacja: 26 sierpnia 2026
Instalacja klikana bez zmian domyślnych zostawia ustawienia, które dla systemu ERP bywają szkodliwe. Nie dlatego, że są błędne, tylko dlatego, że domyślne wartości pochodzą sprzed dwudziestu lat i nie zakładają obciążenia, jakie daje program handlowy z kilkunastoma stanowiskami i integracjami.
Poniżej pięć ustawień, które sprawdzamy w każdej analizie wydajności, wraz z tym, jak odczytać stan bieżący i co z nim zrobić. Wszystkie zapytania sprawdzające są wyłącznie do odczytu.
Najpierw sprawdź, co masz teraz
SELECT name, value_in_use
FROM sys.configurations
WHERE name IN (
'max degree of parallelism',
'cost threshold for parallelism',
'max server memory (MB)',
'min server memory (MB)'
);max degree of parallelism = 0 oznacza brak ograniczenia. cost threshold for parallelism = 5 to wartość domyślna. max server memory (MB) = 2147483647 oznacza brak limitu. Jeżeli widzisz ten komplet, instancja stoi na ustawieniach fabrycznych.
MAXDOP, czyli ile rdzeni na jedno zapytanie
Domyślnie SQL Server może użyć wszystkich rdzeni do wykonania jednego zapytania. Na serwerze jednoprocesorowym to zwykle nie szkodzi. Na serwerze z dwoma węzłami NUMA dochodzi ukryty koszt przenoszenia wątków i pamięci między węzłami, a przy obciążeniu ERP potrafi on przewyższyć zysk ze zrównoleglenia.
U klienta, u którego generowanie JPK_KR w Rewizorze trwało nieakceptowalnie długo na serwerze z dwoma węzłami NUMA, ograniczyliśmy MAXDOP do 8, czyli mniej więcej połowy węzła, i przenieśliśmy duże wyliczenia bezpośrednio na serwer. Punkt wyjścia dla większości instalacji to właśnie połowa rdzeni jednego węzła NUMA, a nie liczba wzięta z poradnika.
Cost threshold for parallelism
Domyślna piątka pochodzi z lat dziewięćdziesiątych i została dobrana do sprzętu, którego dziś nie ma w użyciu. Przy obciążeniu typu ERP, gdzie dominują krótkie zapytania, powoduje zrównoleglanie tego, co lepiej wykonać jednowątkowo, a każde zrównoleglenie kosztuje synchronizację.
To ustawienie zmienia się razem z MAXDOP, nie osobno. Sam MAXDOP przy progu równym 5 nadal będzie rozdzielał drobnicę.
max server memory
Wartość domyślna sprawia, że SQL Server rywalizuje o pamięć z systemem operacyjnym. Objawem jest stronicowanie i spowolnienia, które nie mają nic wspólnego z bazą.
Ważniejsze od ustawiania minimum jest ustawienie sensownego maksimum, żeby silnik sam gospodarował pamięcią, wiedząc, ile jej ma. Zostawiamy systemowi to, czego potrzebuje, i pamiętamy, że jeżeli na tej samej maszynie stoi serwer terminali albo aplikacja, ich apetyt też trzeba odjąć.
Wykluczenia antywirusa
Pliki .mdf, .ndf i .ldf, wraz z bazami systemowymi, wykluczamy ze skanowania w czasie rzeczywistym. Dotyczy to bazy każdej wielkości i jest to najtańsza zmiana z całej listy: kilka minut pracy, zero ryzyka, natychmiastowy efekt na serwerach, na których nikt o tym nie pomyślał.
Log transakcyjny i pliki bazy
Cztery rzeczy, które sprawdzamy zawsze.
Autogrowth ustawiony procentowo daje coraz większe skoki i zauważalne przycięcia w pracy, bo każdy kolejny przyrost jest większy od poprzedniego. Ustawiamy stały przyrost w megabajtach.
Częste automatyczne powiększanie logu to objaw źle dobranego rozmiaru początkowego albo braku kopii logu przy modelu odtwarzania FULL. Jedno i drugie da się ustawić raz i zapomnieć.
Log powinien leżeć na wolumenie o niskim opóźnieniu zapisu. To jedyne miejsce, w którym dysk naprawdę decyduje o odczuwalnej wydajności, bo zapis do logu jest synchroniczny i użytkownik czeka na jego potwierdzenie.
tempdb wymaga osobnej uwagi: liczba plików danych dopasowana do liczby rdzeni, wszystkie tej samej wielkości, stały przyrost. Nierówne pliki tempdb to jedna z tych rzeczy, które nie bolą, dopóki obciążenie nie urośnie.
Czego tu nie ma
SHRINK bazy nie jest elementem konfiguracji ani optymalizacji. Powoduje drastyczną fragmentację indeksów i w dłuższej perspektywie spowalnia system. Jeżeli ktoś proponuje shrink jako sposób na przyspieszenie bazy, warto zapytać, co jeszcze proponuje.
Gdy to nie pomoże
Konfiguracja instancji rozwiązuje problemy z dużymi wyliczeniami, stronicowaniem i przycięciami przy zapisie. Nie rozwiąże trzech innych rzeczy i warto wiedzieć o tym, zanim wyda się wieczór na strojenie.
Jeżeli wolno jest tylko przy jednej konkretnej operacji, a reszta programu działa normalnie, przyczyną jest zwykle plan wykonania albo brakujący indeks, nie konfiguracja. Opisujemy to w artykule o złym planie wykonania.
Jeżeli wolno jest u jednego użytkownika przy tym samym sprzęcie, szukaj blokad, nie ustawień instancji.
A jeżeli baza się nudzi, stanowiska lokalne pracują dobrze i wolno jest wyłącznie na pulpicie zdalnym, wąskim gardłem jest serwer terminali i w bazie nie ma czego optymalizować. Pełny przegląd przyczyn: optymalizacja bazy danych w programach InsERT.
Kiedy warto to komuś oddać
Powyższe zmiany możesz wprowadzić sam i przy większości instalacji to wystarczy. Dobranie wartości do konkretnego serwera wymaga jednak wiedzy o tym, ile rdzeni ma węzeł NUMA, ile pamięci zjada reszta maszyny i jak wygląda realne obciążenie w godzinach pracy. Bez tego ustawia się liczby z internetu, co bywa lepsze od domyślnych, ale nie musi.
Analiza wydajności bazy danych za 1050 zł netto obejmuje przegląd konfiguracji instancji razem z pomiarem w godzinach realnej pracy, więc wartości wynikają z Waszego serwera, a nie z przeciętnej. Jeżeli przyczyną okaże się sprzęt albo terminal, napiszemy to wprost.
Zamów analizę wydajności bazy danych
Konfiguracja i strojenie instancji SQL Server pod programy InsERT: Subiekt GT, Subiekt nexo, Rewizor GT, Rewizor nexo, Gratyfikant, Navireo. Typowe zgłoszenia: JPK liczy się godzinami, zamknięcie roku trwa w nieskończoność, serwer mocny a program wolny.