Freigeben über

Gesichtspunkte bei der Verwendung von Testservern

  • Artikel

Aktualisiert: 05. Dezember 2005

Die Verwendung eines Testservers zur Optimierung einer Datenbank auf einem Produktionsserver ist ein wesentlicher Vorteil des Datenbankmodul-Optimierungsratgebers. Mit diesem Feature 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.

ms189551.note(de-de,SQL.90).gifHinweis:
Das Feature der Optimierung mit einem Testserver wird auf der grafischen Benutzeroberfläche (Graphical User Interface, GUI) des Datenbankmodul-Optimierungsratgebers nicht unterstützt.

Lesen Sie die in den folgenden Abschnitten aufgeführten Punkte sorgfältig durch, um dieses Feature 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_msver muss für die Verwendung des Testserver/Produktionsserver-Szenarios aktiviert sein. Der Datenbankmodul-Optimierungsratgeber 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. Ist xp_msver nicht aktiviert, verwendet der Datenbankmodul-Optimierungsratgeber die Hardwaremerkmale des Computers, auf dem der Datenbankmodul-Optimierungsratgeber ausgeführt wird. Sind die Hardwaremerkmale des Computers, auf dem der Datenbankmodul-Optimierungsratgeber ausgeführt wird, nicht verfügbar, wird von einem Prozessor und 1024 MB Arbeitsspeicher ausgegangen. Diese erweiterte gespeicherte Prozedur wird standardmäßig aktiviert, wenn Sie Microsoft SQL Server 2005 installieren. Weitere Informationen finden Sie unter Oberflächenkonfiguration und xp_msver (Transact-SQL).
  • Der Datenbankmodul-Optimierungsratgeber 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 Edition, ausgeführt, schließt der Datenbankmodul-Optimierungsratgeber keine indizierten Sichten, Partitionierungen und Onlinevorgänge in seine Empfehlungen ein, selbst wenn SQL Server Enterprise Edition auf dem Produktionsserver ausgeführt wird. Weitere Informationen zu den Optimierungsoptionen, die von den verschiedenen Editionen von SQL Server unterstützt werden, finden Sie unter Nicht unterstützte Optimierungsoptionen.

Informationen zum Verhalten von Testserver und Produktionsserver

  • Der Datenbankmodul-Optimierungsratgeber 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 Datenbankmodul-Optimierungsratgeber kann durch das Sammeln der Metadaten und die Erstellung der erforderlichen Statistiken für die Optimierung zusätzliche Arbeitsauslastung auf dem Produktionsserver verursachen.
  • Der Datenbankmodul-Optimierungsratgeber 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 Datenbankmodul-Optimierungsratgeber 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 Datenbankmodul-Optimierungsratgeber veranlasst, die Shelldatenbank beizubehalten. Weitere Informationen finden Sie unter XML-Eingabedatei (Referenz) (DTA).
  • 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. 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 Datenbankmodul-Optimierungsratgebers, um das Optimierungsprotokoll anzuzeigen. Weitere Informationen finden Sie unter Vorgehensweise: Anzeigen der Optimierungsausgabe.
  • Wenn der Datenbankmodul-Optimierungsratgeber viele Ereignisse nicht optimieren kann, weil Objekte in der Shelldatenbank fehlen, die vom Datenbankmodul-Optimierungsratgeber 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. (Siehe Vorgehensweise: Optimieren einer Datenbank mithilfe des dta-Dienstprogramms.)
  • Ist auf dem Testserver eine Datenbank mit demselben Namen bereits vorhanden, kopiert der Datenbankmodul-Optimierungsratgeber 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 Datenbankmodul-Optimierungsratgebers 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 Datenbankmodul-Optimierungsratgeber im Empfehlungsskript das Löschen von indizierten Sichten vor, die die DATE_CORRELATION-Option erzwingen.
      Daher ist es unter Umständen sinnvoll, Empfehlungen des Datenbankmodul-Optimierungsratgebers zu den indizierten Sichten, die Korrelationsstatistiken enthalten, zu ignorieren. Der Datenbankmodul-Optimierungsratgeber kennt deren Kosten, aber nicht deren Vorteile. Der Datenbankmodul-Optimierungsratgeber 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önnte.
      Wählen Sie die is_date_correlation_view-Spalte der sys.views-Katalogsicht aus, um zu bestimmen, ob eine Sicht auf Korrelationsstatistiken basiert.
      Weitere Informationen zu dieser Option finden Sie unter Optimieren von Abfragen, die auf korrelierte datetime-Spalten zugreifen.

Siehe auch

Konzepte

Reduzieren der Optimierungsauslastung des Produktionsservers

Andere Ressourcen

ALTER DATABASE (Transact-SQL)

Hilfe und Informationen

Informationsquellen für SQL Server 2005

Änderungsverlauf

Version Verlauf

05. Dezember 2005
Neuer Inhalt:
  • Informationen zu den Auswirkungen, die sich aus der Ausführung verschiedener Editionen von SQL Server auf dem Testserver und dem Produktionsserver ergeben können, wurden im Abschnitt "Einrichten der Testserver-/Produktionsserverumgebung" hinzugefügt.
  • Informationen zu den Auswirkungen nachfolgender Optimierungssitzungen, wenn unerwünschte Shelldatenbanken versehentlich nach dem Optimieren auf dem Testserver verbleiben, wurden im Abschnitt "Aspekte im Zusammenhang mit der Shelldatenbank" hinzugefügt.