Profile cover photo
Profile photo
Uwe Ricken
100 followers -
Microsoft Certified Master - SQL Server 2008 und MVP SQL Server
Microsoft Certified Master - SQL Server 2008 und MVP SQL Server

100 followers
About
Uwe's posts

Post has attachment
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!

Post has attachment
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 geschriebenen Artikel habe ich das Sperrverhalten von SELECT-Statements in den verschiedenen Isolationsstufen beschrieben. Dieser Artikel befasst sich nicht mit den Grundlagen von Isolationsstufen sondern behandelt die besonderen Merkmale.


Post has attachment
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 ich finde – interessante Lösung präsentiert, um sogenannte “Wildcard-Suchen” zu optimieren. Hierbei macht er sich den Umstand zu Nutze, dass der CPU-Anteil bei Verwendung von SQL Sortierungen deutlich reduziert wird und somit Abfragen mit Wildcards schneller ausgeführt werden.

Post has attachment
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 Indexscan durchgeführt. Ursache für die schlechte Performance war, dass die WHERE-Klausel keine SARGable Argumente verwendete.


Post has attachment
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 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.

Post has attachment
Am 14.12.2016 fand zum 6. Mal das Treffen der S.I.G. – SQL Server Internals statt. Dieses – virtuelle – Treffen wurde wie immer aufgezeichnet und kann über den S.I.G.-eigenen Youtube-Channel abgerufen werden. Thema des Treffens war eines meiner Lieblingsthemen – HEAPS.

http://www.db-berater.de/2016/12/special-interest-group-sql-server/


Post has attachment
Wer täglich mit Microsoft SQL Server arbeitet – sei es als DBA oder als Entwickler – wird sich schon mal mit dem Problem von Parameter Sniffing auseinandergesetzt haben. “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 und zukünftige Ausführungen der Abfrage auf Basis des ERSTEN Übergabeparameters durchführt. Die Kardinalität des Parameters fließt in die Bestimmung der Abfragestrategie mit ein. Die Abfragestrategie wird als Ausführungsplan im Plancache abgelegt. Dieser Artikel beschäftigt sich mit den Problemen, die sich aus dieser Arbeitsweise ergeben und zeigt mögliche Lösungsansätze.

Post has attachment
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 wieder zu Heaps gemacht. Die Deadlocks sind laut Aussage vollkommen verschwunden – jedoch hat man ein paar Dinge nicht beachtet, die sich nun nachteilig auf die Performance auswirken; und es sind nicht fehlende Indexe gemeint!
http://www.db-berater.de/2016/08/heaps-in-verbindung-mit-delete-operationen/

Post has attachment
Trigger sind eine beliebte Technologie, um Geschäftsregeln auf Ebene von Tabellen zu implementieren. Durch die Verwendung von Triggern kann z. B. für die bearbeiteten Datensätze immer der Name und das Datum des letzten Anwenders gespeichert werden, der den Datensatz manipuliert hat. Von relativ einfachen bis zu komplexen Regelwerken sind Trigger in Datenbanken von vielen Entwicklern eine gerne adaptierte Technologie. So “elegant” die Verwendung von Triggern für viele Entwickler sein mag  –  im Zusammenhang mit “System Versioned Temporal Tables” sollten sie auf keinen Fall verwendet werden. Der folgende Artikel zeigt einen klassischen Anwendungsfall, der bei Implementierung von “System Versioned Temporal Tables” eklatante Nachteile in sich birgt.
http://www.db-berater.de/2016/07/temporal-tables-verwendung-von-triggern/

Post has attachment
Im Kommentar zu meinem Artikel “Temporal Tables – Umbenennen von Metadaten” hat ein von mir sehr geschätzter Kollege aus meiner Access-Zeit – Philipp Stiefel (w) – angemerkt, dass eine Gegenüberstellung von Programmierung und Systemlösung interessant wäre. Das finde ich auch – also wurde der Urlaub dazu genutzt, sich mit den unterschiedlichen Lösungsansätzen zu beschäftigen.
Wait while more posts are being loaded