SQL – Fragen und AntwortenSommerzeit, Serverspeicher und mehr

Herausgegeben von Nancy Michell

Sommerzeit

F: Muss ich angesichts der in den USA bevorstehenden Änderung der Sommerzeit, die in Übereinstimmung mit dem Energy Policy Act von 2005 erfolgt, SQL Server™ aktualisieren?

A: Nein. Zu diesem Zeitpunkt sind keine SQL Server-spezifischen Aktualisierungen erforderlich, um die Änderung der Sommerzeit zu unterstützen. SQL Server ruft zeitbezogene Daten aus dem zugrunde liegenden Betriebssystem ab. Das bedeutet, dass SQL Server die Werte des Betriebssystems verwendet und anzeigt, wenn das Betriebssystem die richtigen Daten und Zeiten berichtet. In Übereinstimmung mit der in den USA bevorstehenden Änderung der Sommerzeit müssen Sie Ihre Versionen von Windows® aktualisieren. Informationen hierzu finden Sie unter support.microsoft.com/kb/928388. Diese Aktualisierung ist aufgrund der bevorstehenden Änderung der Sommerzeit unter allen Windows-Betriebssystemen vor Windows Vista™ (enthält die Änderung bereits) erforderlich, einschließlich derjenigen, die SQL Server ausführen. (Auch in Australien werden Änderungen vorgenommen. Siehe support.microsoft.com/kb/912475.)

Herstellen einer Verbindung mit Windows Vista

F: Ich habe Windows Vista installiert und kann jetzt keine Verbindung zu SQL Server 2005 auf meinem System herstellen. Ich bin ein lokaler Administrator und konnte diese Verbindung bisher problemlos herstellen. Was ist passiert?

A: Hierbei handelt es sich um erwartetes Verhalten in Windows Vista und SQL Server 2005 ohne Service Pack 2 (SP2). Windows Vista besitzt ein neues Sicherheitsmodell (Benutzerkontensteuerung), das Ihre Mitgliedschaft in der lokalen Administratorgruppe erfasst und Sie bittet, Vorgänge zu überprüfen, für die Administratorrechte erforderlich sind. Wenn Sie auf die Schaltfläche „Zulassen“ klicken, werden Ihre Anmeldeinformationen einschließlich Ihres Administratortokens an die Anwendung gesendet. Im Fall vom SQL Server Management Studio (SSMS) wird kein Dialogfeld angezeigt, weil für die Ausführung des Tools keine Administratorrechte erforderlich sind. Das Problem besteht darin, dass die SQL Server 2005-Systemadministratorrolle standardmäßig die lokale Administratorgruppe aus dem Betriebssystem enthält. In der Vergangenheit hat Ihr Konto genau diese für den Zugriff auf SQL Server verwendet. Da Windows Vista diese Berechtigung nicht mitsendet, erhalten Sie keinen Zugriff.

Beachten Sie, dass SQL Server 2005 ohne SP2 nicht unter Windows Vista unterstützt wird und dass SP2 ein Tool hat, das Ihr Konto für Sie hinzufügt. Wenn Sie noch auf SP2 warten, kann dies leicht behoben werden. Ihr eigenes Windows-Benutzerkonto muss SQL Server, in Ihrem Fall der Systemadministratorrolle, hinzugefügt werden. Dies erreichen Sie, indem Sie mit der rechten Maustaste auf „SQL Server Management Studio“ klicken und „Ausführen als Administrator“ auswählen. Stellen Sie eine Verbindung zu Ihrem SQL Server her, und fügen Sie Ihr Windows-Konto der Systemadministratorrolle hinzu. Weitere Informationen hierzu finden Sie unter SQL Server Books Online (auf Englisch).

Transaktionsreplikation mit Ansichten

F: Wenn ich eine veröffentlichte Ansicht habe und diese aktualisiere, weiß ich, dass diese Transaktion repliziert wird. Wird die Transaktion jedoch auch repliziert, wenn ich die Basistabelle dieser Ansicht aktualisiere? Wird darüber hinaus die Transaktion repliziert, wenn ich von einer veröffentlichten Tabelle eine Ansicht erstelle und die Ansicht anstelle der Basistabelle aktualisiere?

A: Angenommen, die Basistabelle ist als Artikel in einer Veröffentlichung konfiguriert (d. h. auch sie ist für die Replikation konfiguriert), dann werden alle Aktualisierungen der Basistabelle repliziert.

