1

OPT060 – Comarch ERP Optima w środowisku terminalowym

Data aktualizacji: 28-11-2018

Wprowadzenie

Biuletyn przedstawia informacje na temat konfiguracji programu Comarch ERP Optima oraz środowiska terminalowego do pracy z programem, biorąc pod uwagę parametry łącza, konfigurację serwera, konfigurację klienta, podłączanie urządzeń współpracujących z programem a także ustawienia po stronie aplikacji Comarch ERP Optima. Biuletyn zakłada, że na serwerze terminali uruchamiana jest sama Comarch ERP Optima. Natomiast baza danych znajduje się na osobnym serwerze, którego konfiguracja jest poza zakresem niniejszego dokumentu. Biuletyn zawiera również informacje na temat urządzeń współpracujących z Comarch ERP Optima oraz sposobu ich konfiguracji w środowisku terminalowym.

Parametry łącza

Przepustowość łącza

Protokół RDP ma stosunkowo niskie wymagania, jeżeli chodzi o przepustowość. Oczywiście zależą one od parametrów sesji terminalowej czyli ilości kolorów, włączonych opcji w kliencie zdalnego pulpitu (szczegóły w p. 4 – Konfiguracja po stronie klienta) oraz rodzaju wykonywanej pracy. Z praktycznego punktu widzenia można przyjąć, że jedno połączenie przez pulpit zdalny przy głębi kolorów 16 bit zajmuje około 80 kbit/s. Może się ono wahać od 5 kbit/s do około 150 kbit/s.
Przy czym kalkulacje wielkości łącza potrzebnego dla serwera terminali należy przeprowadzić w oparciu o parametr Upload, czyli transfer „do Internetu”. Ten parametr ma zwykle u dostawców Internetu znacząco niższą wartość od „Download”, czyli szybkości pobierania danych „z Internetu”.
Czyli dla 10 równocześnie pracujących użytkowników należy zabezpieczyć łącze z parametrem Upload rzędu 800 kbit/s. Przepustowość łącza można przetestować za pomocą narzędzi online dostępnych w Internecie np. https://www.predkosc.pl/info/

Przykładowa strona pozwalająca na przetestowanie łącza internetowego

Jakość łącza

Na wydajność pracy ma również wpływ jakość łącza to znaczy wielkość opóźnień pakietów, wariancja opóźnień (jitter) oraz straty pakietów. Dobre jakościowo łącze, to łącze o opóźnieniach poniżej 100 ms, wariancją opóźnień do kilkunastu ms, straty pakietów w okolicach zera.

Konfiguracja po stronie serwera usług terminalowych

Wytyczne do konfiguracji sprzętowej dla serwera usług terminalowych

Przy doborze konfiguracji sprzętowej dla serwera terminali należy przede wszystkim zwrócić uwagę na mocne procesory. Zalecane byłyby procesory Xeon ze rdzeniami nowej generacji (Nehalem lub nowsze) oraz częstotliwością taktowania przynajmniej 2,6 GHz lub odpowiadające im procesory AMD. Ilość rdzeni zależna jest od ilości użytkowników. Zgrubnie szacując na jednym rdzeniu można uruchomić około 5 użytkowników. Przy czym jeden rdzeń należy odliczyć dla systemu operacyjnego. Ilość pamięci RAM również powinna być dostosowana do ilości użytkowników przeznaczając średnio około 500 MB dla jednego użytkownika, dodatkowo przynajmniej 2 GB na potrzeby systemu Windows plus około 1-2 GB rezerwowe. Dodatkowo należy wziąć pod uwagę, że zbyt mała ilość pamięci RAM może doprowadzić do intensywnego wykorzystania dysku twardego, co ostatecznie doprowadza do bardzo znaczącego spadku wydajności całego systemu, włączając w to działające na nim aplikacje. Do niezawodnej pracy serwera terminali zalecane jest uruchomienie dysków w konfiguracji RAID 1, czyli mirroring. Zastosowanie szybszych dysków (Serial SCSI 15 000 RPM lub SSD) pozwoli na szybsze wczytywanie binariów aplikacji, a przez to korzystnie wpływa na jej wydajność.

Podsumowując dla 10 użytkowników powinno się zabezpieczyć trzy procesory lub jeden czterordzeniowy oraz około 7-8 GB pamięci RAM.

Wersja serwera terminala

Z wersji na wersję protokół RDP jest udoskonalany dlatego zalecamy używanie najnowszej jego wersji 8.0 dostępnej w serwerze Windows Server 2012. Poniższa tabela przedstawia różnice w ilości przesyłania danych (w Bajtach) przez takich samych klientów w zależności od wersji protokołu:

Wersja klienta zdalnego pulpituSystem operacyjny po stronie serwera BajtyZmniejszenie ilości przesłanych danych przy użyciu protokołu RDP 6.1
RDC 6.1 (Windows Server 2008)Windows Server 20087559075
RDC 5.2 (Windows Server 2003)Windows Server 200894503510.2
RDC 5.1 (Windows XP)Windows Server 2008111856330.32

