Diese Seite beschreibt Calíope 1.5, die Version, die ich gerade baue. Die 1.4 ist im App Store für Mac, iPad, iPhone, Apple Watch, Apple TV und Apple Vision Pro. Das Changelog sagt, in welcher Version jede Funktion kam.
Fügt jedem Thema einen Button „In Calíope öffnen“ hinzu. Funktioniert nur mit installierter App.
Was der Server von sich aus über die Abfragen notiert hat, die seine Schwelle überschritten haben — von allen seinen Clients.
Wo es zu finden ist: Workspace › Werkzeuge › Langsame Abfragen
Das hier hat der Server von sich aus notiert: die Abfragen, die seine Schwelle überschritten haben, von allen seinen Clients und nicht nur von Calíope. Das Abfrageprotokoll der App ist etwas anderes —was Sie von hier aus ausgeführt haben— und hat sein eigenes Werkzeug.
Die Leiste bietet bis zu drei Ansichten, und welche es gibt, entscheidet der Server: Einstellungen immer; Einträge, eine Zeile pro Ausführung, nur wenn die Engine einzelne Ausführungen speichert und einen Client lesen lässt; Pro Anweisung, die nach Abfrageform gruppierte Zusammenfassung, nur wenn die Engine sie veröffentlicht. Eine Ansicht, die der Server nicht füllen kann, wird nicht ausgegraut gezeichnet: sie wird gar nicht gezeichnet.
MySQLMariaDBAurora
Die MySQL-Familie liefert beides: mysql.slow_log speichert Ausführungen —mit Zeit, Benutzer und wörtlichem Text— und performance_schema speichert die Zusammenfassung pro Form.
PostgreSQL
PostgreSQL speichert keine Ausführungen, die ein Client lesen könnte: sein Log geht in eine Datei auf der Servermaschine. Veröffentlicht wird das Aggregat, über pg_stat_statements, deshalb sehen Sie hier Pro Anweisung und nicht Einträge.
SQL Server
SQL Server hat kein Protokoll langsamer Abfragen: weder Schwellenwert noch aufgezeichnete Ausführungen. Was er führt, immer und ohne etwas einzuschalten, ist die Zählung jedes Plans in seinem Cache, und das siehst du unter Nach Anweisung. Einträge erscheint nicht.
Um eine ganze Zeile zu sehen —den vollen Text und alles, was der Server dazu notiert hat— doppelklicken Sie sie am Mac oder tippen Sie sie am iPad an. Aus ihrer Karte lässt sich die Abfrage kopieren oder in den Editor schicken.
Die Auswahl rechts sagt, wie viele Zeilen angefordert werden: fünfzig, um zu sehen, was jetzt passiert, tausend, um den ganzen Tag durchzugehen. Die automatische Aktualisierung liest alle zehn Sekunden neu, und die Leiste sagt, wann das Gezeigte gelesen wurde.
Das Log einschalten, die Schwelle verschieben und das Ziel wählen — soweit der Server das von hier aus zulässt.
Wo es zu finden ist: Langsame Abfragen › Einstellungen
Die Karten oben sagen, was der Server in diesem Moment antwortet: ob er aufzeichnet, mit welcher Schwelle und wohin er schreibt. Darunter erscheint eines von zwei Dingen: die Bedienelemente, um es zu ändern, oder ein Hinweis, wo es wirklich geändert wird. Niemals ausgegraute Bedienelemente, die «hier nicht» nicht von «das ist kaputt» unterscheiden.
Die Schwelle wird getippt oder mit den Minus- und Plus-Tasten verschoben und mit Anwenden gesendet. Eine negative wird schon hier abgelehnt: keine Abfrage dauert kürzer als nichts, und der Server würde sie kommentarlos auf null kappen — womit jede Abfrage langsam wäre und das Log ungebremst wachsen würde.
MySQLMariaDBAurora
Die Schwelle steht in Sekunden (long_query_time), und das Ziel wird zwischen der Tabelle mysql.slow_log, der Datei des Servers oder beidem gewählt (log_output). Nur was in die Tabelle geht, kann ein Client lesen.
Zwei Dinge, die überraschen: eine Änderung von hier übersteht keinen Neustart des Servers —dafür gehört sie in seine Konfigurationsdatei— und erreicht bereits offene Verbindungen nicht, auch nicht die von Calíope: laufende Sitzungen messen mit dem alten Wert weiter, bis sie recycelt werden.
Aurora
Bei Amazon Aurora liegen diese Einstellungen nicht im Server, sondern in der Parametergruppe des Clusters, deshalb sehen Sie hier den Hinweis statt der Bedienelemente. Das Log leeren geht trotzdem: das macht der Server selbst mit mysql.rds_rotate_slow_log.
PostgreSQL
Die Schwelle steht in Millisekunden (log_min_duration_statement), und eine Änderung von hier bleibt bestehen: sie wird mit ALTER SYSTEM geschrieben, und der Server lädt seine Konfiguration neu.
Es gibt aber Quellen, die ihr stillschweigend vorgehen. Kommt der Wert von der Befehlszeile, mit der der Server gestartet ist, oder von einer Einstellung dieser Datenbank, dieser Rolle oder dieser Sitzung, wird der Schreibvorgang angenommen, die Datei enthält den neuen Wert und wirksam bleibt der alte. Deshalb ist die erste Variable in der Liste unten die Herkunft der Schwelle: sie sagt, wo sie geändert werden muss. Ist die Herkunft eine davon, sehen Sie hier den Hinweis und nicht die Bedienelemente.
Das Ziel ist keine Wahl: PostgreSQL schreibt immer in sein eigenes Log, eine Datei auf der Servermaschine.
SQL Server
In SQL Server gibt es nichts einzustellen: Der Plancache zählt immer mit und hat weder Schwellenwert noch Ziel zur Auswahl. Deshalb erscheint die Schwellenwert-Karte nicht, und du siehst den Hinweis statt der Steuerelemente. Was gelesen wird, liegt im Arbeitsspeicher des Servers: Es geht beim Neustart verloren, und ein Plan, der den Cache verlässt, nimmt seine Zahlen mit. Mit eingeschaltetem optimize for ad hoc workloads kommt eine einzelne Abfrage erst bei ihrer zweiten Ausführung hinein.
Die Liste am Ende sind die Variablen, die dieser Server rund um das Log veröffentlicht, mit den Namen, die er ihnen gibt. Sie sind informativ: sie ändern sich dort, wo ihre eigenen Einstellungen geändert werden, nicht hier.
Stichwörter: Schwelle, long_query_time, log_min_duration_statement, log_output, ALTER SYSTEM, parameter group
Sie gruppiert nach Abfrageform, nicht nach Ausführung: sie sagt, was den Server den Tag kostet.
Wo es zu finden ist: Langsame Abfragen › Nach Anweisung
Pro Anweisung listet keine Ausführungen: es gruppiert nach der Form der Abfrage. Literale werden durch einen Platzhalter ersetzt, also sind tausend Abfragen, die sich nur im gesuchten Wert unterscheiden, eine Zeile — mit ihren Aufrufen, ihrer Gesamtzeit und ihrer Durchschnittszeit. Das antwortet auf «was kostet diesen Server den Tag?», und das ist fast nie die langsamste Einzelabfrage.
MySQLMariaDBAurora
Veröffentlicht wird es von performance_schema, und Literale erscheinen als ?. Auf MariaDB ist es ab Werk aus: wenn diese Ansicht sagt, es gebe keine Zusammenfassung, heißt das nicht, dass es keine langsamen Abfragen gibt — es heißt, performance_schema steht auf OFF. Im laufenden Betrieb lässt es sich nicht einschalten: es gehört in die Konfigurationsdatei, und der Server muss neu starten.
PostgreSQL
Veröffentlicht wird es von pg_stat_statements, und Literale erscheinen als $1. Es braucht zwei Dinge, beide außerhalb der App: die in shared_preload_libraries vorgeladene Bibliothek, was einen Neustart des Servers verlangt, und die in dieser Datenbank erzeugte Erweiterung, einmal pro Datenbank:
CREATE EXTENSION pg_stat_statements;
Ist die Erweiterung erzeugt und die Bibliothek nicht geladen, existiert die Sicht und sammelt nichts. Das sind zwei verschiedene Zustände, und das Werkzeug sagt, welcher vorliegt.
SQL Server
Es stammt aus sys.dm_exec_query_stats, gruppiert nach query_hash, der Form der Abfrage. Der angezeigte Text ist der einer ihrer Ausführungen, mit ihren Literalen, keine Form mit Platzhaltern. Zum Lesen braucht es die Berechtigung VIEW SERVER STATE; ohne sie zeigt die Ansicht den Fehler des Servers. Statistiken zurücksetzen erscheint nicht: Diese Übersicht zu leeren wäre DBCC FREEPROCCACHE, das die Pläne des ganzen Servers verwirft, und das geschieht nicht von hier aus.
Die Zusammenfassung gehört dem ganzen Server, also zählen Rechte: wo Ihr Benutzer die Abfragen der anderen nicht lesen darf, gibt der Server die Zeile ohne den Text zurück. Wenn das passiert, wird es hier mit der Zahl gesagt —wie viele weitere Formen Sie nicht lesen können—, und das ist etwas ganz anderes als eine leere Liste.
Statistik zurücksetzen setzt diese Zähler für den ganzen Server auf null, nicht für Ihre Sitzung: es trifft jeden, der dieselbe Zusammenfassung ansieht, und ist nicht rückgängig zu machen.
Stichwörter: Zusammenfassung, pro Anweisung, performance_schema, pg_stat_statements, normalisiert, Rechte
Das Log sagt, welche Abfrage langsam ist; um das Warum zu erfahren, schickt man sie in den Editor und profiliert sie dort.
Wo es zu finden ist: Langsame Abfragen › Rechtsklick › In den Editor übernehmen
Das Log sagt, welche Abfrage langsam ist. Um das Warum zu erfahren, muss die Abfrage erneut laufen, und das ist Ihre Entscheidung — nicht die einer Liste, die sich alle zehn Sekunden aktualisiert.
Aus einer Zeile heraus, über ihr Kontextmenü oder durch Öffnen ihrer Karte, legt In den Editor übernehmen die Abfrage im SQL-Editor ab, in einem Tab, ohne sie auszuführen. Dort entscheiden Sie, was damit geschieht.
MySQLMariaDBAurora
Ausführen und Profilen drücken, um die Aufschlüsselung nach Phasen zu sehen, oder die Engine mit visuellem EXPLAIN nach ihrem Plan fragen.
PostgreSQLSQL Server
Die Engine mit visuellem EXPLAIN nach ihrem Plan fragen. Profilen, die Aufschlüsselung nach Phasen, gehört zur MySQL-Familie und erscheint hier nicht im Editor.
Bevor Sie ausführen, was eine Zeile mitbringt: Der Text ist der, den ein anderer Client ausgeführt hat, mit seinen Parametern und gegen die Datenbank, die er offen hatte.
MySQLMariaDBAuroraPostgreSQL
Und aus der Zusammenfassung pro Anweisung kommt die normalisierte Form, mit Platzhaltern statt Werten: Sie müssen eigene Werte einsetzen, bevor Sie sie ausführen.
SQL Server
Aus der Zusammenfassung pro Anweisung kommt der Text einer ihrer Ausführungen, mit deren Werten: Die Zeile steht für alle Ausführungen derselben Form.
Stichwörter: profilieren, Profiler, Editor, explain, Plan, in den Editor schicken