SQL Server VSS Writer-Protokollierung

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
  • Es ist systemweit wirksam (es verfolgt die SQL Writer-Aktivität für alle SQL Server-Instanzen, die auf dem Server ausgeführt werden)
  • Textbasiert
  • Sein Arbeitsverzeichnis ist C:\Program Files\Microsoft SQL Server\90\Shared
  • Inhalt dieses Verzeichnisses:
    • Die Protokollierung erfolgt in der Datei SqlWriterLogger.txt
    • Diese Datei wird in SqlWriterLogger1.txt umbenannt, sobald eine maximale Größe (standardmäßig 1 MB) erreicht wird, wobei die Protokollierung in der Hauptdatei SqlWriterLogger.txt fortgesetzt wird.
    • Es gibt nur eine Rolloverdatei, sodass der zweite Rollovervorgang die vorhandene SqlWriterLogger1.txt überschreiben würde.
    • Parameter werden über die Datei SqlWriterConfig.ini verwaltet

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 hier beschriebenen neuen Ablaufverfolgung in 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 OnIdentify ausgelöste vssadmin list writers-Ereignisse
  • Backup-Ereignisse
  • Ereignisse wiederherstellen

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
    • Die maximale Dateigröße, bevor ein Rollover erfolgt, die in diesem Beispiel 1 MB beträgt
    • Die Option „ForceFlush“ für jede einzelne Aktualisierung der Protokolldatei im Vergleich zu einem entspannteren/gepufferten Ansatz, der standardmäßig auf "False" eingestellt ist.
  • Zur Erinnerung: Die Protokollierung erfolgt in lokaler Zeit zusammen mit dem UTC-Versatz dieser lokalen Zeit.

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 gängiger 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 durch aktive Profiler-Ablaufverfolgung erkennen. Beim neuen Protokollierungsfeature führt jedes Ereignis zum obigen Eintrag.

In der Reihenfolge, in der sie erscheinen, sehen wir, dass die folgenden Informationen protokolliert werden:

  • Eine explizite Erwähnung des OnIdentify VSS-Ereignisses.
  • 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 erwähnt, häufig einen Sicherungsvorgang einleitet.
  • Erwähnung aller VSS-Hauptphasen der Sicherung, mit dem Muster "Entering SQL Writer xxxx".
    • Die erste hier wäre 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').
  • Der Typ der angeforderten VSS-Sicherung. Normalerweise VSS_BT_FULL oder VSS_BT_COPY. Siehe die Enumeration VSS_BACKUP_TYPE.
  • Ein weiterer OnIdentify-Abschnitt
  • Weitere Einträge zur Bestimmung der Hauptphasen der VSS-Sicherung (OnFreeze, OnThaw, OnPostSnapshot)
  • Ein letzter OnIdentify Abschnitt.
  • Ein abschließender Bericht über die VSS-Phase, dessen Namen ihn zu einem nützlichen "Abschlussereignis" macht: OnBackupComplete.

Diese Einträge enthalten Details zu den VSS-Vorgängen, die zuvor nur schwer schnell zu ermitteln waren und dafür 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 dies gemäß den 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. Ein Doppelklick im Explorer öffnet den Editor ohne erhöhte Rechte. Der Benutzer kann den Inhalt lesen, doch jeder Versuch, Änderungen zu speichern, schlägt fehl. Starten Sie entweder Notepad als Administrator und öffnen Sie dann SqlWriterConfig.ini, oder verwenden Sie einen Texteditor, der beim Speichern der Datei bei Bedarf erhöhte Rechte anfordern kann.

Die Kommentare zur Datei SqlWriterConfig.ini werden hier dupliziert:

Parameter Optionen Beschreibung
EnableLogging - TRUE (Standardwert)
-FALSCH		 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 Ermöglicht dem Benutzer, den Pfad und den Dateinamen der Ablaufverfolgungsdatei zu ändern. Es wird nicht empfohlen, dies zu ändern, da der bekannte Standardspeicherort es erleichtert, auf jedem SQL Server 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 (Standardwert) 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 -STIMMT
- FALSE (Standardwert)		 Diese Option auf TRUE zu setzen, wäre nur in den seltenen Fällen sinnvoll, in denen der SQL Writer-Dienst abstürzt, bevor er seine letzten Protokolleinträge schreiben kann; andernfalls behalten Sie den Standardwert bei.

Ä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. Es wird auch an vielen wichtigen Stellen des Codes Ausgaben erzeugen. 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, dies über kurze Untersuchungen hinaus aktiviert zu lassen, da der hohe Detailgrad bei der Standarddateigröße von 1 MB die Verlaufstiefe erheblich verringert. 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 derselbe Kommentar wie für MINIMAL: Wenn diese Ebene über längere Zeit aktiv bleibt, wird die Verlaufstiefe der Standarddateigröße von 1 MB stark reduziert, und eine Erhöhung des Werts TraceFileSizeMb kann daher sinnvoll sein.

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

  • Last updated on