Share via

Gesichtspunkte bei der Verwendung von Testservern

  • Artikel

Gilt für:SQL Server

Die Verwendung eines Testservers zum Optimieren einer Datenbank auf einem Produktionsserver ist ein wichtiger Vorteil des Database Engine Tuning Advisor. 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

Das Feature zum Optimieren des Testservers wird in der grafischen Benutzeroberfläche des Datenbankmoduls Tuning Advisor (GUI) 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 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 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 ist standardmäßig aktiviert, wenn Sie SQL Server installieren. Weitere Informationen finden Sie unter Surface Area Configuration and xp_msver (Transact-SQL).For more information, see 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. Bei verschiedenen Editionen 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 Verhalten von Testserver und Produktionsserver

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

  • 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. 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 sollte der Datenbankmoduloptimierungsratgeber während des Optimierungsprozesses alle Metadaten entfernen, die es 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. Die Verwendung dieser Optionen bewirkt, dass der Datenbankmoduloptimierungsratgeber die Shelldatenbank behält. Weitere Informationen finden Sie unter XML-Eingabedateireferenz (Database Engine Tuning Advisor).

  • 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 GUI des Datenbankmoduloptimierungsratgebers, um das Optimierungsprotokoll anzuzeigen. Weitere Informationen finden Sie unter Anzeigen und Verwenden der Ausgabe des Datenbankoptimierungsratgebers.

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

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

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

    • 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 keine Auswahl bestimmter Indizes wie gruppierte Indizes in Datetime-Spalten , was bei aktivierter DATE_CORRELATION_OPTIMIZATION von Vorteil sein könnte.

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