sqlwriter logging : minor formatting updates and corrections

Author: Guillaume-Fourrat

docs/relational-databases/backup-restore/sql-server-vss-writer-logging.md

@@ -158,7 +158,7 @@ These entries provide details on the VSS operations that were previously difficu
 
 ### Failure Situation: torn database
 
-To illustrate the earlier statement that SQL Writer logging complements original EventLog architecture, let’s look at the entries associated to a well-known failure situation: a Torn Database. It can occur when a  VSS backup attempts to create a snapshot set of volumes where only a partial set of files of a given database is included. SQL Writer will block it as per VSS conventions.
+To illustrate the earlier statement that SQL Writer logging complements original EventLog architecture, let’s look at the entries associated to a well-known failure situation: a Torn Database. It can occur when a  VSS backup attempts to create a snapshot set of volumes, which includes only a partial set of files of a given database. SQL Writer will block it as per VSS conventions.
 
 This extract is the content of `SqlWriterLogger.txt` for the operation:
 
@@ -202,7 +202,7 @@ Sqllib error: Database db_on_G_and_H of SQL Server instance GF19  is stored on m
 ```
 The event provides a full user-friendly formatted message explaining the situation.
 
-The OS VSS framework will also report the issue in Event Logs, using its nomenclature (VSS manages ‘components,’ which in context of SQL Server are ‘databases’).
+The OS VSS framework will also report the issue in Event Logs, using its nomenclature (VSS manages ‘components,’ which are ‘databases’ in the context of SQL Server).
 
 ``` txt
 Log Name:      Application
@@ -275,8 +275,8 @@ SQL Writer will report active parameters in its log file upon (re)start, as can
 The INI file lists the following level: DEFAULT | MINIMAL | VERBOSE.
 
 - **DEFAULT**: The default verbosity parameters should be adequate for most needs: refer to the [Review of typical logging entries](#review-of-typical-logging-entries) section to observe what is already generated by default. In addition to errors, successful VSS calls, along with VSS metadata, will be logged by default.
-- **MINIMAL**: This level will retain the formatting of `DEFAULT` mode, and its events. It will also generate output in many key places of the code. Most notably it will log all the files and database iterations that are commonplace in the SQLWriter logic. It can increase the number of entries logged for each VSS operation (including mundane OnIdentify event) by a large margin, especially on instances hosting a large number of databases: every single physical file of every single Database may be reported more than once over the course of a VSS backup. This level only helps giving a more precise idea of the logical position of SQL Writer logic at the time of a failure. It's also convenient for exploration purposes. It’s not useful to keep it active beyond momentary investigations, as the level of details will greatly reduce the history depth of the default 1-MB file size. Increasing the `TraceFileSizeMb` value may be relevant.
-- **VERBOSE**: Currently this level reports the same events as `MINIMAL`, but prefixes each entry with source code object and methods descriptors. It makes the output wider (larger in size than Minimal) and less readable. The added information wouldn't be useful outside of interactions with Microsoft Support Services. The same comment as `MINIMAL` would apply: keep this level active for long duration will greatly reduce the history depth of the default 1-MB file size as each operation will generate at least five times as many entries, and wider entries: increasing the `TraceFileSizeMb` value may be relevant.
+- **MINIMAL**: This level will keep the formatting of `DEFAULT` mode, and its events. It will also generate output in many key places of the code. Most notably it will log all the files and database iterations that are commonplace in the SQLWriter logic. It can increase the number of entries logged for each VSS operation (including mundane `OnIdentify` event) by a large margin, especially on instances hosting a large number of databases: every single physical file of every single Database may be reported more than once over the course of a VSS backup. This level only helps giving a more precise idea of the logical position of SQL Writer logic at the time of a failure. It's also convenient for exploration purposes. It’s not useful to keep it active beyond momentary investigations, as the level of details will greatly reduce the history depth of the default 1-MB file size. Increasing the `TraceFileSizeMb` value may be relevant.
+- **VERBOSE**: Currently this level reports the same events as `MINIMAL`, but prefixes each entry with source code object and methods descriptors. It makes the output wider (larger in size than Minimal) and less readable. The added information wouldn't be useful outside of interactions with Microsoft Support Services. The same comment as `MINIMAL` would apply: keep this level active for long duration will greatly reduce the history depth of the default 1-MB file size, and increasing the `TraceFileSizeMb` value may be relevant.
 
 > [!NOTE]
 > **MINIMAL** (and **VERBOSE**) level will *not* provide additional error details in case of failure, only additional *progress details* for each low level operation related to SQL Writer activities.