SQL Server Blog
Installation | Konfiguration | Optimierung von Microsoft SQL Server
Temporal Tables und INSTEAD OF-Trigger
Mit der Einführung von System Versioned Temporal Tables wurde für die Programmierer ein Weg geschaffen, um eigene Historisierungslösungen ad acta zu legen. In grauer Vorzeit verwendete man entweder Trigger oder Stored Procedures für die Entwicklung einer eigenen Historisierungslösung. Die Möglichkeiten dieser Lösungen waren beschränkt und unter Umständen sehr fehleranfällig. Viele Entwickler haben den Wunsch, im Datensatz den Benutzer zu speichern, der zuletzt Änderungen vorgenommen hat. Üblicherweise kann das nur mit Hilfe eines UPDATE-Triggers geschehen. Das AFTER-Trigger erhebliche Probleme in System Versioned Temporal Tables verursachen können, habe ich im Artikel “Temporal Tables – Verwendung von Triggern” bereits beschrieben. INSTEAD OF Trigger sind in System Versioned Temporal Tables nicht erlaubt. Was also tun? Dieser Artikel beschreibt eine Lösung, in der INSTEAD OF-Trigger dennoch zum Erfolg führen.
Leere Seiten in HEAP ermitteln
Wer mich kennt, weiß, dass ich ein großer Fan von HEAPS bin. HEAPS zeigen gegenüber gruppierten Indexen bei bestimmten Workloads bessere Leistungsverhalten. Neben den vielen Vorteilen haben HEAPS auch Nachteile. Ein deutlicher Nachteil ist, dass HEAPS allokierte...
Zugriffssteuerung mit Hilfe von LOGON-Triggern
Ein Kunde kam mit einer Anforderung auf uns zu, den Zugriff zu einen Microsoft SQL Server zu limitieren. Die Einschränkung sollte aber nicht auf einem Anmeldenamen basieren, sondern auf dem Namen bestimmter Applikationen. Die Einschränkung sieht vor, dass ausgewählte...
Read Committed Snapshot Isolation und hohe Anzahl von version_ghost_record_count
Bereits zum 3. Mal wurde ich zu einem Notfalleinsatz gerufen, bei dem ein Microsoft SQL Server völlig unerwartet einen Performanceeinbruch hatte. Die üblichen Verdächtigen (Parameter Sniffing, Statistiken, …) konnten nach kurzer Prüfung ausgeschlossen werden. Die weitere Suche brachte dann eine interessante Ursache zu Tage, die ich so bisher noch nie gesehen habe. Wenn eine Datenbank mit READ COMMITTED SNAPSHOT ISOLATION arbeitet, sollte man seinen Applikationscode (auch in SQL Server) gründlich testen!
Isolationsstufe SERIALIZABLE im Detail
Eine Frage in einem englischsprachigen Forum für Microsoft SQL Server motivierte mich, diesen Artikel über die verschiedenen ISO-Isolationsstufen zu schreiben. Dieser Artikel beschäftigt sich mit der restriktivsten Isolationsstufe – SERIALIZABLE. In einem zuvor...
Optimierung von LIKE-Suche
Immer wieder kommt es vor, dass trotz guter Indexierung ein Index nicht optimal genutzt werden kann, da die Suchmuster eine optimale Verwendung eines Index verhindern. Eher durch Zufall bin ich auf einen interessanten Artikel von Fabricio Lima gestoßen, der eine – wie...
SARGable- und Non-SARGable-Abfragen
Ein Kunde beklagte sich über die schlechte Ausführungsgeschwindigkeit einer Funktion, die er von einem Programmierer erhalten hatte. Bei der Durchsicht des Codes der Funktion war das Problem schnell gefunden. Statt eines performanten Indexseek hat die Abfrage einen...
Abfragen nicht mit Variablen testen
Häufig fällt auf, dass Datenbankentwickler ihre Abfragen mit Hilfe von Variablen testen. Die Programmiersprachen, wie z. B. C, C++, Basic und Java, besitzen ihre eigenen Variablen zur Aufnahme von Daten und diesen Lösungsansatz möchte man gerne in der Datenbank wiederverwenden. Der gravierende Unterschied zwischen beiden Lösungsansätzen liegt darin, dass Abfragen in Microsoft SQL Server diese Variablen zur Evaluierung der geschätzten Abfragekosten verwenden. Der folgende Artikel beschreibt, warum Variablen für Tests ungeeignet sind und zeigt Alternativen, wie man trotz der Verwendung von Variablen in Testabfragen zuverlässige Auswertungen durchführen kann.
Parameter Sniffing – Lösungsansätze
Wer täglich mit Microsoft SQL Server arbeitet – sei es als DBA oder als Entwickler – wird schon mal mit dem alltäglichen Problem von Parameter Sniffing konfrontiert gewesen sein. “Parameter Sniffing” bedeutet, das Microsoft SQL Server beim Ausführen einer Stored Procedure/parameterisierten Abfrage den Übergabeparameter verwendet, um die Kardinalität des Wertes zu bestimmen. Die Kardinalität des Parameters fließt in die Bestimmung der Abfragestrategie mit ein. Die Abfragestrategie wird als Plan im Plancache abgelegt. Der folgende Artikel beschäftigt sich mit den Problemen, die sich aus der Technologie ergeben und zeigt diverse Lösungsmöglichkeiten.
HEAPS in Verbindung mit DELETE-Operationen
In einem Projekt wurde den Entwicklern gesagt, dass man grundsätzlich mit Heaps arbeiten solle, da durch die Verwendung eines Clustered Index viele Deadlocks verursacht worden sein. Daraufhin hat man für fast alle Tabellen in der Datenbank die geclusterten Tabellen...
