Diese Seite beschreibt Calíope 1.7, die Version, die ich gerade baue. Die 1.6 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 du von hier aus ausgeführt hast— 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 siehst du 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— doppelklick sie am Mac oder tipp 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.
Oracle
Oracle hat kein Protokoll langsamer Abfragen: weder einen Schwellenwert des Servers noch einzeln aufgezeichnete Ausführungen. Gelesen wird der Anweisungscache (V$SQL), der die Zahlen jeder Anweisung führt, solange sie darin bleibt. Einträge zeigt eine Zeile pro Anweisung in ihrer durchschnittlichen Ausführung —Zeit, CPU, Lesevorgänge und Zeilen geteilt durch die Zahl der Ausführungen, die daneben steht— und Nach Anweisung die nach Form gruppierte Zusammenfassung. Es ist kein Verlauf: Eine Anweisung, die den Cache verlässt, verschwindet mit ihren Zahlen, und ein Neustart leert ihn. Die internen Abfragen von SYS und SYSTEM erscheinen nicht, außer deinen eigenen, wenn du dich mit einem dieser Konten anmeldest. Das Lesen von V$SQL erfordert ein Wörterbuchprivileg (SELECT_CATALOG_ROLE oder SELECT ANY DICTIONARY); ohne es zeigt der Bildschirm den Fehler des Servers. AWR und die Views DBA_HIST_* werden nicht abgefragt: Sie erfordern ein kostenpflichtiges Oracle-Paket.
ClickHouse
ClickHouse liefert beides aus system.query_log: die Ausführungen, gelesen direkt nach einem SYSTEM FLUSH LOGS, damit das gerade Ausgeführte schon dabei ist, und die Zusammenfassung nach Form. Die Ausführungen enthalten auch die fehlgeschlagenen, mit ihrem Fehler in einer eigenen Spalte, und bringen die gelesenen Bytes und den Speicher hinter der Zeit; die Uhrzeit ist die Uhr des Servers. Calíopes eigene ausblenden, standardmäßig an, blendet aus, was Calíope von sich aus abfragt, nie das, was du im Editor geschrieben hast.
Apple Vision Pro: wie auf dem iPad: Sieh die Zeile an und führe Daumen und Zeigefinger zusammen, um sie zu öffnen.
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 siehst du 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, siehst du 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.
Oracle
In Oracle gehört der Schwellenwert zu Calíope, nicht zum Server: Er wird beim Lesen auf die durchschnittliche Ausführung jeder Anweisung angewendet und in diesem Profil gespeichert. Ihn zu ändern berührt nichts auf dem Server und gilt ab dem nächsten Lesen. Er ist in Sekunden angegeben, obwohl der Cache die Zeit in Mikrosekunden zählt; wenn du ihn nicht geändert hast, ist es eine Sekunde. Es gibt keinen Schalter —der Cache lässt sich nicht ausschalten— und kein Ziel zur Auswahl: Was gelesen wird, liegt im Speicher des Servers.
ClickHouse
Der Server führt den Schwellenwert in Millisekunden (log_queries_min_query_duration_ms), auch wenn er hier in Sekunden gezeigt wird, und das Ziel ist immer system.query_log. Schalter und Schwellenwert werden in deinem eigenen Konto gespeichert, mit ALTER USER … MODIFY SETTINGS, und gelten für die Abfragen dieses Kontos ab der nächsten, nicht für die der anderen. Ist das Konto in der Serverkonfiguration definiert oder fehlt ihm ALTER USER, siehst du den Hinweis statt der Bedienelemente. Das Protokoll zu leeren ist TRUNCATE TABLE system.query_log, für den ganzen Server.
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 View 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 dein 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 du nicht lesen kannst—, 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 deine Sitzung: es trifft jeden, der dieselbe Zusammenfassung ansieht, und ist nicht rückgängig zu machen.
Oracle
Sie stammt aus V$SQL, gruppiert nach FORCE_MATCHING_SIGNATURE: Zwei Abfragen, die sich nur in einem Literal unterscheiden, sind eine Zeile, und der angezeigte Text ist der einer von ihnen. Anweisungen ohne diese Signatur —PL/SQL-Blöcke, DDL— werden nach ihrer SQL_ID gruppiert. Die Zusammenfassung wendet den Schwellenwert nicht an, und das Maximum ist die langsamste durchschnittliche Ausführung unter den gruppierten: Der Cache speichert nicht jede Ausführung. Statistiken zurücksetzen erscheint nicht, ebenso wenig Protokoll leeren in Einträge: Beides hieße, den gemeinsamen Cache des ganzen Servers zu leeren.
ClickHouse
Sie kommt aus system.query_log, gruppiert nach normalized_query_hash: Zwei Abfragen, die sich nur in einem Literal unterscheiden, sind eine Zeile, und der angezeigte Text ist der einer von ihnen. Statistiken zurücksetzen leert genau diese Tabelle und nimmt damit auch die Ausführungen mit, und die Bestätigung sagt es.
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 deine 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 entscheidest du, was damit geschieht.
MySQLMariaDBAuroraClickHouse
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 ServerOracle
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 du ausführst, 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: Du musst eigene Werte einsetzen, bevor du sie ausführst.
SQL ServerClickHouseOracle
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
Das Protokoll leeren und die Zusammenfassung zurücksetzen
Was jede Schaltfläche auf dem Server löscht und bei welchen Engines sie erscheint.
Wo es zu finden ist: Workspace › Werkzeuge › Langsame Abfragen
Zwei Schaltflächen löschen, was der Server aufgezeichnet hat, und keine lässt sich rückgängig machen.
- Protokoll leeren löscht in Einträge die aufgezeichneten Ausführungen.
- Statistiken zurücksetzen setzt in Nach Anweisung die Zusammenfassung des ganzen Servers auf null zurück, nicht nur deine.
Beide Bestätigungen nennen, wie viele Zeilen wegfallen, vor der Frage auf dem Server gezählt, und laufen über den Schutz des Umgebungsetiketts. Sie erscheinen nur, wo die Engine es erlaubt und die Sitzung schreiben darf.
MySQLMariaDBAurora
Mit MySQL, MariaDB und Aurora gibt es beide Schaltflächen.
PostgreSQL
Mit PostgreSQL gibt es nur das Zurücksetzen der Statistiken.
ClickHouse
Mit ClickHouse gibt es beide, und das Zurücksetzen der Statistiken löscht auch die Ausführungen, weil es dieselbe Tabelle ist.