SQL – Fragen und AntwortenSpeicherkonfiguration, Leistungsprofilerstellung, Einstellen des Füllfaktors und mehr

Herausgegeben von Nancy Michell

Konfigurieren des Speichers

Tipp: Leichtere Profilerstellung

Wussten Sie, dass Sie jetzt PerfMon mit SQL Server 2005 Profiler korrelieren können?

Vielleicht haben Sie schon einmal CPU-Auslastungsspitzen, eine übermäßige Speichernutzung oder eine allgemeine Leistungsabnahme im Systemmonitor Ihres SQL Server-Computers bemerkt und sich gewundert, wodurch diese Leistungsanomalien verursacht wurden. Vor SQL Server 2005 mussten Sie Profiler zur Ablaufverfolgung verwenden, dann die „sysprocesses“ in Enterprise Manager untersuchen und abschließend die Systemmonitor-Protokolle erfassen, was natürlich den Start von PerfMon erforderte. Nach all diesen Arbeitsvorgängen mithilfe der Tools mussten die Ereignisse zwischen den Tools trotzdem noch manuell abgestimmt werden, um herauszufinden, was die Leistungsbeeinträchtigung verursachte. Sie mussten sich also durch jedes Protokoll einzeln durchkämpfen. Dies war ziemlich mühsam, aber unumgänglich, wenn Sie den Leistungsproblemen auf den Grund gehen wollten.

Mit SQL Server 2005 müssen Sie nach wie vor eine Ablaufverfolgung durchführen und Ihre PerfMon-Protokolle untersuchen, doch mithilfe von Profiler können Sie sie jetzt anhängen. Sie können einen Bildlauf durch die T-SQL-Anweisungen durchführen, und Profiler zeigt Ihnen automatisch alle Anweisungen in einer Grafik an. Wenn Sie auf der Systemmonitor-Benutzeroberfläche in Profiler klicken, gelangen Sie zu der Anweisung, die dem jeweiligen Zeitstempel entspricht. Dies erspart Ihnen bei der Problembehandlung Ihrer SQL Server-Umgebung viel Zeit.

Im Folgenden wird untersucht, wie Sie PerfMon-Protokolle an Profiler anfügen:

1. Starten Sie den Systemmonitor, und beginnen Sie mit dem Erfassen der Informationen vom Datenbankserver.
2. Erstellen Sie ein neues Gegenprotokoll unter „Leistungsprotokolle und -warnungen“, und geben Sie einen Namen für Ihr neues Protokoll ein.
3. Fügen Sie neue Zähler wie „Prozessorzeit (%)“ hinzu. Außerdem empfiehlt es sich, das Protokollieren so festzulegen, dass es entweder manuell oder anhand einer Vorgabe auf der Registerkarte „Zeitplan“ startet.
4. Klicken Sie auf „OK“. Falls Sie die manuelle Option ausgewählt haben, stellen Sie sicher, dass Sie das Protokollieren starten.
5. Richten Sie auf Ihrem SQL Server mithilfe von Profiler eine Ablaufverfolgung ein. Klicken Sie dazu im Menü „Datei“ auf „Neue Ablaufverfolgung“. Stellen Sie sicher, dass Sie StartTime und EndTime in die Ablaufverfolgung aufnehmen, benennen Sie die Ablaufverfolgung, und legen Sie fest, dass sie in einer Datei gespeichert wird. Abschließend müssen Sie den Server starten, damit eine Transaktionsaktivität simuliert wird, und dann das Erfassen von Daten über Systemmonitor und Profiler beenden.
6. Wählen Sie in Profiler im Menü „Datei“ die Option „Leistungsdaten importieren“ aus. Wählen Sie als Nächstes an dem Ort, an dem Sie das PerfMon-Protokoll ausgewählt und gespeichert haben, „Datei“ | „Öffnen“ | „Ablaufverfolgung“ aus. Wählen Sie abschließend den Ort aus, an dem Sie die Profiler-Ablaufverfolgung gespeichert haben.

Danach werden Sie viel leichter herausfinden können, welche Auswirkung bestimmte SQL-Anweisungen auf die Verarbeitungszeit hatten.

