Sonntag, 17. August 2014

ISNULL als Prädikat – SEEK oder SCAN?

Im Gespräch mit einem Kunden haben wir uns über NON SARGable Abfragen unterhalten. Dabei ist unter anderem auch ausgeführt worden, dass Funktionen grundsätzlich zu Index-Scans führen, da sie immer jede Zeile überprüfen müssen. Dieses Thema habe ich im Artikel “Optimierung von Datenbankmodellen – SARGable Abfragen” bereits ausführlich behandelt. Viele Funktionen arbeiten tatsächlich nach diesem Prinzip; dennoch ist z. B. die Arbeitsweise von ISNULL als Predikat davon abhängig, wie das Attribut in der Tabelle definiert wird.

Mittwoch, 30. Juli 2014

Aufsteigende Indexschlüssel – Performance Killer

Ein reißerischer Titel, oder? Aber tatsächlich ist für die Performance einer Datenbankanwendung das Design ein entscheidender Faktor, der – wie in diesem Fall – schnell zu einem Performancekiller werden kann. Dieses Problem ist in der Community allseits unter dem Begriff “Ascending Key Problem” bekannt. Das Problem tritt in einer Anwendung auf, in der zu einer Haupttabelle [dbo].[master_table] jeweils n Datensätze in einer Detailtabelle [detail_table] gespeichert werden. Sobald neue Datensätze in der Haupt- und Detailtabelle eingetragen werde und anschließend die abhängigen Detaildaten abgefragt werden, verschlechtert sich die Performance dramatisch, wenn es sich um neue Einträge handelte. Die Zusammenhänge zeigt der nachfolgende Artikel.

Sonntag, 20. Juli 2014

Verwendung von Variablen statt Literalen

Im Forum eines von mir sehr geschätzten MVP-Kollegen wurde eine Frage bezüglich der Verwendung von Variablen anstelle von Literalen gestellt (hier). Das Problem war, dass die Abfrage sich deutlich verlangsamte, wenn Variablen statt Literale verwendet wurden. Warum dieses Verhalten für Microsoft SQL Server jedoch korrekt ist, soll der folgende Artikel zeigen.

Mittwoch, 25. Juni 2014

Sperrverhalten von Shared Locks…

Auf Grund einer Anfrage des von mir sehr geschätzten Kollegen Johannes Curio (e | w), die sich um Sperren von Objekten in einem HEAP drehte, habe ich mich etwas intensiver mit dem Sperrverhalten von Microsoft SQL Server beschäftigt, da die grundsätzliche Frage war, ob Microsoft SQL Server in einem HEAP jede Datenseite / jeden Datensatz nach dem Scannen sofort wieder freigibt. Die Antwort – wie meistens bei Microsoft SQL Server – … “It depends”. Dieser Artikel beschreibt die unterschiedlichen Sperrverhalten bei SELECT-Statements unter Berücksichtigung der verschiedenen ISO-Isolationsstufen in einem HEAP und in einem Clustered Index.

Samstag, 31. Mai 2014

Sortierungskonflikte – Auswirkungen auf Ausführungspläne

Erst im letzten Artikel “Warum korrekte Datentypen für WHERE-Klauseln wichtig sind” habe ich die Auswirkungen von erforderlichen Typenkonvertierungen auf das Ausführungsverhalten beschrieben. Kaum geschrieben kam dann auch ein “echter” Fall diese Woche, der zunächst unerklärlich war; ein Blick auf die Ausführungspläne hat dann aber sehr schnell gezeigt, dass ein falsch gelöster “Sortierungskonflikt” die Ursache für das sehr schlechte Ausführungsverhalten der Abfrage war.

Sonntag, 25. Mai 2014

Warum korrekte Datentypen für WHERE-Klauseln wichtig sind

In einer Anfrage in den Microsoft Foren (link) ging es darum, warum Microsoft SQL Server trotz einer SEEK-Operation alle Datenseiten einer Tabelle durchsucht hat. Tatsächlich kann eine SEEK-Operation die vollständige Tabelle betreffen, wenn bestimmte Voraussetzungen nicht erfüllt sind. Wie wichtig zum Beispiel die korrekte Verwendung von Datentypen bei Einschränkungen sind, zeigt der nachfolgende Artikel.

Sonntag, 6. April 2014

Löschen von Daten aus Heap gibt Datenseiten nicht frei

Wenn alle Datensätze aus einem Heap gelöscht werden, mag man meinen, dass Microsoft SQL Server nach dem Löschvorgang auch die allozierten Datenseiten wieder frei gibt. Das macht der Microsoft SQL Server jedoch nur, wenn bestimmte Voraussetzungen vorhanden sind wie der nachfolgende Artikel zeigt.

Dienstag, 1. April 2014

Berater / DBA / DEV – Dokumentation ist eine Hauptleistungspflicht!

Mit diesem Artikel möchte ich die technischen Berater für Microsoft SQL Server, DBAs und Entwickler erreichen, die täglich bei den Kunden sind, um technische Probleme zu analysieren und zu lösen. Der folgende Artikel beruht auf einem aktuellen Projekt. Ich wurde zu diesem Projekt hinzu gezogen, weil die technischen Analysen meines Vorgängers nicht ausreichend waren, um Probleme zu erkennen und zu beheben. Um mich mit dem Thema im Vorfeld beschäftigen zu können, habe ich um vorhandene Dokumentation(en) gebeten. Die dann zugesendeten Dokumente waren den Namen nicht wert, wie einige Auszüge im Artikel zeigen werden. Gleich Eines vorweg – es soll hier kein Finger Pointing stattfinden – ich möchte aufzeigen, welche Minimalanforderungen aus meiner Sicht an eine Analysedokumentation gestellt werden sollten.

Sonntag, 23. März 2014

Tabellenvariablen – Mythos der Datenverarbeitung im Buffer Pool

Ich hatte am 22.03.2014 in Nürnberg während der SNEK (SQL Server + .NET Entwickler Konferenz) die Gelegenheit, nach meinem Vortrag ein interessantes Gespräch führen können, in dem unter anderen behauptet wurde, dass Tabellenvariablen Objekte seien, deren Datenoperationen (INSERT/UPDATE/DELETE)  im Buffer Pool – und somit im RAM – stattfinden und daher ein Grund für die bevorzugte Wahl von Tabellenvariablen sei. Diese Aussage ist nicht richtig wie der nachfolgende Artikel zeigen soll.

Mittwoch, 19. März 2014

Wie viele Datensätze passen auf eine Datenseite

Es versteht sich von selbst, dass diese Frage eher akademischer Natur ist und mehr dem Spaß am Ausprobieren gewidmet ist. Dennoch wurde diese Frage auf LinkedIn gestellt (http://tinyurl.com/q4zuxzc) und ich habe mir einfach mal die Arbeit gemacht, dieser Frage – aus rein akademischer Neugier – nachzugehen. Wer wissen möchte, wie viele Datensätze maximal auf eine Datenseite in einer Datenbank von Microsoft SQL Server 2012 passen, dem wünsche ich viel Spaß beim Lesen.