Optima zwolniła po aktualizacji SQL Server 2025? Przyczyna i naprawa

U jednego z naszych klientów po aktualizacji SQL Server z wersji 2022 do 2025 zwolniło księgowanie w Comarch ERP Optima. Sama Optima była już w najnowszej wersji (2026.5), więc zmienił się tylko serwer bazy danych. Na serwerze z Windows Server 2019 działa kilkaset baz firm, a pracownicy korzystają z Optimy głównie przez pulpit zdalny.

Objawy

Księgowanie każdego dokumentu trwało 4 sekundy, bez względu na rodzaj: faktura zakupu, sprzedaży czy dokument z KSeF. Księgowanie paczki dokumentów trwało około 49 sekund. Pracownicy zgłaszali, że operacje, które wcześniej trwały sekundy, trwają minuty.

(otwiera obraz w pełnym rozmiarze)

Co sprawdziliśmy i odrzuciliśmy

Zanim znaleźliśmy przyczynę, sprawdziliśmy serwer w godzinach pracy. Te elementy działały prawidłowo:

• Dysk: odczyt danych ok. 0,2 ms, zapis dziennika transakcji 3–4 ms.
• Procesor: SQL Server używał średnio mniej niż jednego rdzenia z ośmiu.
• Blokady: w pomiarach co sekundę nie było żadnych.
• Sieć po stronie serwera: oczekiwanie ok. 1 ms.
• Antywirus: wykluczenia Microsoft Defender dla SQL Server nic nie zmieniły.

Przyczyna: wolniejsze sprawdzanie haseł w SQL Server 2025

SQL Server 2025 zapisuje i sprawdza hasła loginów SQL algorytmem PBKDF2 (100 000 powtórzeń SHA-512). Microsoft wymienia tę zmianę wśród znanych problemów SQL Server 2025, bo spowalnia logowanie. Stare hasła serwer sam zapisuje w nowy sposób przy pierwszym udanym logowaniu po aktualizacji.

W naszych pomiarach nowe połączenie loginem SQL trwało średnio 118,8 ms, a kontem Windows 2,4 ms.

Przy jednym połączeniu 120 ms nie miałoby znaczenia. Optima łączy się z bazą loginem SQL CDNOperator i otwiera bardzo dużo nowych połączeń: przy jednej paczce księgowania naliczyliśmy ok. 166 nowych połączeń w 49 sekund, a w 15 minutach zwykłej pracy biura 2 481 logowań. Przy każdym z nich serwer sprawdza hasło nowym, wolniejszym sposobem.

Szacujemy, że w paczce trwającej 49 sekund same logowania zajmowały 12–20 sekund. Reszta to zapytania w bazie i praca samego programu. Logowanie odpowiada więc za dużą część opóźnienia, ale nie za całe.

Jak sprawdzić, czy to Państwa przypadek

W SQL Server Management Studio wystarczy jedno zapytanie:

SELECT name, CONVERT(varchar(6), password_hash, 1) AS hash_type
FROM sys.sql_logins;

Wynik 0x0300 oznacza nowy zapis PBKDF2, a 0x0200 dawny, szybki zapis z SQL Server 2022.

Co pomogło: flaga 4671

To rozwiązanie eksperymentalne. Flagi śledzenia 4671 nie ma w dokumentacji Microsoft, Microsoft jej nie wspiera, a część specjalistów SQL ją odradza. U naszego klienta zadziałała. Zrobiliśmy to w tej kolejności:

1. Pełny backup wszystkich baz, także systemowej master, w której są loginy i hasła. Wiele prostych skryptów backupu pomija bazy systemowe.
2. Zapisanie obecnego password_hash loginu CDNOperator, żeby móc wrócić do poprzedniego hasła.
3. Test flagi na tymczasowym loginie testowym, po godzinach pracy.
4. Włączenie flagi poleceniem DBCC TRACEON(4671, -1) i parametrem startowym -T4671 w SQL Server Configuration Manager, żeby flaga działała też po restarcie.
5. Nowe hasło CDNOperator ustawione w Optimie przy włączonej fladze (Narzędzia, Serwer bazy danych, Zmiana hasła użytkownika „CDNOperator”) z opcją „Zapisz hasło dla wszystkich użytkowników Windows”. Optimę trzeba uruchomić jako administrator, inaczej wspólny plik z hasłem się nie zaktualizuje.
6. Nowe hasło na każdym komputerze z własną instalacją Optimy, w Serwisie Operacji Automatycznych i w każdym programie, który używa tego loginu.

Wyniki testu na loginie testowym (10 prób na każdy krok):

• Bez flagi: 118,8 ms na nowe połączenie.
• Flaga włączona, hasło nadal w zapisie PBKDF2: 116,8 ms. Samo logowanie nie zmienia zapisu.
• Flaga włączona i ponownie ustawione to samo hasło: 0,8 ms.
• Flaga wyłączona: 121,1 ms. Pierwsze logowanie przepisało zapis z powrotem na PBKDF2.

(otwiera obraz w pełnym rozmiarze)

(otwiera obraz w pełnym rozmiarze)

Wynik

Nowe połączenie loginem SQL skróciło się z 118,8 ms do 0,8 ms. Czas księgowania jednego dokumentu spadł z 4 do ok. 3 sekund. To wynik jednego testu. Pracownicy, którzy łączą się z serwerem przez pulpit zdalny, mówią, że Optima działa dużo lepiej. Nie porównaliśmy jeszcze tej samej paczki dokumentów przed zmianą i po niej na jednym komputerze.

Na co uważać

• Sama flaga nic nie daje. Hasło trzeba ustawić ponownie przy włączonej fladze.
• Flagi nie wyłączamy. Bez niej SQL Server przy pierwszym logowaniu wraca do PBKDF2: program działa dalej, ale znów wolno.
• Po każdej aktualizacji SQL Server sprawdzamy flagę i zapis hasła. Kolejna aktualizacja może zmienić działanie flagi. U nas po aktualizacji bezpieczeństwa KB5126967 flaga nadal działała.
• Powrót do SQL Server 2022 nie jest prostym wyjściem: baz i backupów z SQL Server 2025 nie da się odtworzyć na wersji 2022.
• Programy, które nadal logują się starym hasłem, widać w dzienniku SQL Server (ERRORLOG, błąd 18456). U nas była to między innymi stara, nieużywana aplikacja WWW na serwerze.
• Serwis Operacji Automatycznych w Optimie 2026.5 nie działa na koncie LocalSystem. Potrzebuje osobnego konta Windows, a plik z hasłem musi leżeć w profilu tego konta.
• Hasła CDNOperator nie podajemy osobom spoza firmy. Ten login ma zwykle dostęp do baz wszystkich firm w Optimie.
• Przy komputerach, które łączą się z bazą przez VPN albo Wi-Fi, opóźnienie sieci dokłada się do każdego z wielu połączeń Optimy. Dlatego polecamy pracę przez pulpit zdalny na serwerze.

Sprawdzenie flagi po aktualizacji:

DBCC TRACESTATUS(4671);

Źródła

• Microsoft: SQL Server 2025 known issues
• Microsoft: sys.sql_logins
• VladDBA: SQL Server 2025 PBKDF2
• Comarch: CDNOperator

Zrobimy to za Państwa

Jeśli Optima zwolniła po aktualizacji SQL Server, sprawdzimy przyczynę i wprowadzimy zmianę z backupem i planem powrotu. Więcej o tym, jak dbamy o IT biur rachunkowych. Prosimy napisać na kontakt@proop.pl albo zadzwonić: +48 690 504 074.