Das Zeitverhalten von Ansichten, ist von einer Vielzahl von verschiedenen Faktoren abhängig. Auch wenn die Datenbankanbindung optimiert ist, kann in laufenden Systemen Probleme auftauchen. Die Zunahme der Datenmenge ist dabei nur einer der möglichen Faktoren.
Wird eine Ansicht angezeigt, werden grundsätzlich 3 SQL-Abfragen ausgeführt:
- In der ersten Abfrage wird die Anzahl der Datensätze ermittelt. Dort werden keine Spaltenwerte ermittelt und auch keine Sortierung durchgeführt, aber die Filter genutzt.
- In der zweiten Abfrage werden die Oids der Datensätze ermittelt, die in der Ansicht angezeigt werden sollen. Dabei werden sowohl die Filter als auch die Sortierung berücksichtigt. Diese Abfrage erhält auch automatisch einen „top n”-Teil, da nur die angezeigten Datensätze benötigt werden. Für „n” wird in der Regel der doppelte Wert verwendet. Kann der aktuelle Anwender also 10 Datensätze sehen wird „top 20” und bei 15 Datensätze „top 30” verwendet. Maximal wird „top 150” verwendet. Mehr Datensätze werden beim ersten Laden nicht ermittelt. Erst beim Scrollen werden weitere geladen.
- In der dritten Abfrage werden dann anhand der Oids aus der zweiten Abfrage die Datensätze mit den Spaltenwerten geladen.
Ausführungspläne (MS SQL)
In einem vorherigen Abschnitt wurden die Ausführungspläne und deren Überwachung beschrieben. Da der SQL-Server seine Pläne an den Text der SQL-Abfrage bindet, kann es immer wieder vorkommen, dass bei einem Anwender der die Ansicht nutzt ein neuer Plan generiert wird, der dann eventuell ein sehr negatives Zeitverhalten zeigt.
Wenn also das System sich grundsätzlich zufriedenstellend verhält und ein Anwender über ein schlechtes Zeitverhalten einer ansonsten gut funktionierenden Ansicht klagt, kann bei diesem Anwender ein spezieller Plan vorliegen, der schlecht skaliert.
Wenn der Anwender keine ungewöhnliche Sortierung, Gruppierung oder Summierung verwendet (Siehe nächste Abschnitte) kann er schon alleine deswegen einen anderen Plan haben, weil er der einzige Anwender ist, der beispielsweise genau 13 Datensätze sieht. In diesem Fall wird nämlich in das SQL Statement „top 26” verwendet. Siehe dazu das Kapitel Ursachenerkennung / SQL Server / Ausführungspläne.
Berechnete Spalten
Berechnete Spalten bieten das größte Risiko, sich negativ auf das Zeitverhalten von Ansichten auszuwirken. Zum einen können darüber komplexe Formeln implementiert werden, die dann vom SQL-Server ausgeführt werden müssen. Und zum anderen kann der SQL-Server Sortierungen, Gruppierungen, Summierungen und Spaltenfilter für solche Spalten nicht optimieren.
Wenn beispielsweise nach einer solchen Spalte sortiert wird, muss der SQL-Server für alle Datensätze die Formel ausführen und dies kann bei großen Datenmenge entsprechend lange dauern. Dies kann auch nicht weiter optimiert werden, da ein Index in der SQL Datenbank nur auf konkrete Spalten erstellt werden kann. Daher kann es notwendig sein, die Sortierbarkeit, die Gruppierbarkeit und die Spaltenfilter für solche Spalten zu deaktivieren.
Das Auftreten solcher Probleme ist stark von der Datenmenge abhängig. Daher ist ein grundsätzlicher Verzicht auf diese Funktionalitäten nicht notwendig.
Datum/Zeit-Spalte
Bei Auswahl einer Datum-Zeit-Komponente (Tag, Woche, etc.) muss grundsätzlich eine Berechnung durchgeführt werden. Daher gilt dort ähnliches, wie bei den „Berechneten Spalten”.
Filter
Sowohl die Datensatzfilter in der Konfiguration der Ansicht, als auch die Spaltenfilter im Benutzerinterface wirken sich eher vorteilhaft auf das Zeitverhalten aus. Dazu zählen auch die Filter zum Anzeigen abhängiger Datensätze in den Detailansichten.
Für Filter auf berechnete Spalten gilt dies wie beschrieben nicht unbedingt.
Relationen
Die „Spalte aus Einfach-Relation” zeigt beispielsweise den Firmennamen bei Kontakten oder Vorgängen an und wird zur Laufzeit aus dem Firmendatensatz ausgelesen. Daher macht jede Spalte aus einer Relation die Ansicht komplexer. In der Regel hat dies aber keine auffälligen Auswirkungen auf das Zeitverhalten der Ansicht, da die Spaltenwerte erst in der dritten Abfrage ermittelt werden.
Erst die Sortierung, Gruppierung oder die Filterung danach bewirkt, dass auch in den ersten beiden Abfragen der Spaltenwert notwendig ist. Da der Zugriff auf den Wert komplexer ist, als das Auslesen eines Wertes aus dem aktuellen Datensatz, können zu viele Spalten aus unterschiedlichen Relationen negative Auswirkungen haben.
Sortierung
Die Sortierung hat ausschließlich Einfluss auf die zweite Abfrage. Das bedeutet, wenn ausschließlich diese Abfrage ein negatives Zeitverhalten ausweißt, deutet dies auf eine problematische Sortierung hin.
Sortierungen können unter Umständen durch einen zusätzlichen Index verbessert werden. Wobei zu beachten sind das Indexe nur auf einer Tabelle angelegt werden können.
Beispiel 1: Wird eine Sortierung nach dem Nachnamen und dem Vornamen eines Kontaktes benötigt, ist es eventuell sinnvoll einen Index nach diesen beiden Spalten in der Tabelle OrmContact anzulegen. Dies hilft aber nur dann, wenn die beiden Werte in zwei einzelnen Spalten angezeigt werden. Werden diese beiden Spalten in einer berechneten Spalte zusammengerechnet, hilft der Index nicht.
Beispiel 2: Wird eine Sortierung nach Firmennamen, Kontaktnamen und Datum des Vorgangs in einer Vorgangsansicht benötigt, kann dafür kein spezieller Index angelegt werden, da sich die Werte in unterschiedlichen Tabellen befinden.
Indexe sollten auch nicht aus Vorsorge angelegt werden, da diese auch einen Verwaltungsaufwand für den SQL-Server bedeuten. Daher sollten Sie nur Indexe anlegen, um aktuelle Probleme zu beseitigen und die nachweislich zu einem Erfolg führen.
Zeigt eine Spalte ein negatives Zeitverhalten bei der Sortierung und kann dies mit keinen Maßnahmen beseitigt werden, sollte in Betracht gezogen werden, die Sortierbarkeit der Spalte konfigurativ zu deaktivieren.
Gruppierung
Ist eine Ansicht gruppiert, ändern sie die Abfragen erheblich. Ist keine Gruppe aufgeklappt, wird nur eine Abfrage ausgeführt. Dabei werden ALLE Gruppierungen mit deren Anzahl ermittelt. Angezeigt werden aber nur die ersten 75 und beim weiteren Scrollen wird dann jeweils wieder eine Abfrage zur Ermittlung mit allen Gruppierungen abgesetzt.
Ein Vorteil dieses Verhaltens ist das die Gesamtzahl aller Datensätze durch die Summe aller Gruppierungen ermittelt werden kann und damit keine weitere Abfrage ausgeführt werden muss.
Damit ist das Zeitverhalten abhängig davon, wie schnell der SQL-Server die Gruppierung ermitteln kann. Die Gruppierung nach berechneten Spalten kann daher ein negatives Zeitverhalten aufweisen.
Zeigt eine Spalte ein negatives Zeitverhalten bei der Gruppierung und kann dies mit keinen Maßnahmen beseitigt werden, sollte in Betracht gezogen werden, die Gruppierbarkeit der Spalte zu deaktivieren.
Mehrfachgruppierungs-Spalten
Das Besondere bei der Verwendung dieser Spalten ist, dass durch einen Join der eigentliche Datensatz mehrfach aufgelistet werden kann. Dies lässt die maximale Anzahl der Datensätze entsprechend ansteigen und stellt daher andere Anforderungen an die Datenbank-Optimierer. Ist die Ansicht gruppiert und / oder sortiert, entsprechen die technischen Besonderheiten den schon diskutierten.
Hat eine Ansicht mit einer dieser Spalten eine Wichtigkeit, sollten diese daher separat betrachtet und untersucht werden.
Summen
Es gibt zwei Arten von Summen. Das sind die Gruppierungssummen und Gesamtsummen. Wobei Gruppierungssummen keine separaten SQL-Abfragen generieren. Gesamtsummen tun dies, falls sie während der Gruppierung angezeigt werden. Die Gruppierungssummen werden mit den Gruppierungen und deren Anzahl zusammen ermittelt und machen diese Abfragen entsprechend komplexer.
Bei einer flachen Darstellung werden die Gesamtsummen zusammen mit der Anzahl in der ersten Abfrage ermittelt und machen diese entsprechend komplexer.
Leserechte
Leserechte machen eine Ansichten-Abfrage grundsätzlich komplexer und daher langsamer. Wenn ein Anwender alle Datensätze einer Datentabelle lesen kann, wird der entsprechende Teil der Abfrage automatisch vom System optimiert. Daher wird empfohlen, Anwendergruppen die alles lesen dürfen, die entsprechenden Berechtigungen in der Datentabelle zu geben.
Beispiel BA.CRM: Hat ein Anwender die Rolle “Read All”, bedeutet dies in der Regel, dass er alle Datensätze aller Datentabellen lesen kann. Auch dann, wenn individuelle Leserechte aktiv sind. In diesem Fall werden die Leserechte in den Ansichten entsprechend weggelassen und damit hat dieser Anwender ein besseres Zeitverhalten bei dem Abruf von Ansichten als andere Anwender bei denen die Leserechte geprüft werden müssen.
Beispiel Everyone: Die Rolle “Everyone” hat automatisch jeder Anwender. Wenn “Everyone” nun in der Datentabelle im Feld „Alles Lesen” eingetragen ist, muss für keinen Anwender die Leserechteüberprüfung durchgeführt werden.
Where Teil der Leserechte: Um während der SQL-Query-Analyse den Einfluss der Leserechte bestimmen zu können, ist es sinnvoll den Leserechteteil in der Where-Bedingung zu erkennen. Daher wird diese hier genauer betrachtet.
In der OrmReadAccess stehen die Berechtigungen des Datensatzes und in OrmReadAccessUserRole stehen die Rollen des aktuellen Anwenders. Die hier dargestellte SQL-Where-Bedingung bildet dies ab. In Details kann sich dies von der reellen Bedingung unterscheiden. Insbesondere können anstatt “@p0”, “N2” und “N3” andere Werte stehen.
exists(select * from "dbo"."OrmReadAccess" N2 where ((N2."Target" = N0."OID") and exists(select * from "dbo"."OrmReadAccessUserRole" N3 where ((N3."User" = @p0) and (N3."Role" = N2."Source")))))