Freigeben über

  • Artikel

Verhaltensänderungen von Datenbankmodul-Features in SQL Server 2008

In diesem Thema werden Verhaltensänderungen im Database Engine (Datenbankmodul) beschrieben. Verhaltensänderungen wirken sich darauf aus, wie Features in SQL Server 2008 im Vergleich zu früheren Versionen von SQL Server funktionieren oder interagieren.

SQL Server-Agent

Verhaltensänderungen beim Schreiben eines Tasks des SQL Server-Agents.

Wenn Sie in SQL Server 2008 einen neuen Auftrag erstellen, indem Sie das Skript eines vorhandenen Auftrags kopieren, kann der neue Auftrag versehentlich den bestehenden beeinflussen. Um einen neuen Auftrag unter Verwendung des Skripts eines bestehenden Auftrags zu erstellen, löschen Sie manuell den Parameter @schedule_uid. Dieser ist normalerweise der letzte Parameter des Abschnitts, der im vorhandenen Auftrag den Auftragszeitplan erstellt. Hierdurch wird für den neuen Auftrag ein unabhängiger Zeitplan erstellt, ohne den bestehenden Auftrag zu beeinflussen.

Zugreifen auf die Überprüfungscacheoptionen

In SQL Server 2005 kann die interne access check result cache-Struktur nur mit Ablaufverfolgungsflags konfiguriert werden. In SQL Server 2008 können Sie diese Struktur mithilfe der access check cache-Optionen ändern. Weitere Informationen finden Sie unter Optionen für den Zugriffsprüfungscache.

Volltextsuche

Mit SQL Server 2008 wird eine neue Architektur für die Volltextsuche eingeführt. Das Volltext-Suchmodul ist jetzt vollständig in SQL Server Database Engine (Datenbankmodul) integriert und stellt keinen separaten Dienst mehr dar. Diese Integration führt zu einer besseren Verwaltbarkeit, Skalierbarkeit, Sicherheit und Leistung der Volltextsuche als in vorherigen Versionen von SQL Server. Weitere Informationen zu den Hauptunterschieden zwischen der Volltextsuche in SQL Server 2005 und SQL Server 2008 sowie die Best Practices für dieses neue Volltext-Suchmodul finden Sie auf der MSDN-Website im technischen Artikel SQL Server 2008-Volltextsuche: Internes und Erweiterungen (möglicherweise nur in englischer Sprache verfügbar).

Verbindungsserver

In SQL Server 2008 wurde die Transaktionssemantik von INSERT...EXECUTE-Anweisungen geändert, die für einen Loopbackverbindungsserver ausgeführt werden. In SQL Server 2005 wird dieses Szenario nicht unterstützt und verursacht Fehler. In SQL Server 2008 kann eine INSERT...EXECUTE-Anweisung für einen Loopbackverbindungsserver ausgeführt werden, wenn für die Verbindung Multiple Active Result Sets (MARS) nicht aktiviert ist. Wenn MARS für die Verbindung aktiviert ist, entspricht das Verhalten dem in SQL Server 2005.

Parallelität

Abfrageverarbeitung partitionierter Tabellen und Parallelität

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.

Sternverknüpfung und Parallelität

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).

Parallelität bei wenigen äußeren Zeilen

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.

Partitionierte Tabellenabfragen mit dem USE PLAN-Hinweis

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.

Planhinweislisten

Wenn in SQL Server 2008 eine Planhinweisliste nicht berücksichtigt werden kann, wird die Abfrage mithilfe eines anderen Plans kompiliert, und es wird kein Fehler ausgegeben. In SQL Server 2005 wird ein Fehler ausgelöst, und die Abfrage scheitert.

