Gesichtspunkte bei der Verwendung von Testservern

Gilt für:SQL Server

Die Verwendung eines Testservers zur Optimierung einer Datenbank auf einem Produktionsserver ist ein wesentlicher Vorteil des Datenbankoptimierungsratgebers. Mit dieser Funktion können Sie den Verarbeitungsaufwand für die Optimierung auf einen Testserver auslagern, ohne die tatsächlichen Daten vom Produktionsserver auf den Testserver zu kopieren.

Lesen Sie die in den folgenden Abschnitten aufgeführten Punkte sorgfältig durch, um diese Funktion optimal einzusetzen.

Einrichten der Testserver-/Produktionsserverumgebung

• Der Benutzer, der mit einem Testserver eine Datenbank auf einem Produktionsserver optimieren möchte, muss auf beiden Servern einen Anmeldenamen besitzen. Andernfalls kann das Szenario nicht verwendet werden.

• Die erweiterte gespeicherte Prozedur xp_msvermuss für die Verwendung des Testserver/Produktionsserver-Szenarios aktiviert sein. Der Datenbankoptimierungsratgeber ruft mit dieser erweiterten gespeicherten Prozedur die Anzahl der Prozessoren und den verfügbaren Arbeitsspeicher des Produktionsservers ab, die für die Optimierung des Testservers verwendet werden sollen. Wenn xp_msver nicht aktiviert ist, übernimmt der Datenbankoptimierungsratgeber die Hardwaremerkmale des Computers, auf dem er ausgeführt wird. Wenn die Hardwaremerkmale des Computers, auf dem der Datenbankoptimierungsratgeber ausgeführt wird, nicht zur Verfügung stehen, geht der Ratgeber von einem Prozessor und 1024 MB (Megabyte) Speicher aus. Diese erweiterte gespeicherte Prozedur wird standardmäßig aktiviert, wenn Sie SQL Server installieren. Weitere Informationen finden Sie unter Oberflächenkonfiguration und xp_msver (Transact-SQL).

• Der Datenbankoptimierungsratgeber geht davon aus, dass die Editionen von SQL Server sowohl auf dem Testserver als auch auf dem Produktionsserver identisch sind. Bei verschiedenen Editionen hat die Edition auf dem Testserver Vorrang. Wenn auf dem Testserver beispielsweise SQL Server Standard ausgeführt wird, schließt der Datenbankoptimierungsratgeber indizierte Sichten, Partitionierung und Onlinevorgänge nicht in seine Empfehlungen ein, selbst wenn auf dem Produktionsserver SQL Server Enterprise ausgeführt wird.

Informationen zum Verhalten von Testserver und Produktionsserver

• Der Datenbankoptimierungsratgeber berücksichtigt Hardwareunterschiede zwischen dem Produktions- und dem Testserver beim Erstellen von Empfehlungen. Die Empfehlung lautet genau so, als wenn die Optimierung auf dem Produktionsserver erfolgt wäre.

• Der Datenbankoptimierungsratgeber kann durch das Sammeln der Metadaten und die Erstellung der erforderlichen Statistiken für die Optimierung zusätzliche Arbeitsauslastung auf dem Produktionsserver verursachen.

• Der Datenbankoptimierungsratgeber kopiert keine tatsächlichen Daten vom Produktionsserver auf den Testserver. Er kopiert lediglich die Metadaten der Datenbanken und die erforderlichen Statistiken.

• Alle Sitzungsinformationen werden in msdb auf dem Produktionsserver gespeichert. So können Sie einen beliebigen verfügbaren Testserver für die Optimierung verwenden, und die Informationen zu allen Sitzungen stehen an einer Stelle (auf dem Produktionsserver) zur Verfügung.

Aspekte im Zusammenhang mit der Shelldatenbank

• Nach der Optimierung entfernt der Datenbankoptimierungsratgeber alle Metadaten, die er während der Optimierung auf dem Testserver erstellt hat. Dazu gehört auch die Shelldatenbank. Wenn Sie eine Reihe von Optimierungssitzungen mit demselben Produktions- und demselben Testserver ausführen, ist es sinnvoll, die Shelldatenbank beizubehalten, um Zeit zu sparen. Geben Sie in der XML-Eingabedatei das Unterelement RetainShellDB zusammen mit den anderen Unterelementen unter dem übergeordneten TuningOptions-Element an. Die Verwendung dieser Optionen bewirkt, dass Datenbankoptimierungsratgeber die Shelldatenbank beibehält. Weitere Informationen finden Sie unter XML-Eingabedateireferenz (Datenbankoptimierungsratgeber).