F: Ich möchte herausfinden, was die beste Speicherkonfiguration für meine SQL Server™-Computer ist. Der Administrator vor mir hat „Boot.ini“ für jeden Computer mit 12 GB RAM auf einem SQL Server 2000 mit einem Cluster mit zwei Knoten folgendermaßen festgelegt: „Yes /PAE NO /3GB“ (Keine AWE-Einstellung für SQL Server). Da ein Arbeitsspeicher von 12 GB zur Verfügung steht, ist es ratsam, den /3GB-Schalter in „Boot.ini“ zu entfernen, AWE zu aktivieren und SQL Server ungefähr 10 GB von 12 GB zuzuteilen? Auf den Computern wird außer SQL Server sonst nichts ausgeführt, es sind also keine anderen Anwendungen vorhanden, die den Speicher nutzen.

A: Ja. AWE (Address Windowing Extensions) sollte aktiviert und eine RAM-Obergrenze für SQL Server vorgegeben werden. 10 GB ist ein geeigneter Wert für einen dedizierten 12 GB-SQL Server-Computer. (Beachten Sie, dass ein Vorgabewert nur für SQL Server 2000 gilt. Ab SQL Server 2005 ist die Verwendung von AWE nicht mehr statisch und kann jederzeit geändert werden.) Es gab immer schon eine große Debatte darüber, ob sowohl der /3GB- als auch der /PAE-Schalter oder ob nur der erforderliche /PAE-Schalter verwendet werden soll. Obwohl tatsächlich nur der /PAE-Schalter erforderlich ist und AWE aktiviert sein sollte, empfiehlt es sich, beide Schalter zu verwenden. Dabei müssen jedoch einige Faktoren berücksichtigt werden.

Die Verwendung des /3GB-Schalters hängt davon ab, ob er in Ihrer Situation benötigt wird. Reichen die MemToLeave-Speicherbereiche, die sich in den ersten 2 oder 3 GB des virtuellen Adressraums befinden müssen, nicht aus? Entziehen Sie bei Aktivierung des Schalters dem Betriebssystem dringend erforderlichen Speicher? (Weitere Informationen hierzu erhalten Sie unter „support.microsoft.com/kb/316739“.) Wenn Sie mit einem Cluster arbeiten, können Sie „/3GB“ auf einem Knoten einrichten, ohne ihn auf dem anderen einzurichten. Sollten dann beim Testen mit „/3GB“ Probleme auftreten, können Sie für die Instanz relativ schnell ein Failover auf den anderen Knoten erreichen. Denken Sie daran, dass bei mehr als 16 GB RAM der /3GB-Schalter nicht unterstützt wird.

Mithilfe von „/3GB“ erhöhen Sie den virtuellen Adressraum (VAS) um 50 Prozent. Das heißt, dass nicht nur der Datencache, sondern auch Anwendungen, die VAS hinsichtlich des Speichers belasten, davon profitieren. Erfreulicherweise ist dieser missverständliche Faktor bei den 64-Bit-Servern (sowohl bei IA64 als auch bei x64) beseitigt. Wenn der Computer für SQL Server dediziert ist, sind Bedenken zum Speicherentzug für das Betriebssystem unnötig. 2 GB für das Betriebssystem einzuplanen, ist ebenfalls nicht erforderlich. Wenn dieser Server für SQL Server dediziert ist und nur die standardmäßig erforderlichen Betriebssystemdienste ausgeführt werden, wird sich auf dem Server vermutlich etwa 1,3 GB freier Speicherplatz befinden. Deshalb sollten Sie ruhig das zusätzliche 1 GB für SQL Server bereitstellen. Starten Sie mit 10 GB, überwachen Sie mithilfe von PerfMon den verfügbaren Speicherplatz über einen längeren Zeitraum hinweg, um den Umfang des Leerlaufs festzustellen, und passen Sie den Wert dementsprechend an. Denken Sie daran, dass Sie einen Austausch herbeiführen, wenn Sie SQL Server 2000 zu viel Speicher zuweisen, da AWE beim Einsatz von SQL Server 2000 nicht so dynamisch ist wie bei SQL Server 2005. Die Frage, ob Sie den /3GB-Schalter verwenden sollen, lässt sich am besten anhand von Tests in Ihrer spezifischen Umgebung beantworten.

Instanznamen für Replikation

F: Kann ich jetzt die IP-Adresse meines Servers bei der Replikation von SQL Server 2005 verwenden, um anzugeben, welche Instanz repliziert werden soll? In SQL Server 2000 führt dies laut dem Artikel „So replizieren Sie zwischen Computern, die SQL Server in nicht vertrauenswürdigen Domänen oder im Internet ausführen“ (support.microsoft.com/kb/321822) zu Fehlern, doch ich weiß nicht, ob dies nach wie vor zutrifft.

