Freigeben über

Gesichtspunkte bei der Verwendung von Testservern

  • Artikel

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.

Hinweis

Die Funktion der Optimierung mit einem Testserver wird auf der grafischen Benutzeroberfläche (Graphical User Interface, GUI) des Datenbankoptimierungsratgebers nicht unterstützt.

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. Wird beispielsweise auf dem Testserver SQL Server Standard, ausgeführt, schließt der Datenbankoptimierungsratgeber keine indizierten Sichten, Partitionierungen und Onlinevorgänge in seine Empfehlungen ein, selbst wenn SQL Server Enterprise auf dem Produktionsserver 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.

  • 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 dazu in der XML-Eingabedatei das untergeordnete RetainShellDB -Element zusammen mit den anderen untergeordneten Elementen des übergeordneten TuningOptions -Elements an. Mit diesen Optionen wird der Datenbankoptimierungsratgeber veranlasst, die Shelldatenbank beizubehalten. 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.

  • 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. Beispielsweise ist ein Benutzeranmeldename auf dem Testserver nicht vorhanden. Ist ein Benutzeranmeldename auf dem Testserver nicht vorhanden, können die Ereignisse in der Arbeitsauslastung, die von diesem Benutzer ausgelöst werden, 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 optimiert 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 DATE_CORRELATION_OPTIMIZATION-Option für eine Datenbank auf dem Produktionsserver aktiviert, wird bei der Optimierung des Testservers kein vollständiges Skript für die Metadaten und die Daten zu dieser Option erstellt. Bei der Optimierung in einem Testserver/Produktionsserver-Szenario 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.

    • Möglicherweise schlägt der Datenbankoptimierungsratgeber im Empfehlungsskript das Löschen von indizierten Sichten vor, die die DATE_CORRELATION_OPTIMIZATION-Option 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.