Comarch Optima - optymalizacja bazy MS SQL pod dużą ilość danych

Comarch Optima - optymalizacja bazy MS SQL pod dużą ilość danych
AdamWox
  • Rejestracja: dni
  • Ostatnio: dni
  • Lokalizacja: Jastrzębie-Zdrój
  • Postów: 2180
0

Witam.
Potrzebuje nakierowania, sugestii, narzędzia do optymalizacji bazy danych pod Comarch Optima. Mam klienta, który ma bardzo dużo dokumentów i Optima już nie wyrabia z wyświetlaniem tych dokumentów. Wczoraj nawet doszło do tego, że nie można wystawić korekty do faktury, bo formatka otwiera się 15-20 minut i nie da się jej zapisać.

Comarch robi bardzo dużo jakiś dziwnych rzeczy w tle. O sporo danych odpytuje baze po kilka razy. Prześwietliłem go profilerem, skopiowałem przykładowe zapytanie i w management studio chodzi podobnie, wiadomo, że nieco szybciej, bo w skład Optimy jeszcze wchodzi renderowanie tego przez DevExpressa, ale jednak problem jest po stronie ilości danych.

Na Google'ach znalazłem takie narzędzie
SQLIndexManager

Słyszałem, że indexowanie ma też swoje wady, ale to jest chyba jedyne wyjście z tej sytuacji. Głównie bym się skupił na tabelach transakcyjnych, w których tych danych jest najwięcej.

Może podniesienie SQLa coś da, może najnowsza wersja ma wiecej feature'ów.

Microsoft SQL Server Standard (64-bit) 14.0.3475.1
Windows Server 2019 Standard (10.0)

Ryan_1975
  • Rejestracja: dni
  • Ostatnio: dni
  • Postów: 27
2

Weryfikacja fragmentacji indeksów na bazie i ich odbudowa:

Kopiuj
SELECT 
    dbschemas.[name] as 'Schema', 
    dbtables.[name] as 'Table', 
    dbindexes.[name] as 'Index', 
    indexstats.[avg_fragmentation_in_percent] 
FROM sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, NULL) indexstats 
INNER JOIN sys.tables dbtables on dbtables.[object_id] = indexstats.[object_id] 
INNER JOIN sys.schemas dbschemas on dbtables.[schema_id] = dbschemas.[schema_id]
INNER JOIN sys.indexes AS dbindexes ON dbindexes.[object_id] = indexstats.[object_id] 
    AND indexstats.index_id = dbindexes.index_id 
WHERE indexstats.database_id = DB_ID() AND indexstats.avg_fragmentation_in_percent > 10;


ALTER INDEX ALL ON [nazwa_tabeli] REBUILD;
DBCC DBREINDEX;

Dalej przejrzenie i archiwizacja danych do bazy archiwalnej. Można też zrobić cykliczne zadanie archiwizujące. Nie wiem od kiedy istnieje baza, ale często jest tak, że jak opiekuje się nią 1 osoba to pewnie nigdy nie było wykonywanej archiwizacji i tu można sporo zyskać. Najpierw by trzeba pogadać z biznesem ile prawnie musicie przechowywać jakieś dokumenty np. z tego co kojarzę faktury 5 lat od końca roku kalendarzowego oraz czy polityka na to zezwala.

Weryfikacja planów zapytań. Wtedy np. przepisanie ich lub utworzenie dodatkowych indeksów. Trzeba by się rozejrzeć po wbudowanych narzędziach jak SQL Profiler oraz od SQL Server 2016 jest z tego co kojarzę coś takiego jak Query Store, czyli włączasz sobie zbieranie i np. wracasz po tygodniu i patrzysz jak co chodzi.

Aktualizacja statystyk.

Kopiuj
EXEC sp_updatestats;

Dalej sprawdzenie RAM i CPU SQL Servera. Przy czym z tego co wiem na Standard są limity, ale warto zobaczyć czy Max Server Memory jest odpowiednio ustawione.

Ustawienie zadań cyklicznych na czyszczenie dzienników transakcji oraz reorganizowanie indeksów jak wyżej. Regularne kopie dziennika transakcji mogą pomóc w zmniejszeniu jego rozmiaru.

Sprawdzenie czy wersja samej Optimy jest aktualna. Może nowsze wersje coś poprawiają wydajnościowo. Dodatkowo jeśli aplikacja jest odpalana desktopowo lub przez przeglądarkę to warto wyczyścić tempy i cache.

Jeśli jest wielu użytkowników serwera to warto sprawdzić maksymalną ilość połączeń do bazy. Jak jest blisko limitu to mogą być przeciążenia. Warto zerknąć na maksymalną liczbę połączeń oraz czas życia danego połączenia.

Na koniec jeśli wszystko powyższe zawiedzie to najlepiej się skonsultować z Comarchem pewnie trochę zabulić i powiedzą fachowo co i jak można jeszcze od strony samej aplikacji konfigurować.

99xmarcin
  • Rejestracja: dni
  • Ostatnio: dni
  • Postów: 2420
3

Ja bym raczej sprawdził IO i CPU na serwerku DB.
Danych pewnie przez ostatnie lata przyrosło a sprzentu pewnie nikt nie upgrade'ował.

Query się wlecze, to odpal query execution plan i zobacz co dokładnie: brak indeksu, IO, czy może po prostu za dużo danych? Może ktoś nawrzucał skanów po 10MB do bazy i teraz muli.

Generalnie query execution plan & system staty to twoi przyjaciele. Warto jeszcze sprawdzić czy ta degradacja nastąpiła nagle (może ktoś coś zmienił "poprawił") czy też następowała powoli. Jeżeli nastąpiła nagle sprawdził bym czy ostatnio nie było jakichś zmian w sprzęcie, sieci, konfiguracji bazy lub importu danych/restore backupu.

Warto jeszcze rzucić okiem w system logi na win oraz logi bazy danych, może tam będzie coś ciekawego. Może być tak że do DB łączy się nowa apka i młotkuje bazę N+1 bo pisali to juniorscy?

https://www.tatvasoft.com/blog/optimize-sql-query/

Zarejestruj się i dołącz do największej społeczności programistów w Polsce.

Otrzymaj wsparcie, dziel się wiedzą i rozwijaj swoje umiejętności z najlepszymi.