A: Wenn Sie Server zur Teilnahme an einer Replikation angeben, müssen Sie den Namen der bei SQL Server registrierten Instanz bereitstellen. Sie müssen zum Beispiel den SQL Server-Instanznamen verwenden, wenn Sie die Verleger- oder Abonnentenparameter für die gespeicherten Replikationsverfahren oder für die Replikationsagent-Verbindungseinstellungen in der Befehlszeile angeben. Wenn der Netzwerkname für die SQL Server-Instanz vom registrierten Instanznamen abweicht, schlagen die Replikationsverbindungen durch Agents fehl.

Wenn sich der Netzwerkname der Instanz und der SQL Server-Instanzname unterscheiden, können Sie den SQL Server-Instanznamen als gültigen Netzwerknamen hinzufügen. Eine Möglichkeit, einen alternativen Netzwerknamen festzulegen, besteht darin, ihn der lokalen Hostdatei hinzuzufügen. Die lokale Hostdatei befindet sich standardmäßig unter WINDOWS\system32\drivers\usw. oder WINNT\system32\drivers\usw. Wenn der Computername beispielsweise „comp1“ lautet, der Computer die IP-Adresse „10.193.17.129“ hat und der Instanzname „inst1/instname“ lautet, fügen Sie der Hostdatei den folgenden Eintrag hinzu:

10.193.17.129 inst1

SQL Server Integration Services

F: Ich installiere einen Cluster (aktiv/aktiv) für SQL Server 2005 (64-bit Enterprise Edition mit zwei Servern), und mir werden insgesamt vier Instanzen von SQL Server 2005 zur Verfügung stehen. SQL Server Integration Services (SSIS) ist für alle Instanzen erforderlich. Was können Sie mir über das Clustering von SSIS und die Auswirkungen auf Wartungspläne mitteilen?

A: Sie können SSIS zwar gruppieren, dies ist jedoch nicht erforderlich, und es könnten dabei verschiedene Probleme auftreten, einschließlich einer nicht ausreichenden Unterstützung für die Delegierung (siehe msdn2.microsoft.com/aa337083) und der Tatsache, dass es sich nicht um mehrere Instanzen handelt – es kann immer nur eine Instanz auf einem Knoten ausgeführt werden.

Früher musste SSIS installiert – nicht ausgeführt, sondern nur installiert – werden, damit der Wartungsplanungs-Assistent ausgeführt werden konnte. Dies ist jedoch in SQL Server 2005 SP1 nicht mehr der Fall. Wenn SSIS nicht ausgeführt wird, können die Wartungspläne von SQL Server Agent ausgeführt werden.

Erwägen Sie statt einer Clusterbildung, SSIS weiterhin als eigenständigen Dienst auszuführen und „MsDtsSrvr.ini.xml“ so zu bearbeiten, dass auf alle ausführenden Instanzen verwiesen wird. Dadurch können Sie die Pakete von allen Knoten aus verwalten und die von den meisten Kunden geforderte hohe Verfügbarkeit bereitstellen, ohne auf die Probleme zu stoßen, die sich beim Clustering des Diensts oft ergeben.

Weitere Informationen zu Fehlern bei der Wartungsplanerstellung erhalten Sie im empfohlenen Knowledge Base-Artikel unter „support.microsoft.com/kb/909036“.

Seltsame Ausführungszeiten

F: Bei einem Auslastungstest auf meinem SQL Server 2005 SP1-Computer hat SQL Server Profiler viele negative Werte für die Ausführungszeit der gespeicherten Verfahren ermittelt, und in einigen Fällen stimmt die Ausführungszeit nicht mit dem Ergebnis überein, das ich erhalte, wenn ich die Startzeit von der Endzeit abziehe.

A: Eine Reihe von Faktoren können sich auf die Berichterstellung in Bezug auf die Ausführungszeit gespeicherter Verfahren und auf andere Leistungszeiten in SQL Server Profiler auswirken. Denken Sie daran, dass SQL Server 2005 die Ausführungszeit in Millisekunden berechnet. Wenn Sie eine Technologie verwenden, die die Maßeinheit ändert, erhalten Sie eine inkonsistente Berichterstellung und Ausführungszeiten, die keinen Sinn ergeben.

