Diese Seite beschreibt Calíope 1.8, die Version, die ich gerade baue. Die 1.7 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.
TiDB
TiDB liefert beides, aus anderen Tabellen: die Ausführungen kommen aus CLUSTER_SLOW_QUERY, das die Datei tidb-slow.log jedes Knotens liest —ohne die Abfragen, die TiDB selbst startet—, und die Zusammenfassung pro Form aus STATEMENTS_SUMMARY.
PostgreSQL
PostgreSQL schreibt die Ausführungen in seine Logdatei, und Calíope liest sie per SQL (pg_ls_logdir() und pg_read_binary_file()), wenn der Server den Collector an hat (logging_collector = on), ein Format mit einer Zeile pro Ausführung (jsonlog oder csvlog in log_destination) und dein Konto sie lesen darf (pg_monitor und pg_read_server_files); fehlt etwas, sagt Einträge, was. Das Aggregat kommt aus pg_stat_statements, unter Nach Anweisung.
SQL Server
SQL Server hat kein eigenes Protokoll langsamer Abfragen, also legt Calíope eines an: eine Extended-Events-Sitzung, caliope_slow_statements, die jede Anweisung über dem Schwellenwert aufzeichnet. Das sind die Einträge, und die Sitzung wird unter Einstellungen eingeschaltet. Nach Anweisung ist etwas anderes: die Zählung, die der Server immer für jeden Plan in seinem Cache führt.
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. Calíopes eigene ausblenden blendet aus, was Calíope von sich aus abfragt —seine Anweisungen beginnen mit der Marke /*Caliope*/—, nie das, was du im Editor geschrieben hast.
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 nicht ablehnen: je nach Engine kappt er sie auf null —womit jede Abfrage langsam wäre und das Log ungebremst wachsen würde— oder macht kommentarlos einen anderen Wert daraus.
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.
TiDB
Die Schwelle ist tidb_slow_log_threshold, und der Server führt sie in Millisekunden: hier wird sie in Sekunden eingegeben, wie bei den anderen Engines, und die Liste am Ende zeigt den Wert des Servers mit seiner Einheit. long_query_time gibt es und steuert nichts. Eine negative Schwelle läuft bei TiDB über und wird so hoch, dass nichts mehr protokolliert wird.
Das Ziel wird nicht gewählt: TiDB schreibt immer in die Datei jedes Knotens und veröffentlicht sie als Tabelle. Eine Änderung von hier gilt sofort für alle Verbindungen zu diesem Knoten, auch die von Calíope, und hält bis zum Neustart des Knotens: dann gilt wieder der Wert aus seiner Konfiguration.
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 wird nicht hier gewählt: PostgreSQL schreibt immer in sein eigenes Log, eine Datei auf der Servermaschine, und Einträge liest es per SQL, wenn Collector und Format gesetzt sind.
SQL Server
In SQL Server legt der Schalter die Extended-Events-Sitzung caliope_slow_statements an und startet sie, oder er hält sie an. Sie gilt für den ganzen Server: Sie zeichnet die Anweisungen aller Verbindungen auf und startet mit STARTUP_STATE = ON mit ihm neu. Der Schwellenwert ist ihr Prädikat (duration, auf dem Server in Mikrosekunden), und Schreibt nach wählt zwischen Der Arbeitsspeicher des Servers, bis zum Neustart (ein ring_buffer, der etwa tausend behält) und Eine Datei des Servers (eine event_file in seinem Datenverzeichnis). Sie zu ändern braucht die Berechtigung ALTER ANY EVENT SESSION, und ohne sie nennt die Ablehnung sie; sie zu lesen, VIEW SERVER STATE. Calíopes eigene ausblenden blendet aus, was Calíope von sich aus abfragt und die Marke /*Caliope*/ trägt; was du im Editor schreibst, bleibt immer sichtbar. Die Übersicht Nach Anweisung kommt weiter aus dem Plancache: Sie geht beim Neustart des Servers verloren, und mit 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. Darunter listet Variablen, die das Protokoll feinjustieren sechs Einstellungen dazu, was von jeder Abfrage gespeichert wird —ab welcher Phase (log_queries_min_type), welcher Anteil (log_queries_probability), wo der Text abgeschnitten wird und ob die Einstellungen, Threads und Views gespeichert werden, die sie berührt hat—, mit dem Wert Ihres Kontos; wo das Konto seine Einstellungen speichern kann, hat jede ein Feld und Anwenden und wird wie der Schwellenwert geschrieben.
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.
TiDB
Sie kommt aus STATEMENTS_SUMMARY, und Literale erscheinen als ?. Sie sammelt nicht seit dem Start: es ist das laufende Fenster, das der Server alle tidb_stmt_summary_refresh_interval Sekunden (standardmäßig 1800) schließt und neu öffnet, also zählen die Aufrufe ab dem Beginn dieses Fensters. Ist die Zusammenfassung aus (tidb_enable_stmt_summary), lässt sie sich ohne Neustart einschalten, mit SET GLOBAL. Statistik zurücksetzen erscheint nicht: es gibt keine Anweisung, die sie leert.
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 › Kontextmenü › 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.
MySQLMariaDBAuroraClickHouseOracle
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, erscheint nicht im Editor: Diese Engine liefert sie nicht.
TiDB
Die Engine mit visuellem EXPLAIN nach ihrem Plan fragen. Profilen, die Aufschlüsselung nach Phasen, erscheint nicht im Editor: TiDB hat sie nicht.
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.
MySQLMariaDBAuroraPostgreSQLTiDB
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: Die Ausführungen sind das Log des Servers, das ein Client nicht löscht; der Server rotiert es.
ClickHouse
Mit ClickHouse gibt es beide, und das Zurücksetzen der Statistiken löscht auch die Ausführungen, weil es dieselbe Tabelle ist.
Oracle
Bei Oracle wird keines von beiden angeboten.
SQL Server
Bei SQL Server hält Protokoll leeren die Sitzung an und startet sie neu, was den Arbeitsspeicher leert; schreibt sie in eine Datei, wechselt sie in eine neue, und die alte bleibt im Datenverzeichnis des Servers, ohne wieder gelesen zu werden. Statistiken zurücksetzen erscheint nicht: Das wäre DBCC FREEPROCCACHE, das die Pläne des ganzen Servers verwirft.
TiDB
Mit TiDB wird keine angeboten: das Log ist eine Datei auf jedem Knoten, und die Zusammenfassung erneuert sich mit jedem Fenster von selbst.