Deutsch

Situation 1: Performance Probleme beim Öffnen von AppDesigner-basierten Fenstern

Ursache

Mögliche Lösungen

Situation 2: Performance Probleme durch Suchfunktionen

Ursache

Mögliche Lösungen

Deutsch

Situation 1: Performance Probleme beim Öffnen von AppDesigner-basierten Fenstern

Beim Öffnen von AppDesigner-basierten Fenstern kommt es - scheints ohne direkte erkennbare Ursache - zu massiven Performance-Problemen und Wartezeiten für die Anwender.

Ursache

Caching wird ausgehebelt durch häufiges Löschen der gesamten Tabelle "USysCompiledMetadataCache_x"

Die Ursache ist ein komplettes Löschen der "USysCompiledMetadataCache_x"-Tabelle(n).

Im aktuellen Fall bei einem unserer Kunden, erfolget dies bis zu 1800 Mal pro Tag.

Wie sich herausstellte, kommt das im Wesentlichen vor, wenn Mandanteneinstellungen gespeichert werden, so zum Beispiel bei der Übergabe von der VK-Belegbearbeitung in die EK-Belegbearbeitung oder dergl.

Es wird das Microsoft Access Fenster "frmAbfMainErfassungBestellung" zur Auswahl des Lieferanten und zum Setzen weiterer Optionen aufgerufen.

Wird dieses Fenster mit OK geschlossen, dann werden die Einstellungen gespeichert:

   Call gbUpdateAbfManProp(goMandant, olBVMindestbestellmenge, gbCBool(Me.chkMindestbestellmenge))
    Call gbUpdateAbfManProp(goMandant, olBVGebindefaktor, gbCBool(Me.chkGebindefaktor))
    Call gbUpdateAbfManProp(goMandant, olBVKarenztage, gnCInt(Me.txtVorBedarf))
    If mbAuftragbelegart And gbVerursacherLizenz Then
        Call gbUpdateAbfManProp(goMandant, olBVBedarfVerursacher, gbCBool(Me.chkBedarfsverursacher))
    End If

Weitere Untersuchungen haben gezeigt, was mögliche Ursachen für die Löschung des Cache (auch seitens AppServer) sind:

• sehr häufig aus dem PropertyManager des Mandantenobjektes.

• dieser befindet sich in der "Sagede.Officeline.Engine.dll".

• der Cache-Reset wird immer aufgerufen, wenn eine Mandanten-Eigenschaft geändert wird; ggf. auch aus neuen Masken über Serverroundtrip und AppServer.

• es erfolgt keine Prüfung ob der Wert sich überhaupt geändert hat, vielmehr wird die "USysCompiledMetadataCache_x" komplett für den aktuellen Mandanten geleert:

exec sp_executesql N'IF EXISTS(select * from sys.objects where name = ''USysCompiledMetadataCache_5'')
BEGIN
DELETE FROM [dbo].[USysCompiledMetadataCache_5] WHERE [Database] = @Database And [Mandant] = @Mandant
END',N'@Database varchar(8),@Mandant smallint',@Database='OLDB',@Mandant=1

• die Aufrufe aus MS-Access laufen am Ende auch gegen den "Propertymanager" und verursachen somit die Löschungen.

Mögliche Lösungen

Warten auf neuere Sage 100-Versionen, in denen nur noch tatsächlich geänderte Mandanteneigenschaften durch Sage in die KHKMandanten geschrieben werden.

D.h. es wird also nicht mehr bei jedem Aufruf von Dialogen mit Mandanteneigenschaften die USysMetadataCache gelöscht und neu wieder aufgebaut. Diese Änderung soll ggf. bereits in der 9.0.4 kommen, aber spätestens auf jeden Fall mit der 9.0.5.

Situation 2: Performance Probleme durch Suchfunktionen

Bei Kunden mit großen Datenbanken und z.B. sehr vielen Belegen oder Artikeln reicht es oftmals nicht den Listentyp "Auskunft (Wählen, suchen, filtern, gruppieren, analysieren)” zu benutzen, weil hierin zu wenige Datensätze geladen werden.

Hier wird von Anwenderseite dann oft der Listentyp "Auswahl (Wählen, suchen, filtern)" eingestellt.

Für diesen Listentyp trifft Folgendes zu:

• Die "Übergreifende Suche" ist ein absoluter "Performance Killer".

• Dies trifft auch für "Spaltenbezogene Ad-hoc-Filter" zu, wenn auch in etwas geringerem Maße.

• Es werden SQL Statements gegen die Datenbank abgesetzt, die teilweise mehrere Minuten laufen. Die Systemlast und Shared Locks die dabei entstehen führenen dazu, dass scheinbar die gesamte Sage 100 “einfriert”.

Ursache

• Es wird immer eine SQL-Abfrage an die Datenbank geschickt, wenn in einem Suchfeld etwas eigegeben wird, im Gegensatz zum Listentyp "Auskunft (Wählen, suchen, filtern, gruppieren, analysieren)", in dem die Suchfelder ausschließlich auf die bereits geladenen Daten im Hauptspeicher filtern.

• Bei Eingabe in ein solches Suchfeld wird - dynamisch - eine äußerst problematische ad-hoch SQL-Abfrage generiert und an die Datenbank geschickt

• In der WHERE Bedingung stehen dann für die betroffenen Spalten jeweils Statements wie "AND Belegnummer LIKE '%4000001%'

• Bei Sortierungen wird "ungünstiges" SQL erzeugt (z.B. "WKZ" bei Belegen).

• Dies führt zwangsläufig zu Full Table / Full Index Scans, d.h. dass z.B. im Fall der Belegsuche entsprechende Datensätze aller Belege gelesen werden (dasselbe Problem gilt natürlich für alle anderen Tabellen mit extrem vielen Datensätzen).

Mögliche Lösungen

• "Übergreifende Suche" vermeiden!

• Unnötige Felder aus der Liste entfernen!

• Sortierung für ungünstige Felder entfernen!

• Ggf. Suchfelder SQL-seitig indizieren!

• Für die Suche die Funktion "Datensätze wählen" benutzen