Wenn Sie zum Beispiel andere Energieschemas, CPU-Stepping oder die AMD-Technologie „Cool 'n Quiet“ verwenden, ändern Sie die CPU-Frequenzen, die dann nicht mit dem übereinstimmen, was SQL Server Profiler beim Berechnen der Ausführungszeiten erwartet.

Im Knowledge Base-Artikel unter „support.microsoft.com/kb/931279“ werden die Symptome, die vielen verschiedenen Ursachen und einige Abhilfen erläutert.

Tipp: Prüfen Sie Ihren Füllfaktor

Angenommen, Ihr Glas ist bis zum Rand mit Wasser gefüllt, und Sie versuchen, mehr Wasser in das Glas zu schütten. Was geschieht? Das Wasser läuft über.

So verhält es sich auch mit SQL Server. Wann immer einer vollen Indexseite eine neue Zeile hinzugefügt wird, verschiebt SQL Server ungefähr die Hälfte der Zeilen auf eine neue Seite, um für die neue Zeile Platz zu schaffen. Dieser Vorgang wird als Seitenteilung bezeichnet. Seitenteilungen schaffen Platz für neue Datensätze, sind allerdings zeit- und ressourcenaufwändig. Außerdem können sie zur Fragmentierung führen, die sich ungünstig auf E/A-Vorgänge auswirkt. Wie lässt sich dies vermeiden?

Um solche Situationen zu verhindern, müssen Sie den Füllfaktorwert proaktiv bestimmen. Wenn ein Index (neu) erstellt wird, bestimmt der Füllfaktorwert, wie viel Prozent des Speicherplatzes auf jeder Blattebenenseite mit Daten gefüllt wird, und behält den Rest für zukünftiges Wachstum vor. Das Konfigurieren eines Füllfaktorwerts auf 60 bedeutet zum Beispiel, dass 40 Prozent jeder Blattebenenseite leer gelassen wird, um die Indexerweiterung zu ermöglichen, die erfolgt, wenn der zugrunde liegenden Tabelle Daten hinzugefügt werden.

Der Standardfüllfaktorwert ist immer 0, was für die meisten Situationen geeignet ist. Grundsätzlich bedeutet der Füllfaktor 0, dass die Blattebene nahezu bis zur Kapazitätsgrenze gefüllt wird, jedoch etwas Speicherplatz für mindestens eine zusätzliche Indexzeile vorhanden ist. (Beachten Sie, dass die Füllfaktoren 0 und 100 ähnlich sind.)

Sie können den Füllfaktorwert für einzelne Indexe während einer CREATE INDEX- oder ALTER INDEX-Anweisung festlegen, oder Sie können diesen Wert direkt auf Serverebene konfigurieren, damit alle neu erstellten Indexe die Standardeinstellung verwenden.

Im folgenden Beispiel wird der Füllfaktorwert auf Serverebene auf 70 Prozent festgelegt. Das bedeutet, dass 30 Prozent freier Speicherplatz für zukünftige Erweiterungen zur Verfügung steht. Selbstverständlich müssen Sie diese Option vor dem Implementieren in einer Produktionsumgebung sorgfältig testen.

USE Master;
GO
SP_Configure 'show advanced options',1;
GO
SP_Configure 'Fill Factor', 70;
GO
--You must restart SQL Server Engine for changes to take effect.

Was geschieht, wenn Sie den Füllfaktor auf der einzelnen Indexebene konfigurieren wollen? Angenommen Sie erstellen die folgende Tabelle und möchten einen eindeutigen Index für die Spalte „Col_A“ mit einem Füllfaktorwert von 70 erstellen. Der Befehl sieht dann etwa so aus:

--Create an Item table
USE Item_DB;
GO
CREATE TABLE ITEM (Col_A Varchar(100),Col_b Varchar(200));
GO;

--Create a unique index on colum Col_A of Item table with a Fill Factor value of 70
CREATE UNIQUE INDEX AK_Index ON Item (Col_A)
WITH (FillFactor = 70);
GO

Wie identifizieren Sie den Füllfaktor für jeden Index? Sie können „sys.Indexes“ abfragen, um den Füllfaktorwert für alle Indexe in einer Datenbank abzurufen, etwa so:

USE Item_DB;
GO
SELECT Fill_Factor FROM Sys.Indexes WHERE Object_id=object_id('item') AND name IS NOT NULL;
GO

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