Freigeben über

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-Backup-Anwendungen - 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 in SQL Server 2019 (15.x) eingeführte Protokoll beschrieben, das eine bessere Übersicht über die SQLWriter-Vorgänge bietet. 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
  • Inhalt 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 gemeinsam genutzte Komponente von SQL Server ist, gibt es nur eine Instanz auf einem System, deren Hauptversion der höchsten Hauptversion aller installierten SQL Server-Instanzen entspricht. Wenn beispielsweise SQL Server 2016 (13.x) SP2 und SQL Server 2019 (15.x) auf demselben System installiert sind, wird die SQL Writer-Binärdatei die von SQL Server 2019 (15.x) bereitgestellte sein und alle laufenden Instanzen aller Hauptversionen bedienen (auch wenn das Stammverzeichnis unter \90) bleibt. Lokale Instanzen und Versionen profitieren von der neuen hier beschriebenen Ablaufverfolgung von SQL Server 2019 (15.x). Es bedeutet auch, dass nur kumulative Updates für SQL Server 2019 (15.x) die SQL Writer-Binärdateien in dieser Situation aktualisieren können.

Hinweis

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

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, auch wenn diese Vorgänge erfolgreich ablaufen, werden in der Protokolldatei weiterhin detaillierte Einträge aufgezeichnet. Sie können bestätigen, dass VSS-Operationen durchgeführt werden und erfolgreich mit SQL Writer interagieren. Es handelt sich um eine Verbesserung, die eine einfache integrierte Möglichkeit bietet, diese Details auf der Ebene der SQL Server-Instanz festzulegen.

Zusätzlich werden auch Ereignisse beim Start des SQLWriter-Diensts aufgezeichnet, wobei aktive Protokollierungs-Parameter gemeldet werden.

Wenn ein Fehler bei einem VSS-Vorgang mit Beteiligung von SQL Server auftritt, wird SqlWriterLogger zu einer wichtigen Stelle, an der Sie nach Informationen suchen können.

Hinweis

Diese neue Infrastruktur für die Protokollierung ergänzt die bestehende Infrastruktur für die Fehlerberichterstattung für SQL Server, aber ersetzt sie nicht. Daher ist im Fehlerfall das Windows-Anwendungsereignisprotokoll die erste Anlaufstelle (Filterung nach Quellen wie "SQLWRITER" und "VSS"). SqlWriterLogger.txt würde zusätzliche Informationen zu diesem ersten Satz liefern.

Überprüfen typischer Protokollierungseinträge

Die folgenden Exporte erfolgen unter Einstellung Default.

Start des Dienstes

