Kategorie: "Administration"

Performancevorteile durch Instant File Initialization

Link: http://db-berater.blogspot.de/2014/02/performancevorteile-durch-instant-file.html

Beim Anlegen von Datenbankdateien (Daten, Log) werden standardmäßig die zu erstellenden Dateien beim Initialisieren mit 0 aufgefüllt, damit eventuell auf dem Datenträger zurückgebliebene Daten von vorherigen (gelöschten) Dateien überschrieben werden. Dieses Verfahren betrifft nicht nur das Erstellen neuer Datenbanken sondern auch die Wiederherstellung von Datenbanken aus einem Backup oder die stetige Vergrößerung einer Datenbank. Welchen Einfluss diese Vorgänge auf die Leistung von Microsoft SQL Server hat, beschreibt der nachfolgende Artikel.

Seiten: 1· 2

JOIN-Operatoren im Detail – NESTED LOOP

Link: http://db-berater.blogspot.de/2013/12/join-operatoren-im-detail-nested-loop.html

In meinen Seminaren zu Microsoft SQL Server werden in Verbindung mit der Optimierung von Ausführungsplänen von Abfragen immer wieder Fragen nach den unterschiedlichen JOIN-Operatoren gestellt und nach welchen Kriterien der Microsoft SQL Server welchen Operator auswählt. In diesem wie den nachfolgenden Artikeln möchte ich diese Operatoren und die Entscheidungswege von Microsoft SQL Server etwas genauer mit Beispielen erläutern.

Ganze Geschichte »

Mitglied im TechNet Wiki Advisory Board

Link: http://db-berater.blogspot.de/2013/11/mitglied-im-technet-wiki-advisory-board.html

Heute mal überhaupt nichts technisches sondern vielmehr ein weiteres persönliches Highlight meiner Tätigkeit im Umfeld von Microsoft SQL Server. Heute hat mich Ed Price von Microsoft darüber informiert, dass ich als 3. Mitglied im Advisory Board (Beirat) von TechNet Wiki aufgenommen wurde (http://social.technet.microsoft.com/wiki/contents/articles/2495.technet-wiki-advisory-board.aspx). Als Mitglied dieses Beirats unterstützt man die Community bei Inhalten, die im TechNet Wiki veröffentlicht werden, in der Technologie, zu der man als MVP ausgezeichnet wurde.

Meine Auszeichnung zum MVP erhielt ich im Juli 2013. Herzlichen Dank an Ed Price, dass er – trotz der doch sehr kurzen Zeit seit der Auszeichnung – angefragt hat, ob ich Interesse an dieser Aufgabe habe.

Meine bisher in TechNet Wiki veröffentlichten Artikel basieren alle auf Fragen, die in den TechNet-Foren gestellt wurden. Nachdem ich diese Fragen auch hier in meinem eigenen Blog veröffentlicht habe, wurde daraus i. d. R. auch schnell ein entsprechender Wiki-Artikel.

Herzlichen Dank fürs Lesen!

Fremdschlüssel–Probleme in Verbindung mit FILLFACTOR

Link: http://db-berater.blogspot.de/2013/11/fremdschlusselprobleme-in-verbindung.html

Das folgende Szenario basiert auf einer Anfrage in den Microsoftforen, in der die Frage in den Raum gestellt wurde, ob die Verwendung von FILLFACTOR für einen non clustered index, der als Optimierung für eine Fremdschlüsselbeziehung erstellt wurde, effektiv ist und Abfragen beschleunigt. Die Standardaussage: “It depends” gilt nicht, wenn der Clustered Key fortlaufend ist. Der nachfolgende Artikel verdeutlicht die Problematik im Detail.

Ganze Geschichte »

DBCC SHRINKDATABASE – wirklich ein Segen für dba?

Link: http://db-berater.blogspot.de/2013/09/dbcc-shrinkdatabase-wirklich-ein-segen.html

In der letzten Woche wurde ich zu einem “Kurzeinsatz” hinzu gezogen, bei dem es darum ging, den hohen I/O bei Abfragen zu untersuchen. Die Programmierer waren alles erfahrene Leute und kannten sich sehr gut mit den Möglichkeiten der Indexanalyse und der Bewertung von Indexstatistiken aus. Die Programmierer haben die Datenbank der Produktionsumgebung in eine Testumgebung portiert, die Indexe defragmentiert und das I/O für die Abfragen gemessen. Anschließend wurden diese Ergebnisse mit dem I/O der Produktionsumgebung verglichen und man stellte fest, dass das I/O für identische Abfragen nahezu doppelt so hoch war. Man stellte anschließend fest, dass die Indexe in der Produktion sehr stark fragmentiert waren. Also wurden die Indexe neu aufgebaut und man glaubte, damit das Problem gelöst zu haben. Am nächsten Tag ist das Problem erneut aufgetreten und man konnte sich dieses Verhalten nicht erklären, war doch der Clustered Index in allen Relationen so definiert, dass immer ein Surrogatschlüssel auf einem IDENTITY-Attribut lag. Um die Ursache zu finden, musste man nicht lange suchen – die DBA des Unternehmens haben für alle SQL-Server im Unternehmen einen Standardauftrag implementiert, der am Abend die Datenbanken "verkleinert”. Warum der Unsinn einer Verkleinerung einen massiven Einfluss auf die Performance von Datenbanken hat, beschreibt der folgende Artikel mit einem Beispiel. 

Ganze Geschichte »
1 3 4