Witam,

Posiadam następujący sprzęt:
Serwer:
DELL R2210
Procesor: Intel Xenon E31230 @ 3.20 GHz 3.20 GHz
Ram: 8 GB
Dysk: Sata 320 GB
Z oprogramowanie:
System: Windows Server 2008 R2 Fundation
System Forte w wersji : 2012a na SQL Server 2008 R2

Od jakiegoś czasu system strasznie muli.
Klienci po sieci muszą długo czekać na zalogowanie się do stacji.
A bezpośrednio na serwerze bardzo czelesto program się zawiesza, czasami na chwilę czasami na bardzo długą chwilę.

Z góry dziękuje za każda wskazówkę.

Może jest jakiś sposób na skontrolowanie systemu FORTE jakiś program testujący.
Jak sprawdzić co powoduje takie spowolnienie.

Przy okazji wie ktoś z was jak przetestować kondycję mechanizmu Common?

Sprawdziłem komunikacje tym programem:

Tam jest opcja testuj.
Test trwał prawie 2 minuty nie wydaje mi się żeby to było normalne...?

Ma ktoś z was jakiś pomysł?

Jak już się program uruchomi to chodzi znośnie.

Pomogła zmiana sposobu parametrów konfiguracji globalnej w pliku: CMNConfig.exe z:

na

Po tym był jeszcze był tylko problem z synchronizacją czasu. (po aktualizacji czasu na stacji roboczej jest ok. Ale czynność ta co jakiś czas trzeba powtarzać).
Doczytałem w dokumentacji
że da się to wyłączyć.
Czy wyłączenie synchronizacji czasu to dobry pomysł, jakie mogą być tego niepożądane konsekwencje?
Czy lepiej ustawić jakiś

OK, przyspieszyłeś bo teraz twoja stacja nie odczytuje konfiguracji z serwera common czyli pozbawiłeś się w tym momencie konfiguracji globalnej parametrów haseł itp. Ogólnie to jest BARDZO nie zalecana metoda pracy z systemem forte, może poza instalacjami jednostanowiskowymi i okresowym ustawieniem tej opcji tak np. na czas konwersji bazy. Celem do którego powinieneś dążyć, to taka konfiguracja serwera common (czy maszyny na którym jest) by poprawnie działała konfiguracja globalna na serwerze.

No i czemu wstydliwie ukrywasz numer portu? to zadna tajna informacja :)

Żeby mu się ktoś nie włamał ;)

Widzę że zamaskowanie portu wywołało większą dyskusje niż podmiot mojego tematu

Wracając do wątku głównego co może być przyczyną powolnego pobierania konfiguracji globalnej z serwera.


Cały czas próbuje.
Mam się czegoś obawiać pracując w trybie konfiguracji lokalnej na końcówkach klienckich.
Efekt jest częściowo osiągnięty czyli Symfonia uruchamia się i pracuje szybko.
Mam jeszcze taki komunikat przy uruchamianiu końcówki w trybie konfiguracji lokalnej:

Występuje on zaraz po uruchomieniu komputera.
Po kilkunastu minutach po uruchomieniu komputera i ponownej próbie Symfonia uruchamia się już normalnie.

Z góry dziękuje za wszystkie uwagi.

Czy wielkość pliku LDF może mieć wpływ na prędkość pobierania parametrów konfiguracji z Common?
U mnie ten plik dla bazy Handlu ma 35 GB

No pewnie ma taki sam wplyw na common jak ilosc pingwinow na antarktydzie :) Ale czemu sobie po prostu nie obcinasz log-u czasem? nie szkoda ci miejsca na dysku i na kopie?

Proponuję zoptymalizować SQL pod względem wydajności, zmiana recovery, optymalizacja plików logicznych, sprawdzenie środowiska SQL czy optymalizacja samej bazy (sprawdzenie indeksów, podział bazy).
Niestety serwer z jednym dyskiem nie będzie wydajny jeżeli na nim będzie także SQL.

Po odchudzeniu plików tranzakcyjnych (.LDF) powiązanych z bazami.
Stwierdzam że mechanizm pobierania konfiguracji z serwera znacznie przyspieszył!

Nie wiem jak z pingwinami ale wielkość pliku LDF chyba ma wpływ na tempo pracy tego mechanizmu

Temat rozwiązany.

Prawda jest taka, że brak jest sensownego technicznego uzasadnienia dla wydajności bazy MS SQL bezpośrednio związanego z wielkością pliku LDF. Często od Microsoft padają argumenty, że wręcz baza pracuje bardziej wydajnie posiadając nieciętego loga. Wielkość LDF nie ma wpływu na szybkość działania i zwiechy systemu jeśli jego rozmiar nie rzutuje na działanie samego systemu serwera fizycznie czyli np duży plik i problemy z jego obsługą przez nieaktualny/zabugowany sterownik kontrolera dysków, wolny dysk, fragmentacja, ilość wolnego miejsca na dysku, wejście na uszkodzony obszar itp... itd... powodów może być wiele.
U ciebie zmniejszenie LDF pomogło ale podejrzewam, że jest to działanie pośrednie i nadal jest usunięciem skutku a nie przyczyny gdyż spowolniona obsługa dużego LDF ma zapewne jakieś inne powody, a tylko w dalszej konsekwencji propagowała się na zwiechy systemu. Można by się pokusić o stwierdzenie, że Twojego prawdziwego źródła problemów jeszcze nie poznałeś.

A przy okazji - piszesz, że masz SQL 2008R2 a który SP? Bo niestety w większości przypadków zastanych przeze mnie samodzielnych instalacji u klientów natykam się na zainstalowaną gołą wersje 2008R2 RC (bo taka była na płytce) bez jakiegokolwiek SP zainstalowanego i potem jest płacz że system "sie wiesza" a jak ma sie nie wieszać, gdy sie pracuje na SQL w wersji "późna BETA" :).