Źródło: Remote Desktop Protocol Performance
(http://download.microsoft.com/download/4/d/9/4d9ae28534314335a86e969e7a146d1b/RDP_Performance_WhitePaper.docx)

Konfiguracja serwera terminali

Na serwerze terminali należy wyłączyć wszystkie nieużywane opcje i usługi w systemie. Szczególnie nie jest zalecane włączanie funkcji „Środowisko pulpitu” (ang. Desktop Experience), ustawianie tapet na pulpicie oraz uruchamianie aplikacji, które obciążają procesor i pamięć serwera.

Ograniczenie maksymalnej głębi kolorów oraz blokowanie mapowanych urządzeń

W konfiguracji serwera terminali w celu zmniejszenia wymaganego pasma dla połączenia można ograniczyć głębię kolorów do 15 bit. Oznacza to, że użytkownicy mimo innych ustawień w kliencie zdalnego pulpitu będą mogli zestawić połączenie z maksymalną zdefiniowaną ilością kolorów. Dodatkowo dobrze jest zablokować mapowanie nieużywanych dodatkowych urządzeń takich jak porty COM, dyski lokalne klienta i inne ze względu na to, że każde z takich mapowań generuje dodatkowy ruch sieciowy.

Serwer Usług Terminalowych – ustawienia klienta

Konfiguracja sesji użytkowników

W konfiguracji serwera warto również dbać o to, aby na serwerze nie „wisiały” nieużywane, rozłączone sesje terminalowe, które zajmują zasoby serwera w szczególności pamięć. Można to zrobić ustawiając parametry sesji użytkowników na zakładce Sesja. Przykładowe wartości znajdują się na zrzucie ekranu, przy czym należy je dostosować do specyfiki pracy w danym środowisku.

Serwer Usług Terminalowych – ustawienia sesji

Na powyższym zrzucie ekranu ustawienia są wyszarzone, ponieważ zostały ustawione z poziomu polityki grupy.

Mapowanie drukarek sieciowych

Dla systemów Windows Server 2008 oraz Windows Server 2008 R2 zalecanym sposobem mapowania drukarek jest domyślny mechanizm EasyPrinting. Nie wymaga on żadnych dodatkowych czynności na serwerze terminali natomiast komputer klienta musi mieć zainstalowany Microsoft .Net Framework 3.0 SP1 oraz aplikację do połączenia przez pulpit zdalny (Remote Desktop Connection) minimum w wersji 6.1 (aplikacja ta jest składnikiem systemu, ale może wymagać uaktualnienia).

W przypadku systemu Windows Server 2003, aby możliwe było mapowanie drukarki z klienta konieczna jest instalacja wszystkich sterowników drukarek używanych przez klienta. Dodatkowo, aby mapowanie powiodło się konieczna jest dokładna zgodność w nazwie sterownika po stronie klienta i serwera. W przypadku problemów można skorzystać z rozwiązania zawartego w dokumencie http://support.microsoft.com/kb/239088.

Zmiana algorytmu kompresji

Z poziomu zarządzania politykami grup (polecenie gpedit.msc) można zmienić domyślny algorytm kompresji, który bazuje na konfiguracji sprzętowej komputera. Pozwala to na samodzielne dostosowanie parametrów protokołu do warunków środowiska i konfiguracji komputera. Polityka grup pozwalająca na zmianę algorytmu kompresji na anglojęzycznych systemach nazywa się „Konfiguruj kompresję danych RemoteFX”.

Konfiguracja komputera\ Szablony Administracyjne\ Składniki systemu Windows\ Usługi pulpitu zdalnego\ Host sesji pulpitu zdalnego\ Środowisko sesji zdalnej: Konfiguruj kompresję danych RemoteFX

Mamy możliwość wprost wskazać, czy algorytm ma używać jak najmniejszych zasobów sieciowych kosztem pamięci i procesora (Optimized to use less network bandwidth), czy ma jak najmniej obciążać procesor i pamięć kosztem większego zapotrzebowania na pasmo sieciowe (Optimized to use less memory). Jest też możliwość wybrania konfiguracji zbalansowanej pomiędzy tymi dwoma opcjami (Balanced memory and network bandwith) oraz wyłączenie kompresji RDP (Do not use RDP compression algorithm).

Okno konfiguracji kompresji danych RemoteFX dla sesji zdalnych

Konfiguracja po stronie klienta

Analogicznie jak w przypadku serwera najlepiej jest korzystać z najnowszej wersji klienta zdalnego pulpitu. Dla połączeń z Windows Server 2008 R2 powinien to być klient o wersji minimum 6.1, a najlepiej w wersji 7.0.

Parametry połączenia do serwera terminali po stronie klienta

Głębia kolorów oraz mapowanie dodatkowych urządzeń

Dla połączeń przez Internet zalecane jest użycie ograniczonej liczby kolorów, czyli trybu High Color (15 bit lub 16 bit). Ilość kolorów można ustawić w kliencie połączenia przez pulpit zdalny na zakładce Ekran.

Właściwości klienta RDP – ustawienia głębi kolorów w sesji zdalnej

W bardzo trudnych warunkach można rozważyć połączenia w trybie 256 kolorów (głębia kolorów 8 bit).

W tym celu należy zapisać ustawienia połączenia w pliku, a następnie otworzyć plik notatnikiem i zmodyfikować parametr: Session bppi:16 ustawiając: session bpp:i:8

Właściwości klienta RDP – zapis ustawień połączenia

Comarch ERP Optima w 256 kolorach przy standardowej skórce

Dodatkowo w celu uzyskania lepszej wydajności zaleca się zmianę skórki programu na UltraFlat.

Zablokowanie mapowania wszystkich nieużywanych elementów takich jak porty, dyski, karty inteligentne, czy inne urządzenia Plug and Play ma również wpływ na zmniejszenie przesyłania dodatkowych danych, a przez co przyspiesza wyświetlanie aplikacji na wolnych łączach.

Właściwości klienta RDP – Mapowanie Zasobów lokalnych

Parametry graficzne w połączeniu zdalnego pulpitu

Znaczący wpływ na ilość zajętego pasma sieciowego przez połączenie pulpitu zdalnego mają parametry związane z graficznymi efektami w ramach sesji. Można je dostosować na zakładce „Wrażenia” klienta zdalnego pulpitu, są one tam powiązane z ustawieniami szybkości posiadanego łącza, ale można je również osobno zaznaczać i odznaczać.

Właściwości klienta RDP – Ustawienia efektów graficznych

W celu osiągnięcia najlepszej wydajności przy pracy przez wolniejsze łącza zaleca się wyłączenie wszystkich lub prawie wszystkich parametrów na zakładce „Wrażenia” zaczynając od góry, czyli od parametrów „Tło pulpitu” oraz „Wygładzanie czcionek”.

Przykładowo opcja wygładzania czcionek może zwiększyć zapotrzebowanie na przepustowość od ponad 50% nawet do prawie 800%.

Zapotrzebowanie na pasmo przy wykorzystaniu wygładzania czcionek ClearType oraz bez stosowania tego mechanizmu.

Typ użytkownikaTekst ClearType [kbit/s]Normalny tekst [kbit/s]Zwiększenie zapotrzebowania na pasmo przy użyciu ClearType
Pisanie i przewijanie35.622.5657.64 %
Przewijanie25.447.04260.92 %
Internet Explorer1410.4157.68794.52 %

Żródło: Remote Desktop Protocol Performance
(http://download.microsoft.com/download/4/d/9/4d9ae28534314335a86e969e7a146d1b/RDP_Performance_WhitePaper.docx)

Pobieranie licencji

Program pracujący na komputerze usług terminalowych pobiera licencje w ten sam sposób co aplikacja pracująca „Stacjonarnie”, czyli instalacja taka jest wyposażona w Comarch ERP Menadżer Licencji (ML).
Specyfiką usług terminalowych jest sposób zamykania sesji na serwerze usług terminalowych, np.: gdy host który pracował z sesją stracił połączenie do sesji na terminalu bądź też przerwał to połączenie celowo, to w obydwu przypadkach na serwerze terminali pozostaje pracująca sesja razem z programami uruchomionymi w niej, w tym z Comarch ERP Optima. Konfiguracja usług terminalowych pozwala na zarządzanie takimi sesjami na dwa sposoby – pozwala na ponowne podłączenie się do sesji z hosta, który utracił z nią połączenie (lub operatora który jest zalogowany w sesji) bądź pozwala na automatyczne zamknięcie takiej sesji. Problemem może okazać się automatyczne zamknięcie sesji, które zamyka aplikacje pracujące w tej sesji. Licencje które zostały przydzielone Comarch ERP Optima, która została zamknięta w taki sposób będą wciąż licencjami zajętymi, zmniejszającymi ilość dostępnych licencji w instalacji. Żeby uniknąć tego problemu wystarczy w Menu Widok Comarch ERP Optima wyłączyć parametr: „Potwierdzenie zamknięcia programu”. Program z tak ustawionym parametrem w automatycznie zamykanej sesji wyloguje zajmowane przez siebie licencje z (ML).

Konfiguracja interfejsu w Comarch ERP Optima

W konfiguracji Comarch ERP Optima przygotowano specjalne ustawienia pozwalające na uzyskanie lepszej wydajności przy słabszych parametrach połączenia do serwera terminali.

Ustawienie skórki

Skórkę programu można ustawić z poziomu menu Widok po zalogowaniu do programu.

Zmiana skórki w programie Comarch ERP Optima

Wyłączenie animacji

Również w menu Widok po zalogowaniu do programu można wyłączyć animacje w programie.

Zmiana Efektów animacji w programie Comarch ERP Optima

Zwinięcie graficznego menu (ribbon)

Obszar graficznego menu (ribbon) jest najdłużej odrysowywany dlatego jego wyłączenie na wolnym łączu powinno poprawić szybkość ściągania obrazu aplikacji z serwera.

Comarch ERP Optima – praca z rozwiniętą wstążką

Comarch ERP Optima – praca ze zwiniętą wstążką

Drukarki fiskalne w usługach terminalowych

System Comarch ERP Optima posiada możliwość pracy w środowisku terminalowym. Istotnym elementem pracy tego systemu jest możliwość korzystania z drukarek fiskalnych. Przepisy wymagają od użytkownika umieszczenia drukarek fiskalnych na stanowisku, gdzie odbywa się sprzedaż fiskalna.

W środowisku terminalowym oznacza to podłączenie drukarki fiskalnej do komputera, na którym pracuje klient terminala. W przypadku systemów Microsoft Windows Terminal Serwer do podłączenia drukarki fiskalnej do portu COM stanowiska terminalowego można wykorzystać stworzone przez nas oprogramowanie.

Oprogramowanie pozwala na przekazanie do końcówki terminala danych dla drukarki fiskalnej poprzez tak zwany kanał wirtualny. Aby przekazywanie danych do drukarki mogło mieć miejsce zarówno po stronie końcówki terminala jak i po stronie serwera musi być zainstalowane odpowiednie oprogramowanie, które można użytkować zgodnie z zasadami podanymi w punkcie 7.3.

Instalacja i konfiguracja komponentów na serwerze

Program Comarch ERP Optima nawiązują połączenie z drukarką fiskalną poprzez API udostępnione przez bibliotekę sterownika fiskalnego. Instalacja sterowników odbywa się wraz z instalacją programu Comarch ERP Optima. Konfiguracja programu do współpracy z drukarką podłączoną do konsoli terminala odbywa się, poprzez wybranie odpowiednio zmodyfikowanego sterownika przeznaczonego do pracy w TS. W konfiguracji programu „Comarch ERP Optima System / Konfiguracja / Stanowisko / Ogóle / Drukarka fiskalna” należy wybrać odpowiedni dla drukarki fiskalnej sterownik z dopiskiem „terminal” w nazwie.

Instalacja komponentów na końcówce terminala

Po stronie końcówki terminala umieszczone są komponenty zajmujące się obsługą kanału wirtualnego oraz połączeniem z drukarką fiskalną.
Pliki zawierające instalatory komponentów znajdują się w katalogu „Drukowanie Fiskalne w usługach terminalowych – Client” (na płycie instalacyjnej programu w katalogu Dodatki), lub bezpośrednio w katalogu z programem Comarch ERP Optima. Plik OnlineFP.exe zawiera instalator odpowiedni dla systemów 32 i 64 bitowych.

Aby zainstalować obsługę terminalowych drukarek fiskalnych należy:

1. Plik OnlineFP.exe przegrać na końcówkę terminala.
2. Przeprowadzić instalację obsługi sterowników terminalowych na końcówce. Użytkownik Windows, który instaluje obsługę sterowników, musi mieć uprawnienia administratora.

Oprogramowanie po stronie klienta składa się z plików obsługujących kanał wirtualny i z samych sterowników do drukarek.
Wszystkie pliki kopiowane są do katalogu wskazanego podczas instalacji. Sterowniki drukarki nawiązują połączenie z portem COM wybranym w konfiguracji programu pracującego po stronie pulpitu zdalnego.

Należy zwrócić uwagę również na następujące aspekty:

1. Mechanizm komunikacji z drukarkami fiskalnymi nie wykorzystuje mapowania portów COM w samej usłudze terminalowej.
2. Przy aktualizacji wersji programu Comarch ERP Optima zaleca się również aktualizację sterowników na końcówce terminala. Odinstalowanie z poziomu panelu sterowania programu Comarch ERP Sterowniki i usługi terminalowe i zainstalowanie aktualnej wersji z pliku OnlineFP.exe

Po prawidłowo wykonanej instalacji na końcówce terminala i konfiguracji komponentów na serwerze można wykonać test połączenia z drukarką z poziomu konfiguracji programu.

Licencje

Komponenty do współpracy z drukarką fiskalną poprzez usługi pulpitu zdalnego wymagają licencji na „Fiskalny driver terminalowy”.
Licencje są pobierane przez Comarch ERP Optima w sesji terminalowej w momencie wywołania pierwszej operacji chronionej licencją. Są to: fiskalizacja i wydruk raportów fiskalnych. Licencje są zwalnianie przy wylogowaniu się operatora z programu.

Uwaga

Do prawidłowego pobierania licencji wymagane jest wprowadzenie bezpośrednio do programu nazwy serwera klucza.

W sytuacji, gdy baza konfiguracyjna znajduje się na tym samym serwerze, gdzie pracuje menadżer licencji (ML), program nie wymaga wprowadzania nazwy serwera klucza – domyślnie szuka ich na serwerze gdzie znajduje się baza konfiguracyjna. Dla potrzeb komponentów, o których mówi ten artykuł nazwa takiego serwera zawsze musi być wprowadzona. Informację tą wprowadzamy w oknie logowania w polu Serwer Klucza.

Schemat połączenia do drukarki fiskalnej

Połączenie drukarki fiskalnej w sesji terminalowej

Podłączenie kolektorów i kas fiskalnych

Komunikacja z tego typu urządzeniami odbywa się poprzez mapowanie portów COM pomiędzy stacją roboczą a sesją na komputerze usług terminalowych, na które pozwala protokół RDP. Z pracą tak podłączonych urządzeń wiążą się niekiedy kłopoty z czasem przesyłania danych z podpiętego urządzenia (z tego powodu dla drukarek fiskalnych wprowadzone są dodatkowe kanały przesyłania danych).
Aby mapowanie urządzeń było możliwe w sesji terminalowej należy:

Po stronie serwera:
Sprawdzić czy mapowanie portów COM jest załączone w konfiguracji serwera usług terminalowych (Terminal Server Configuration)

Serwer Usług Terminalowych – mapowanie portów

Po stronie klienta:
Załączyć parametr mapowania portów (LPT, COM) (ustawiamy to w oknie „Podłączanie pulpitu zdalnego” Opcje: zakładka Zasoby lokalne/Lokalne urządzenia i zasoby/Porty)

Właściwości klienta RDP – Mapowanie portów

Konfiguracja z poziomu programu wykonywana jest identycznie przy podłączeniu urządzenia bezpośrednio do komputera, mapowane porty COM będą widoczne jako kolejne porty na liście dostępnych portów w systemie.

Drukowanie na drukarki i urządzenia przez wydruki XML (tekstowe/inne)

Wydruki XML (tekstowy/inne) wysyłają rezutlat wydruku zawierający dane oraz kody sterujące dla urządzenia bezpośrednio do portu (LPT/USB/COM) przypisanego do urządzenia.

Z reguły wysłanie tych danych odbywa się metodą kopiowania plików do określonego portu. Może to powodować problemy przy przesyłaniu tych danych z sesji terminalowej do urządzenia.

Uruchamiając wysłanie danych z tych wydruków w konfiguracji połączenia należy włączyć opcję mapowania portów, identycznie jak w punkcie Podłączenie kolektorów i Kas Fiskalnych. Ta metoda nie pozwala jednak na wysyłanie danych do urządzeń pracującyh na portach USB, bywa też zawodna.

Jeśli napotykamy na problem przesyłania danych bezpośrednio do mapowanych portów możemy, zastosować dodatkowy mechanizm przesyłania danych z wydruku do strumienia danych RAW sterownika drukarki, który został zmapowany w sesji. Opcja mapowania drukarek w konfiguracji połączenia sesji terminalowej musi być włączona.

Do przesyłania danych do strumienia drukarki używamy dodatkowego programu RawPrint.exe.
Pozwala on na przesłanie pliku utworzonego w sesji do strumienia drukarki – jako parametr podajemy nazwę pliku oraz nazwę drukarki w systemie Windows:

RawPrint.exe “Oki ML3320 (from PCBIURO) in session 1” PlikDanych.dat

Uruchomienie wydruku w takim trybie wykonujemy zmieniając sekcję [RUN] w definicji wydruku XML (od wersji 2013.6. możliwe jest przekazywanie parametrów do programu uruchamianego w sekcji RUN). W tej sekcji wprowadzamy komendę uruchamiającą program RawPrint lub kombinacje uruchomienia programu PrintTxt
i RawPrint. Połączenie uruchomienia tych programów możemy zrealizować za pomocą pliku bat lub cmd umieszczonego w katalogu roboczym Comarch ERP Optima. W sekcji [RUN] podajemy nazwę pliku z komendami, np wykonaj_wydruk.bat:

Sekcja [RUN] w definicji wydruku
Program Printtxt w takiej sytuacji musi być skonfigurowany tak żeby wynik drukowania był zapisywany do pliku tekstowego, plik ten będzie wysyłany przez program RawPrint do drukarki docelowej.

Czytniki kodów kreskowych EAN

Program obsługuje czytniki kodów kreskowych podłączane szeregowo z klawiaturą. Czytniki te będą działać w sesji terminalowej bez dodatkowej konfiguracji.

Skanery dokumentów do współpracy z modułem OBD

W programie Comarch ERP Optima uruchamianej przez terminal jest możliwość podłączenia skanera. W tym celu należy zainstalować na końcówce sieciowej aplikacji OnlineFP.exe i w konfiguracji Optimy w gałęzi Stanowisko \ Ogólne \Parametry i załączyć parametr : Wymiana danych z komputerem lokalnym w pracy Terminalowej.

Po wykonaniu powyższych czynności i przelogowaniu w programie Comarch ERP Optima, Skaner powinien być dostępny z poziomu modułu Obieg Dokumentów i pracować jak w sesji lokalnej.

Wysyłanie i odbieranie plików przez kanały wirtualne

W programie Comarch ERP Optima uruchamianej przez terminal jest możliwość wysyłania i odbierania plików na końcówce sieciowej w następujących funkcjach programu:
Funkcje w programie:
Eksport ustawień personalizacji.
Import urzędów,
Eksport wydruków.
Eksporty przelewów
Eksport i import kontrahentów
Export i import cennika
Eksporty do ECOD
Eksport i import danych kadrowych
Eksport wypłat
Eksport deklaracji ZUS do Płatnika
Eksport deklaracji PFRON do SODiR
Import czasu pracy z czytników RCP
Import z pliku KEDU
Eksport/import ustawień operatora.

Funkcje są dostępne w Comarch ERP Optima po zainstalowaniu na końcówce sieciowej aplikacji OnlineFP.exe i załączeniu w konfiguracji programu w gałęzi Stanowisko \ Ogólne \ Parametry parametru : Wymiana danych z komputerem lokalnym w pracy terminalowej.
Dla pozostałych przypadków eksporty plików z programu wykonywane są na dyski serwera usług terminalowych, chyba że przy połączeniu terminalowy mapujemy dyski stacji lokalnej, to wówczas możemy pliki zapisać w tych lokalizacjach.

Pozostałe uwagi dotyczące konfiguracji Comarch ERP Optimy pracującej w usługach terminalowych

Uruchamianie Comarch ERP Przypominacz – program uruchomi się podczas logowania na serwer terminalowy, jeżeli nie było aktywnej sesji logującego się użytkownika; jeżeli użytkownik podłącza się pod istniejącą sesję, to program się nie uruchomi.

Podpis elektroniczny dla e-maili, PDFów, e-Deklaracji – działa po konfiguracji certyfikatów po stronie serwera usług terminalowych bądź dla przekazywanie certyfikatów po stronie stanowiska. I tak:

  • Dla certyfikatów po stronie stanowiska sieciowego musimy zainstalować obsługę kanałów wirtualnych przez aplikację OnlineFP.exe a następnie załączyć w konfiguracji Comarch ERP Optima w gałęzi Stanowisko \ Ogólne \ Parametru parametr : Wymiana danych z komputerem lokalnym w pracy terminalowej.
  • Dla certyfikatów po serwera usług terminalowych certyfikaty klienta muszą być przeniesione na system z usługami terminalowymi. Na terminalu i serwerze należy zainstalować komponenty obsługi podpisu elektronicznego, dostarczane przez jego producenta. W opcjach połączenie zdalnego należy zaznaczyć „Mapuj zasoby lokalne – karty inteligentne”.

Współpraca z programem Płatnik – Możliwa jest na dwa sposoby:

  • Przez tworzenie plików dla płatnika z użyciem kanałów wirtualnych (Program płatnik pracuje po stronie stanowiska sieciowego)-punkt Wysyłanie i odbieranie plików przez kanały wirtualne,
  • Bądź przez instalacje Płatnika bezpośrednio na serwerze ( program Płatnik będzie pracował „po stronie” serwera TS ).


Menadżer Licencji powinien zostać skonfigurowany na komputerze z serwerem SQL, który znajduje się w tej samej sieci lokalnej co serwer terminalowy. Innymi słowy przy połączeniu przez Internet do serwera terminali nie ma możliwość korzystania z licencji po stronie Klienta, czyli Menadżera Licencji zainstalowanego w sieci lokalnej stanowiska, z którego uruchamiamy połączenie pulpitu zdalnego.




OPT057 – Strojenie wydajnościowe baz MS SQL dla Comarch ERP Optima

Data aktualizacji: 28-11-2018

Wprowadzenie

Serwer bazy danych jest centralnym miejscem dla całej instalacji Comarch ERP Optima i ma bardzo duże znaczenie dla wydajnej jej pracy. Dlatego bardzo ważne jest odpowiednie skonfigurowanie serwera zarówno pod względem sprzętowym, doboru właściwego oprogramowania oraz jego ustawień. Dodatkowo z biegiem czasu i działalnością klienta spływają nowe dane słownikowe oraz dokumenty, co powoduje przyrost bazy danych. Ważne jest więc monitorowanie stanu serwera SQL i odpowiednie reagowanie w celu zapewnienia jak najlepszej wydajności.

Niniejszy biuletyn zawiera wytyczne dla konfiguracji serwera bazy danych dedykowanego do pracy z Comarch ERP Optima. Przedstawiono w nim również podstawowe metody diagnozy problemów wydajnościowych oraz sposoby optymalizacji. W ostatnim rozdziale znajduje się obszerny opis cyklicznych czynności administracyjnych, których celem jest utrzymanie serwera SQL w dobrej kondycji. Do biuletynu dołączone są skrypty, które pozwalają zautomatyzować cykliczne czynności administracyjne dla wersji Express serwera SQL.

Planowanie instalacji

Dobór konfiguracji sprzętowej dla serwera bazy danych

Serwer bazy danych jest wrażliwym elementem, którego awaria może spowodować przestój całej firmy oraz duże straty finansowe, dlatego warto zainwestować w markowy, sprawdzony sprzęt. Taki serwer w atrakcyjnych cenach można np. nabyć w ramach Zintegrowanej Oferty Comarch.

Konfiguracja sprzętowa

Przy doborze serwera bazy danych należy zwrócić szczególną uwagę to, aby zapewniał on niezawodną pracę i bezpieczeństwo przechowywanych danych. Dlatego warto, aby jak najwięcej komponentów było nadmiarowych usuwając pojedyncze ogniwa awarii. Czyli dobrze jest zastosować podwójne zasilacze oraz zasilanie awaryjne (UPS) pozwalające na prawidłowe zamknięcie systemu w momencie braku prądu.
Jeżeli chodzi o wydajność to przede wszystkim należy zwrócić na ilość pamięci RAM oraz szybkość podsystemu dyskowego. Procesor zwykle odgrywa mniejsze znaczenie. Jednakże powinien zawierać rdzenie nowej generacji (Intel Nehalem lub lepszy) i taktowaniu przynajmniej 2 GHz.
Im więcej dostępnej pamięci tym lepiej, oczywiście ze względu na koszty, jej ilość musi być dobrana do zapotrzebowania, bazując na wielkości instalacji, czyli ilości użytkowników, wielkości baz danych oraz ich ilości. Orientacyjne ilości pamięci RAM dla różnych konfiguracji zostały podane w Podręczniku konfiguracji dla bieżącej wersji Comarch ERP Optima. Później oczywiście należy obserwować liczniki serwera i sprawdzać, czy nie ma potrzeby jej zwiększenia. Informacje na temat przykładowych liczników, na które warto zwrócić uwagę podano w punkcie 4. Diagnoza problemów wydajnościowych.
Podsystem dyskowy powinien być zabezpieczony przed awariami poprzez odpowiednią konfigurację. Zalecana konfiguracja to przynajmniej Raid 1 (mirror) dla wolumenu obsługującego system oraz w miarę możliwości Raid 10 dla wolumenu przechowującego dane. Dodatkowo należy zwrócić uwagę, aby kontroler dyskowy posiadał podtrzymywanie bateryjne, które umożliwia zastosowanie opcji write-back przyspieszającej działanie podsystemu dyskowego.
Najczęściej przyjmowaną jednostką wydajności podsystemu dyskowego jest IOPS[1] (ang. Input/Output Operations Per Second, IOPS), czyli ilość operacji wejścia wyjścia na sekundę. Jako operację wejścia/ wyjścia rozumie się odczyt lub zapis fragmentu danych, najczęściej o rozmiarze 4 kB.

Poniżej znajdują się orientacyjne dane dotyczące wydajności różnych podsystemów dyskowych:

DyskOrientacyjna wartość IOPS[2]
Dysk Sata 5400~50-80
Dysk Sata 7200 ~75-100
Dysk SAS 10k~140
Dysk SAS 15k~175-210
Dysk SSD~400-1000000[3]

Wymagania co do podsystemu dyskowego zależą od wielkości instalacji to znaczy wielkości bazy oraz ilości równoczesnych użytkowników.

Jako zgrubną zasadę można przyjąć, że dla mniejszych baz danych (<2 GB) należy zarezerwować około 15-25 IOPS dla użytkownika. Natomiast dla większych baz (> 2 GB) dla jednego użytkownika należy przeznaczyć 25-40 IOPS lub więcej.

Jak widać Rozwiązaniem godnym polecenia jest zastosowanie dysków SSD. Przy czym należy pamiętać o zabezpieczeniu ich przed awarią np. poprzez konfigurację RAID 1. Bardziej szczegółowe informacje dotyczące określenia wymagań aplikacji do podsystemu dyskowego można znaleźć w poniższym odnośniku: http://msdn.microsoft.com/en-us/library/ee410782(v=sql.100).aspx

Porównanie wydajności pracy Comarch ERP Optima z dyskami SSD i SATA znajduje się w biuletynie technicznym: OPT076 – Porównanie wydajności HDD vs SSD w Comarch ERP Optima.pdf, który jest dostępny na Indywidualnych Stronach Partnerów (https://www.erp.comarch.pl//partnerzy/default.aspx).

Biura rachunkowe:

Kilka mniejszych baz danych słabiej obciąża serwer niż jedna duża. Dlatego przy skalowaniu serwera SQL dla biura rachunkowego należy przede wszystkim sprawdzić jaka będzie wielkość największej bazy danych i pod nią dobierać konfigurację plus zabezpieczyć dodatkową ilość pamięci RAM współmiernie do ilości baz danych. Raczej nie należy przekraczać ilości 50 baz danych o wielkości do 200 MB na rdzeń procesora.

Edycje serwera SQL

Bardzo duże znaczenie dla wydajnej pracy serwera SQL jest właściwe dobranie edycji serwera SQL. Comarch ERP Optima jest dystrybuowana z darmową serwera SQL o nazwie Express. Edycja ta posiada określone ograniczenia co do możliwości wykorzystania zasobów komputera, na którym jest zainstalowana. Szczegóły znajdują się w poniższej tabeli.

EdycjaMaksymalna ilość pamięci RAM (dla puli buforów)Maksymalna wielkość bazy danychIlość obsługiwanych procesorów
SQL 2008 Express1 GB*4 GB1
SQL 2008 R2 Express1 GB*10 GB1
SQL 2012 / 2014 Express1 GB*10 GB1 (maksymalnie 4 rdzenie)
SQL 2008 R2 Workgroup3 GBBez ograniczeń (524 PB)2
SQL 2008 R2 Standard64 GBBez ograniczeń (524 PB)4
SQL 2012 Standard / BI64 GBBez ograniczeń (524 PB)4 procesory (do 16 rdzeni)
SQL 2014 Standard / BI128 GBBez ograniczeń (524 PB)4 procesory (do 16 rdzeni)

Źródło: http://www.microsoft.com/sqlserver/en/us/product-info/compare.aspx
*Badania niezależne od Producenta pokazują, że wersja Express może wykorzystać maksymalnie 1,4 GB RAM (http://sqlgeek.pl/2010/08/23/pl-sql-server-limity-w-sql-server-2008-r2-express-edition/)

Architektura 32 bit, a 64 bit.

Obecnie obowiązującą architekturą jest architektura 64 bitowa i w miarę możliwości zalecana jest aktualizacja do niej środowisk 32 bitowych, które posiadają ograniczenia związane z ilością adresowanej pamięci, a także różnymi komplikacjami w jej alokacji. W podstawowej konfiguracji proces 32 bitowy może maksymalnie zaadresować 2 GB pamięci, przy zastosowaniu specjalnego przełącznika można tą wartość zwiększyć do 3 GB, ale dzieje się to kosztem ilości dostępnej przestrzeni adresowej dla systemu operacyjnego dlatego należy robić to ostrożnie. Serwer SQL może dodatkowo wykorzystać mechanizm AWE, który pozwala na systemach 32 bitowych wyjść poza zakres 4 GB pamięci. Szczegóły można znaleźć w archiwalnym biuletynie technicznym OPT041-Wydajność Comarch OPT!MA a procesory wielordzeniowe i 64 bitowe, który jest dostępny na stronach walidowanych.
Na systemach 64 bitowych warto zwrócić uwagę, aby instalować również serwer SQL w wersji 64 bitowej ponieważ jego 32 bitowy odpowiednik będzie w stanie wykorzystać jedynie 4 GB z dostępnej pamięci nawet w edycji Standard.
Więcej informacji na temat możliwości wykorzystania pamięci operacyjnej przez poszczególne wersje systemów operacyjnych Windows można znaleźć tutaj:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa366778(v=vs.85).aspx

Konfiguracja serwera SQL

Większość parametrów serwera SQL należy pozostawić bez zmian, ponieważ domyślne wartości są optymalne dla większości warunków pracy. Sugerujemy jednakże zwrócić uwagę na
Maksymalną / Minimalna ilość wykorzystywanej pamięci RAM.

Minimalna i Maksymalna ilość wykorzystywanej pamięci RAM>

Parametr minimalnej i maksymalnej ilości wykorzystanej pamięci RAM odnosi się wyłącznie do jednego z komponentów serwera SQL, czyli puli buforów. Jest to kluczowy element jednakże, przy rezerwowaniu pamięci dla puli buforów należy wziąć pod uwagę również inne składniki samego serwera SQL jak i samego systemu operacyjnego.

Minimum Server Memory

Domyślną wartością parametru Minimum Server Memory jest zero, co oznacza, że serwer będzie dynamicznie zarządzał dostępną pamięcią RAM dla puli buforów. Ustawienie tego parametru powyżej zera oznacza, że serwer SQL nie będzie mógł zwolnić tej pamięci w razie potrzeby. Z drugiej strony w środowisku, gdzie pracuje więcej aplikacji prócz samego serwera SQL może być konieczne zarezerwowanie niezbędnego minimum pamięci, ponieważ niemożność zaalokowania niezbędnego minimum spowoduje konieczność korzystania z pliku wymiany na dysku twardym i znaczną degradację wydajności Serwera SQL. Na komputerach dedykowanych do pracy tylko z serwerem SQL zaleca się pozostawienie domyślnej wartości tego parametru.

Maximum Server Memory

Domyślna wartością tego parametru to: 2147483647 MB, co oznacza że Server SQL będzie chciał zająć całą dostępną pamięć na komputerze. Może to niestety prowadzić do spadku wydajności całego środowiska poprzez to, że pula buforów zajmie pamięć potrzebną do działania systemu operacyjnego lub innych komponentów serwera SQL. Dlatego zaleca się ograniczenie tej pamięci rezerwując niezbędną przestrzeń do działania systemu operacyjnego i pozostałych elementów serwera SQL (oraz ewentualnie dla dodatkowych aplikacji pracujących na tym systemie).

Ustawienia pamięci dla instancji Microsoft SQL Server

Poniżej znajdują się sugestie ustawień parametru Maximum Server Memory (przy założeniu, że na serwerze nie pracują dodatkowe aplikacje oraz inne moduły serwera SQL takie jak wyszukiwanie pełnotekstowe, analizy czy raporty). Dane te oczywiście dotyczą wersji, które nie posiadają wbudowanych ograniczeń tak jak wersja Express. Dla wersji Express biorąc pod uwagę wcześniej podane informacje można ustawić Maximum Server Memory na 1400 MB.

Pamięć fizycznaMaximum Server Memory
2 GB1500 MB
4 GB3200 MB
6 GB4800 MB
8 GB6400 MB
12 GB10000 MB
16 GB13500 MB
24 GB21500 MB

Źródło: http://www.sqlservercentral.com/blogs/glennberry/2009/10/29/suggested-max-memory-settings-for-sql-server-2005_2F00_2008/

Inne parametry

Optimize for Ad hoc Workloads

Włączenie parametru „Optimize for Ad hoc Workloads” pozwala na lepsze wykorzystanie dostępnej pamięci RAM w sytuacji, gdy na serwerze generowane jest wiele zapytań, które nigdy więcej lub bardzo rzadko są uruchamiane ponownie. Parametr ten powoduje, że plany dla zapytań „ad hoc” nie są zapisywane w pamięci podręcznej do późniejszego wykorzystania. Zapisywany jest tylko ich mały fragment, cały plan jest zapisywany dopiero przy powtórnym wykonaniu tego samego zapytania. W ten sposób oszczędzana jest pamięć RAM, przez co może być ona wykorzystana przez serwer SQL do innych celów, a co za tym idzie zwiększa się jego wydajność.

Zaawansowane właściwości serwera SQL – włączony parametr Optimize for Ad hoc Workloads

Zaleca się włączenie tego parametru przy pracy z Comarch ERP Optima. Opcja ta jest dostępna od wersji SQL 2008.

Zajętość pamięci planów dla zapytań można sprawdzić poniższym zapytaniem:

select objtype,
count(*) as number_of_plans,
sum(cast(size_in_bytes as bigint))/1024/1024 as size_in_MBs,
avg(usecounts) as avg_use_count
from sys.dm_exec_cached_plans
group by objtype

Poniższy wynik wskazuje, że plany typu „Adhoc” zajmują 1439 MB pamięci, co jest stosunkowo dużą wartością więc warto włączyć opcję „Optimize for ad hoc workloads”.

Za pomocą komendy:

DBCC FREESYSTEMCACHE('SQL Plans')

można wyczyścić pamięć podręczną planów dla planów typu Adhoc.

Diagnoza problemów wydajnościowych

Temat diagnozy wydajności serwera SQL jest bardzo obszerny, jednakże poniżej wybrano kilka podstawowych wskaźników, które warto sprawdzić, gdy występują problemy wydajnościowe.
Wszystkie poniższe wskaźniki dostępne są z poziomu systemu operacyjnego.
Narzędzia administracyjne \ Monitor wydajności

Nazwa parametruZalecane wartościZalecane działania
Procesor: Czas procesora [%]< 80%Jeżeli wartość tego parametru przynajmniej kilka razy dziennie na dłuższy czas przekracza zalecaną wartość należy zaplanować dołożenie drugiego procesora lub jego wymianę na wydajniejszy
System: Processor Queue Lenght< 2 (dla rdzenia)Jeżeli wartość tego parametru przynajmniej kilka razy dziennie na dłuższy czas przekracza zalecaną wartość należy zaplanować dołożenie drugiego procesora lub jego wymianę na wydajniejszy
Pamięć: Strony/s< 20Zbyt mała ilość dostępnej pamięci RAM
Pamięć: Dostępne bajty> 300Zbyt mała ilość dostępnej pamięci RAM
Dysk fizyczny: Czas dysku [%] (poddzielone przez ilość dysków)< 55%Wysoka wartość tego parametru może wskazywać na nie wystarczająco szybki podsystem dyskowy lub zbyt małą ilość dostępnej pamięci RAM.
Dysk fizyczny: Średnia długość kolejki dysku (podzielone przez ilość dysków)< 2Wysoka wartość tego parametru może wskazywać na nie wystarczająco szybki podsystem dyskowy lub zbyt małą ilość dostępnej pamięci RAM.
(najlepiej w okolicach zera)
SQL Server Buffer: Buffer Cache Hit Ratio> 90%Zbyt mała ilość dostępnej pamięci RAM dla serwera SQL
(najlepiej w granicach 99%)
Page life expectancy> 300Zbyt mała ilość dostępnej pamięci RAM dla serwera SQL

Zbyt mała ilość dostępnej pamięci dla serwera SQL może wynikać z poniższych czynników:

  • Za mało pamięci w serwerze
  • Ograniczenia wersji Express
  • Nieprawidłowo skonfigurowany parametr Max Server Memory
  • Ograniczenia architektury 32 bitowej

Importy dużych dokumentów poprzez pracę rozproszoną lub inne mechanizmy mogą na dłuższy czas blokować dostęp do tabel, a przez co powodować wydłużenie czasu operacji dla pozostałych użytkowników. Dlatego zaleca się, aby szczególnie duże importy były wykonywane poza godzinami pracy innych użytkowników.
Jeżeli jakiś scenariusz działania okazuje się szczególnie wolny prosimy o opisanie go krok po kroku i zgłoszenie go przez System Obsługi Zgłoszeń (SOZ).

Optymalizacja dużych baz danych

Program jest dostosowany do pracy w większości warunków, jednakże niektóre szczególnie duże bazy ze względu na specyficzny rozkład danych w tabelach mogą wymagać dodatkowej optymalizacji. Za duże bazy danych uważamy te, które mają rozmiar rzędu kilku gigabajtów lub więcej. Przed przystąpieniem do poniższych czynności dobrze upewnić się, czy serwer jest prawidłowo skonfigurowany i posiada odpowiednią ilość zasobów.

Wyszukiwanie brakujących indeksów

Microsoft SQL Server posiada wbudowane mechanizmy, które pozwalają określić orientacyjnie jakich indeksów może brakować. W tym celu można uruchomić na serwerze następujące zapytanie:

select d.*
, s.avg_total_user_cost
, s.avg_user_impact
, s.last_user_seek
,s.unique_compiles
from sys.dm_db_missing_index_group_stats s
,sys.dm_db_missing_index_groups g
,sys.dm_db_missing_index_details d
where s.group_handle = g.index_group_handle
and d.index_handle = g.index_handle
order by s.avg_user_impact desc
go

Źrodło: http://www.google.pl/url?sa=t&rct=j&q=performance_tuning_waits_queues.doc&source=web&cd=1&ved=0CFkQFjAA&url=http%3A%2F%2Fdownload.microsoft.com%2Fdownload%2F4%2F7%2Fa%2F47a548b9-249e-484c-abd7-29f31282b04d%2FPerformance_Tuning_Waits_Queues.doc&ei=IrjYT__PAcXk4QSOxJzRAw&usg=AFQjCNFRIebSlMLnry8gH99CQklhdmokJw

Zapytanie to najlepiej uruchomić po dłuższej pracy użytkowników wykonujących swoje zadania z Comarch ERP Optima w szczególności w obszarach, gdzie zauważają problemy wydajnościowe. Należy pamiętać, że dane o brakujących indeksach są usuwane po restarcie serwera SQL.
Przykładowy wynik powyższego zapytania (pominięto kilka kolumn, aby zachować czytelność).

Po pierwsze patrzymy na kolumny avg_user_impact oraz avg_total_user_cost, podają one zysk jaki można uzyskać przy zastosowaniu danego indeksu. Pierwszy z nich avg_user_impact wskazuje na procentową poprawę w zmniejszeniu kosztu wykonania zapytań użytkownika . Drugi natomiast avg_total_user_cost podaje całkowity zysk w koszcie wykonywanych przez użytkownika zapytań.
Należy mieć również świadomość, że podejście to ma również swoje ograniczenia. Najbardziej istotne z nich jest takie, że podane dane należy traktować jako sugestię, a nie jako konieczność. Pozostałe ograniczenia podane są tutaj: http://msdn.microsoft.com/en-us/library/ms345485(v=sql.105).aspx

Poniżej znajduje się skrypt używany przez Dział Wsparcia Microsoft:
(http://msdn.microsoft.com/en-us/library/ms345421.aspx)

PRINT 'Missing Indexes: '
PRINT 'The "improvement_measure" column is an indicator of the (estimated) improvement that might '
PRINT 'be seen if the index was created. This is a unitless number, and has meaning only relative '
PRINT 'the same number for other indexes. The measure is a combination of the avg_total_user_cost, '
PRINT 'avg_user_impact, user_seeks, and user_scans columns in sys.dm_db_missing_index_group_stats.'
PRINT ''
PRINT '-- Missing Indexes --'
SELECT CONVERT (varchar, getdate(), 126) AS runtime,
mig.index_group_handle, mid.index_handle,
CONVERT (decimal (28,1), migs.avg_total_user_cost * migs.avg_user_impact * (migs.user_seeks + migs.user_scans)) AS improvement_measure,
'CREATE INDEX missing_index_' + CONVERT (varchar, mig.index_group_handle) + '_' + CONVERT (varchar, mid.index_handle)
+ ' ON ' + mid.statement
+ ' (' + ISNULL (mid.equality_columns,'')
+ CASE WHEN mid.equality_columns IS NOT NULL AND mid.inequality_columns IS NOT NULL THEN ',' ELSE '' END + ISNULL (mid.inequality_columns, '')
+ ')'
+ ISNULL (' INCLUDE (' + mid.included_columns + ')', '') AS create_index_statement,
migs.*, mid.database_id, mid.[object_id]
FROM sys.dm_db_missing_index_groups mig
INNER JOIN sys.dm_db_missing_index_group_stats migs ON migs.group_handle = mig.index_group_handle
INNER JOIN sys.dm_db_missing_index_details mid ON mig.index_handle = mid.index_handle
WHERE CONVERT (decimal (28,1), migs.avg_total_user_cost * migs.avg_user_impact * (migs.user_seeks + migs.user_scans)) > 10
ORDER BY migs.avg_total_user_cost * migs.avg_user_impact * (migs.user_seeks + migs.user_scans) DESC
PRINT ''
GO

Przygotowuje on od razu definicję indeksu wraz z przykładową nazwą sortując indeksy po polu „miara poprawy”, które jest wyliczane biorąc pod uwagę wspomniane wcześniej kolumny: avg_total_user_cost, avg_user_impact, oraz dodatkowo user_seeks i user_scans z sys.dm_db_missing_index_group_stats.

Uwaga

Należy przygotować skrypt dodający oraz usuwający dodawane indeksy, ponieważ dodatkowe indeksy uniemożliwią wykonanie konwersji do nowej wersji programu. Po skonwertowaniu bazy można na nowo dodać przygotowane indeksy

Uwaga

Dodane indeksy mogą mieć negatywny wpływ na operacje dodawania, aktualizowania i usuwania rekordów w bazie, dlatego należy przetestować ich wpływ na całościowe funkcjonowanie programu.

Database Engine Tuning Advisor

Pełne wersje Microsoft SQL Server posiadają dodatkowe narzędzie o nazwie Database Engine Tuning Advisor. Pozwala ono również na dodanie brakujących indeksów na podstawie zapisanego wcześniej ruchu SQL. Ruch ten można zapisać za pomocą innego narzędzia Microsoft SQL Server Profiler, które również jest dostępne w pełnej wersji serwera SQL.
W skrócie proces optymalizacji można przedstawić w poniższych krokach:

  • Zapis ruchu za pomocą Microsoft SQL Server Profiler
  • Przygotowanie optymalizacji w Database Engine Tuning Advisor
  • Zapis rekomendacji
  • Przygotować plik usuwający dodatkowe indeksy i statystyki
  • Utworzenie dodatkowych indeksów i statystyk

Zapis ruchu za pomocą Microsoft SQL Server Profiler

Po wyborze nowego trace’a należy wskazać szablon Tuning, zaleca się zapisać plik od razu na dysk i ograniczyć jego rozmiar np. do 100 MB. Zaznaczony domyślnie parametr Enable file rollover powoduje utworzenie nowego pliku po osiągnięciu zadanego limitu. Zbyt duże pliki znacząco zwiększają czas analizy przez Database Engine Tuning Advisor.

Przygotowanie optymalizacji w Database Engine Tuning Advisor

Po zakończeniu zapisu ruchu przechodzimy do Database Engine Tuning Advisor.
Na pierwszej zakładce „General” nowej sesji wskazujemy plik (File) jako źródło ruchu do optymalizacji oraz podajemy bazę do analizy. Na drugiej zakładce „Tuning Options” pozostawiamy domyślne parametry.

W celu uruchomienia analizy klikamy ikonę Start Analysis (menu Actions \ Start Analysis)

Zapis rekomendacji

Po zakończonej analizie otrzymujemy szacowany wzrost wydajności oraz rekomendacje co do założenia dodatkowych indeksów i statystyk. Przygotowane rekomendacje należy zapisać w pliku poprzez przejście do menu Action \ Save Rekommendations.
Z tak przygotowanych rekomendacji można wybrać kilka lub wszystkie indeksy i statystyki, jednakże należy pamiętać, że każdy dodatkowy indeks będzie spowalniał operacje dodawania, aktualizowania i usuwania rekordów w tabeli, której on dotyczy. Następnie wybrane indeksy i statystyki należy zapisać w skrypcie nadając im nazwy, które będą łatwe do identyfikacji. Na koniec należy również przygotować skrypt, który będzie usuwał niestandardowe indeksy i statystyki, ponieważ trzeba je usuwać przed przystąpieniem do konwersji bazy danych. Po zakończeniu konwersji można je ponownie dodać.

Uwaga

Należy przygotować skrypt dodający oraz usuwający dodawane indeksy, ponieważ dodatkowe indeksy uniemożliwią wykonanie konwersji do nowej wersji programu. Po skonwertowaniu bazy można na nowo dodać przygotowane indeksy.

Uwaga

Dodane indeksy mogą mieć negatywny wpływ na operacje dodawania, aktualizowania i usuwania rekordów w bazie, dlatego należy przetestować ich wpływ na całościowe funkcjonowanie programu.

Cykliczne czynności administracyjne

Cykliczne czynności administracyjne są bardzo istotne z punktu widzenia bezpieczeństwa jak i wydajności serwera SQL i należy traktować je jako obowiązkowe, a nie opcjonalne.
Do najważniejszych czynności administracyjnych można zaliczyć:

  • Kopia bezpieczeństwa
  • Cykliczne odtwarzanie kopii bezpieczeństwa w celu weryfikacji poprawności backupu.
  • Optymalizacja indeksów
  • Kontrola poprawności baz danych DBCC CHECKDB

Dla wydajności szczególnie dla większych baz duże znaczenie ma cykliczna optymalizacja indeksów w bazie, które ze względu na swoją defragmentację będą spowalniać pracę Comarch ERP Optima.
W kolejnych podrozdziałach opisano w jaki sposób można zautomatyzować niektóre z wymienionych czynności administracyjnych.

Maintenance Plan – zautomatyzowane strojenie dla pełnych wersji MS SQL

Każda pełna wersja MS SQL posiada mechanizm automatyzacji procesów, których zadaniem jest optymalizowanie bazy danych oraz kreowanie kopii bezpieczeństwa. Raz skonfigurowany zestaw operacji nazywany Maintenance Plan’em, czyli planem serwisowym, może być wielokrotnie uruchamiany w zadanym czasie. Tworzony jest zatem pewien „automat”, który o konkretnej porze wykona za nas operacje, które można wykonać z interfejsu programu Comarch ERP Optima.
W niniejszym podrozdziale przedstawiony został przykład planu serwisowego obejmującego:

  • Sprawdzenie spójności i ciągłości bazy danych (element testów integralności)
  • Odbudowę indeksów (ikona pioruna na oknie listy baz danych w konfiguracji)
  • Aktualizację statystyk
  • Wykonanie kopii bezpieczeństwa bazy konfiguracyjnej oraz firmowej
  • Usunięcie plików powstałych na potrzeby wykonywania planu

Materiał został sporządzony przy pomocy MS SQL 2008 za pomocą kreatora. Dla wcześniejszych wersji silnika bazy danych postępuje się podobnie.

Krok 1 – Uruchomienie kreatora Maintenance Plan’u

Kreator uruchamiany jest z poziomu programu Management Studio (pełna wersja).
SQL Server /Management/Maintenance Plan Wizard

Krok 2 – Wskazanie nazwy planu oraz terminu jego wykonywania

Kolejnym oknem kreatora, na które natrafiamy, jest krótki opis możliwości samego kreatora. Możemy zaznaczyć opcję, aby nie pokazywało się ono następnym razem. Interesuje nas następne okno.

Wypełniamy w nim pola odpowiadające za nazwę oraz opis planu. Deklarujemy następnie jego ramy czasowe. Mamy dwie możliwości:
„Seperate schedule for each task” – opcja pozwala na ustalenie terminu wykonania dla każdej operacji planu osobno.
„Single schedule for entire plan or no schedule” – opcja pozwala na ustalenie terminu wykonania całego planu lub wykonania go na życzenie (on demand).
Naciskając przycisk „Change” przechodzimy do okna konfiguracji ram czasowych.

Poniższy obraz przedstawia wybór ram czasowych dla opisywanego przykładu.

Istnieją cztery kombinacje ram czasowych dla planu. Mamy zatem:

  • „Start automatically (…)” – plan uruchomi się tuż po uruchomieniu serwera oraz usługi SQL Agent
  • „Start whenever when CPU (…)” – plan uruchomi się, kiedy procesor nie będzie obciążony
  • „Recurring” – plan ustala się według interwałów rok / miesiąc / dzień
  • „On time” – plan wykona się tylko raz w zadanym dniu i godzinie

W przykładzie użyjemy opcji terminarza według interwału co tydzień. Na obrazku widać, iż ma wykonywać się w każdy piątek o godzinie 18:30. Plan ma rozpocząć się od 15 grudnia 2009 roku i ma nie mieć końca.

Plan ma symulować koniec tygodnia roboczego, kiedy po godzinie 18:00 wszyscy pracownicy skończyli pracę, a serwer SQL nie jest już niczym obciążony.

Poprawne wskazanie ram czasowych dla planu jest bardzo istotne. Uruchomienie go podczas szczytu aktywności pracowników może nawet uniemożliwić im pracę. Podczas optymalizacji serwer pobiera dużo zasobów sprzętowych oraz blokuje elementy struktury bazy danych.

Krok 3 – wskazanie składników planu serwisowego

Kolejne okno kreatora planu przedstawia zakres czynności, jakie można wykonać. Są to:

  • „Check Database Inegrity” – kontrola poprawności struktury bazy danych. Nie można mylić jej z testami integralności, które walidują poprawność samych danych.
  • „Shrink Database” – pomniejszenie wielkości bazy danych poprzez usunięcie już niepotrzebnej rezerwy. Serwer SQL podczas pracy alokuje nowe zasoby na potrzeby przyszłych danych oraz operacji. Nie usuwa natomiast powstałem w tej sposób nadwyżki, kiedy dane zostaną usunięte a operacja się zakończy. Shrink pozwala na uwolnienie tych danych. Należy jednak pamiętać o tym, iż usunięcie nadmiarowych danych skutkuje fragmentacją dysku i może negatywnie wpływać na wydajność SQL. Nie zaleca się shrinkowania bazy danych tuż po wykonaniu odbudowy indeksów. Może to przynieść efekt odwrotny od zamierzonego.
  • „Reorganize Index” – defragmentacja indeksów.
  • „Rebuild Index” – odbudowa indeksów na nowo. Operacja ta jest bardziej długotrwała aniżeli defragmentacja, lecz daje lepsze efekty.
  • „Update Statistics” – aktualizacja “query optimizer’a” dzięki której serwer będzie potrafił wydajniej wykonywać polecenia.
  • „Clean Up History” – usuwanie historii wykonywania i odtwarzania kopii baz danych.
  • „Execute SQL Server Agent Job” – wykonanie “Job’a”.
  • „Back Up Database” – wykonanie kopi bezpieczeństwa bazy danych.
  • „Maintenance Cleanup Task” – usunięcie plików powstałych podczas wykonywania planu.

Poniższy obraz przedstawia wybór opcji, które realizowane są w opisywanym przykładzie.

Krok 4 – wskazanie kolejności wykonywania składników planu serwisowego

Kolejne okno kreatora planu pozwala na zadecydowanie, w jakiej kolejności powinny wykonać się poszczególne składniki planu serwisowego.

Krok 5 – wskazanie baz danych dla każdego elementu planu serwisowego

Każdy element planu serwisowego można wykonać dla dowolnego zestawu baz danych. Naszym celem będzie baza konfiguracyjna i baza firmowa.
Krok ten pozwala na elastyczność podczas tworzenia planu dla serwera przechowującego dużą ilość baz danych. Każdej z nich można przypisać oddzielne punkty planu.
Ogólna zasada wyboru baz danych jest wspólna dla wszystkich elementów planu serwisowego. Możemy wybrać:

  • „All databases” – operacja zostanie wykonana na wszystkich bazach danych znajdujących się na serwerze.
  • „System databases” – operacja zostanie wykonana tylko dla systemowych baz danych (przykład nie zakłada żadnych optymalizacji na tym typie baz danych).
  • „All user databases” – operacja zostanie wykonana tylko dla baz danych użytkownika, czyli niesystemowych. Dzięki tej opcji mamy pewność, iż zoptymalizujemy wszystkie bazy danych i nie narazimy na niebezpieczeństwo bazy systemowe.
  • „These databases” – operacja zostanie wykonana tylko dla zaznaczonych baz danych. Opisywany przykład wykorzystuję tę opcję.
  • „Ignore databases (…)” – wszystkie te bazy danych, których stan nie jest „Online” nie będą podlegać optymalizacji.

Poniższy obraz przedstawia wybór baz danych poddawanych sprawdzaniu poprawności. Każde kolejne okno opiera się na podobnym wyborze.

Krok 6 – charakterystyczne opcje dla każdego elementu planu serwisowego

Podczas wskazywania, które bazy danych mają zostać zoptymalizowane, możemy ustalić pewne opcje charakterystyczne dla elementu planu serwisowego.
Dla elementów wykorzystanych w przykładzie mamy:

  • Check Database Inegrity
    -Include indexes – po odznaczeniu proces kontroli nie obejmie indeksów, zajmie więc mniej czasu.
  • Rebuild Index
    -Reorganize pages with the default amount of free space – odbudowa indeksów z domyślnym
    “fill factor”. Oznacza to, iż indeksy zostaną odbudowane zgodnie z ustawieniami zadanymi podczas kreowana bazy danych, czyli przewidziane przez Comarch.
    -Change free space per page percentage to … – wskazanie wartości “fill factor” samodzielnie.
    -Sort results in tempdb – zastosowanie SORT_IN_TEMPDBoption.
    -Keep index online while reindexing – podczas odbudowy indeksy będą możliwe do odczytu (ta opcja dostępna jest dla edycji Enterprise)
  • Update Statistics
    -Update: – wybór elementów poddanych aktualizacji.
    -Scan type: – zakres elementów poddanych aktualizacji.
  • Back Up Database
    -Sekcja „Create a backup file for every database” – opcje związane z katalogiem, w którym zostaną umieszczone pliki kopii zapasowych.
  • Maintenance Cleanup Task
    -Dostępne opcje pozwalają na zadecydowanie jaki typ danych historycznych ma podlegać kasowaniu. Wskazuje się albo pewien plik, albo folder. Określa się również wymagany wiek pliku.

Krok 7 – wskazanie sposobu raportowania wyników wykonania planu serwisowego oraz zakończenie pracy z kreatorem.

Ostatnim etapem tworzenia planu serwisowego jest wskazanie ścieżki dostępu dla pliku raportu. Zawiera on zestawienie podjętych czynności oraz wyniki ich działania.
Po zakończeniu kreatora, nowy plan znajduje się na liście Maintenance Plans w programie Management Studio.

Na tym etapie kończy się konfiguracja planu serwisowego. Wykona się w następny piątek o godzinie 18:30.
Szerszy opis wszystkich elementów Maintenance Plan’u w języku angielskim można uzyskać na stronie: http://msdn.microsoft.com/en-us/library/ms188981.aspx

Plan serwisowy dla bezpłatnych wersji MS SQL

Opisany wcześniej plan serwisowy zbudować można tylko dla płatnych wersji silnika bazy danych. Nic nie stoi jednak na przeszkodzie, aby samemu sporządzić podobną funkcjonalność i zaproponować ją klientowi. Podobny efekt uzyskamy poprzez sporządzenie:

  • Skryptu SQL, który zawierał będzie wszystkie potrzebne dla optymalizacji zapytania.
  • Skryptu JS/VBS lub pliku .bat, który będzie zdalnie uruchamiał skrypt SQL z poziomy konsoli.
  • Harmonogramu systemu Windows, w którym zawrze się ramy czasowe planu.


W niniejszym biuletynie technicznym załączone zostały dwa pliki:

Plik StrojenieBazy.sql to skrypt zawierający wszystkie niezbędne zapytania, aby przeprowadzić plan tożsamy
z wcześniej opracowanym Maintenance Plan’em. Przed użyciem należy zmodyfikować w nim dwa parametry:

SET @Nazwa_bazy = 'CDN_DEMO' — Tu wpisz nazwę bazy danych do optymalizacji
SET @Sciezka = N’C:\BACKUP\' — Tu wpisz ścieżkę dostępu do katalogu dla kopii baz

Skrypt optymalizuje tylko jedną, wybraną bazę danych. Został tak sporządzony dla łatwiejszego zrozumienia jego działania. Warto prześledzić jego strukturę.

Drugi skrypt o nazwie StrojenieBazCDN.sql wymaga wskazania ścieżki dostępu do katalogu dla kopii baz. Zastosowano w nim kursor wyszukujący wszystkie bazy danych, których nazwa zaczyna się od ‘CDN’. Dla każdej z nich przeprowadzona zostanie optymalizacja.

Przed uruchomieniem skryptu należy zmodyfikować w nim następujące elementy:

sqlcmd.exe -S SERWER -E -i D:\StrojenieBazCDN.sql -o C:\Backup

  • SERWER – nazwa serwera, na którym znajdują się bazy danych.
  • D:\StrojenieBazCDN.sql – ścieżka dostępu oraz nazwa skryptu SQL.
  • C:\Backup – ścieżka docelowego miejsca składowania kopii baz danych (katalog musi istnieć).

Aby uruchomić automatyczne wykonywanie planu serwisowego należy w harmonogramie systemu Windows utworzyć nową regułę, która będzie w zadanym czasie uruchamiać odpowiedni skrypt VBS. Tym sposobem uzyskamy ten sam efekt, jaki przynieść może Maintenance Plan.

Pliki do pobrania