Praxisnahe Artikel über ClickHouse, SQL Server, Analytics-Architektur, Performance, Migration und Datenbankbetrieb.
Ein praxisnaher Leitfaden, um parameterabhängige Ausführungspläne in SQL Server zu erkennen, die Ursache zu belegen und die risikoärmste Lösung zu wählen.
Artikel lesenEin Job kann erfolgreich melden, obwohl Datenbanken übersprungen, keine Zeilen verarbeitet oder Fristen verpasst wurden. Der Endstatus beweist nicht das gewünschte Ergebnis.
Artikel lesenTemporäre Tabellen und Tabellenvariablen speichern Zwischenergebnisse, doch Statistiken, Kompilierung, Indizierung und Transaktionen können sehr unterschiedliche Pläne erzeugen.
Artikel lesenRow- und Page-Compression reduzieren Speicher und I/O, benötigen aber CPU und helfen nicht jeder Tabelle gleich. Die Entscheidung hängt von Datenform und Last ab.
Artikel lesenPartitionierung wird oft als automatische Performancefunktion dargestellt. Ihre größten Vorteile liegen meist in Lebenszyklus, Sliding Window, Archivierung und Wartungsgrenzen.
Artikel lesenDynamisches SQL ist für optionale Filter und variable Abfrageformen nützlich. Stringverkettung erzeugt jedoch Injection-Risiken, Quote-Fehler, schlechte Planwiederverwendung und schwierige Fehlersuche.
Artikel lesenFehler in Speicher, Firmware, Hardware oder Software können Seiten beschädigen, ohne die Anwendung sofort zu stoppen. Sicherungen können unerkannte Korruption bewahren.
Artikel lesenLeser und Schreiber können sich unter sperrbasiertem Read Committed blockieren. RCSI reduziert dies mit Zeilenversionen, verändert aber Ressourcenverbrauch und Parallelität.
Artikel lesenEin Index hilft nicht, wenn ein Prädikat seine Spalte in einer Funktion oder Berechnung versteckt. SQL Server muss dann oft alle Kandidaten scannen.
Artikel lesenBei inkompatiblen Datentypen kann SQL Server eine indizierte Spalte zur Laufzeit konvertieren. Das führt zu Scans, schlechten Schätzungen und unnötiger CPU.
Artikel lesenUnerwartetes Protokollwachstum kann ein Volume füllen, Transaktionen verlangsamen, Replikate verzögern und Recovery verlängern. Shrink behandelt nur das Symptom.
Artikel lesenDer Standardwert für max server memory kann Windows und andere Dienste aushungern. Ein zu niedriger Wert verursacht zusätzliche Lesevorgänge, Kompilierungen und Grant-Druck.
Artikel lesenStandardwerte für Parallelität sind selten ein bewusstes Lastdesign. Zu viel Parallelität erhöht CPU- und Worker-Druck, zu starke Begrenzung verlangsamt analytische Arbeit.
Artikel lesenEine lange Liste blockierter Sitzungen lässt jede Abfrage verdächtig erscheinen. Meist bestimmt eine Transaktion am Anfang der Kette Dauer und Auswirkung.
Artikel lesenEin erfolgreicher Sicherungsjob beweist nur, dass SQL Server einen Sicherungsstrom geschrieben hat. Er beweist keine rechtzeitige Wiederherstellung von Datenbanken, Schlüsseln, Logkette und Abhängigkeiten.
Artikel lesenEine Availability Group kann gesunde Replikate anzeigen, obwohl Wiederherstellungsziele gefährdet sind. Warteschlangen, Listener, Sicherungen und Failover-Bereitschaft müssen überwacht werden.
Artikel lesenDer Optimierer wählt Joins, Zugriffsmethoden und Speicherzuteilungen anhand geschätzter Zeilenzahlen. Weichen Schätzungen stark ab, wird ein vernünftiger Plan teuer.
Artikel lesenTempDB unterstützt Sortierungen, Hashes, Zeilenversionierung, temporäre Objekte, Spills und interne Arbeitstabellen. Schlechte Konfiguration kann zum gemeinsamen Engpass werden.
Artikel lesenEin Deadlock ist ein Zyklus, in dem Sitzungen gegenseitig benötigte Ressourcen halten. SQL Server beendet einen Teilnehmer, doch das Opfer ist nicht zwingend die Ursache.
Artikel lesenViele Performanceprobleme verschwinden, bevor ein Ausführungsplan erfasst wird. Query Store bewahrt Abfrage-, Plan-, Laufzeit- und Wartedaten für die spätere Analyse.
Artikel lesenDer pauschale Neuaufbau aller Indizes verbraucht CPU, I/O, Protokollplatz und Wartungszeit, auch wenn Benutzer keinen messbaren Vorteil erhalten.
Artikel lesen