Einstellungen für den Plan Cache

[dschroeder]

Hallo Baldur,
sorry, dass ich erst jetzt auf deinen Beitrag antworte. Ja, du hast Recht. Mit einer passenden Indexstrategie treten viele Problem gar nicht erst auf und für den normalen Hausgebrauch reicht das auch. Das machen wir hier genauso.

Allerdings gibt es ja weitergehende Optimierungsmöglichkeiten, die dann eher Mikroverbesserungen sind. Wie z.B. dass man einen auf den ersten Blick sinnlos erscheinenden zusätzlichen Index erstellt, der aber dafür sorgt, dass alle Daten direkt aus dem Index gelesen werden und dann kein zusätzlicher Zugriff auf die physische Tabelle gemacht werden muss.

Wir haben bei uns sehr viele Abfragen parallel laufen, weil bei uns viel gesynct wird. Da möchte ich an der einen oder anderen Stelle mal gucken, ob eine kleinteilige Optimierung bei bestimmten Jobs etwas verbessert. Wobei wir grundsätzlich erstmal kein echtes Performanceproblem haben, aber das heißt ja nicht, dass es nicht noch besser laufen könnte.

Ich bin über manche Daten selbst überrascht, die uns das Performance Center anzeigt. Wenn ich das richtig interpretiere, sollen über 300.000 Queries parallel ausgeführt werden. Das kann ich mir kaum vorstellen, auch wenn man jeden Einzelsatzzugriff mitzählt, der ja seit einigen Releases im Hintergrund immer über die SQL-Engine verarbeitet wird.

Hier mal ein aktueller Ausschnitt aus unserem Performance Center:



Für mich sieht es so aus, als würden 332535 Queries "currently", also gerade jetzt ausgeführt. Finde ich viel.

LG, Dieter

[Fuerchau]

Das würde ja bedeuten, dass aktuell auch soviele SQL-Jobs laufen, neben den vielen anderen.
Physikalisch kannst du (Anzahl CPU's mal Anzahl Platten) tatsächliche Abfragen parallel fahren.
Andererseits können auch viele kleine Abfragen unte 0,001 Sekunden auch aus dem Cache befriedigt werden und wie der Snapshot zählt weißt du ja auch nicht.
Wenn bedenkt, dass man durchaus mehrere 1000 Inserts/Sekunde durchbekommt, mit Index fast genauso viele Updates oder Deletes.

Die Mehrzahl der Abfragen sind ja weniger Reports auf Basis von mehreren 100.000 Zeilen sondern Einzelsatz/Einzelbeleg-Abfragen. Und da reicht ja genau 1 passender Index.

Für unser DWH und Reportingsystem (Web-Dashboard) bilde ich Indizes automatisch auf Grund der Abfragebestimmungen (Where-Klausel). Allerdings ist unser DWH auch auf einer Firebird-DWH um die Quellsysteme (ins besonders SQL-Server) zu entlasten.

Bei der IBM i sind die SQL-Serverprobleme bei größeren Resultsets schlichtweg nicht vorhanden.
Such mal nach Lockescalation. Bei bestimmten Abfragen und Transaktionen (Read Committed) kann gleich die gesamte Tabelle gegen Veränderungen gesperrt werden bis die Abfragetransaktion committed hat. Da fragen sich schnell ein paar hundert User, wer denn da schon wieder Power-BI-Abfragen lädt.
Denn die anderen Transaktionen laufen da nicht auf timeout sondern werden bis zum Ende geparkt.
Aber versuche das mal als schlechtes Konzepte den Microsoft-SQL-Spezies darzustellen.

Was die Performance generell angeht hatte ich mal einen Zwangsvergleich zu einem SQL-Server.
Hier wurden Daten per ODBC in den SQL-Server gepumpt. Laut "Microsoftspezialist" liefert die IBM i die Daten zu langsam. Der SQL-Server könnte erheblich mehr.
Bei einem Beispiel mit einer Tabelle über 8 Felder konnte der SQL-Server ca. 12000 Zeilen/Sekunde einfügen. Mit einem kleinen C#-Programm konnte ich aber bis zu 280.000 Zeilen/Sekunde abrufen.
Laut "Microsoftspezialist" hätte ich da ein Fakeprogramm geschrieben. Die Quelle haben die sich gar nicht angesehen und selber ausprobiert. Selbst per SQL-Server-Bulkload kam ich dann nur auf ca. 30.000 Zeilen/Sekunde, was aber der "Microsoftspezialist" auch als Fake abgewiesen hat, da ich ja kein "Microsoftspezialist" bin.

[dschroeder]

Ja, vielleicht ist der Namensteil "Micro" in Microsoft tatsächlich aussagekräftig :-)