Das Schema, das nur in der laufenden Datenbank lebt

Alles, was dieser Dienst tut, steht in der Versionsverwaltung. Der Code jedenfalls. Die Datenbank, auf der er läuft, sind 32 Tabellen, und 15 davon haben nirgends im Repo eine Definition — kein CREATE TABLE, keine Schemadatei, nichts. Ginge der Server verloren, käme der Code genau zurück, und die Form der Daten müsste man daraus rekonstruieren, wonach der Code zufällig fragt.

Diese Zahlen stammen aus einem Vergleich der laufenden Datenbank mit 736 Dateien und 5.671.710 Zeichen Repo. Sie sind nicht geschätzt.

Wie ein halbes Schema abhandenkommt

Es ist keine Schlamperei, und genau das macht es aufschreibenswert. Jeder einzelne Schritt war vernünftig.

Tabellen, die vor dem heutigen Code entstanden, wurden nie aufgeschrieben, weil sie damals einfach da waren. Tabellen, die seither hinzukamen, kamen über Migrationsskripte, und die stehen schon im Repo — daher stammen die 17 Definitionen. Spalten, die später dazukamen, kamen mit einem einzeiligen ALTER TABLE an der Eingabezeile, weil Tippen schneller war als ein Skript für eine Änderung, die eine Sekunde dauert.

Am schlimmsten sind die Indizes. Ein Index wird angelegt, wenn etwas langsam ist, in dem Moment, in dem es langsam ist, und er behebt das sofort. Es bleibt kein Erzeugnis zurück, nichts zum Durchsehen, nichts, was fehlschlägt, wenn man es vergisst. Elf der zweiunddreißig Sekundärindizes hier gibt es aus genau diesem Grund, und aufgezeichnet sind sie nirgends.

Die Tabelle, in der die Zähler selbst stehen, 166.438 Zeilen davon, gehört zu den fünfzehn ohne Definition im Repo.

Was tatsächlich kaputtgeht

Wenig, bis zu einem bestimmten Augenblick: wenn die Datenbank aus einem Abzug zurückgespielt wird.

Ein Abzug trägt die Struktur mit, ein glattes Zurückspielen ist also in Ordnung. Gefährlich ist jeder Weg, der eine Tabelle neu aufbaut statt sie zurückzuspielen — ein Umzug auf eine andere Maschine, das Einspielen einzelner Tabellen, das Neuanlegen aus einem Skript. Die Daten kommen zurück, die Indizes still nicht. Nichts schlägt fehl. Die Abfragen liefern die richtigen Antworten. Sie brauchen nur länger, und die Ursache ist unsichtbar, weil die einzige Aufzeichnung dessen, was der Index war, auf der Maschine liegt, die ihn nicht mehr hat.

Das ist der Fehler, den man benennen sollte: ein fehlender Index erzeugt keinen Fehler, er erzeugt eine langsamere richtige Antwort. Dafür gibt es keinen Test, denn die Tests laufen durch.

Was wir bis dahin tun

Die ehrliche Lage ist, dass das nicht behoben ist. Das Schema steht heute nicht im Repo. Was es gibt, ist kleiner als eine Behebung und besser als nichts:

Ein Abzug vor allem Zerstörerischen, aufbewahrt außerhalb des Web-Verzeichnisses. Ein Zurückspielen, das wirklich einmal durchgeführt wurde statt angenommen. Und eine kurze Liste, nach jedem Zurückspielen geprüft, der Indizes, von denen man weiß, dass es sie nur in der laufenden Datenbank gibt — denn die Maschine lässt sich fragen, welche Indizes sie hat, und die Antwort lässt sich mit der vom letzten Mal vergleichen.

Die allgemeine Fassung gilt für mehr als Datenbanken. Wenn ein Teil des Systems nur im laufenden System steht, hat man keine Kopie davon, sondern eine Geisel. Die Frage, die sich für jedes Stück Technik lohnt, ist nicht „ist es gesichert", sondern „was ließe sich, wenn diese Maschine verschwände, nicht aus dem Repo wiederherstellen". Hier lautet die Antwort fünfzehn Tabellen und elf Indizes, und es hat einen Nachmittag gekostet, das herauszufinden.