In SQL Server 2005 erstellte Planhinweislisten sind möglicherweise nicht gültig, nachdem das System auf SQL Server 2008 aktualisiert wurde. Ungültige Planhinweislisten bewirken keine Anwendungsfehler, sie werden lediglich nicht verwendet. Es empfiehlt sich, die Definitionen der Planhinweislisten nach einer Aktualisierung Ihrer Anwendung auf eine neue Version von SQL Server neu zu bewerten und zu testen. Die Anforderungen an die Leistungsoptimierung und das Abgleichverhalten der Planhinweislisten können sich ändern. Nachdem Sie eine Datenbank auf SQL Server 2008 aktualisiert haben, sollten Sie die folgenden Aufgaben durchführen, um bestehende Planhinweislisten mit der sys.fn_validate_plan_guide-Funktion zu überprüfen. Alternativ können Sie auch mit dem Plan Guide Unsuccessful-Ereignis in SQL Server Profiler nach ungültigen Planhinweislisten suchen.

Architektur des Abfrageprozessors

SQL Server 2008 ändert die Art und Weise, wie Abfragen von partitionierten Tabellen und Indizes verarbeitet werden. Abfragen auf partitionierte Objekte, die den USE PLAN-Hinweis für einen von SQL Server 2005 generierten Plan verwenden, enthalten unter Umständen einen ungültigen Plan. Weitere Informationen finden Sie unter Überlegungen zum Aktualisieren des Datenbankmoduls. Weitere Informationen zum Verarbeiten von Abfragen auf partitionierte Objekte finden Sie unter Verbesserte Abfrageverarbeitung bei partitionierten Tabellen und Indizes.

REPLACE-Funktion

In SQL Server 2005 werden im ersten Eingabeparameter der REPLACE-Funktion angegebene nachfolgende Leerzeichen abgeschnitten, wenn der Parameter vom Datentyp char ist. In der Anweisung SELECT '<' + REPLACE(CONVERT(char(6), 'ABC '), ' ', 'L') + '>' wird zum Beispiel der Wert 'ABC ' fälschlicherweise als 'ABC' ausgewertet.

In SQL Server 2008 werden nachfolgende Leerzeichen immer beibehalten. Für Anwendungen, die sich auf das frühere Verhalten der Funktion stützen, verwenden Sie die RTRIM-Funktion bei der Angabe der ersten Eingabeparameter der Funktion. Die folgende Syntax reproduziert beispielsweise das SQL Server 2005-Verhalten: SELECT '<' + REPLACE(RTRIM(CONVERT(char(6), 'ABC ')), ' ', 'L') + '>'.

Systemdatenbanken

Ressourcendatenbank

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.

tempdb-Datenbank

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.

Verwenden von INSERT…SELECT zum Massenladen von Daten mit minimaler Protokollierung

In früheren Versionen von SQL Server handelt es sich immer um einen vollständig protokollierten Vorgang, wenn Sie Zeilen mithilfe der Anweisung INSERT INTO <target_table> SELECT <columns> FROM <source_table> in einem Massenladevorgang in eine Zieltabelle laden. In SQL Server 2008 kann dieser Vorgang mit minimaler Protokollierung ausgeführt werden, wenn die Zieltabelle ein Heap ist, das Wiederherstellungsmodell der Datenbank auf einfach oder massenprotokolliert festgelegt ist und der TABLOCK-Hinweis für die Zieltabelle angegeben wurde. Die minimale Protokollierung kann die Leistung der Anweisung verbessern und die Wahrscheinlichkeit senken, dass der Vorgang den verfügbaren Transaktionsprotokoll-Speicherplatz während der Transaktion auffüllt. Weitere Informationen finden Sie unter INSERT (Transact-SQL).

XML

Aktualisieren von typisiertem XML von SQL Server 2005 auf SQL Server 2008

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.

Lax-Überprüfung und xs:anyType-Elemente

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.

Änderungsverlauf

Aktualisierter Inhalt

Die Abschnitte "Optionen für den Zugriffsüberprüfungscache", "Volltextsuche", "Parallelität" und "XML" wurden hinzugefügt.

Der Abschnitt "Verwenden von INSERT…SELECT zum Massenladen von Daten mit minimaler Protokollierung" wurde hinzugefügt.

Der Abschnitt "Verhaltensänderungen beim Schreiben eines Tasks des SQL Server-Agents" wurde hinzugefügt.