Lista towarów - problem z rezerwacjami i zawieszaniem

[szczygielp]

Po zmianie serwera n SQL 2016 i przejście na wersję 2017.2 mam problem z listą towarów (zakładka wg kodu).
Po wpisaniu abc% program potrafi zatrzymać działanie i wyświetlenie listy spełniające kryteria zajmuję kilka do kilkunastu minut.
W czasie szukania problemy wykonałem reindeksacje tabeli CDN.Rezerwacje. Po zrobieniu reindeksacji wyświetlanie listy towarów wróciło do normy.
Niestety problem z wyświetlaniem powraca raz na kilka godzin. Problem występuje na kilku serwerach terminalowych jednocześnie a nawet na serwerze na którym działa SQL Server.
Podsłuchałem zapytanie jakie wysyłane jest na serwer SQL przez CDNXL. Zapytanie to wykonane w SQL Management Studio w czasie kiedy pojawia się problem zwraca wyniki w optymalnym czasie. Podejrzewam że problem leży w interfejsie pomiędzy CDNXL i SQL.
Tabel rezerwacje w ciągu dnia jest mocno obciążona zarówno odczytami jak i zmianami - większość zasobów mamy zarezerwowanych pod klienta ze wskazaniem dostawy - wykonujemy hurtowe zmiany rezerwacji.
Przed zmianą SQL i wersji CDNXL wszystko pracowało poprawnie. Zastanawiam się gdzie można szukać rozwiązania problemu ?

[john_doe]

co to znaczy "wykonujemy hurtowe zmiany rezerwacji"
robicie jakieś modyfikacje zewn. mechanizmem?

[szczygielp]

Mamy rozwiązanie własne tworzące kasujące i dodające rekordy t tabeli rezerwacje. Rozwiązanie działa od 3 lat i nie było z nim problemów.
Przypomnę jeszcze iż wykonanie zapytania wyświetlającego towary z wykorzystaniem SSMS wyświetla listę towarów w czasie <1s CDNXL wyświetlą tą samą listę kilkanaście sekund.

[szczygielp]

Problem ostatecznie udało się rozwiązać.
Okazało się iż wszystkiemu winne są indeksy.
Po analizie planów wykonania wyłączyłem kilka indeksów i wprowadziłem własny. Takie zmiany na tyle przyspieszyły czas wykonania funkcji do obliczania dostępnych zasobów iż problem z " zawieszaniem się" listy towarów został rozwiązany.

[Yuber]

Jeśli to nie problem, to poproszę o dokładniejszy opis tego co wykonałeś. Mam przypadek, że baza co pewien czas bardzo mocno przymula i to niekoniecznie przy dużym obciążeniu. Dzieje się to w obrębie tabel MagNag i MagElem i objaw jest podobny do Twojego. Próbowaliśmy już przeróżne cuda, Deadlocki, indeksy, testy dysków, sprzętów, przenoszenie logów itd. Pomysły się pokończyły a problem zostaje. Liczę, że może na coś wpadnę.

[szczygielp]

Proponuję ustalenie kodu SQL który powoduje zawieszanie się systemu. Następnie wykonać analizę planu zapytania. U mnie kluczem była funkcja DokSumaStanowTowaru której wykonanie udało się skrócić o 80 % dzięki wyłączeniu wszystkich indeksów i wprowadzeniu własnych w oparciu o plan wykonania. Proszę pamiętać o częstym wykonaniu reindeksacji przy dużych bazach.
Podałeś mało danych - wielkość bazy - ilość RAM serwera SQL?

[Yuber]

Dane: MSSQL 2012 STD, Baza 31 GB, RAM 96 GB, XL 2016.3.4
No i tak jakbym wywołał sobie tym postem wilka z lasu. W ostatni piątek znowu po godzinie 16 problem się uaktywnił gdy akurat był to dla mnie dzień wolny. Tym razem pozwoliłem sobie nieco sprawę przeciągnąć i wiem o problemie już nieco więcej. Otóż po godzinie 16 pracę kończy jeden z pracowników. Na koniec dnia sprawdza listę WM i zamyka XL-a. Nie wiem jeszcze w jaki sposób to robi ale sesja RDP wisi a Sprzedaż jest odpalona i wywala wyjątek (przerwany wątek). Ta odpalona sesja XL-a powoduje, na SQL-u zostają śmieci w procesach a to zaś powoduje że jeśli ktoś wykonuje jakąś akcję na dokumentach WM np zamyka dokument to jego proces na bazie danych zostaje zablokowany (Processes kolumna Head Blocker > 700, Wait Time - rośnie). Ciekawe jest to, że użytkownicy pracujący w tym centrum przywieszani są całkowicie natomiast w innych centrach daje się odczuć mocne spowolnienie działanie XL-a.

Po ubiciu z menadżera Sprzedaży wszystko wraca do normy.
Moje podejrzenie jest takie, że dzieje się tak tylko wtedy gdy na jednej sesji odpali się dwa razy jeden moduł np sprzedaż (zalogowanych dwóch różnych operatorów). Jeden moduł jest zamykany natomiast drugi prawdopodobnie przy wylogowywaniu próbuje być ubijany. Błędem jaki popełniłem jest to, że skupiłem się na wątku który się nie wykonywał a tak naprawdę całość przycina inny wątek czyli pozostałości po uszkodzonej sesji. Teraz kończenie tego z taskmgr nie jest dobrym rozwiązaniem, bo wyraźnie coś tu nie zostało dokończone w bazie. Muszę zadbać o to by takie akcje się nie powtórzyły. Tak czy inaczej dzięki za podpowiedzi.