Klient mi zgłosił, że ma problem z tym, że niekiedy nie może się zalogować do baz klientów z aplikacji Optima. W firmie jest około 20 użytkowników, którzy pracują, każdy na swoim komputerze, niektórzy zdalnie, niektórzy z firmy. Pierwsze co znalazłem to to, że kiedy robiłem aktualizację choćby jednej bazy firmy do nowej wersji, co czasem potrafi trwać nawet i 20 minut per baza, nikt z użytkowników nie mógł przelobować się do innej bazy klienta. Napomknę tylko, że na serwerze było kilkaset baz. Było to związane z blokadami na bazie konfiguracyjnej.
Przelogowanie do innej bazy klienta powodowało, że program Optima, musi sprawdzić dane w bazie konfiguracyjnej bo tam są zarejestrowane wszystkie bazy klientów. Podczas aktualizacji bazy klienta, jest blokowana też baza konfiguracyjne i nikt w tym czasie nie mógł zrobić nawet SELECTa, więc nie mógł się przelogować na inną bazę klienta.
Magiczną zmianą która pomogła mi z tym problemem była zmiana poziomu izolacji z READ_COMMITTED nad READ_COMMITTED_SNAPSHOT dla bazy konfiguracyjnej. Od tego momentu przy aktualizacji do nowej wersji, „czytelnik nie blokuje pisarza” ani „pisarz nie blokuje czytelnika”, wszyscy użytkownicy mogą przełączać się między bazami klientów, niezależnie od prowadzonej aktualizacji. Bo stare wersje wierszy są przechowywane w TEMPDB.
Komenda poniżej (uwaga, komenda może rozłączyć wszystkich połączonych użytkowników do bazy konfiguracyjnej):
ALTER DATABASE [NazwaBazyKonfiguracyjnej]
SET READ_COMMITTED_SNAPSHOT ON
WITH ROLLBACK IMMEDIATE;
Jak już jesteśmy przy konfiguracji i poprawie wydajności SQL Servera dla Comarch Optima, warto wziać pod uwagę też poniższe zmiany, które nie są już tak spektakularne, ale poprawią komfort i bezpieczeństwo pracy:
- Max Server Memory – ustawić na 70-80% całego ramu na serwerze, aby SQL nie „zjadł” całego ramu. OPT057
- Optimize for Ad hoc Workloads – ustawić na 1, żeby mniej zużywał plan cache. OPT057
- Max Degree of Parallelism (MaxDOP) – między 1-4 zależnie od ilości rdzeni, ja dałem 4, żeby zapytania te które mają być uruchomione równolegle na 4 rdzeniach. Optima ma dużo małych zapytani, więc nie ma co wrzucać na więcej rdzeni.
- Cost Threshold for Parallelism – między 30-50, żeby tylko ciężkie zapytania były uruchamiane równolegle.
- Page Verify – zmieniamy na CHECKSUM, lepsze wykrywanie korupcji danych.
- Auto Shrink – zmieniamy na OFF, żeby nie robiło nam fragmentacji danych w plikach.
- Liczba plików danych tempdb – tyle ile rdzeni w CPU ale nie więcej niż 8.
- Zawsze pamiętaj aby mieć zautomatyzowany backup, optymalizowanie indeksów i CHECKDB.
