Merge pull request #13731 from MicrosoftDocs/MashaMSFT-patch-4

PRMerger15 · web-flow · commit b5faf01a0443 · 2020-03-17T17:35:00.000-07:00
Added clarity to log shipping
diff --git a/docs/database-engine/log-shipping/fail-over-to-a-log-shipping-secondary-sql-server.md b/docs/database-engine/log-shipping/fail-over-to-a-log-shipping-secondary-sql-server.md
@@ -32,11 +32,11 @@ ms.author: mathoma
   
 2.  Apply any unapplied transaction log backups in sequence to each secondary database. For more information, see [Apply Transaction Log Backups &#40;SQL Server&#41;](../../relational-databases/backup-restore/apply-transaction-log-backups-sql-server.md).  
   
-3.  If the primary database is accessible, back up the active transaction log and apply the log backup to the secondary databases.  
+3.  If the primary database is accessible back up the active transaction log and apply the log backup to the secondary databases. You may need to set the database to [single-user mode](../../relational-databases/databases/set-a-database-to-single-user-mode.md) to obtain exclusive access before issuing the restore command, and then switch it back to multi-user after the restore completes.  
   
      If the original primary server instance is not damaged, back up the tail of the transaction log of the primary database using WITH NORECOVERY. This leaves the database in the restoring state and therefore unavailable to users. Eventually you will be able to roll this database forward by applying transaction log backups from the replacement primary database.  
   
-     For more information, see [Transaction Log Backups &#40;SQL Server&#41;](../../relational-databases/backup-restore/transaction-log-backups-sql-server.md).  
+     For more information, see [Transaction Log Backups &#40;SQL Server&#41;](../../relational-databases/backup-restore/transaction-log-backups-sql-server.md).   
   
 4.  After the secondary servers are synchronized, you can fail over to whichever one you prefer by recovering its secondary database and redirecting clients to that server instance. Recovering puts the database into a consistent state and brings it online.  
   
diff --git a/docs/relational-databases/backup-restore/tail-log-backups-sql-server.md b/docs/relational-databases/backup-restore/tail-log-backups-sql-server.md
@@ -41,7 +41,7 @@ ms.author: mathoma
   
 |BACKUP LOG option|Comments|  
 |-----------------------|--------------|  
-|NORECOVERY|Use NORECOVERY whenever you intend to continue with a restore operation on the database. NORECOVERY takes the database into the restoring state. This guarantees that the database does not change after the tail-log backup. The log will be truncated unless the NO_TRUNCATE option or COPY_ONLY option is also specified.<br /><br /> **Important:** Avoid using NO_TRUNCATE, except when the database is damaged.|  
+|NORECOVERY|Use NORECOVERY whenever you intend to continue with a restore operation on the database. NORECOVERY takes the database into the restoring state. This guarantees that the database does not change after the tail-log backup. The log will be truncated unless the NO_TRUNCATE option or COPY_ONLY option is also specified.<br /><br /> **Important:** Avoid using NO_TRUNCATE, except when the database is damaged. You may need to put the database into [single-user mode](../../relational-databases/databases/set-a-database-to-single-user-mode.md) to obtain exclusive access before performing the restore with NORECOVERY. After the restore, set the database back to multi-user mode. |  
 |CONTINUE_AFTER_ERROR|Use CONTINUE_AFTER_ERROR only if you are backing up the tail of a damaged database.<br /><br /> When you use back up the tail of the log on a damaged database, some of the metadata ordinarily captured in log backups might be unavailable. For more information, see [Tail-Log Backups That Have Incomplete Backup Metadata](#IncompleteMetadata), in this topic.|  
   
 ##  <a name="IncompleteMetadata"></a> Tail-Log backups that have incomplete backup metadata  
