Gesichtspunkte bei der Verwendung von Testservern

Die Verwendung eines Testservers zum Optimieren einer Datenbank auf einem Produktionsserver ist ein wichtiger Vorteil des Database Engine Tuning Advisor. Mit diesem Feature können Sie den Optimierungsaufwand auf einen Testserver entladen, ohne die tatsächlichen Daten vom Produktionsserver auf den Testserver zu kopieren.

Wenn Sie dieses Feature erfolgreich verwenden möchten, lesen Sie die in den folgenden Abschnitten aufgeführten Überlegungen.

Einrichten der Testserver-/Produktionsserverumgebung

• Der Benutzer, der einen Testserver zum Optimieren einer Datenbank auf einem Produktionsserver verwenden möchte, muss auf beiden Servern vorhanden sein, oder dieses Szenario funktioniert nicht.

• Die erweiterte gespeicherte Prozedur xp_msver muss aktiviert sein, um das Testserver-/Produktionsserverszenario zu verwenden. Der Datenbankmoduloptimierungsratgeber verwendet diese erweiterte gespeicherte Prozedur, um die Anzahl der Prozessoren und den verfügbaren Arbeitsspeicher des Produktionsservers abzurufen, der beim Optimieren des Testservers verwendet werden soll. Wenn xp_msver nicht aktiviert ist, geht der Datenbankmoduloptimierungsratgeber von den Hardwaremerkmalen des Computers aus, auf dem der Datenbankmoduloptimierungsratgeber ausgeführt wird. Wenn die Hardwaremerkmale des Computers, auf dem der Database Engine Tuning Advisor ausgeführt wird, nicht verfügbar sind, wird ein Prozessor und 1024 Megabyte (MBs) des Arbeitsspeichers vorausgesetzt. Diese erweiterte gespeicherte Prozedur ist standardmäßig aktiviert, wenn Sie SQL Server installieren. Weitere Informationen finden Sie unter Surface Area Configuration and xp_msver (Transact-SQL).

• Der Datenbankmoduloptimierungsratgeber erwartet, dass die Editionen von SQL Server sowohl auf dem Testserver als auch auf dem Produktionsserver identisch sind. Wenn zwei verschiedene Editionen vorhanden sind, hat die Edition auf dem Testserver Vorrang. Wenn beispielsweise der Testserver SQL Server Standard ausführt, enthält der Datenbankmoduloptimierungsratgeber keine indizierten Ansichten, Partitionierungs- und Onlinevorgänge in seinen Empfehlungen, auch wenn der Produktionsserver SQL Server Enterprise ausführt.

Informationen zum Testserver-/Produktionsserververhalten

• Der Datenbankmoduloptimierungsratgeber berücksichtigt beim Erstellen von Empfehlungen Hardwareunterschiede zwischen der Produktion und dem Testserver. Die Empfehlung ist identisch, als ob die Optimierung allein auf dem Produktionsserver durchgeführt wurde.

• Der Datenbankmoduloptimierungsratgeber kann einige Lasten auf dem Produktionsserver zum Sammeln von Metadaten sowie zum Erstellen von Statistiken aufzwingen, die für die Optimierung erforderlich sind.

• Der Datenbankmoduloptimierungsratgeber kopiert keine tatsächlichen Daten vom Produktionsserver auf den Testserver. Sie kopiert nur die Metadaten der Datenbanken und die erforderlichen Statistiken.

• Alle Sitzungsinformationen werden in msdb auf dem Produktionsserver gespeichert. Auf diese Weise können Sie alle verfügbaren Testserver für die Optimierung ausnutzen und Informationen zu allen Sitzungen an einem Zentralen Ort (dem Produktionsserver) verfügbar sein.

Probleme im Zusammenhang mit der Shelldatenbank

• Nach der Optimierung sollte der Datenbankmoduloptimierungsratgeber während des Optimierungsprozesses alle Metadaten entfernen, die es auf dem Testserver erstellt hat. Dies schließt die Shelldatenbank ein. Wenn Sie eine Reihe von Optimierungssitzungen mit denselben Produktions- und Testservern durchführen, sollten Sie diese Shelldatenbank beibehalten, um Zeit zu sparen. Geben Sie in der XML-Eingabedatei das RetainShellDB-Unterelement mit den anderen Unterelementen unter dem übergeordneten Element TuningOptions an. Die Verwendung dieser Optionen bewirkt, dass der Datenbankmoduloptimierungsratgeber die Shelldatenbank behält. Weitere Informationen finden Sie unter XML-Eingabedateireferenz (Database Engine Tuning Advisor).