[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 bei jedem Start des SQL Writer-Dienstes beobachtet (er kann sogar zweimal pro Dienststart protokolliert werden).

In der Reihenfolge ihres Erscheinens sehen wir die folgenden Informationen:

  • Ein Zeitstempel (Datum + Uhrzeit) in lokaler Serverzeit und die Thread-ID, von der der Eintrag stammt, für jede Zeile.
  • Die Prozess-ID des gestarteten SQLWriter-Prozesses.
  • Die Tatsache, dass der Dienst im normalen Modus (nicht als WIDWriter ausgeführt) oder im Modus Interne Windows-Datenbank 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
    • Maximale Größe der Datei vor dem Rollover, im Beispiel hier 1 MB
    • Die Option „ForceFlush“ für jede einzelne Aktualisierung der Protokolldatei im Vergleich zu einem entspannteren/gepufferten Ansatz, der standardmäßig auf "False" eingestellt ist.
  • Erinnerung, dass die Protokollierung zur Ortszeit zusammen mit dem UTC-Versatz dieser Ortszeit erfolgt

VSS-Ereignis 'OnIdentify'

[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 den 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 (laufenden) SQL Server-Instanzen, zusammen mit Instanz-Name, Hauptversion und Edition.
  • Der Hinweis, dass wir nicht versucht haben, "Benutzerinstanzen" aufzulisten - ein spezielles SQL Server-Feature, das auch als LocalDB bekannt ist und normalerweise auf Unternehmens-Datenbankservern nicht zum Einsatz kommt.

Erfolgreiche VSS-Sicherung im komponentenbasierten Modus

[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 ihres Erscheinens sehen wir die folgenden Informationen:

  • Ein vollständiger OnIdentify-Abschnitt, der wie bereits angegeben oft eine Sicherung einleitet.
  • Erwähnung jeder VSS-Hauptphase der Sicherung, mit dem Muster "Eingabe SQL Writer xxxx".
    • Die erste hier ist Entering SQL Writer OnPrepareBackup.
  • Ein auffälliger Eintrag, der den Start einer VSS-SQL-Sicherung angibt
    • (ID ist die ThreadId, die die Protokollierung für diesen Sicherungsversuch in SQLWriter vornimmt)
  • Die vom VSS-Anforderer ausgewählte VSS-Sicherungs-API: "Komponentenbasiert" oder "Nicht komponentenbasiert / Volume"
  • Die Anzahl der Datenbanken, die in der vom VSS-Anforderer gesendeten Komponentenliste enthalten sind, hier eine einzelne Datenbank (1).
  • Eine Bestätigung, dass jeder vom Anfragesteller bereitgestellte Datenbankname (hier 'db_on_G') auf der SQL Server-Instanz gefunden (oder nicht gefunden) wurde, mit der er vom VSS-Anfragesteller verknüpft wurde (hier 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 Bericht über die VSS-Phase, dessen Namen ihn zu einem nützlichen "Abschlussereignis" macht: OnBackupComplete.

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

Fehlersituation: beschädigte Datenbank

Zur Veranschaulichung der früheren Aussage, dass die SQL Writer-Protokollierung die Ereignisprotokoll-Architektur ergänzt, sehen wir uns die Einträge an, die mit einer bekannten Fehlersituation verbunden sind: eine zerrissene Datenbank. Dieses Szenario kann auftreten, wenn ein VSS-Backup versucht, einen Snapshot-Satz von Volumes zu erstellen, die nur einen Teil der 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.

In SqlWriterLogger.txt sehen wir, dass ein Fehler aufgetreten ist, aber die einzigen Details zum Fehler finden wir in 0x80780002 HResult. Dieser Wert ist ohne die Referenzen zu Fehlercodes nur schwierig zu interpretieren. Es zeigt jedoch die Situation mit der zerrissenen Datenbank.

Anzeigen von Ereignisprotokollen

Lassen Sie uns nun den Inhalt der Windows- Anwendungs-Ereignisprotokolle überprüfen:

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 das Problem auch in den Ereignisprotokollen und verwendet dabei seine Nomenklatur (VSS verwaltet 'Komponenten', die im Kontext von SQL Server 'Datenbanken' 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 hier eine bessere Quelle für Informationen zum 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 Protokollierungsparametern für SQL Writer

Die SQL Writer-Protokollierung kann durch Bearbeiten der Textdatei SqlWriterConfig.ini konfiguriert werden. Die Datei selbst enthält eine kurze Inlinebeschreibung der verfügbaren Parameter, auf die wir im Folgenden eingehen.

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 entweder Notepad als Administrator und dann öffnen Sie SqlWriterConfig.ini oder verwenden einen Texteditor, der beim Speichern der Datei nach Bedarf nach einer Berechtigung fragt.

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

Parameter Optionen Beschreibung
EnableLogging - TRUE (Standard)
- FALSE		 Ermöglicht dem Benutzer, das gesamte neue Protokollierungsfeature für den seltenen Fall zu deaktivieren, dass es erforderlich sein sollte.
TraceFile C:\Program Files\Microsoft SQL Server\90\Shared\SqlWriterLog.txt Erlmö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ÜHRLICH		 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. Eine Erhöhung dieses Wertes ist sinnvoll, wenn z.B. intensive VSS-Aktivitäten stattfinden, lange Zeiträume von Protokolleinträgen aufbewahrt werden oder wenn nicht standardmäßige TraceLevel Werte für lange Zeiträume aktiviert sind. Der Standardwert von 1 MB sollte für die meisten Situationen ausreichen.
ForceFlush - TRUE
- FALSE (Standard)		 Die Einstellung dieser Option auf TRUE wäre nur in den seltenen Fällen sinnvoll, in denen der SQL Writer-Dienst abstürzen würde, bevor er die Möglichkeit hatte, seine letzten Protokolleinträge zu leeren.

Änderungen übernehmen

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

Tipp

Der Neustart von SQL Writer erfolgt extrem schnell und kann nach Belieben erfolgen, da SQL Writer zwischen VSS-Aufrufen keine Zustandsinformationen speichert und keine Aktivität aufweist. 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:

Ebene Detail
DEFAULT Die standardmäßigen Ausführlichkeitsparameter sollten für die meisten Anforderungen ausreichend sein. Im Abschnitt Überprüfen typischer Protokollierungseinträge erfahren Sie, 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 übernimmt die Formatierung des DEFAULT Modus und dessen Ereignisse. 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 sinnvoll, diese Ebene über kurzzeitige Untersuchungen hinaus aktiv zu halten, da der Detailgrad der standardmäßig 1 MB großen Datei die Verlaufstiefe stark reduziert. Die Erhöhung des Werts TraceFileSizeMb kann relevant sein.
VERBOSE Derzeit meldet diese Ebene die gleichen Ereignisse wie MINIMAL, stellt aber jedem Eintrag Objekt- und Methodendeskriptoren des Quellcodes voran. 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.

Die Ebenen MINIMAL und VERBOSE liefern im Fehlerfall keine zusätzlichen Fehlerdetails, sondern nur zusätzliche Statusdetails für jeden Vorgang auf niedriger Ebene im Zusammenhang mit SQL Writer-Aktivitäten.

Nächste Schritte