Unterschiede zwischen dem Datenbankmodul-Optimierungsratgeber und dem Indexoptimierungs-Assistenten

Um die neuen Datenbankfeatures von Microsoft SQL Server 2005 zu verarbeiten, weist der Datenbankmodul-Optimierungsratgeber ein anderes Verhalten als der Indexoptimierungs-Assistent von Microsoft SQL Server 2000 auf. Obwohl beide Tools eine grafische Benutzeroberfläche (GUI, Graphical User Interface) und eine Eingabeaufforderungs-Schnittstelle haben, sollten auch Benutzer, die mit dem Indexoptimierungs-Assistenten vertraut sind, die folgenden Änderungen beachten.

Eine vollständige Liste der neuen Features im Datenbankmodul-Optimierungsratgeber finden Sie unter Datenbankmodul-Optimierungsratgeber (Features).

Zum Optimieren von Datenbanken erforderliche Berechtigungen

In SQL Server 2000 konnten nur Mitglieder der festen Serverrolle sysadmin mit dem Indexoptimierungs-Assistenten Datenbanken optimieren. In SQL Server 2005 können Mitglieder der sysadmin-Rolle mithilfe des Datenbankmodul-Optimierungsratgebers weiterhin Datenbanken optimieren. Zusätzlich können jetzt auch Benutzer, die Mitglieder der festen Datenbankrolle db_owner sind, die Datenbanken optimieren, die sie besitzen.

Hinweis:

Bei der ersten Verwendung muss der Datenbankmodul-Optimierungsratgeber von einem Benutzer gestartet werden, der über Systemadministratorberechtigungen verfügt, um die Anwendung zu initialisieren. Nach der Initialisierung können sowohl Mitglieder der festen Serverrolle sysadmin als auch Mitglieder der festen Datenbankrolle db_owner Datenbanken mit dem Datenbankmodul-Optimierungsratgeber optimieren. Beachten Sie dabei jedoch, dass Mitglieder der db_owner-Rolle nur die Datenbanken optimieren können, die sie besitzen. Weitere Informationen finden Sie unter Initialisieren des Datenbankmodul-Optimierungsratgebers.

Arbeitsauslastungskontext

Der Indexoptimierungs-Assistent wertete die einzelnen Anweisungen in der Arbeitsauslastung anhand der zur Optimierung ausgewählten Datenbank aus, ungeachtet dessen, ob die Anweisung ursprünglich im Kontext dieser Datenbank ausgeführt wurde. Der Indexoptimierungs-Assistent konnte während einer Optimierungssitzung nur eine Datenbank optimieren. Der Datenbankmodul-Optimierungsratgeber in SQL Server 2005 kann während einer Optimierungssitzung mehrere Datenbanken optimieren. Der Datenbankmodul-Optimierungsratgeber bestimmt anhand der Informationen aus dem Skript die Datenbank, in der die Anweisung ausgeführt wird, und wertet die Anweisung für diese Datenbank aus. Die zum Optimieren ausgewählten Datenbanken haben keinen Einfluss auf die Art der Auswertung der Anweisungen.

Beispiel:

• In der AdventureWorks-Datenbank gibt es eine Person.Contact-Tabelle mit den Spalten FirstName und LastName.

• Die Arbeitsauslastung TuneQuery.sql enthält die folgende Abfrage:

  SELECT FirstName, LastName
  FROM Person.Contact
  WHERE LastName = 'Abercrombie';
  GO
  

• Standardmäßig wird für User1 eine Verbindung zur MyDB-Datenbank hergestellt.

In SQL Server 2000 hat User1 Folgendes an der Befehlszeile ausgegeben bzw. ähnliche Schritte mithilfe der GUI des Indexoptimierungs-Assistenten ausgeführt:

Itwiz -D AdventureWorks -I TuneQuery.sql –o rec.sql –U <username> –P <password>

Diese Methode hat funktioniert, da jede Anweisung in TuneQuery.sql für die AdventureWorks-Datenbank analysiert wurde, da sie in der Befehlszeile (-D AventureWorks) angegeben war. TuneQuery.sql war in der AdventureWorks-Datenbank gültig, und die Datenbank wurde ohne Probleme optimiert.

In SQL Server 2005 hat sich das Verhalten geändert. Die Befehlszeilensyntax des Datenbankmodul-Optimierungsratgebers lautet:

dta -s Session1 –D AdventureWorks –if TuneQuery.sql –of rec.sql –U username –P password

Da für User1 standardmäßig eine Verbindung zur MyDB-Datenbank hergestellt wird, wird der Datenbankkontext vom System auf MyDB festgelegt. Als Nächstes wird die Transact-SQL-Anweisung für die MyDB-Datenbank analysiert statt für AdventureWorks. Die Anweisung ist in MyDB ungültig und wird daher ignoriert.

Begründung für dieses Verhalten: Wenn User1TuneQuery.sql mithilfe von sqlcmd oder SQL Server Management Studio ausführt, ohne eine Zieldatenbank anzugeben, wird TuneQuery.sql für MyDB ausgeführt und erzeugt einen Fehler. Der Datenbankmodul-Optimierungsratgeber imitiert dieses Verhalten.

Abhilfemaßnahmen: Fügen Sie dem TuneQuery.sql-Skript folgendermaßen eine USE <database>-Anweisung hinzu:

USE AdventureWorks;
GO
SELECT FirstName, LastName
FROM Person.Contact
WHERE LastName = 'Abercrombie';
GO

