Viele IT-Leiter klingen erstaunlich gelassen, wenn es um ihre Datenbanken geht. „Mit meinen SQL Servern läuft alles einwandfrei“ ist ein Satz, den man häufig hört. Doch wer sich ein wenig intensiver mit Datenbanken beschäftigt, ahnt schnell: ganz so reibungslos ist es selten. Vieles, was nach außen hin stabil wirkt, beruht in Wahrheit auf einer Mischung aus Gewohnheit, Pragmatismus und einer Portion Schweigen über die weniger glänzenden Seiten des Betriebs.
Ein klassisches Beispiel ist die Performance. Solange Abfragen Ergebnisse liefern, gilt das System als funktionierend. Dass manche Prozesse längst zehn oder zwanzig Sekunden benötigen, wird hingenommen. Nutzer arrangieren sich damit, und die IT stuft es nicht als akutes Problem ein. Query-Optimierungen sind aufwendig und bringen selten sofort sichtbaren Ruhm – also schiebt man sie gerne auf.
Noch heikler ist das Thema Sicherheit. SQL Server selbst bietet zahlreiche Möglichkeiten, um Zugriffe sauber zu regeln, Daten zu verschlüsseln oder Verbindungen abzusichern. Doch in vielen Umgebungen sieht die Praxis anders aus. Rechte werden großzügig vergeben, weil es bequem ist. Backups laufen unverschlüsselt, weil niemand den zusätzlichen Aufwand treiben möchte. Und Patches? Die kommen zwar monatlich, aber in Produktionssysteme gelangen sie oft erst sehr verspätet – wenn überhaupt. Die Angst, mit einem Update einen Ausfall zu provozieren, wiegt schwerer als die Sorge vor einer Sicherheitslücke.
Auch die Hochverfügbarkeit wirkt auf dem Papier besser, als sie in Wirklichkeit ist. Ja, es gibt Cluster, Always-On-Verfügbarkeitsgruppen und regelmäßige Backups. Aber wie viele Teams haben in den letzten zwölf Monaten tatsächlich einen Restore durchgespielt? Wie oft wurde der Failover-Mechanismus getestet? Die bittere Wahrheit: in vielen Fällen bleibt es bei der Theorie. Läuft das System, wird es nicht angefasst – auch wenn man tief im Inneren ahnt, dass es im Ernstfall nicht so glatt funktionieren würde.
Hinzu kommt die stille Gefahr des Wachstums. Datenbanken blähen sich über Jahre hinweg auf. TempDBs laufen irgendwann über, Tabellen werden riesig, und plötzlich tauchen Probleme auf, die man „so ja noch nie hatte“. Doch wer spricht schon gern über solche Risiken, wenn der Chef zufällig fragt, wie es mit den Servern läuft?
Und schließlich gibt es den menschlichen Faktor. Manche Administratoren wissen ganz genau, dass es Baustellen gibt, doch sie rühren sie nicht an. Zu groß ist die Sorge, beim Aufräumen mehr kaputtzumachen als zu verbessern. Also bleibt es bei der Haltung: solange kein Alarm schrillt, läuft alles. Nach außen wirkt das souverän, nach innen ist es eher ein Balanceakt.
Wenn also jemand behauptet, dass seine SQL Server „einwandfrei“ laufen, sollte man das mit einem gesunden Maß an Skepsis betrachten. Meist bedeutet es: Es gibt aktuell keine brennenden Probleme, die das Tagesgeschäft stören. Dass unter der Oberfläche Optimierungen, Absicherungen und echte Tests fehlen, bleibt unausgesprochen. Wirklich einwandfrei läuft ein SQL Server nur dann, wenn man sich regelmäßig um die weniger bequemen Themen kümmert – und die hört man im Alltag leider eher selten.
