Find the queries and indexes that cost you time

Langsame Abfragen sind für dieses Produkt existenzielle Fragen. Wenn eine Abfrage langsam ist und SQL DATA LENS sie nicht schneller machen kann oder den Grund nicht erklären kann, dann hat es genauso versagt, als ob es nicht verbindet. Kein SQL-Client sollte veröffentlicht werden, ohne die Fähigkeit, den teuersten Aufwand in einer Produktionsdatenbank zu finden und einen Plan zu lesen. Die Performance-Werkzeuge sind in der Free Edition verfügbar, und sie laufen parallel zum Rest des Tools — sie verlangen nicht, dass man den ganzen Editor schließt, um einen Plan zu sehen.

Beginnen Sie mit den kostspieligsten Statements

Die SQL Runtime Statistics in SQL DATA LENS sind eine lesbare, filterbare Ansicht über %SYS.PTools.Stats, was IRIS intern für jede Abfrage protokolliert, die läuft. Die View zeigt die Statements, sortiert nach der gesamten verbrauchten Zeit, die Anzahl der Ausführungen, die durchschnittliche Dauer und die Modulnamen. Das ist kein Hypothese-Tool — es zeigt, was tatsächlich lief, die tatsächliche Arbeitslast eines echten Workloads.

Die Zeilen, die oben erscheinen, sind die Zeilen, in denen die größten Kostenreduzierungen liegen: die teuersten und die am häufigsten ausgeführten Statements. Vierzig Ausführungen bei durchschnittlich zwei Sekunden jede ist ein besserer Indexkandidat als zwanzig Ausführungen bei einer Sekunde, einfach weil die Gesamtkosten höher sind. Die Routine oder Klasse, die ein Statement ausgeführt hat, wird mitprotokolliert, wo verfügbar, was nützlich ist, um herauszufinden, welche Anwendung das ist, was man gerade betrachtet.

Es gibt zwei Gründe, warum ein Statement hier nicht erscheint. Erstens, das Tool läuft auf dem aktuellen Namespace, und %SYS.PTools protokolliert nur den aktuellen Namespace — Statements, die in anderen Namespaces liefen, gehen an ihr eigenes PTools-Schema. Zweitens, Runtime Stats sehen Statements, nachdem sie für die Ausführung vorbereitet wurden, also nicht die gespeicherten Abfragen oder dynamischen SQL-Statements, die nie vorbereitet wurden.

Die drei Statistik-Schema-Views

Zusätzlich zu Runtime Stats bietet SQL DATA LENS drei View-Gruppen, die aggregierte SQL-Performance-Statistiken aus den IRIS %SYSTEM APIs exponieren:

• Query Statistics — Welche Statements werden häufig ausgeführt, durchschnittliche Dauer, Gesamtkosten. Quelle: %Library.ResultSet.
• Index Statistics — Welche Indizes verwendet werden, wie oft, wann zuletzt. Quelle: %SYS.DatabaseQuery.
• Table Statistics — Zugriffsmuster auf Tabellen, Anzahl der Reads/Writes, Grobkosten. Quelle: ebenfalls %SYS.DatabaseQuery.

Alle drei werden in demselben Performance-Bereich neben Runtime Stats angezeigt, und alle sind abfragbar wie normale Tabellen. Das macht es möglich zu fragen: „Welche Statements greifen auf diese Tabelle zu?" oder „Welche Indizes wurden in den letzten vierzehn Tagen nie verwendet?" mit dem SQL-Editor auf demselben Bildschirm wie die Statistik selbst.

Jede View ist eine Client-Session, also werden die Statistiken jedes Mal neu gesammelt, wenn SQL DATA LENS die View lädt. Änderungen in der zugrundeliegenden Arbeitslast kommen sofort durch. Gegenwärtig gibt es keine Möglichkeit, Statistiken über die Zeit zu erfassen — das ist rein ein Echtzeit-Snapshot der aktuellen Datenbank.

Ein Statement in seine Schritte zerlegen

