Share via

SQL Server VSS Writer-Protokollierung

  • Artikel

Gilt für:SQL Server

SQL Server kann über den dedizierten SQL Writer-Dienst in VSS (Volume Shadow Copy Service) sicherungs- und wiederherstellungsvorgänge einbezogen werden. Weitere Informationen finden Sie unter SQL Server Back up Applications – Volume Shadow Copy Service (VSS) und SQL Writer.

Der Dienst meldet Ausführungsfehler an Windows-Anwendungsereignisprotokolle mit einem Ereignis Source (oder ProviderName in PowerShell oder XML-Kontext) von Wert SQLWRITER, wie Sie im Beispiel weiter unten in diesem Artikel sehen können. Vor SQL Server 2019 (15.x) gab es kein dediziertes Aktivitätsprotokoll, das Untersuchungen gegen SQL Server als Teilnehmer an VSS-Vorgängen erschwerte.

In diesem Artikel wird das neue Protokoll beschrieben, das von SQL Server 2019 (15.x) eingeführt wurde, um eine bessere Sichtbarkeit der SQLWriter-Vorgänge zu ermöglichen. Diese Funktionalität wurde auch in SQL Server 2016 (13.x) Service Pack 3 und SQL Server 2017 (14.x) kumulatives Update (CU) 27 zur Verfügung gestellt.

Übersicht

Die wichtigsten Merkmale der SQL Server 2019 (15.x) SQLWriter-Protokollierung sind:

  • Standardmäßig aktiviert
  • Systemweit aktiviert (verfolgt wird die SQL Writer-Aktivität für alle auf dem Server ausgeführten SQL Server-Instanzen)
  • Textbasiert
  • Arbeitsverzeichnis: C:\Program Files\Microsoft SQL Server\90\Shared
  • Innerhalb dieses Verzeichnisses:
    • Protokollierung in Datei SqlWriterLogger.txt
    • Umbenennung in SqlWriterLogger1.txt bei Erreichen einer maximalen Größe (standardmäßig 1 MB) bei fortgesetzter Protokollierung in die Hauptdatei SqlWriterLogger.txt
    • Nur eine Rolloverdatei, sodass der zweite Rollovervorgang die vorhandene Datei SqlWriterLogger1.txt überschreibt
    • Verwaltung der Parameter in der Datei SqlWriterConfig.ini

Da SQL Writer eine freigegebene SQL Server-Komponente ist, verfügt sie über eine einzelne Instanz auf einem System, und ihre Hauptversion entspricht der höchsten Hauptversion jeder installierten SQL Server-Instanz. Wenn z. B. SQL Server 2016 (13.x) SP2 und SQL Server 2019 (15.x) auf demselben System installiert sind, ist die SQL Writer-Binärdatei die von SQL Server 2019 (15.x) bereitgestellte, und alle ausgeführten Instanzen werden von allen Hauptversionen bedient (auch wenn das Heimverzeichnis unter \90ist). Lokale Instanzen und Versionen profitieren von der hier beschriebenen neuen SQL Server 2019 (15.x)-Ablaufverfolgung. Es bedeutet auch, dass nur kumulative UPDATES von SQL Server 2019 (15.x) in dieser Situation SQL Writer-Binärdateien aktualisieren.

Hinweis

In den folgenden Absätzen wird die Situation beschrieben, die mit SQL Server 2019 (15.x) CU 4 beginnt. Frühere SQL Server 2019 (15.x)-Versionen verfügen nicht über die gleiche Menge an Informationen in der Protokolldatei unter den Standardeinstellungen.

Basisvorgänge

Sie können ohne manuelle Änderungen von der neuen Protokollierung profitieren. Sie können die Hauptprotokolldatei SqlWriterLogger.txt in C:\Program Files\Microsoft SQL Server\90\Shared\ öffnen bzw. eine Kopie davon abrufen. Die Datei spiegelt alle VSS-Ereignisse wider, die in SQL Writer eingehen, d. h. hauptsächlich:

  • Vom Befehl vssadmin list writers ausgelöste OnIdentify-Ereignisse
  • Sicherungsereignisse
  • Wiederherstellungsereignisse

Das heißt, selbst wenn diese Vorgänge erfolgreich ausgeführt werden, zeichnet die Protokolldatei weiterhin detaillierte Einträge auf. Sie können bestätigen, dass VSS-Vorgänge auftreten und erfolgreich mit SQL Writer interagieren. Es ist eine Verbesserung, die eine einfache integrierte Möglichkeit zum Einrichten dieser Details auf SQL Server-Instanzebene bietet.