Wenn Sie eine Ansicht replizieren, ist standardmäßig alles, was als Teil einer Ansicht repliziert wird, der Schemateil der Ansicht oder der Code hinter der Ansicht. Die zugrunde liegenden Daten gehören nicht dazu, es sei denn, Sie haben eine indizierte Ansicht. Jedes Mal, wenn Sie (auch ohne Replikation) eine Ansicht aktualisieren, in diesem Fall also eine Datenbearbeitungssprachen-Anweisung (Data Manipulation Language, DML) mit der Ansicht als Ziel ausführen, aktualisieren Sie tatsächlich nur die Daten in der zugrunde liegenden Tabelle, nicht die Ansicht. Eine Ansicht ist nur ein logischer Speicher einer Abfrageanweisung ohne verbundenen physischen Speicher (es sei denn, Sie verwenden auch hier indizierte Ansichten).

Maximaler Serverspeicher

F: Ich habe ein System, auf dem Windows Server® 2003 und SQL Server 2000 mit 5 GB RAM ausgeführt werden. Angenommen, ich verwende den /3 GB-Switch zum Erhöhen des virtuellen Adressspeichers für meinen Benutzermodus, den /PAE-Switch zum Laden der Windows-Kernelversion der physischen Adresserweiterung (PAE) und setze aktivierte AWE (Address Windowing Extensions) auf 1 (und aktiviere Sperrseiten im Speicher). Konfiguriert die Option für maximalen Serverspeicher bei aktivierten AWE nur die Größe des Datencaches oder die Größe aller Puffercaches (Daten, Prozesse, Sitzungen usw.)? Nur der Datencache kann den AWE-zugeordneten Speicher nutzen. Wenn ich den maximalen Serverspeicher auf 4 GB konfiguriere, verwendet der Datencache nur 1 GB (den durch AWE zugeordneten Teil)? Oder kann er dieses zusätzliche 1 GB verwenden und weiterhin verwenden oder mit allen anderen Speicherverbrauchern im Standardadressraum konkurrieren?

A: Ein maximaler Serverspeicher beschränkt immer die gesamte Pufferpoolgröße. Der einzige Verbraucher, der den AWE-zugeordneten Speicher nutzen kann, ist jedoch der Datencache.

Um auf Ihre erste Frage zurückzukommen: Auch mit aktivierten AWE beschränkt der maximale Serverspeicher den gesamten Pufferpool. Verbraucher, die keinen Datencache verwenden, verwenden aber nie AWE-zugeordneten Speicher.

Nun zu Ihrer zweiten Frage: Der Datencache verwendet AWE-zugeordneten Speicher sowie jeden anderen Speicher im Pufferpool, den SQL Server für geeignet hält. Es findet keine Begrenzung auf AWE-Speicher statt. Er ist nur zufällig der einzige Verbraucher, der AWE-Speicher nutzen kann. Weitere Informationen zum /3 GB-Switch erhalten Sie im Blog von Raymond Chen (auf Englisch).

Profilerstellung und Leistung

F: Ich arbeite mit einem SQL Server 2000, der in der Produktion gespiegelt wird. Wenn ich SQL Server Profiler auf dem Datenbankcomputer starte und die Ablaufverfolgungsdaten in eine Datei schreibe, stelle ich einen erheblichen Leistungsabfall fest. Warum?

A: Der Grund für den Leistungsabfall hängt davon ab, wo Sie Profiler ausführen. Wenn Sie Profiler interaktiv auf dem Servercomputer ausführen, verbrauchen die Benutzeroberfläche von Profiler sowie die CPU auf dem Server Speicher, was die Leistung beeinträchtigt.

Wenn Sie Profiler interaktiv auf einer Arbeitsstation ausführen, dann verschieben Sie Ereignisinformationen im gesamten Netzwerk. Dies wirkt sich auf den Durchsatz aus. Wenn Sie das gleiche Netzwerk für die Spiegelung verwenden, werden Sie dort ebenso eine Beeinträchtigung feststellen. Wenn Sie darüber hinaus die Profiler-Ausgabe auf einer Netzwerkfreigabe speichern, verschieben Sie Daten im gesamten Netzwerk, was die Leistung beeinträchtigt.

Die beste Methode, diese Folgen zu begrenzen, besteht wahrscheinlich darin, Profiler in nicht interaktivem Modus auf dem Server auszuführen, der die zu profilierende Instanz ausführt, und anschließend die Ausgabe zu einer lokalen Datei zu leiten. Mit dieser Methode werden zwar Serverressourcen verbraucht, die Auswirkung ist jedoch am geringsten. Sie funktioniert viel besser als die (speicherinterne) Profiler-Ablaufverfolgung. Die Dateiablaufverfolgung verwendet den Systemspeicher effizienter. Sie verfügt über größere Puffer und leert sie effektiver auf den Datenträger. Darüber hinaus besteht keine Abhängigkeit von externen Prozessen (wie bei SQL Server Profiler).

