Datenbank-Services

Wir beginnen bei den Fakten: Slow-Query-Logs, Ausführungspläne der teuersten Endpunkte, Tabellen- und Indexgrößen, Cache-Trefferquoten, Verbindungszahlen und die Frage, wo das Transfervolumen tatsächlich entsteht. In der Regel zeigt sich eine überschaubare Zahl von Abfragen, die den Großteil der Last verursachen — deutlich nützlicher als ein pauschales Audit über alles.

Wir prüfen, ob das Modell zur realen Nutzung passt: wo Normalisierung die Integrität schützt, wo eine bewusste Denormalisierung einen teuren Join einspart und wo fehlende Constraints oder unscharfe Datentypen stillschweigend fehlerhafte Datensätze zulassen. Mandantenfähige Systeme betrachten wir gesondert, weil Trennung durch das Schema erzwungen werden muss und nicht dadurch, dass jemand an einen Filter denkt.

Indizes entstehen für Abfragen, die es gibt, nicht für Spalten, die wichtig aussehen; ungenutzte Indizes entfernen wir, weil jeder Index Schreibdurchsatz und Speicher kostet. Parallel beheben wir die üblichen Verursacher: N+1-Zugriffe, das Lesen aller Spalten breiter Tabellen, zeilenweise Roundtrips, die in ein aggregierendes Statement gehören, und Pagination, die für Seite fünfzig die gesamte Tabelle durchläuft.

Serverless- und Edge-Deployments öffnen Verbindungen auf eine Weise, für die klassisches Pooling nie ausgelegt war; das Fehlerbild ist keine allmähliche Verlangsamung, sondern eine plötzliche Wand aus Verbindungsfehlern unter Last. Wir dimensionieren den Pool, platzieren einen Pooler korrekt, halten Transaktionen kurz und verlagern leselastige Arbeit auf gecachte oder replizierte Pfade, wo es sinnvoll ist.

Schema- und Plattformmigrationen planen wir als umkehrbare Schritte: neue Struktur anlegen, doppelt schreiben, historische Daten in Batches nachziehen, Lesezugriffe umstellen, alte Struktur später entfernen. Wir proben auf einer Kopie mit produktionsnaher Datenmenge, messen die tatsächliche Dauer jedes Schritts und legen Cutover-Fenster sowie Rollback-Kriterium fest, bevor jemand die Produktion anfasst.

Wir prüfen Backup-Intervall, Aufbewahrung und Point-in-Time-Recovery durch eine echte Wiederherstellung und dokumentieren anschließend die Recovery-Prozedur, die alarmwürdigen Monitoring-Signale und das Schema selbst. Ziel ist, dass Ihr Team die Datenbank auch ohne uns betreiben kann und uns für die schwierigen Aufgaben behält statt aus Abhängigkeit.