Darüber hinaus werden start-up-Ereignisse des SQLWriter-Diensts ebenfalls aufgezeichnet und die aktiven Protokollierungsparameter melden.

Wenn ein VSS-Vorgangsfehler SQL Server umfasst, wird der SqlWriterLogger zu einem wichtigen Ort, um nach Informationen zu suchen.

Hinweis

Diese neue Protokollierungsinfrastruktur ergänzt die vorhandene Fehlerberichterstattung für SQL Server und ersetzt sie nicht. Daher bleibt das Windows-Anwendungsereignisprotokoll im Fehlerfall der erste Ort, um zu überprüfen (Filtern nach Quellen wie "SQLWRITER" und "VSS"). SqlWriterLogger.txt würde zusätzliche Informationen zu diesem anfänglichen Satz bereitstellen.

Überprüfen typischer Protokollierungseinträge

Die folgenden Exporte erfolgen unter Einstellung Default.

Dienststart

[01/11/2021 02:54:59, TID 61f8] ****************************************************************
[01/11/2021 02:54:59, TID 61f8] **  SQLWRITER TRACING STARTED - ProcessId: 0x4124
[01/11/2021 02:54:59, TID 61f8] **  Service is not running as WIDWriter.
[01/11/2021 02:54:59, TID 61f8] **  SQL Writer version is 15.0.4073.23
[01/11/2021 02:54:59, TID 61f8] **  MODERN LOGGER V2 ENABLED ON C:\Program Files\Microsoft SQL Server\90\Shared\SqlWriterLogger.txt
[01/11/2021 02:54:59, TID 61f8] **  With TraceLevel = DEFAULT, TraceFileSizeMb = 1, ForceFlush = False
[01/11/2021 02:54:59, TID 61f8] **  Recording events in Server Local Time. UTC OFFSET: -8:00
[01/11/2021 02:54:59, TID 61f8] ****************************************************************

Der obige Eintrag wird für jeden Start des SQL Writer-Diensts beobachtet (er kann sogar zweimal pro Dienststart protokolliert werden).

In der Reihenfolge der Darstellung können wir die folgenden Informationen sehen:

  • Ein Zeitstempel (Datum + Uhrzeit) in der lokalen Serverzeit und die ThreadId, die den Eintrag für jede Zeile stammt.
  • Die ProcessId des SQLWriter-Prozesses, der gestartet wird.
  • Die Tatsache, dass der Dienst im "normalen" Modus (nicht als WIDWriter ausgeführt) oder im internen Windows-Datenbankmodus gestartet wurde.
  • Die Version der SQL Writer-Binärdateien
  • Alle Parameter, die von der SqlWriterConfig.ini Datei festgelegt werden:
    • Zielpfad der aktiven Protokolldatei
    • Die Detailebene der Ablaufverfolgung, die in diesem Beispiel DEFAULT ist
    • Die maximale Größe der Datei vor dem Rollover, die in diesem Beispiel 1 MB beträgt
    • Die Option zum ForceFlush jedes einzelne Update in der Protokolldatei im Vergleich zu einem entspannteren/gepufferten Ansatz, der standardmäßig "False" ist.
  • Erinnerung, dass die Protokollierung zur Ortszeit zusammen mit dem UTC-Versatz dieser Ortszeit erfolgt

VSS "OnIdentify"-Ereignis

[01/12/2021 08:23:40, TID 464c] Entering SQL Writer OnIdentify.
[01/12/2021 08:23:40, TID 464c] Service: MSSQLSERVER Server: GF19. Version=15
[01/12/2021 08:23:40, TID 464c] Instance MSSQL15.MSSQLSERVER Edition: Developer Edition
[01/12/2021 08:23:40, TID 464c] Instance MSSQL15.NAMED1 Edition: Enterprise Edition: Core-based Licensing
[01/12/2021 08:23:40, TID 464c] Skip User Instances Enumeration

OnIdentify ist ein allgemeiner VSS-Vorgang. Er wird durch vssadmin list writers Befehl ausgelöst. Die meisten VSS-Anforderer würden einen VSS-Sicherungs- oder Wiederherstellungsvorgang mit einem OnIdentify-Ereignis starten.

Bisher konnte der DBA ein solches Ereignis nur bei aktivierter Ablaufverfolgung durch den Profiler erkennen. Beim neuen Protokollierungsfeature führt jedes Ereignis zum obigen Eintrag.