Der Datenbankmodul-Optimierungsratgeber erkennt zuerst die USE AdventureWorks-Anweisung und legt AdventureWorks anhand dieser Informationen als aktuelle Datenbank fest. Anschließend, wenn er die SELECT FirstName, LastName FROM Person.Contact WHERE LastName = 'Abercrombie'-Anweisung liest, wird diese für AdventureWorks analysiert, da der aktuelle Datenbankkontext AdventureWorks lautet. Dadurch kann der Datenbankmodul-Optimierungsratgeber die Datenbank erfolgreich optimieren. Wenn Sie das oben beschriebene Skript mithilfe von sqlcmd oder SQL Server Management Studio ausführen, wird die Anweisung für AdventureWorks ausgeführt, da der Datenbankkontext durch die erste USE <database>-Anweisung von MyDB in AdventureWorks geändert wird.

Mit den USE <database>-Anweisungen lässt sich die Datenbank angeben, für die die Anweisung ausgeführt werden soll. Im Allgemeinen ist dies nicht erforderlich, wenn jede Anweisung vollqualifizierte Tabellennamen verwenden.

Da der Datenbankmodul-Optimierungsratgeber die jeweiligen Datenbanken sucht, für die die einzelnen Anweisungen ausgeführt werden (Imitieren der Ausführungsumgebung), sind die folgenden Informationen äußerst wichtig, um zu verstehen, wie der Datenbankmodul-Optimierungsratgeber mit verschiedenen Eingabetypen umgeht.

SQL-Datei- oder Inlinearbeitsauslastung

Wie im vorherigen Abschnitt beschrieben, verwendet der Datenbankmodul-Optimierungsratgeber USE <database>-Anweisungen, die einer Transact-SQL-Abfrage vorgestellt sind, um die Datenbank zu identifizieren, für die die Abfrage ausgeführt werden soll. Der Datenbankmodul-Optimierungsratgeber überprüft die Eingabe ab der ersten Anweisung in der Transact-SQL-Skriptdatei. Er startet mit der Annahme, dass die aktuelle Datenbank die Standarddatenbank ist. Wenn USE <database>-Anweisungen vorhanden sind, wird der aktuelle Datenbankkontext geändert, für den die Anweisungen analysiert werden.

Ablaufverfolgungsdateien und Ablaufverfolgungstabellen

Der Datenbankmodul-Optimierungsratgeber imitiert beim Durchlaufen der Ablaufverfolgungsdatei die Wiedergabe von SQL Server Profiler. Dabei verwendet er die folgenden Informationen aus Ablaufverfolgungsdateien in der aufgeführten Reihenfolge:

• Wenn es in der Ablaufverfolgungsdatei Ereignisse mit aufgefüllter DatabaseName-Spalte gibt, sucht der Datenbankmodul-Optimierungsratgeber damit die Datenbank, für die dieses Ereignis ausgeführt wurde.
• Wenn die DatabaseID-Spalte in der Ablaufverfolgungsdatei aufgefüllt ist, sucht der Datenbankmodul-Optimierungsratgeber damit die Datenbank, für die dieses Ereignis ausgeführt wurde. Der Ratgeber fragt den Systemkatalog ab, um den Datenbanknamen zu suchen, der DatabaseID entspricht.

Hinweis:

Wenn eine Datenbank getrennt, angefügt, gelöscht oder erstellt wurde, nachdem eine Ablaufverfolgung gesammelt wurde, weichen die DatabaseID- und DatabaseName-Zuordnungen möglicherweise von denen beim Erstellen der Ablaufverfolgung ab. Der Datenbankmodul-Optimierungsratgeber kann diese Informationen nicht bestimmen. Wenn dies auftritt, müssen Sie DatabaseID vollständig aus der Ablaufverfolgung entfernen, um zu verhindern, dass der Datenbankmodul-Optimierungsratgeber eine fehlerhafte Datenbank optimiert.

• Wenn in der Ablaufverfolgung weder DatabaseName noch DatabaseID als Spalte vorhanden ist, entscheidet der Datenbankmodul-Optimierungsratgeber wie bei Transact-SQL-Skripts für die einzelnen SPID-Spalten in der Ablaufverfolgungsdatei, welche Datenbank für die einzelnen Anweisungen verwendet werden soll. Wenn keine SPID-Spalte vorhanden ist, wird diese Entscheidung genau wie für Transact-SQL-Skriptdateien getroffen.

Der Datenbankmodul-Optimierungsratgeber verwendet beim Analysieren der einzelnen Anweisungen außerdem die Anmeldeinformationen (wie bei der Wiedergabe von SQL Server Profiler). Standarddatenbanken auf dem Server können sich aufgrund der LoginName-Spaltenwerte in der Ablaufverfolgungsdatei ändern.

Hinweis:
Wenn eine in der Ablaufverfolgung vorhandene Anmeldung nicht länger im System auftritt, wird sie vom Datenbankmodul-Optimierungsratgeber ignoriert. Der Datenbankmodul-Optimierungsratgeber verwendet dann die Anmeldung als Standard, die zurzeit den Optimierungsprozess ausführt. Hierbei wird eine Meldung in das Optimierungsprotokoll des Datenbankmodul-Optimierungsratgebers geschrieben.

Optimieren von Zeitgrenzen

In SQL Server 2005 können Sie mithilfe des Datenbankmodul-Optimierungsratgebers eine bestimmte oder unbegrenzte Optimierungszeit angeben. Im Indexoptimierungs-Assistent war dieses Feature nicht verfügbar. Weitere Informationen finden Sie unter Beschränken von Optimierungsdauer und -ereignissen.

Siehe auch

Andere Ressourcen

Lernprogramm zum Datenbankmodul-Optimierungsratgeber
Optimieren des physikalischen Datenbankentwurfs

Hilfe und Informationen

Informationsquellen für SQL Server 2005