SQL-Konsole für Produktionsdatenbanken: lesen, und ändern nur mit Vorschau

1. 01

   Änderungen erlauben

   Wer „Operations“ verwalten darf, schaltet Änderungen für den Workspace ein. Danach erscheint pro Tab „Allow changes“ – für alle, die zusätzlich auf Datenbanken ausführen dürfen.

2. 02

   Vorschau

   Die Anweisung läuft in einer Transaktion, die zurückgerollt wird, und sagt, was sie täte: „UPDATE would change 37 rows“, mit den Zeilen aus RETURNING. Gespeichert ist noch nichts.

3. 03

   Übernehmen

   „Apply changes“ führt genau die geprüfte Anweisung mit denselben Werten aus. DROP, TRUNCATE und UPDATE oder DELETE ohne WHERE fragen vorher nach dem Datenbanknamen.

4. 04

   Nachweis

   Vorschau und Übernahme stehen im Audit-Log: Anweisung, geänderte Zeilen, Person und Zeit.

Änderungen laufen mit dem Login der Datenbank selbst, weil nur er die Struktur ihrer Tabellen ändern darf; der Lese-Login der Konsole wird dafür nie erweitert. Nicht möglich sind Datenbanken, Rollen und Rechte, Erweiterungen, COPY und Sitzungsbefehle – Nutzer und Stufen verwaltet Clusterward auf der Instanzseite. Strukturänderungen bei MySQL lassen sich nicht vorab prüfen, weil MySQL sie sofort festschreibt; die Konsole sagt das und fragt nach dem Datenbanknamen. Rückgängig machen kann die Konsole eine Änderung nicht – vor einem großen Eingriff legen Sie auf der Instanzseite ein Backup an.

• Kann die SQL-Konsole Daten ändern?

  Nur wenn Sie es erlauben. Abfragen laufen mit einem eigenen Login mit Leserecht in einer Nur-Lese-Transaktion, die danach zurückgerollt wird – jede dieser Schichten verhindert Schreiben schon allein. Änderungen sind ein eigener Weg: Ein Schalter erlaubt sie für den Workspace, dann zeigt jeder Tab „Allow changes“. Jede Änderung läuft zuerst als Vorschau, die zurückgerollt wird und sagt, wie viele Zeilen sie ändern würde; „Apply changes“ führt genau diese Anweisung aus. DROP, TRUNCATE und UPDATE oder DELETE ohne WHERE fragen nach dem Datenbanknamen. Datenbanken, Rollen und Rechte lassen sich über die Konsole nie ändern.

• Welche Datenbanken kann ich abfragen?

  PostgreSQL- und MySQL-Datenbanken auf Scaleway, deren Instanz an einem Cluster hängt – also alle, die Clusterward mit einem Cluster angelegt hat. Sie sehen nur Datenbanken, die Sie auch auf ihrer Seite öffnen dürften.

• Wer darf die SQL-Konsole benutzen?

  Wer die Berechtigung „Operations“ hat: Ansehen zeigt die Seite, Ausführen startet Abfragen, Verwalten ändert die Grenzen des Workspaces. Dazu kommt mindestens Ansehen auf Datenbanken. Bestehende Rollen starten ohne diese Berechtigung, API-Tokens können die Konsole nicht nutzen. Änderungen übernehmen darf nur, wer „Operations“ verwalten und auf Datenbanken ausführen darf – und nur, wenn der Workspace Änderungen erlaubt. KI-Assistenten erreichen die Konsole ebenfalls nicht.

• Was steht im Audit-Log?

  Der Text der Abfrage, die Datenbank, die Zahl der Zeilen und die Dauer, dazu wer wann gefragt hat. Ergebniswerte werden nie gespeichert – das Audit-Log soll keine zweite Kopie Ihrer Kundendaten werden. Werte von Parametern stehen mit im Eintrag, außer bei Namen, die nach einem Geheimnis klingen. Nach 12 Monaten löscht Clusterward den Eintrag automatisch, wie jeden Audit-Eintrag. Jede Vorschau und jede übernommene Änderung steht ebenfalls darin, mit der Anweisung und der Zahl geänderter Zeilen.

• Was, wenn eine Änderung falsch war?

  Die Konsole kann eine übernommene Änderung nicht rückgängig machen. Darum zeigt die Vorschau vorher, wie viele Zeilen betroffen sind, und große Eingriffe fragen nach dem Datenbanknamen. Vor einem größeren Eingriff legen Sie auf der Instanzseite unter Backups eine Sicherung an; eine Wiederherstellung landet in einer neuen Datenbank, die laufende bleibt unberührt.

• Kann ich Ergebnisse herunterladen?

  Ja, als CSV, als CSV für Excel (mit Semikolon und korrekten Umlauten) oder als JSON – mit den Spalten in der Reihenfolge, die Sie gerade sehen. Die Datei entsteht in Ihrem Browser. Im Audit-Log steht die Abfrage, nie ihr Ergebnis. Werte, die mit =, +, - oder @ beginnen, bekommen ein Apostroph vorangestellt, damit Excel sie nicht als Formel ausführt.

• Kann ich Abfragen speichern und im Team teilen?

  Ja. Eine gespeicherte Abfrage ist privat oder für den ganzen Workspace sichtbar. Parameter wie :kunde füllen Sie beim Ausführen; die Werte gehen als gebundene Parameter an die Datenbank, nie in den Text. Ein Link öffnet eine Abfrage in einem neuen Tab, ohne sie auszuführen – so bleibt jede Ausführung eine bewusste.

• Was tun, wenn eine Abfrage zu lange läuft?

  Abbrechen stoppt genau Ihre Anweisung in der Datenbank. Warum sie langsam war, zeigt der Abfrageplan: EXPLAIN als Baum mit dem teuersten Schritt markiert, bei PostgreSQL auf Wunsch mit echten Zeilen und Zeiten. Die Diagnosen zeigen zudem lange Abfragen, Sperren und ungenutzte Indizes der Datenbank.

• Muss ich im Cluster etwas installieren?

  Nein. Die erste Abfrage startet einen kleinen Query-Runner im Cluster; das dauert bis zu einer Minute, weil er beim Start seine Datenbanktreiber lädt und dafür ausgehenden Zugriff auf die npm-Registry braucht. Cluster, deren Operator-Identität älter ist als die Konsole, erneuern diese einmal im Cockpit. Unter Infrastructure → SQL console sehen Sie pro Cluster, ob der Runner läuft und was er an CPU und Speicher nutzt und reserviert; „Remove runner…“ gibt die Reservierung bis zur nächsten Abfrage frei.

• Was passiert mit dem Lese-Login, wenn die Datenbank gelöscht wird?

  Er lebt und stirbt mit seiner Datenbank. Wird sie gelöscht oder der zugehörige Kunde offboardet, verschwindet auch der Login der Konsole.

Ihre Frage ist nicht dabei? Schreiben Sie uns, wir antworten in der Regel am selben Werktag.