Schließlich werden die Ablaufverfolgungsdaten in eine Datenträgerdatei geschrieben, während Profiler noch das Profil erstellt. Die Ablaufverfolgungsdatei ist freigegeben, damit andere Personen die Echtzeitprofildaten von einem Remotestandort aus anzeigen können. Wenn Sie die Ablaufverfolgungsdatei interaktiv aufrufen, bedeutet dies, dass Sie Profiler manuell aufgerufen haben und eine Ausgabe am Bildschirm anzeigen. Ablaufverfolgungen können programmatisch ohne visuelle Ausgabe erstellt werden. Aus diesem Grund sollte die Ausführung nicht interaktiv stattfinden.

Sie können eine Freigabe zusätzlich zu einem lokalen Verzeichnis erstellen, und andere Benutzer können auf die dort gefundenen Dateien zugreifen. Dies stellt in der Regel kein Problem dar. Wie oben erwähnt, möchten Sie keine Ablaufverfolgungsausgabe an eine Datei auf einer Remotefreigabe senden, insbesondere nicht an eine, auf die über die gleiche Netzwerkpipe wie für die Spiegelung zugegriffen wird.

Sie sollten auch nur den Minimalsatz an Ereignissen auswählen, der für Ihre Untersuchung erforderlich ist. Die Ablaufverfolgungsdatei sollte auf dem schnellsten Laufwerk Ihres Systems gespeichert werden. Wenn möglich, sollte es sich um ein anderes Laufwerk handeln als das, auf dem sich die SQL Server-Datenbank und die Transaktionsprotokolle befinden. Wenn Sie weiterhin einen erheblichen Leistungsabfall feststellen, teilen Sie die Ereignisse in zwei oder mehr Verfolgungen auf, die jeweils auf eine andere Festplatte abzielen. Selbst wenn die Ablaufverfolgungen auf die gleiche Festplatte abzielen, profitieren Sie von einer Teilung, weil jede Verfolgung ihren eigenen Puffersatz besitzt. Weitere Informationen erhalten Sie unter sp_trace_create und Ähnlichem unter SQL Server Books Online (auf Englisch).

Clusterbildungsprobleme

F: Ich versuche SQL Server auf einem Cluster zu installieren, auf dem Windows Server 2003 ausgeführt wird. Bei jedem Versuch erhalte ich eine Fehlermeldung, die besagt, dass beim Ausführen erforderlicher Vorgänge auf den Clusterknoten ein Setupfehler aufgetreten ist. In der Datei „sqlstp.log“ steht:

Script file copied to '\\SERVER01\ADMIN$\SERVER01_MSSQLSERVER.iss' successfully.
Installing remote service (SERVER01)...
An error occured in the service create (SERVER01): 1069...

Was passiert?

A: Für diesen Fehler gibt es mehrere mögliche Gründe. Das Setup installiert den Windows NT®-Dienst auf allen ausgewählten Knoten, um die Installation auf den einzelnen Computern von einem Remotestandort aus zu verwalten. Daher müssen Sie sich auf einige Schwierigkeiten einstellen.

Erstens besitzen Ihre Domänenkontobenutzer möglicherweise eine Gruppenrichtlinie, die eine Berechtigung für das Anmelden als Dienst verweigert. (Beachten Sie, dass die Domänenrichtlinie die Richtlinie Ihres lokalen Computers außer Kraft setzt.) Stellen Sie sicher, dass Sie ein Konto ohne diese Einschränkungen verwenden.

Zweitens sollte das angemeldete Konto des Computers, auf dem Sie das Setup ausführen, aus folgenden Gründen auf allen Knoten über Administratorzugriff verfügen: Für den Hauptinstallationsvorgang wird ein Remoteregistrierungszugriff auf allen Computern benötigt. Setup kopiert „cnvsvc.exe“ in das Windows-Verzeichnis des Remotecomputers. Alternativ verwendet Setup Windows-APIs, die nur die angemeldete Kontoberechtigung für den Zugriff auf Remotecomputer verwenden. Aus diesen Gründen sollten Sie standardmäßig in allen Modi als Administrator angemeldet sein.

Notfallwiederherstellungsplan

F: Ich überlege, ob ich die Datenbankspiegelung (asynchroner Modus) oder den Protokollversand für die Implementierung meiner Notfallwiederherstellungsstrategie für meine SAP-Datenbanken verwenden soll. Meine Standorte für die Produktion und die Notfallwiederherstellung verfügen über eine 100 MB-Breitbandverbindung, die nicht dediziert für die Spiegelungssitzung verwendet wird. Die Verbindung wird von mehreren Spiegelungssitzungen oder sogar von anderen Notfallwiederherstellungsservern gemeinsam genutzt.

Wenn ein Netzwerkproblem auftritt, dem zufolge der Protokolldatensatz nicht an die Spiegelungsdatenbank gesendet werden kann, wird der Versuch dann wiederholt?