In der Reihenfolge ihres Auftretens werden die folgenden Informationen protokolliert:

  • Eine explizite Erwähnung des VSS-Ereignisses OnIdentify
  • Eine Liste aller aktiven (ausgeführten) SQL Server-Instanzen sowie deren Instanzname, Hauptversion und Edition.
  • Der Hinweis, den wir nicht versucht haben, "Benutzerinstanzen" auflisten – ein bestimmtes SQL Server-Feature, das auch als "LocalDB " bezeichnet wird und in der Regel nicht auf Unternehmensdatenbankservern beteiligt ist.

Erfolgreiche VsS-Sicherung im Komponentenmodus

[01/11/2021 02:30:19, TID 32c8] Entering SQL Writer Initialize.
[01/11/2021 02:33:33, TID 232c] Entering SQL Writer OnIdentify.
[01/11/2021 02:33:33, TID 232c] Service: MSSQLSERVER Server: GF19. Version=15
[01/11/2021 02:33:33, TID 232c] Instance MSSQL15.MSSQLSERVER Edition: Developer Edition
[01/11/2021 02:33:33, TID 232c] Instance MSSQL15.NAMED1 Edition: Enterprise Edition: Core-based Licensing
[01/11/2021 02:33:33, TID 232c] Skip User Instances Enumeration
[01/11/2021 02:33:37, TID 232c] Entering SQL Writer OnPrepareBackup.
[01/11/2021 02:33:37, TID 232c] ****************************************************************
[01/11/2021 02:33:37, TID 232c] **  VSS SQL BACKUP BEGIN - ID: 232c
[01/11/2021 02:33:37, TID 232c] ****************************************************************
[01/11/2021 02:33:37, TID 232c] Component based backup selected.
[01/11/2021 02:33:37, TID 232c] Database count from metadata is 1
[01/11/2021 02:33:37, TID 232c] Database db_on_G on instance GF19 found in metadata
[01/11/2021 02:33:37, TID 232c] Backup type is VSS_BT_COPY
[01/11/2021 02:33:38, TID 232c] Entering SQL Writer OnPrepareSnapshot.
[01/11/2021 02:33:38, TID 232c] Service: MSSQLSERVER Server: GF19. Version=15
[01/11/2021 02:33:38, TID 232c] Instance MSSQL15.MSSQLSERVER Edition: Developer Edition
[01/11/2021 02:33:38, TID 232c] Instance MSSQL15.NAMED1 Edition: Enterprise Edition: Core-based Licensing
[01/11/2021 02:33:38, TID 232c] Skip User Instances Enumeration
[01/11/2021 02:33:38, TID 232c] Entering SQL Writer OnFreeze.
[01/11/2021 02:33:38, TID 232c] Entering SQL Writer OnThaw.
[01/11/2021 02:33:38, TID 232c] Entering SQL Writer OnPostSnapshot.
[01/11/2021 02:33:38, TID 232c] Entering SQL Writer OnIdentify.
[01/11/2021 02:33:38, TID 232c] Service: MSSQLSERVER Server: GF19. Version=15
[01/11/2021 02:33:38, TID 232c] Instance MSSQL15.MSSQLSERVER Edition: Developer Edition
[01/11/2021 02:33:38, TID 232c] Instance MSSQL15.NAMED1 Edition: Enterprise Edition: Core-based Licensing
[01/11/2021 02:33:38, TID 232c] Skip User Instances Enumeration
[01/11/2021 02:33:40, TID 232c] Entering SQL Writer OnBackupComplete.

Dieses Ereignis führt zu einer umfassenderen Menge von Einträgen. In der Reihenfolge der Darstellung können wir die folgenden Informationen sehen:

  • Ein vollständiger OnIdentify-Abschnitt, der wie bereits angegeben oft eine Sicherung einleitet.
  • Erwähnen Sie jede Haupt-VSS-Phase der Sicherung mit dem Muster "Eingeben von SQL Writer xxxx".
    • Die erste hier ist Entering SQL Writer OnPrepareBackup.
  • Ein auffälliger Eintrag, der den Beginn einer VSS SQL-Sicherung angibt
    • (ID ist die ThreadId, die die Protokollierung für diesen Sicherungsversuch in SQLWriter durchführt)
  • Die VSS-Sicherungs-API, die vom VSS-Anforderer ausgewählt wurde, "Komponente" oder "Nicht-Komponente/Volume"
  • Die Anzahl der Datenbanken, die in der Vom VSS-Anforderer gesendeten Komponentenliste enthalten sind, hier eine einzelne DB (1).
  • Eine Bestätigung, dass jeder vom Requestor bereitgestellte Datenbankname (hier "db_on_G") in der SQL Server-Instanz gefunden (oder nicht gefunden) wurde, der er vom VSS-Anforderer zugeordnet wurde (hier die Standardinstanz 'GF19').
  • Die Variante der angeforderten VSS-Sicherung. Normalerweise VSS_BT_FULL oder VSS_BT_COPY. Weitere Informationen finden Sie im Artikel zur Enumeration VSS_BACKUP_TYPE.
  • Ein weiterer OnIdentify-Abschnitt
  • Weitere Einträge zur Bestimmung der Hauptphasen der VSS-Sicherung (OnFreeze, OnThaw, OnPostSnapshot)
  • Ein abschließender OnIdentify-Abschnitt.
  • Ein abschließender VSS-Phasenbericht, der es zu einem nützlichen "Abschlussereignis" macht: OnBackupComplete.

Diese Einträge enthalten Details zu den VSS-Vorgängen, die zuvor schwer zu erstellen waren, und erforderten eine erweiterte Ablaufverfolgung. Ein erstes Beispiel ist der Modus „Komponentenbasiert“ oder „Nicht komponentenbasiert“ einer beliebigen VSS-Sicherungsanforderung. Mit SQL Server 2019 (15.x) SQL Writer werden sie standardmäßig für jede einzelne VSS-Anforderung protokolliert und sind leicht zugänglich.

Fehlersituation: Torndatenbank

Um die frühere Anweisung zu veranschaulichen, dass die SQL Writer-Protokollierung die Ereignisprotokollarchitektur ergänzt, sehen wir uns die Einträge an, die einer bekannten Fehlersituation zugeordnet sind: einer Torndatenbank. Dieses Szenario kann auftreten, wenn eine VSS-Sicherung versucht, eine Momentaufnahmemenge von Volumes zu erstellen, die nur einen Teilsatz von Dateien einer bestimmten Datenbank enthalten. Der SQL Writer blockiert diese Sicherung gemäß VSS-Konventionen.

Dieser Auszug ist der Inhalt von SqlWriterLogger.txt für den Vorgang:

[01/11/2021 02:57:00, TID 5a88] Entering SQL Writer OnIdentify.
[01/11/2021 02:57:00, TID 5a88] Service: MSSQLSERVER Server: GF19. Version=15
[01/11/2021 02:57:00, TID 5a88] Instance MSSQL15.MSSQLSERVER Edition: Developer Edition
[01/11/2021 02:57:00, TID 5a88] Instance MSSQL15.NAMED1 Edition: Enterprise Edition: Core-based Licensing
[01/11/2021 02:57:00, TID 5a88] Skip User Instances Enumeration
[01/11/2021 02:57:02, TID 5a88] Entering SQL Writer OnPrepareBackup.
[01/11/2021 02:57:02, TID 5a88] ****************************************************************
[01/11/2021 02:57:02, TID 5a88] **  VSS SQL BACKUP BEGIN - ID: 5a88
[01/11/2021 02:57:02, TID 5a88] ****************************************************************
[01/11/2021 02:57:02, TID 5a88] Volume based (= NonComponent) backup selected.
[01/11/2021 02:57:02, TID 5a88] Backup type is VSS_BT_FULL
[01/11/2021 02:57:03, TID 5a88] Entering SQL Writer OnPrepareSnapshot.
[01/11/2021 02:57:03, TID 5a88] Service: MSSQLSERVER Server: GF19. Version=15
[01/11/2021 02:57:03, TID 5a88] Instance MSSQL15.MSSQLSERVER Edition: Developer Edition
[01/11/2021 02:57:03, TID 5a88] Instance MSSQL15.NAMED1 Edition: Enterprise Edition: Core-based Licensing
[01/11/2021 02:57:03, TID 5a88] Skip User Instances Enumeration
[01/11/2021 02:57:03, TID 5a88] HRESULT EXCEPTION CAUGHT: hr: 0x80780002
[01/11/2021 02:57:03, TID 5a88] Entering SQL Writer OnAbort.

Wir SqlWriterLogger.txt sehen, dass ein Fehler aufgetreten ist, aber die einzigen Details, die wir beim Fehler haben, ist die 0x80780002 HResult. Dieser Wert ist ohne die Referenzen zu Fehlercodes nur schwierig zu interpretieren. Es identifiziert jedoch die Torndatenbanksituation.

Ereignisprotokoll anzeigen

Überprüfen wir nun den Inhalt der Windows-Anwendungsereignisprotokolle:

Log Name:      Application
Source:        SQLWRITER
Date:          1/11/2021 02:57:03 AM
Event ID:      24579
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      GF19
Description:
Sqllib error: Database db_on_G_and_H of SQL Server instance GF19  is stored on multiple volumes, only some of which are being shadowed.

Das Ereignis liefert eine vollständige benutzerfreundlich formatierte Meldung zur Erläuterung der Situation.

Das Betriebssystem-VSS-Framework meldet auch das Problem in Den Ereignisprotokollen unter Verwendung der Nomenklatur (VSS verwaltet "Komponenten", die "Datenbanken" im Kontext von SQL Server sind).

Log Name:      Application
Source:        VSS
Date:          1/11/2021 02:57:03 AM
Event ID:      8229
Task Category: None
Level:         Warning
Keywords:      Classic
User:          N/A
Computer:      GF19
Description:
A VSS writer has rejected an event with error 0x800423f0, The shadow-copy set only
 contains only a subset of the volumes needed to correctly backup the selected
components of the writer.
Changes that the writer made to the writer components while handling the event will
 not be available to the requester.
Check the event log for related events from the application hosting the VSS writer.

Operation:
   PrepareForSnapshot Event

Context:
   Execution Context: Writer
   Writer Class Id: {a65faa63-5ea8-4ebc-9dbd-a0c4db26912a}
   Writer Name: SqlServerWriter
   Writer Instance Name: Microsoft SQL Server 2019:SQLWriter
   Writer Instance ID: {a16fed29-e555-4cc5-8938-c89201f31f7e}
   Command Line: "C:\Program Files\Microsoft SQL Server\90\Shared\sqlwriter.exe"
   Process ID: 22628

Das Ereignisprotokoll ist eine bessere Informationsquelle für den Fehler selbst. Der Inhalt von SqlWriterLogger liefert jedoch Details zur Sicherungsanforderung (eine VSS_BT_FULL, nicht komponentenbasierte VSS-Sicherungsanforderung mit Fehler in der Phase OnPrepareSnapshot von SQL Writer). Jede Untersuchung von VSS-Fehlern, an denen SQL Server beteiligt ist, sollte daher beide Quellen berücksichtigen und einbeziehen.

Ändern von SQL Writer-Protokollierungsparametern

Die SQL Writer-Protokollierung kann durch Bearbeiten der Textdatei SqlWriterConfig.ini konfiguriert werden. Die Datei selbst enthält eine schnelle Inlinebeschreibung der verfügbaren Parameter, die wir unten überprüfen.

Hinweis

Die INI-Datei befindet in einem von Windows geschützten Ordner (Program Files). Daher sind zum Bearbeiten erhöhte Administratorrechte erforderlich. Durch Doppelklicken im Explorer wird Editor ohne Berechtigungserhöhung geöffnet. Der Benutzer kann den Inhalt zwar lesen, aber keine Änderungen speichern. Starten Sie Editor entweder als Administrator, und öffnen SqlWriterConfig.iniSie es dann, oder verwenden Sie einen Text-Editor, der beim Speichern der Datei zur Erhöhung bei Bedarf aufgefordert werden kann.

Hier finden Sie Erläuterungen zur Datei SqlWriterConfig.ini:

Parameter Tastatur Beschreibung
EnableLogging - TRUE (Standard)
-FALSE		 Ermöglicht es dem Benutzer, das gesamte neue Protokollierungsfeature zu deaktivieren, in dem unwahrscheinlichen Fall, dass es erforderlich ist.
TraceFile C:\Program Files\Microsoft SQL Server\90\Shared\SqlWriterLog.txt Ermöglicht dem Benutzer, den Pfad und Dateinamen der Ablaufverfolgungsdatei zu ändern. Diese Änderung wird nicht empfohlen, da der allgemein bekannte Standardspeicherort es einfach macht, in jeder SQL Server-Instanz direkt zur richtigen Stelle zu gelangen.
Tracelevel - DEFAULT (Standard)
-MINIMAL
-AUSFÜHRLICHE		 Die Ausführlichkeit der Protokollierung. Weitere Informationen sind in TraceLevel-Details enthalten.
TraceFileSizeMb 1 MB (Standard) Die maximale Dateigröße vor dem Rollover. Die TXT-Datei ist UTF-8-codiert und belegt pro Zeichen 2 Bytes. Das Erhöhen dieses Werts ist beispielsweise gültig, mit intensiver VSS-Aktivität, beibehaltung langer Zeiträume von Protokolleinträgen oder wenn Nicht-Standardwerte TraceLevel für lange Dauer aktiviert sind. Der Standardmäßige 1-MB-Wert sollte für die meisten Situationen einen ausreichenden Verlauf bereitstellen.
ForceFlush -STIMMT
- FALSE (Standard)		 Das Festlegen dieser Option TRUE wäre nur in seltenen Fällen nützlich, in denen der SQL Writer-Dienst abstürzte, bevor er die Möglichkeit hatte, die letzten Protokolleinträge zu leeren. Andernfalls behalten Sie den Standardwert.

Änderungen übernehmen

Jede Einstellungsänderung erfordert einen Neustart des SQL Writer-Diensts, damit sie übernommen wird.

Tipp

Das Neustarten von SQL Writer ist extrem schnell und kann ausgeführt werden, da SQL Writer keine zustandsbehafteten Informationen speichert und keine Aktivität zwischen VSS-Aufrufen hat. Die einzige Vorsichtsmaßnahme besteht darin, einen Neustart bei laufendem VSS-Vorgang (Sicherung, Wiederherstellung) zu vermeiden.

Der SQL Writer zeichnet aktive Parameter beim (Neu-)Start in seiner Protokolldatei auf, wie im Beispielauszug unter Dienststart zu sehen.

Details zu TraceLevel

Die SqlWriterConfig.ini Datei listet die folgenden Ebenen auf:

Level Detail
DEFAULT Die Standardmäßigen Ausführlichkeitsparameter sollten für die meisten Anforderungen geeignet sein: Lesen Sie den Abschnitt "Überprüfung der typischen Protokollierungseinträge ", um zu beobachten, was bereits standardmäßig generiert wird. Zusätzlich zu Fehlern werden standardmäßig auch erfolgreiche VSS-Aufrufe zusammen mit VSS-Metadaten protokolliert.
MINIMAL Diese Ebene behält die Formatierung des DEFAULT Modus und deren Ereignisse bei. Außerdem werden an vielen wichtigen Stellen des Codes Ausgaben generiert. Vor allem werden alle Dateien und Datenbankiterationen protokolliert, die in der SQLWriter-Logik üblich sind. Diese Ebene kann die Anzahl der protokollierten Einträge für jeden VSS-Vorgang (einschließlich profaner OnIdentify-Ereignisse) erheblich erhöhen, insbesondere bei Instanzen mit einer großen Anzahl von Datenbanken. Jede einzelne physische Datei jeder einzelnen Datenbank kann im Verlauf einer VSS-Sicherung mehr als einmal protokolliert werden. Diese Ebene dient nur dazu, eine genauere Vorstellung von der logischen Position der SQL-Writer-Logik zum Zeitpunkt eines Fehlers zu geben. Dies ist auch für Erkundungszwecke praktisch. Es ist nicht hilfreich, es über momentäre Untersuchungen hinaus aktiv zu halten, da die Detailebene die Verlaufstiefe der standardmäßigen 1-MB-Dateigröße erheblich reduziert. Die Erhöhung des Werts TraceFileSizeMb kann relevant sein.
VERBOSE Derzeit meldet diese Ebene dieselben Ereignisse wie MINIMAL, präfixiert jedoch jeden Eintrag mit Quellcodeobjekten und Methodendeskriptoren. Dadurch wird die Ausgabe umfassender (größer als bei „Minimal“) und weniger lesbar. Die zusätzlichen Informationen sind außerhalb der Interaktion mit den Microsoft Support Services nicht von Nutzen. Es gilt der gleiche Kommentar wie bei MINIMAL. Wenn Sie diese Ebene über einen längeren Zeitraum aktiv halten, wird die Verlaufstiefe der standardmäßigen 1 MB großen Datei stark reduziert, sodass eine Erhöhung des Werts TraceFileSizeMb sinnvoll sein kann.

MINIMAL und VERBOSE Ebenen enthalten keine zusätzlichen Fehlerdetails im Falle eines Fehlers, nur zusätzliche Statusdetails für jeden Vorgang auf niedriger Ebene im Zusammenhang mit SQL Writer-Aktivitäten.

Nächste Schritte