Aktualizacja: 26 sierpnia 2026
Dodanie jednej pozycji do dokumentu trwa kilkadziesiąt sekund. Indeksy są odbudowane, statystyki świeże, fragmentacja poniżej procenta, sprzęt bez zarzutu. A najdziwniejsze jest to, że zaczęło się nazajutrz po konserwacji bazy.
To nie jest przypadek graniczny. W linii nexo jest to jedna z najczęstszych przyczyn spowolnień, jakie rozpoznajemy w zgłoszeniach, a jednocześnie ta, którą najczęściej myli się ze zbyt słabym serwerem. Poniżej mechanizm, sposób rozpoznania i to, co zrobić, kiedy standardowe rozwiązanie nie wystarczy.
Co się dzieje w silniku
SQL Server nie wymyśla sposobu wykonania zapytania za każdym razem od nowa. Kompiluje plan raz, dla tych parametrów, z jakimi zapytanie trafiło do niego jako pierwsze po restarcie albo po konserwacji, i stosuje ten sam plan do wszystkich kolejnych wywołań. Nazywa się to param-sniffing i przez większość czasu działa na naszą korzyść, bo kompilacja kosztuje.
Kłopot zaczyna się, gdy pierwszy zestaw parametrów był nietypowy. Plan dobrany do wyjątku zostaje w pamięci podręcznej i cała firma pracuje na nim przez kolejne dni. To samo kliknięcie, które w zeszłym tygodniu trwało sekundę, dziś trwa pół minuty, przy zdrowych indeksach i aktualnych statystykach.
W programach linii nexo mechanizm jest szczególnie dotkliwy, bo zapytania generowane przez program bywają wrażliwe na rozrzut danych. Baza, w której jeden towar ma dwie partie, a inny kilka tysięcy, daje dwa skrajnie różne optymalne plany dla tego samego zapytania.
Objaw, który przesądza o rozpoznaniu
Problem pojawia się po nocnej konserwacji albo po restarcie serwera, a nie przed nimi. Brzmi to odwrotnie do intuicji i dlatego bywa lekceważone, a bywa też traktowane jako dowód, że konserwacja coś popsuła.
Mechanizm jest prosty. Odbudowa indeksów i aktualizacja statystyk unieważniają plany wykonania. Następnego ranka wszystko kompiluje się od nowa, na parametrach pierwszego użytkownika, który wszedł do systemu. Jeżeli ten pierwszy użytkownik akurat otworzył nietypowy dokument, jego przypadek staje się wzorcem na cały dzień.
Drugi sygnał: restart serwera daje poprawę na kilkanaście–dwadzieścia minut, po czym objaw wraca. To najbardziej wartościowa wskazówka, jaką można dostać w takim zgłoszeniu, bo wyklucza jednocześnie sprzęt, sieć i fragmentację.
Trzeci sygnał widać w Query Store: to samo zapytanie ma kilka różnych planów o skrajnie różnych czasach wykonania. Nie liczba planów sama w sobie jest problemem, tylko rozrzut czasów między nimi.
Przypadek z naszej praktyki
Firma handlująca telefonami, Subiekt nexo, kilkanaście stanowisk. Każda sztuka towaru to osobna partia, więc typowy asortyment ma kilka tysięcy partii.
Objaw. Skanowanie kodów dostaw i wybór partii narastały od 6–10 sekund do 50–60 sekund i timeoutów.
Co nie zadziałało. Odbudowa indeksów, bo fragmentacja była poniżej 1 procenta. Dokładanie kolejnych indeksów pokrywających, które sprawę pogarszało.
Przyczyna. To samo zapytanie kompilowało się w sześciu wariantach planu, od około 22 do około 90 sekund, a utrwalał się wariant skompilowany dla nietypowych parametrów.
Wynik. 1–3 sekundy na pozycję po ustabilizowaniu planu.
Osobno rzecz, która w tym samym zgłoszeniu okazała się zaskoczeniem: usunięcie nadmiarowych indeksów z rozbudowaną listą INCLUDE skróciło jedną z operacji z 3,5 sekundy do 0,15 sekundy. Odruch „dołóżmy indeks pokrywający” przy problemie z planem wykonania potrafi zaszkodzić, bo poszerza wybór, w którym silnik i tak wybiera źle.
Co zrobić
Doraźnie: wyczyścić pamięć planów w zakresie jednej bazy.
ALTER DATABASE SCOPED CONFIGURATION CLEAR PROCEDURE_CACHE;Nigdy poleceniem obejmującym całą instancję. Na serwerze, na którym stoi więcej niż jedna baza, ubija się wtedy plany wszystkich pozostałych i problem, który miał dotyczyć jednego programu, rozlewa się na resztę firmy.
Docelowo: wpiąć czyszczenie planów w cykliczną konserwację, jako operację następującą po pełnej odbudowie indeksów, nie przed nią. Kolejność ma znaczenie, bo odbudowa sama unieważnia część planów i wykonana po czyszczeniu marnuje jego efekt.
Przed każdą taką zmianą warto zapisać czasy kilku konkretnych operacji, żeby po wdrożeniu było z czym porównać.
Gdy to nie zadziała
Trzy sytuacje, w tej kolejności prawdopodobieństwa.
Objaw wraca po kilku godzinach tego samego dnia. To zwykle znaczy, że problem nie leży w utrwalonym planie, tylko w narastających blokadach. Sprawdź wiszące sesje i wpisy w tabeli ins_Blokada.
Czyszczenie planów nie zmienia nic od pierwszego razu. Wróć do fragmentacji i statystyk, a jeżeli i te są w porządku, do konfiguracji instancji. Pełna lista przyczyn jest w przeglądzie optymalizacji baz InsERT.
Objaw znika, ale wraca co jeden do trzech tygodni. To najtrudniejszy wariant i opisujemy go niżej.
Granica tego rozwiązania
U klienta z opisanego przypadku objaw nawracał co jeden do trzech tygodni, mimo że czyszczenie pamięci planów zostało wpięte w cykliczną konserwację. Ustabilizowanie planu gasi objaw, ale nie usuwa przyczyny źródłowej, którą jest konstrukcja zapytania generowanego przez sam program. Poniżej pewnego pułapu nie da się zejść po stronie SQL Server, bo tego zapytania nie piszemy my.
Właściwa ścieżka prowadzi wtedy dwutorowo. U klienta gasimy objaw cyklicznie i mierzymy, po ilu dniach wraca, żeby dobrać częstotliwość konserwacji do faktów, a nie do kalendarza. Równolegle zgłaszamy sprawę producentowi, z kompletem dowodów: identyfikatorami zapytań, planami wykonania i pomiarami przed i po. Bez tego drugiego toru zgłoszenie ląduje w kategorii „u nas działa”.
Wniosek praktyczny dla bazy o takim profilu: skuteczna jest wyłącznie cykliczna konserwacja z pomiarem, a nie jednorazowa interwencja.
Nie wiesz, czy to Twój przypadek?
Jeżeli rozpoznajesz objaw z pierwszego akapitu, zacznij od zapytań diagnostycznych z przeglądu przyczyn spowolnień i prześlij nam wynik. Wstępne spojrzenie jest bezpłatne.
Jeżeli chcesz mieć to zmierzone i rozstrzygnięte, robimy analizę wydajności bazy danych za 1050 zł netto: pomiar w godzinach realnej pracy, raport ze wskazaniem przyczyny, a przy prostszych przypadkach także rozwiązanie w tej samej cenie.
Zamów analizę wydajności bazy danych
Diagnostyka planów wykonania i optymalizacja baz SQL Server dla programów InsERT: Subiekt nexo, Subiekt GT, Rewizor nexo, Navireo. Typowe zgłoszenia: nexo długo dodaje pozycję do dokumentu, skanowanie kodu dostawy trwa kilkadziesiąt sekund, program zwolnił po nocnej konserwacji.