Performance OL 2014 nach Liveupdate um den 20.01.2015 herum

NTComputing Mattern

NTComputing Mattern

Frank Mattern
Teammitglied
ein Endkunde „klagt“ nach dem letzten Liveupdate in der Office Line 2014 (vor ca. 2 Wochen Wochen vom Endkunden selbständig durchgeführt, wie immer) über Perfomanceprobleme bei den folgenden Punkten:

- AB's abspeichern (NUR bei "großen Kunden")

- Übernahme AB in Lieferschein (NUR bei "großen Kunden", Übernahme Lieferschein in Rechnung ist gleichbleibend schnell!)

- Mandantenwechsel

„großer Kunde“ bedeutet: Kunde mit vielen Vorgängen


Gibt es hier ähnliche Erfahrungen/Rückmeldungen von anderen Kunden? Gibt es Ideen zur Verbesserung der Performance in diesen Punkten? Es handelt sich um Server-Clientinstallationen, keine Terminalserver
Ich freue mich über Anregungen

Mit einem winterlich kühlen Gruß aus Marburg
Frank Mattern
 
Spontan fallen mir da so ein/zwei Dinge ein.
- Prüfen der ldf Dateien der Datenbank, ggf. sind diese einfach zu groß geworden
- Hotfixstand des SQL Servers
- Datenbankreorganisation (kann über den OL Admin gemacht werden)
- Neuaufbau der Statistiken am SQL Server

ggf. kann man mal eine Indexprüfung durchführen und durch das neu setzten bzw. Hinzufügen ein/zwei Indizies gewaltige Wunder vollbringen.
 
Hier mal einige Punkte aus der Vergangenheit, eventuell trifft ja etwas zu:

Datenbankserver

· Betriebssystem (OS), Datenbank (MDF), Transaktionsprotokoll (LDF), Backup (BAK) auf separaten Festplatten, nicht nur Partitionen

· Festplattenanbindung möglichst über internen Controller und nicht per Netzwerkinterface (kann ein möglicher Flaschenhals sein) - SAN nicht empfehlenswert

· Regelmässig (1x Woche) Datenbank reorganisieren, Indizes neu aufbauen, Statistiken neu aufbauen

· Sage Applikationsserver und Mehrbenutzerdienst auf einem eigenständigen Server

Terminalserver

· Cache erhöhen / Max Buffer Size

Registryeditor öffnen, folgenden Key ansteuern:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Office\14.0\Access Connectivity Engine\Engines

Je nach Versionsnummer deines Access kann hinter dem Office auch 10, 12 usw. stehen - einfach das korrekte auswählen.

Dann unter Engines bei Jet 2.x, 3.x den Wert unter "MaxBufferSize" auf 16384 (Dezimal) setzen. Habe bei uns auch unter ACE den Wert so gesetzt (war vorher 0), aber Jet ist die Hauptengine.

Danach ist ein Neustart erforderlich. Die Änderung sorgt dafür, dass die DB Schnittstelle ordentlich Zwischenspeichern kann und einen massiven Geschwindigkeitsvorteil bringt (ist zu 90% der Hauptgrund bei langsamer Geschwindigkeit bei 2k8R2 oder auch Win7)

· DEP Ausstellen für Access

Win2k8 R2 hat damals die Datenausführungsverhinderung eingeführt, mit welcher Programme nicht mehr in geschütze Bereiche schreiben können. Problem bei Access 2007 war aber, das dieses eben doch solche Bereiche geschrieben hat. Folge waren nicht nachvollziehbare Abstürze der Anwendung usw.

Fehlerfindung war auch schwierig, da hier die CPU den Prozess killt, bevor WIndows überhaupt aktiv werden kann und somit auch kein oder zumindest kein Sinnvolles Ereignisprotokoll erstellt wird. Keine Ahnung ob dies bei dir zutrifft, aber einen Versuch ist es wert.

Zum Beheben:
Systemsteuerung > System > Erweitert > "Leistung" > Einstellungen > Reiter Datenausführungsverhinderung > "DAP für alle Programme mit ausnahme der Ausgewählten einschalten" markieren und die Access.exe hinzufügen. Danach ein Neustart. Solltet ihr HyperV einsetzen, DAP via Registry auf HyperVHOst deaktivieren (gab da später bei uns Probleme) - google am besten nach einer Anleitung.

· Energieverwaltung auf Höchstleistung setzen
Hört sich seltsam an, ich weiss. Hatte hier mit HyperV 2008 und 2012 Probleme, welche sich damit beheben liesen. Vielleicht auch bei dir sinnvoll, egal ob du Virtualisierst oder nicht. Am besten mal ausprobieren

Auch interessant hierzu:
http://sage-office-line-blog.de/performance-optimierung-der-sage-office-line/

Gruß
 
Danke an Alle,
die Infos hatte ich dem Kunden auch weitestgehend bereits mitgeteilt. Leider habe ich keinerlei Zugriff auf das System und kann nicht prüfen ob die Wartungsaufgaben tatsächlich durchgeführt werden und wie die Installation tatsächlich aussieht. Ich bleibe aber in Kontakt und gebe bei Gelegenheit Rückmeldung.
 
Der Kunde war jetzt auch nochmal fleißig. die grundsätzlichen SQL-Datenbankwartungsarbeiten werden regelmäßig ausgeführt. Zudem war ja auch tatsächlich die Verlangsamung nach dem Liveupdate festzustellen. Der Kunde hat mit die folgenden Infos durchgegeben:


Die folgenden Tests wurden gemacht:

1. Da der Verdacht nahelag, dass es mit der Überwachung der Kreditlimits zusammenhängt, haben wir das Kreditlimit bei den Kunden mit hohen Vorgangsaufkommen herausgenommen. Ergebnis: signifikant besser.

2. Aufzeichnung der SQL-Ausdrücke die diese Überwachung durchführen: es werden 1500 exec sp_executesql ausgeführt die immer mehr oder weniger gleich sind (in Gruppen) mit unterschiedlichen Parametern. Hier liegt der eigentliche Mangel! Die Aufzeichnung liegt bei.

3. Vergleich mit Rechnern mit der Version 2014.2.3 (6.2.2597) (= alter Stand vor Update) mit neuem Update: Um den Faktor 5 langsamer beim Abspeichern einer AB sowie Übernahme AB in Lieferschein.

Somit scheint die Kreditlimitprüfung in der 2014.2.4 der entsprechende Flaschenhals zu sein. Der Kunde hat ein SQL-Logfile erstellt, dass bei der Prüfung des Kreditlimits bei einem Kunden mit vielen offenen Vorgängen 1 MB groß ist. Falls großes Interesse daran besteht, lade ich es gerne hoch.
So weit so?
 
Guten Tag,
das Verhalten wurde direkt im Support der OL-Warenwirtschaft eingereicht (nach der Beschreibung handelt es sich um den gleichen Kunden) und wurde zur Prüfung für die Entwicklung aufgenommen.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben