Verhaltensänderungen von Datenbankmodul-Features in SQL Server 2008

In SQL Server 2008 ermöglichen Verbesserungen des Designs partitionierter Tabellen während der Abfrageverarbeitung über partitionierte Tabellen hinweg eine bessere Parallelität als in SQL Server 2005. Ein zusätzlicher Effekt dieser Neugestaltung ist, dass nur Zweiwegeverknüpfungen durch Kollokation abgestimmt werden können. Die Abfragepläne für durch Kollokation abgestimmte Zweiwegeverknüpfungen in SQL Server 2008 sehen wie die Abfragepläne in SQL Server 2005 aus, und auch die Leistung ist mit SQL Server 2005 vergleichbar. Wenn weitere Tabellen mit ausgerichteter Partitionierung in der Verknüpfung enthalten sind, wird ein anderer Plan ausgewählt. Ein Beispiel hierfür ist eine durch Kollokation abgestimmte Zweiwegeverknüpfung gefolgt von einer Hashverknüpfung mit der dritten Tabelle. Durch Kollokation abgestimmte Verknüpfungen zwischen mehr als zwei Tabellen sind unüblich. Außerdem profitieren durch Kollokation abgestimmte Verknüpfungen nicht von der verbesserten Parallelität in SQL Server 2008. Wenn Sie jedoch über eine Abfrage verfügen, für die von SQL Server 2005 eine durch Kollokation abgestimmte Dreiwegeverknüpfung (oder eine Verknüpfung mit mehr Wegen) ausgeführt wird, wird die Abfrage in SQL Server 2008 ggf. langsamer ausgeführt, falls der Arbeitsspeicher relativ zur Größe der Tabellen klein ist. Möglichkeiten zur Verbesserung der Leistung in dieser Situation sind z. B. das Erhöhen des verfügbaren Arbeitsspeichers und das erneute Schreiben der Abfrage, damit einzelne Partitionen vor dem Zusammenfassen der Ergebnisse separat verknüpft werden. Weitere Informationen zu durch Kollokation abgestimmten Verknüpfungen finden Sie unter Verbesserte Abfrageverarbeitung bei partitionierten Tabellen und Indizes.

SQL Server bietet eine neue Optimierung für die Verarbeitung von Abfragen mit Sternverknüpfungen, bei der Hashverknüpfungen und Bitmapfilter verwendet werden. Wenn eine Abfrage beim Verknüpfen von Faktentabellen mit Dimensionstabellen in einem Sternschema große Datenmengen verarbeitet, kann ein Abfrageplan diesen Vorgang mithilfe der neuen Optimierung viel schneller ausführen. 

Aus diesem Grund wird für Ihre vorhandenen Abfragen ggf. ein neuer Abfrageplan verwendet, falls diese dem Sternverknüpfungsmuster entsprechen. Der Abfrageoptimierer wählt diesen Plan aus, wenn seine Schätzungen ergeben, dass die Abfrageleistung zunimmt. Falls die in der Kostenschätzung verwendeten Statistiken jedoch ungenau sind, wählt der Abfrageoptimierer ggf. auch dann die Sternverknüpfungsoptimierung aus, wenn ein anderer Plan möglicherweise schneller wäre.

Ist die Konfigurationsoption Max. Grad an Parallelität oder die MAXDOP-Indexoption auf 1 festgelegt, verwendet der Abfrageoptimierer die Sternverknüpfungsoptimierung nicht, sodass Sie nicht in den Genuss der Vorteile der neuen Sternverknüpfungsoptimierung kommen. Wenn das Abfrageausführungssystem eine mit einem parallelen Plan optimierte Abfrage mit nur einem Thread verteilt, kann es sein, dass einige Bitmapfilter aus einem Sternverknüpfungsplan mit mehreren Bitmapfiltern entfernt werden. Diese Änderung verlangsamt die Ausführung ggf. stärker als erwartet, z. B. wenn Sie von 2 Threads zu 1 Thread wechseln.

Die Sternverknüpfungsoptimierung ist nur in der Enterprise, Developer und Evaluation Edition von SQL Server verfügbar. Weitere Informationen zum Filtern mithilfe einer Bitmap finden Sie unter Optimieren der Leistung von Data Warehouse-Abfragen durch das Filtern mithilfe einer Bitmap. Weitere Informationen zum Interpretieren von Abfrageplänen, die Bitmapfilter enthalten, finden Sie unter Interpretieren von Ausführungsplänen mit Bitmapfiltern. Weitere Informationen zur Sternverknüpfungsoptimierung finden Sie im TechNet-Artikel Abfrageleistung in Data Warehouses (möglicherweise nur in englischer Sprache verfügbar).

In SQL Server 2008 wird die Parallelität für geschachtelte Schleifenverknüpfungen erleichtert, wenn die äußere Seite der Verknüpfung nur einige Zeilen aufweist. Wenn mehrere Threads verfügbar sind, wird jedem Thread in SQL Server 2005 eine Seite mit Zeilen der äußeren Seite der Verknüpfung zugeordnet. Falls nur einige Zeilen vorhanden sind, befinden sich diese meist auf derselben Seite. In solchen Fällen wird nur ein Thread eingesetzt, und die potenziellen Vorteile der Parallelität gehen verloren. In SQL Server 2008 werden diese Fälle erkannt und ein Austauschoperator eingeführt, der eine Zeile pro Thread zuordnet, damit alle verfügbaren CPUs genutzt werden. Die erhöhte Parallelität bedeutet, dass der CPU-Verbrauch im Vergleich zu SQL Server 2005 vorübergehend zunimmt, die Abfrageausführung jedoch schneller erfolgt. Dieses neue Verhalten tritt nur auf, wenn die Anzahl der äußeren Zeilen klein ist und wenn der Aufwand für die Abfrage so hoch eingeschätzt wird, dass diese von der zusätzlichen Parallelität profitiert. Falls die Abfragekosten gering eingeschätzt werden oder falls die Kardinalitätsschätzung für die äußere Seite größer als 1.000 ist, wird in SQL Server wie in SQL Server 2005 auch eine Seite pro Thread zugeordnet. Weitere Informationen zu Austauschoperatoren und zur parallelen Abfrageverarbeitung finden Sie unter Parallele Abfrageverarbeitung.

SQL Server 2008 ändert die Art und Weise, wie Abfragen von partitionierten Tabellen und Indizes verarbeitet werden. Abfragen von partitionierten Objekten, in denen der USE PLAN-Hinweis verwendet wird, enthalten unter Umständen einen ungültigen Plan. Wir empfehlen die folgenden Schritte, nachdem Sie auf SQL Server 2008 aktualisiert haben.

Wenn der USE PLAN-Hinweis direkt in einer Abfrage angegeben wird:

1. Entfernen Sie den USE PLAN-Hinweis aus der Abfrage.

2. Testen Sie die Abfrage.

3. Wenn der Optimierer keinen geeigneten Plan auswählt, optimieren Sie die Abfrage, und geben Sie den USE PLAN-Hinweis mit dem gewünschten Abfrageplan an.

Wenn der USE PLAN-Hinweis in einer Planhinweisliste angegeben wird:

1. Verwenden Sie die sys.fn_validate_plan_guide-Funktion, um die Gültigkeit der Planhinweisliste zu überprüfen. Sie können auch anhand des Ereignisses Plan Guide Unsuccessful in SQL Server Profiler nach ungültigen Plänen suchen.

2. Wenn die Planhinweisliste ungültig ist, verwerfen Sie sie. Wenn der Optimierer keinen geeigneten Plan auswählt, optimieren Sie die Abfrage, und geben Sie den USE PLAN-Hinweis mit dem gewünschten Abfrageplan ein.

Weitere Informationen zur Verarbeitung von Abfragen auf partitionierten Objekten finden Sie unter Verbesserte Abfrageverarbeitung bei partitionierten Tabellen und Indizes.

In SQL Server 2005 hängen die Daten- und Protokolldateien für die Resource-Datenbank vom Speicherort der Datendatei der master-Datenbank ab. Daher erfordert das Verschieben der master-Datenbank auch das Verschieben der Resource-Datenbank an denselben Speicherort. In SQL Server 2008 ist diese Abhängigkeit nicht vorhanden. Die master-Datenbankdateien können verschoben werden, ohne dass die Resource-Datenbank verschoben werden muss.

In SQL Server 2008 ist der Standardspeicherort der Resource-Datenbank <Laufwerk>:\Program Files\Microsoft SQL Server\MSSQL10.<instance_name>\Binn\. Die Resource-Datenbank kann nicht verschoben werden.

In früheren Versionen von SQL Server wurde die PAGE_VERIFY-Datenbankoption für die tempdb-Datenbank auf NONE festgelegt und kann nicht geändert werden. In SQL Server 2008 ist für neue Installationen von SQL Server CHECKSUM der Standardwert für die tempdb-Datenbank. Wenn eine Installation von SQL Server aktualisiert wird, bleibt der Standardwert NONE erhalten. Die Option kann geändert werden. Es wird empfohlen, CHECKSUM für die tempdb-Datenbank zu verwenden.

SQL Server 2008 enthält verschiedene Erweiterungen der XML-Schemaunterstützung, beispielsweise die Unterstützung für die lax-Überprüfung, eine verbesserte Behandlung der Instanzdaten von xs:date, xs:time und xs:dateTime und die Unterstützung der Typen list und union. In den meisten Fällen wirken sich die Änderungen nicht auf das Aktualisierungsverhalten aus. Wenn Sie in SQL Server 2005 jedoch eine XML-Schemaauflistung verwenden, die Werte vom Typ xs:date, xs:time oder xs:dateTime (bzw. einen Untertyp davon) zulässt, werden die folgenden Aktualisierungsschritte ausgeführt, wenn Sie die SQL Server 2005-Datenbank auf SQL Server 2008 aktualisieren.

1. Für jede xml-Spalte, die mit einer XML-Schemaauflistung typisiert ist, die Elemente oder Attribute vom Typ xs:anyType, xs:anySimpleType, xs:date (bzw. eines Untertyps davon), xs:time (bzw. eines Untertyps davon) oder xs:dateTime (bzw. eines Untertyps davon) enthält oder bei der es sich um die Typen union oder list mit diesen Typen handelt, geschieht Folgendes:

   1. Alle XML-Indizes der Spalte werden deaktiviert.

   2. Alle SQL Server 2005-Werte werden weiterhin in der Z-Zeitzone dargestellt, weil sie für die Z-Zeitzone normalisiert wurden.

   3. Alle Werte vom Typ xs:date oder xs:dateTime, die kleiner sind als der 1. Januar im Jahr 1, führen zu einem Laufzeitfehler, wenn der Index erneut erstellt wird oder wenn eine XQuery-Anweisung oder XML-DML-Anweisung für den xml-Datentyp ausgeführt wird, der diesen Wert enthält.

2. Alle negativen Jahre in xs:date- oder xs:dateTime-Facets oder Standardwerten in einer XML-Schemaauflistung werden automatisch auf den kleinsten vom Basistyp xs:date oder xs:dateTime zugelassenen Wert aktualisiert. Beispiel: 0001-01-01T00: 00:00.0000000 Z für xs:dateTime.

Beachten Sie, dass Sie den gesamten xml-Datentyp weiterhin mit einer einfachen SQL-SELECT-Anweisung abrufen können, selbst wenn er negative Jahresangaben enthält. Es wird empfohlen, dass Sie die negativen Jahresangaben durch eine Jahresangabe ersetzen, die im neuen unterstützten Bereich liegt, oder den Typ des Elements oder Attributs in xs:string ändern. Weitere Informationen finden Sie unter Typisiertes XML im Vergleich zu nicht typisiertem XML.

In SQL Server 2005 wird die lax-Überprüfung nicht unterstützt, und für Elemente vom Typ anyType wird die strenge Überprüfung angewendet. In SQL Server 2008 wird der Inhalt von Elementen vom Typ anyType per lax-Überprüfung überprüft. Weitere Informationen finden Sie unter Platzhalterkomponenten und Inhaltsüberprüfung.