• Shelldatenbanken verbleiben möglicherweise auf dem Testserver nach einer erfolgreichen Testserver-/Produktionsserveroptimierungssitzung, auch wenn Sie das RetainShellDB-Unterelement nicht angegeben haben. Diese unerwünschten Shelldatenbanken stören möglicherweise nachfolgende Optimierungssitzungen und sollten gelöscht werden, bevor sie eine andere Testserver-/Produktionsserveroptimierungssitzung durchführen. Wenn eine Optimierungssitzung unerwartet beendet wird, bleiben die Shelldatenbanken auf dem Testserver und die Objekte in diesen Datenbanken möglicherweise auf dem Testserver zurück. Sie sollten diese Datenbanken und Objekte auch löschen, bevor Sie eine neue Testserver-/Produktionsserveroptimierungssitzung starten.

Probleme im Zusammenhang mit dem Optimierungsprozess

• Der Benutzer muss das Optimierungsprotokoll auf Optimierungsfehler überprüfen, die sich aus Unterschieden zwischen den Produktions- und Testservern ergeben, und auf Fehler, die sich aus dem Kopieren von Metadaten aus der Produktion auf den Testserver ergeben. Beispielsweise ist auf dem Testserver möglicherweise keine Benutzeranmeldung vorhanden. Wenn auf dem Testserver keine Benutzeranmeldung vorhanden ist, können diese Ereignisse in der Workload, die von dieser Benutzeranmeldung ausgestellt werden, möglicherweise nicht aktiviert werden. Verwenden Sie die GUI des Datenbankmoduloptimierungsratgebers, um das Optimierungsprotokoll anzuzeigen. Weitere Informationen finden Sie unter Anzeigen und Arbeiten mit der Ausgabe des Datenbankmoduloptimierungsratgebers

• Wenn der Datenbankmoduloptimierungsratgeber nicht viele Ereignisse optimieren kann, da objekte in der Shelldatenbank fehlen, die der Datenbankmoduloptimierungsratgeber auf dem Testserver erstellt, muss der Benutzer das Optimierungsprotokoll überprüfen. Ereignisse, die nicht abgestimmt werden können, werden im Protokoll aufgelistet. Um die Datenbank auf dem Testserver erfolgreich zu optimieren, muss der Benutzer die fehlenden Objekte in der Shelldatenbank erstellen und dann eine neue Optimierungssitzung starten.

• Wenn auf dem Testserver bereits eine Datenbank mit demselben Namen vorhanden ist, kopiert der Datenbankmoduloptimierungsratgeber keine Metadaten, sondern führt die Optimierung fort und sammelt nach Bedarf Statistiken. Dies ist nützlich, wenn der Benutzer bereits eine Datenbank auf dem Testserver erstellt und die entsprechenden Metadaten kopiert hat, bevor er den Optimierungsratgeber für Datenbankmodul aufruft.

• Wenn die Option DATE_CORRELATION_OPTIMIZATION für eine Datenbank auf dem Produktionsserver aktiviert ist, werden Metadaten und die mit dieser Option verknüpften Daten beim Optimieren des Testservers nicht vollständig skriptiert. Wenn die Optimierung für ein Testserver-/Produktionsserverszenario durchgeführt wird, können die folgenden Probleme auftreten:

  • Benutzer können unterschiedliche Abfragepläne auf den Servern für Abfragen verwenden, die die Option DATE_CORRELATION_OPTIMIZATION verwenden.

  • Der Datenbankmoduloptimierungsratgeber schlägt möglicherweise vor, indizierte Ansichten zu löschen, die die Option DATE_CORRELATION_OPTIMIZATION im Empfehlungsskript erzwingen.

  Daher sollten Sie empfehlungen ignorieren, die der Datenbankmoduloptimierungsratgeber über die indizierten Ansichten vorgibt, die Korrelationsstatistiken enthalten, da der Datenbankmoduloptimierungsratgeber seine Kosten kennt, aber nicht deren Vorteile. Der Datenbankmoduloptimierungsratgeber empfiehlt möglicherweise nicht die Auswahl bestimmter Indizes wie gruppierte Indizes in Datetime-Spalten , die nützlich sein könnten, wenn DATE_CORRELATION_OPTIMIZATION aktiviert ist.

  Um festzustellen, ob eine Ansicht auf Korrelationsstatistiken basiert, wählen Sie die is_date_correlation_view Spalte der Sys.views-Katalogansicht aus.