Gibt es einen Aufbewahrungszeitraum, wenn die Spiegelungssitzung angehalten wird? Gibt es, abgesehen von der Systemansicht, Protokollinformationen, mit denen ich den Datenverkehr während der Spiegelung und die Übertragung der Protokolldatensätze überwachen kann?

A: Beginnen wir mit dem Beantworten der Frage: Was ist die Wiederholungslogik von Datenbankspiegelungen? Hierfür gibt es zwei mögliche Betrachtungsweisen: Erstens: Wenn es sich um ein vorübergehendes Netzwerkproblem handelt, wird die Verbindung des Spiegelungssitzungsstatus getrennt. Der Standardnetzwerk-Timeoutwert beträgt 10 Sekunden. Folglich kann ein Protokolldatensatz nicht von der Prinzipaldatenbank an die Spiegelungsdatenbank gesendet werden. In solchen Fällen wird der Prinzipal weiter „offen“ ausgeführt, und für die Transaktion wird auf der Clientseite ein Commit ausgeführt. Sobald das Netzwerkproblem gelöst wurde, wird automatisch ohne Benutzereingriff eine Wiederholung der Spiegelungssitzung durchgeführt. Es wird mithilfe der Protokolldatensätze ein Aufholversuch unternommen. Die Partner werden zuerst synchronisiert, und sobald sie soweit sind, wird der Status synchronisiert.

Zweitens: Wenn es ein Wiederholungsproblem gibt, wird der Status der Spiegelungssitzung angehalten. Bei einem Wiederholungsproblem kann die Spiegelungsdatenbank nicht die Protokolldatensätze in ihrer Datenbank übertragen. Wiederholungsprobleme werden hauptsächlich durch eine nicht gefundene physische Datei oder durch unzureichenden Speicherplatz verursacht. In solchen Fällen wird der Prinzipal weiter offen ausgeführt, und für die Transaktion wird folglich auf der Clientseite ein Commit ausgeführt. Nachdem Sie das Wiederholungsproblem manuell auf dem Spiegelserver gelöst haben, erfordert die Spiegelungssitzung Eingriffe:

ALTER DATABASE <db> SET PARTNER RESUME; 

Hinsichtlich des Aufbewahrungszeitraums lautet die Antwort, dass die Protokolldatensätze unabhängig von der Trennung oder der Unterbrechung der Spiegelungssitzung aufbewahrt werden, bis die Sitzung wiederhergestellt und alle Datensätze seit der Unterbrechung der Sitzung bis zur Wiederaufnahme auf dem Spiegel gesichert sind. Während die Spiegelungssitzung getrennt oder angehalten wurde, kann das Protokoll im Prinzipal im Grunde genommen nicht abgeschnitten werden, weil dadurch die Protokollwiederholungskette gebrochen wird. Das bedeutet, dass das Protokoll des Prinzipals uneingeschränkt wächst, bis die Sitzung wiederhergestellt ist. Deshalb gibt es in der Spiegelungssitzung keine Aufbewahrungsbegrenzung. Die einzige Beschränkung stellt der Festplattenspeicher dar, der dem Prinzipalserver für die Speicherung des Protokolls zur Verfügung steht, da das Protokoll nicht abgeschnitten werden kann.

Es gibt keine bestimmte Protokolldatei, die Sie für die Spiegelungsüberwachung verwenden können. SQL Server 2005 stellt zu diesem Zweck ein GUI-Tool, den Datenbankspiegelungs-Monitor, zur Verfügung. Mit diesem können Systemadministratoren den Status anzeigen und aktualisieren sowie Warnschwellenwerte für verschiedene wichtige Leistungsmetriken konfigurieren. Dieses Tool kann eine Warnung ausgeben, wenn die Spiegelung nicht zufriedenstellend durchgeführt wird. Das Hauptproblem hinsichtlich der Leistung der Datenbankspiegelung besteht in der rechtzeitigen Verarbeitung der Protokolldatensätze. Weitere Informationen zur Überwachung von Datenbankspiegelungen finden Sie in dem Artikel „Überwachen des Spiegelungsstatus“ unter https://msdn2.microsoft.com/de-de/library/ms365781.aspx.

Unser Dank gilt den folgenden Microsoft-IT-Experten für ihre fachliche Unterstützung: Chad Boyd, Sandu Chirica, Alan Doby, Kaloian Manassiev, Luciano Moreira, Ivan Penkov, Sivagaminathan Rajarethinam, Deborah To, Patrick Woodward, Buck Woody, Stanley Yau und Warren Young.

© 2008 Microsoft Corporation und CMP Media, LLC. Alle Rechte vorbehalten. Die nicht genehmigte teilweise oder vollständige Vervielfältigung ist nicht zulässig.