Visual Explain in SQL DATA LENS projiziert den Plan eines Statements hierarchisch, mit jedem Schritt als Knoten und den Kosten an jedem Knoten sichtbar. Der Cursor in der Plan-Ansicht ist an den Cursor im Statement-Text gebunden, sodass die Auswahl eines Schritts die Klausel hervorhebt, die ihn verursacht hat, und die Auswahl eines Teils des Statements scrollt zu seinem Schritt im Plan. Sie ist nicht die übliche EXPLAIN-Ausgabe, in ein Tab-Widget geklatscht — sie ist eine Baumdialektik mit der Abfrage.

Fehlende und ungenutzte Indizes entdecken

Zwei Abfragen gegen INFORMATION_SCHEMA erscheinen als eingebaute Ansichten, sodass Sie nicht jedes Mal selbst eine schreiben müssen, wenn Sie das wollen:

• Tables Without Indexes — Tabellen, die keinen primären oder einzigartigen Schlüssel oder Index haben. Diese Tabellen werden als Heap-Strukturen gespeichert und durch Sequenzscan auf jede Abfrage gelesen, bis ein Index erstellt wird. Die Liste zeigt die Zeilenanzahl, sodass große Tabellen zuerst sortiert werden.
• Missing Indexes (aus dem Runtime Stats-Schema) — Spalten, die in WHERE-Klauseln gefiltert wurden und keinen Index hatten, der bei diesem Filter half. IRIS protokolliert diesen als „Missing Index" im Rahmen von %SYS.PTools, und die View fasst sie zusammen. Ein Join oder Filter gegen eine nicht indexierte Spalte, die zehn Mal ausgeführt wird, ist ein besserer Indexkandidat als einer, der einmal ausgeführt wird. Die Anzahl der Ausführungen macht den Unterschied, deshalb wird sie gezählt.

Das Gegenstück ist Unused Indexes, eine der Index-Statistics-Schema-Views: Sie listet jeden Index auf, mit dem Datum, an dem er zuletzt verwendet wurde, sodass Indizes, die seit Monaten nicht verwendet wurden, anhand des Datums sortiert werden können. Jeder Index, den niemand verwendet, ist einen Blick wert, denn das sind Kosten ohne Gewinn. Jedes Insert und Update schreibt in jeden Index, ob irgendein Statement daraus liest oder nicht.

Plan-Caching-Probleme entdecken

Wenn zwei Statements identisch sind, außer dass man alle Literale auf Parameter ändert, sollten sie denselben Plan teilen. Der Plan wird beim ersten Mal kompiliert, gecacht und ab dann wiederverwendet. Wenn jedes Literal im Statement dagegen direkt eingebettet wird (wie wenn Sie %SQL.Statement oder %ResultSet mit einem String verwenden, der nie Fragezeichen hat), stellt jede Ausführung eine neue Zeichenkette für den Query Compiler dar, und der Plan wird erneut kompiliert, wiederum ohne gecacht zu werden.

Beide Fälle — Statements, die denselben Plan teilen sollten und es nicht tun, und Statements, die häufig kompiliert werden — erscheinen in den Runtime Statistics und werden dort gefunden. Ein Statement mit fünftausend Ausführungen und fünftausend Kompilierungen hat ein Parameterisierungsproblem. Zwei Statements, die identisch sind, abgesehen von einem eingebetteten Wert, sind Kandidaten für dieselbe Diagnose.

Wie das ins Tuning passt

SQL DATA LENS zeigt die Statistiken, die IRIS sammelt. Es führt kein serverseitiges Performance-Management durch, es instrumentiert keinen Code, es fügt keine Indizes hinzu, und es ändert keine Abfragen neu. Was es tut, ist, diese Zahlen gut lesbar zu machen und sie mit den Objekten zu verknüpfen, über die sie sprechen: Statements, Indizes, Tabellen, Pläne. Ein Table-Scan wird gefunden, der Index-Name wird herausgenommen, die Index-Definition wird auf einem anderen Panel angesehen, und dann entscheiden Sie, ob der Index eine Priorität ist oder nicht. Das ist die Arbeit, die das Tool entschädigt wird zu tun — erklären, was passiert, in Begriffen, die sich auf Dinge im Code beziehen.

Die Performance-Werkzeuge sind in jeder Edition verfügbar, einschließlich der Free Edition. Laden Sie SQL DATA LENS herunter und finden Sie das teuerste Statement in einem Produktions-Namespace innerhalb von zwei Minuten nach dem Öffnen.