• Nach einer erfolgreichen Optimierungssitzung für einen Testserver/Produktionsserver können Shelldatenbanken auf dem Testserver verbleiben, selbst wenn Sie das Unterelement RetainShellDB nicht angegeben haben. Diese unerwünschten Shelldatenbanken können nachfolgende Optimierungssitzungen beeinträchtigen und sollten gelöscht werden, bevor Sie eine weitere Optimierungssitzung für einen Testserver/Produktionsserver ausführen. Wenn darüber hinaus eine Optimierungssitzung unerwartet beendet wird, verbleiben die Shelldatenbanken auf dem Testserver und die Objekte innerhalb dieser Datenbanken möglicherweise auf dem Testserver. Sie sollten auch diese Datenbanken und Objekte löschen, bevor Sie eine neue Optimierungssitzung für den Testserver/Produktionsserver starten.

Aspekte im Zusammenhang mit dem Optimierungsprozess

• Der Benutzer muss das Optimierungsprotokoll auf Optimierungsfehler überprüfen, die durch Unterschiede zwischen dem Produktions- und dem Testserver verursacht werden, und auf Fehler, die beim Kopieren von Metadaten vom Produktions- auf den Testserver entstehen. Zum Beispiel existiert eine Benutzeranmeldung auf dem Testserver möglicherweise nicht. Wenn auf dem Testserver keine Benutzeranmeldung vorhanden ist, können die Ereignisse im Workload, die von dieser Benutzeranmeldung stammen, möglicherweise nicht optimiert werden. Verwenden Sie die grafische Benutzeroberfläche des Datenbankoptimierungsratgebers, um das Optimierungsprotokoll anzuzeigen. Weitere Informationen finden Sie unter Anzeigen und Verwenden der Ausgabe des Datenbankoptimierungsratgebers.

• Wenn der Datenbankoptimierungsratgeber viele Ereignisse nicht optimieren kann, weil Objekte in der Shelldatenbank fehlen, die vom Datenbankoptimierungsratgeber auf dem Testserver erstellt wird, muss der Benutzer das Optimierungsprotokoll überprüfen. Ereignisse, die nicht angepasst werden können, sind im Protokoll aufgeführt. Um die Datenbank auf dem Testserver erfolgreich optimieren zu können, muss der Benutzer die fehlenden Objekte in der Shelldatenbank erstellen und dann eine neue Optimierungssitzung starten.

• Ist auf dem Testserver eine Datenbank mit demselben Namen bereits vorhanden, kopiert der Datenbankoptimierungsratgeber keine Metadaten, sondern setzt die Optimierung fort und sammelt die erforderlichen Statistiken. Dies ist nützlich, wenn der Benutzer bereits eine Datenbank auf dem Testserver erstellt hat und vor dem Aufruf des Datenbankoptimierungsratgebers die entsprechenden Metadaten kopiert hat.

• Ist die Option DATE_CORRELATION_OPTIMIZATION für eine Datenbank auf dem Produktionsserver aktiviert, werden bei der Optimierung des Testservers die Metadaten und die mit dieser Option verbundenen Daten nicht vollständig per Skript erfasst. Wenn eine Optimierung für ein Testserver-/Produktionsserver-Szenario vorgenommen wird, können die folgenden Probleme auftreten:

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

  • Der Ratgeber zur Optimierung von Datenbankmodulen kann im Empfehlungsskript vorschlagen, indizierte Ansichten zu löschen, die die Option DATE_CORRELATION_OPTIMIZATION erzwingen.

  Daher ist es unter Umständen sinnvoll, Empfehlungen des Datenbankoptimierungsratgebers zu den indizierten Sichten, die Korrelationsstatistiken enthalten, zu ignorieren. Der Datenbankoptimierungsratgeber kennt deren Kosten, aber nicht deren Vorteile. Der Datenbankoptimierungsratgeber empfiehlt möglicherweise nicht die Auswahl bestimmter Indizes, wie z.B. gruppierter Indizes für datetime -Spalten, die jedoch bei aktivierter DATE_CORRELATION_OPTIMIZATION vorteilhaft sein könnten.

  Wählen Sie die is_date_correlation_view -Spalte der sys.views -Katalogsicht aus, um zu bestimmen, ob eine Sicht auf Korrelationsstatistiken basiert.