Ablaufverfolgungsflags (Transact-SQL)
Ablaufverfolgungsflags werden zur temporären Festlegung bestimmter Servereigenschaften oder zum Ausschalten eines bestimmten Verhaltens verwendet. Wenn z. B. das Ablaufverfolgungsflag 3205 beim Starten einer Instanz von SQL Server festgelegt ist, wird die Hardwarekomprimierung der Treiber für Bandlaufwerke deaktiviert. Häufig werden Ablaufverfolgungsflags zur Diagnose der Systemleistung und zum Debuggen von gespeicherten Prozeduren oder komplexen Computersystemen verwendet.
In der folgenden Tabelle werden die in SQL Server verfügbaren Ablaufverfolgungsflags aufgelistet und beschrieben.
.gif "Hinweis") Hinweis |
|---|
Das Verhalten von Ablaufverfolgungsflags wird in zukünftigen Versionen von SQL Server möglicherweise nicht mehr unterstützt. |
Ablaufverfolgungsflag |
Beschreibung |
|---|---|
260 |
Druckt die Versionsinformationen zu den DLLs (Dynamic Link Libraries) von erweiterten gespeicherten Prozeduren. Weitere Informationen zu __GetXpVersion() finden Sie unter Erstellen erweiterter gespeicherter Prozeduren. Bereich: global oder Sitzung |
1204 |
Gibt die an einem Deadlock beteiligten Ressourcen und Sperrentypen sowie den aktuell betroffenen Befehl zurück. Bereich: nur global |
1211 |
Deaktiviert die Sperrenausweitung basierend auf nicht ausreichendem Arbeitsspeicher oder auf der Anzahl von Sperren. SQL Server Database Engine (Datenbankmodul) weitet keine Zeilen- oder Seitensperren zu Tabellensperren aus. Die Verwendung dieses Ablaufverfolgungsflags kann eine übermäßige Anzahl von Sperren generieren. Dies kann die Leistung von Database Engine (Datenbankmodul) verlangsamen oder den Fehler 1204 (Sperrenressource kann nicht zugeordnet werden) aufgrund von nicht genügend Arbeitsspeicher verursachen. Weitere Informationen finden Sie unter Sperrenausweitung (Datenbankmodul). Wenn sowohl das Ablaufverfolgungsflag 1211 als auch das Ablaufverfolgungsflag 1224 festgelegt wurde, dann hat 1211 Vorrang gegenüber 1224. Weil jedoch das Ablaufverfolgungsflag 1211 die Ausweitung in jedem Fall verhindert, auch bei nicht genügend Arbeitsspeicher, wird die Verwendung von 1224 empfohlen. Dies hilft, Fehler aufgrund von nicht genügend Sperren zu vermeiden, wenn viele Sperren verwendet werden. Bereich: global oder Sitzung |
1222 |
Gibt die an einem Deadlock beteiligten Ressourcen und Sperrentypen sowie den aktuell betroffenen Befehl in einem XML-Format zurück, das keinem XSD-Schema entspricht. Bereich:nur global |
1224 |
Deaktiviert die Sperrenausweitung basierend auf der Anzahl von Sperren. Die Sperrenausweitung kann dennoch durch nicht ausreichenden Arbeitsspeicher aktiviert werden. Database Engine (Datenbankmodul) weitet Zeilen- oder Seitensperren nur dann zu Tabellensperren (oder Partitionssperren) aus, wenn der von Sperrenobjekten belegte Arbeitsspeicher einen der folgenden Grenzwerte überschreitet:
Wenn sowohl das Ablaufverfolgungsflag 1211 als auch das Ablaufverfolgungsflag 1224 festgelegt wurde, dann hat 1211 Vorrang gegenüber 1224. Weil jedoch das Ablaufverfolgungsflag 1211 die Ausweitung in jedem Fall verhindert, auch bei nicht genügend Arbeitsspeicher, wird die Verwendung von 1224 empfohlen. Dies hilft, Fehler aufgrund von nicht genügend Sperren zu vermeiden, wenn viele Sperren verwendet werden. Hinweis
Die Ausweitung von Sperren auf Tabellen- oder HoBT-Ebene kann auch mithilfe der LOCK_ESCALATION-Option der ALTER TABLE-Anweisung gesteuert werden.
Bereich: global oder Sitzung |
2528 |
Deaktiviert die parallele Prüfung von Objekten durch DBCC CHECKDB, DBCC CHECKFILEGROUP und DBCC CHECKTABLE. Standardmäßig wird der Grad der Parallelität automatisch durch den Abfrageprozessor bestimmt. Der maximale Grad der Parallelität wird auf dieselbe Weise konfiguriert wie der maximale Grad bei parallelen Abfragen. Weitere Informationen finden Sie unter max degree of parallelism (Option). Das parallele Ausführen von DBCC sollte normalerweise aktiviert bleiben. Für DBCC CHECKDB wertet der Abfrageprozessor die Parallelität bei jeder überprüften Tabelle oder jedem überprüften Tabellenbatch erneut aus und passt sie automatisch an. Manchmal wird die Überprüfung möglicherweise gestartet, wenn sich der Server nahezu im Leerlauf befindet. Ein Administrator, der weiß, dass sich die Last vor Beendigung der Überprüfung erhöht, kann die Parallelität manuell verringern oder deaktivieren. Wenn die parallele Überprüfung von DBCC deaktiviert ist, kann die Ausführung von DBCC viel länger dauern, und DBCC wenn ausgeführt wird und die TABLOCK-Funktion aktiviert und Parallelität deaktiviert ist, werden Tabellen möglicherweise für längere Zeit gesperrt. Bereich: global oder Sitzung |
3205 |
Wenn ein Bandlaufwerk die Hardwarekomprimierung unterstützt, wird dies standardmäßig von der DUMP- oder der BACKUP-Anweisung verwendet. Mit diesem Ablaufverfolgungsflag kann die Hardwarekomprimierung für Treiber des Bandlaufwerkes deaktiviert werden. Diese Deaktivierung ist hilfreich, wenn Sie Datenbänder mit anderen Standorten oder mit Bandlaufwerken austauschen möchten, die keine Datenkomprimierung unterstützen. Bereich: global oder Sitzung |
3226 |
Standardmäßig wird bei jedem erfolgreichen Sicherungsvorgang dem SQL Server-Fehlerprotokoll und dem Systemereignisprotokoll ein Eintrag hinzugefügt. Wenn Sie das Protokoll regelmäßig sichern, kann die Anzahl dieser Erfolgsmeldungen schnell ansteigen, d. h., es entstehen sehr große Fehlerprotokolle, die das Suchen nach anderen Meldungen erschweren können. Mit diesem Ablaufverfolgungsflag können Sie diese Protokolleinträge unterdrücken. Dies ist sehr hilfreich, wenn Sie regelmäßig Protokollsicherungen ausführen und keines der Skripts von diesen Einträgen abhängig ist. |
3608 |
Hindert SQL Server daran, automatisch zu starten und außer der master-Datenbank eine Datenbank wiederherzustellen. Datenbanken werden gestartet und wiederhergestellt, wenn auf sie zugegriffen wird. Einige Features, z. B. Snapshotisolation und Read Committed Snapshot, funktionieren möglicherweise nicht. Verwenden Sie dies für Verschieben von Systemdatenbanken und Verschieben von Benutzerdatenbanken. Verwenden Sie es nicht im Normalbetrieb. |
3625 |
Schränkt den Umfang der in Fehlermeldungen zurückgegebenen Informationen ein. Weitere Informationen finden Sie unter Konfigurieren der Sichtbarkeit von Metadaten. Bereich: nur global |
4616 |
Macht Metadaten auf Serverebene für Anwendungsrollen sichtbar. In SQL Server kann von einer Anwendungsrolle nicht auf Metadaten außerhalb ihrer eigenen Datenbank zugegriffen werden, da Anwendungsrollen keinem Prinzipal auf Serverebene zugeordnet sind. Dieses Verhalten unterscheidet sich von früheren Versionen von SQL Server. Durch Festlegen dieses globalen Flags werden die neuen Einschränkungen deaktiviert, und der Zugriff von Anwendungsrollen auf Metadaten auf Serverebene wird zugelassen. Bereich: nur global |
6527 |
Deaktiviert die Erstellung eines Speicherdumps beim ersten Auftreten einer Ausnahme wegen unzureichenden Arbeitsspeichers in der CLR-Integration. Standardmäßig generiert SQL Server einen kleinen Speicherdump beim ersten Auftreten einer Ausnahme wegen unzureichenden Arbeitsspeichers in der CLR-Integration. Das Ablaufverfolgungsflag verhält sich wie folgt:
Bereich: nur global |
7806 |
Aktiviert eine dedizierte Administratorverbindung (Dedicated Administrator Connection, DAC) in SQL Server Express. Standardmäßig werden in SQL Server Express keine DAC-Ressourcen reserviert. Weitere Informationen finden Sie unter Verwenden einer dedizierten Administratorverbindung. Bereich: nur global |
Hinweise
In SQL Server gibt es zwei Typen von Ablaufverfolgungsflags: Sitzung und global. Ablaufverfolgungsflags vom Typ Sitzung sind für die Dauer einer Verbindung aktiv und nur für diese Verbindung sichtbar. Globale Ablaufverfolgungsflags werden auf Serverebene festgelegt und sind für jede Verbindung auf dem Server sichtbar. Einige Flags können nur als globale Flags aktiviert werden, einige können entweder mit globalem Bereich oder mit Sitzungsbereich aktiviert werden.
Dabei gelten die folgenden Regeln:
Ein globales Ablaufverfolgungsflag muss global aktiviert werden. Andernfalls hat das Ablaufverfolgungsflag keine Wirkung. Es wird empfohlen, globale Ablaufverfolgungsflags beim Start mithilfe der Befehlszeilenoption -T zu aktivieren.
Ein Ablaufverfolgungsflag mit entweder globalem Bereich oder Sitzungsbereich kann mit dem jeweils geeigneten Bereich aktiviert werden. Ein auf Sitzungsebene aktiviertes Ablaufverfolgungsflag wirkt sich nie auf andere Sitzungen aus, und die Wirkung des Ablaufverfolgungsflags endet mit der Abmeldung der SPID, die die Sitzung geöffnet hat.
Ablaufverfolgungsflags werden mithilfe einer der folgenden Methoden auf on oder off festgelegt:
Mithilfe der Befehle DBCC TRACEON und DBCC TRACEOFF.
Beispiel DBCC TRACEON 2528: Verwenden Sie DBCC TRACEON mit dem Argument -1, um das Ablaufverfolgungsflag global zu aktivieren: DBCC TRACEON (2528, -1). Verwenden Sie DBCC TRACEOFF mit dem Argument -1, um ein globales Ablaufverfolgungsflag zu deaktivieren.
Verwenden Sie die Startoption -T, um anzugeben, dass das Ablaufverfolgungsflag beim Start auf on festgelegt werden soll.
Durch die Startoption -T wird ein Ablaufverfolgungsflag global aktiviert. Ablaufverfolgungsflags auf Sitzungsebene können nicht mit einer Startoption aktiviert werden. Weitere Informationen zu Startoptionen finden Sie unter Verwenden der Startoptionen für den SQL Server-Dienst.
Verwenden Sie den DBCC TRACESTATUS-Befehl, um zu bestimmen, welche Ablaufverfolgungsflags zurzeit aktiv sind.
Verhaltensänderungen
In SQL Server 2000 genügt der einfache Aufruf DBCC TRACEON (1204), um die Berichterstellung über Deadlocks im Fehlerprotokoll zu aktivieren. In SQL Server 2008 müssen Sie das Flag global aktivieren, da das Flag auf Sitzungsebene für den Deadlockmonitorthread nicht sichtbar ist.
Weitere Informationen zu Verhaltensänderungen finden Sie unter Fehlerhafte Änderungen an Features des Datenbankmoduls in SQL Server 2008.
Beispiele
Im folgenden Beispiel wird das Ablaufverfolgungsflag 3205 mithilfe von DBCC TRACEON auf on festgelegt.
DBCC TRACEON (3205,-1)