Merge pull request #13324 from MicrosoftDocs/FromPublicRepo

huypub · web-flow · commit 9a8ddc336d86 · 2019-12-20T15:06:39.000-08:00
Confirm merge from FromPublicRepo to master to sync with https://github.com/MicrosoftDocs/sql-docs (branch live)
diff --git a/docs/linux/sql-server-linux-setup-ssis.md b/docs/linux/sql-server-linux-setup-ssis.md
@@ -37,7 +37,7 @@ To install the `mssql-server-is` package on Ubuntu, follow these steps:
    ```
 ::: moniker-end
 <!--SQL Server 2019 on Linux-->
-::: moniker range="= sql-server-ver15 || = sql-server-ver15 || = sqlallproducts-allversions"
+::: moniker range=">= sql-server-linux-ver15 || >= sql-server-ver15 || =sqlallproducts-allversions"
    ```bash
    sudo add-apt-repository "$(curl https://packages.microsoft.com/config/ubuntu/16.04/mssql-server-2019.list)"
    ```
@@ -86,7 +86,7 @@ To install the `mssql-server-is` package on RHEL, follow these steps:
    ```
 ::: moniker-end
 <!--SQL Server 2019 on Linux-->
-::: moniker range="= sql-server-linux-ver15 || = sql-server-ver15 || = sqlallproducts-allversions"
+::: moniker range=">= sql-server-linux-ver15 || >= sql-server-ver15 || =sqlallproducts-allversions"
    ```bash
    sudo curl -o /etc/yum.repos.d/mssql-server.repo https://packages.microsoft.com/config/rhel/7/mssql-server-2019.repo
    ```
diff --git a/docs/relational-databases/backup-restore/recovery-models-sql-server.md b/docs/relational-databases/backup-restore/recovery-models-sql-server.md
@@ -46,7 +46,7 @@ ms.author: mikeray
 |--------------------|-----------------|------------------------|-------------------------------|  
 |**Simple**|No log backups.<br /><br /> Automatically reclaims log space to keep space requirements small, essentially eliminating the need to manage the transaction log space. For information about database backups under the simple recovery model, see [Full Database Backups &#40;SQL Server&#41;](../../relational-databases/backup-restore/full-database-backups-sql-server.md).<br /><br /> Operations that require transaction log backups are not supported by the simple recovery model. The following features cannot be used in simple recovery mode:<br /><br /> -Log shipping<br /><br /> -Always On or Database mirroring<br /><br /> -Media recovery without data loss<br /><br /> -Point-in-time restores|Changes since the most recent backup are unprotected. In the event of a disaster, those changes must be redone.|Can recover only to the end of a backup. For more information, see [Complete Database Restores &#40;Simple Recovery Model&#41;](../../relational-databases/backup-restore/complete-database-restores-simple-recovery-model.md). <br><br> For a more in depth explanation of the Simple recovery model, see [SQL Server Simple Recovery Model](https://www.mssqltips.com/sqlservertutorial/4/sql-server-simple-recovery-model/) provided by the folks at [MSSQLTips!](https://www.mssqltips.com)|  
 |**Full**|Requires log backups.<br /><br /> No work is lost due to a lost or damaged data file.<br /><br /> Can recover to an arbitrary point in time (for example, prior to application or user error). For information about database backups under the full recovery model, see [Full Database Backups &#40;SQL Server&#41;](../../relational-databases/backup-restore/full-database-backups-sql-server.md) and [Complete Database Restores &#40;Full Recovery Model&#41;](../../relational-databases/backup-restore/complete-database-restores-full-recovery-model.md).|Normally none.<br /><br /> If the tail of the log is damaged, changes since the most recent log backup must be redone.|Can recover to a specific point in time, assuming that your backups are complete up to that point in time. For information about using log backups to restore to the point of failure, see [Restore a SQL Server Database to a Point in Time &#40;Full Recovery Model&#41;](../../relational-databases/backup-restore/restore-a-sql-server-database-to-a-point-in-time-full-recovery-model.md).<br /><br /> Note: If you have two or more full-recovery-model databases that must be logically consistent, you may have to implement special procedures to make sure the recoverability of these databases. For more information, see [Recovery of Related  Databases That Contain Marked Transaction](../../relational-databases/backup-restore/recovery-of-related-databases-that-contain-marked-transaction.md).|  
-|**Bulk logged**|Requires log backups.<br /><br /> An adjunct of the full recovery model that permits high-performance bulk copy operations.<br /><br /> Reduces log space usage by using minimal logging for most bulk operations. For information about operations that can be minimally logged, see [The Transaction Log &#40;SQL Server&#41;](../../relational-databases/logs/the-transaction-log-sql-server.md).<br /><br /> For information about database backups under the bulk-logged recovery model, see [Full Database Backups &#40;SQL Server&#41;](../../relational-databases/backup-restore/full-database-backups-sql-server.md) and [Complete Database Restores &#40;Full Recovery Model&#41;](../../relational-databases/backup-restore/complete-database-restores-full-recovery-model.md).|If the log is damaged or bulk-logged operations occurred since the most recent log backup, changes since that last backup must be redone.<br /><br /> Otherwise, no work is lost.|Can recover to the end of any backup. Point-in-time recovery is not supported.|  
+|**Bulk logged**|Requires log backups.<br /><br /> An adjunct of the full recovery model that permits high-performance bulk copy operations.<br /><br /> Reduces log space usage by using minimal logging for most bulk operations. For information about operations that can be minimally logged, see [The Transaction Log &#40;SQL Server&#41;](../../relational-databases/logs/the-transaction-log-sql-server.md).<br /><br /> Log backups may be of a significant size because the minimally-logged operations are captured in the log backup. For information about database backups under the bulk-logged recovery model, see [Full Database Backups &#40;SQL Server&#41;](../../relational-databases/backup-restore/full-database-backups-sql-server.md) and [Complete Database Restores &#40;Full Recovery Model&#41;](../../relational-databases/backup-restore/complete-database-restores-full-recovery-model.md).|If the log is damaged or bulk-logged operations occurred since the most recent log backup, changes since that last backup must be redone.<br /><br /> Otherwise, no work is lost.|Can recover to the end of any backup. Point-in-time recovery is not supported.|  
   
 ##  <a name="RelatedTasks"></a> Related Tasks  
   
diff --git a/docs/relational-databases/json/solve-common-issues-with-json-in-sql-server.md b/docs/relational-databases/json/solve-common-issues-with-json-in-sql-server.md
@@ -36,7 +36,7 @@ SELECT col1, col2, col3,
      (SELECT col11, col12, col13 FROM t11 WHERE t11.FK = t1.PK FOR JSON PATH) as t11,  
      (SELECT col21, col22, col23 FROM t21 WHERE t21.FK = t1.PK FOR JSON PATH) as t21,  
      (SELECT col31, col32, col33 FROM t31 WHERE t31.FK = t1.PK FOR JSON PATH) as t31,  
-     JSON_QUERY('{"'+col4'":"'+col5+'"}' as t41  
+     JSON_QUERY('{"'+col4'":"'+col5+'"}') as t41  
 FROM t1  
 FOR JSON PATH  
 ```  
diff --git a/docs/relational-databases/pages-and-extents-architecture-guide.md b/docs/relational-databases/pages-and-extents-architecture-guide.md
@@ -48,7 +48,7 @@ The following table shows the page types used in the data files of a [!INCLUDE[s
 > [!NOTE]
 > Log files do not contain pages; they contain a series of log records.
 
-Data rows are put on the page serially, starting immediately after the header. A row offset table starts at the end of the page, and each row offset table contains one entry for each row on the page. Each entry records how far the first byte of the row is from the start of the page. The entries in the row offset table are in reverse sequence from the sequence of the rows on the page.
+Data rows are put on the page serially, starting immediately after the header. A row offset table starts at the end of the page, and each row offset table contains one entry for each row on the page. Each row offset entry records how far the first byte of the row is from the start of the page. Thus, the function of the row offset table is to help SQL Server locate rows on a page very quickly. The entries in the row offset table are in reverse sequence from the sequence of the rows on the page.
 
 ![page_architecture](../relational-databases/media/page-architecture.gif)
 
@@ -62,7 +62,7 @@ This is done whenever an insert or update operation increases the total size of
 
 ##### Row-Overflow Considerations 
 
-When you combine varchar, nvarchar, varbinary, sql_variant, or CLR user-defined type columns that exceed 8,060 bytes per row, consider the following: 
+As mentioned earlier, a row cannot reside on multiple pages and can overflow if the combined size of variable-length data-type fields exceeds the 8060-byte limit. To illustrate, a table may be created with two columns: one varchar(7000) and another varchar (2000). Individually neither column exceeds the 8060-byte, but combined they could do so, if the entire width of each column is filled. SQL Server may dynamically move the varchar(7000) variable length column to pages in the ROW_OVERFLOW_DATA allocation unit. When you combine varchar, nvarchar, varbinary, sql_variant, or CLR user-defined type columns that exceed 8,060 bytes per row, consider the following:
 -  Moving large records to another page occurs dynamically as records are lengthened based on update operations. Update operations that shorten records may cause records to be moved back to the original page in the IN_ROW_DATA allocation unit. 
    Querying and performing other select operations, such as sorts or joins on large records that contain row-overflow data slows processing time, because these records are processed synchronously instead of asynchronously.   
    Therefore, when you design a table with multiple varchar, nvarchar, varbinary, sql_variant, or CLR user-defined type columns, consider the percentage of rows that are likely to flow over and the frequency with which this overflow data is likely to be queried. If there are likely to be frequent queries on many rows of row-overflow data, consider normalizing the table so that some columns are moved to another table. This can then be queried in an asynchronous JOIN operation. 
@@ -132,7 +132,7 @@ The algorithms that are actually used internally by the [!INCLUDE[ssDEnoversion]
 
 After an extent has been allocated to an object, the [!INCLUDE[ssDEnoversion](../includes/ssdenoversion-md.md)] uses the PFS pages to record which pages in the extent are allocated or free. This information is used when the [!INCLUDE[ssDEnoversion](../includes/ssdenoversion-md.md)] has to allocate a new page. The amount of free space in a page is only maintained for heap and Text/Image pages. It is used when the [!INCLUDE[ssDEnoversion](../includes/ssdenoversion-md.md)] has to find a page with free space available to hold a newly inserted row. Indexes do not require that the page free space be tracked, because the point at which to insert a new row is set by the index key values.
 
-A PFS page is the first page after the file header page in a data file (page ID 1). This is followed by a GAM page (page ID 2), and then an SGAM page (page ID 3). There is a new PFS page approximately 8,000 pages after the first PFS page, and additional PFS pages in subsequent 8,000 page intervals. There is another GAM page 64,000 extents after the first GAM page on page 2, another SGAM page 64,000 extents after the first SGAM page on page 3, and additional GAM and SGAM pages in subsequent 64,000 extent intervals. The following illustration shows the sequence of pages used by the [!INCLUDE[ssDEnoversion](../includes/ssdenoversion-md.md)] to allocate and manage extents.
+A new PFS, GAM or SGAM page is added in the data file for every additional range that it keeps track of. Thus, there is a new PFS page 8,088 pages after the first PFS page, and additional PFS pages in subsequent 8,088 page intervals. To illustrate, page ID 1 is a PFS page, page ID 8088 is a PFS page, page ID 16176 is a PFS page, and so on. There is a new GAM page 64,000 extents after the first GAM page and it keeps track of the 64,000-extents following it; the sequence continues at 64,000-extent intervals. Similarly, there is a new SGAM page 64,000 extents after the first SGAM page and additional SGAM pages in subsequent 64,000 extent intervals. The following illustration shows the sequence of pages used by the [!INCLUDE[ssDEnoversion](../includes/ssdenoversion-md.md)] to allocate and manage extents.
 
 ![manage_extents](../relational-databases/media/manage-extents.gif)
 
diff --git a/docs/t-sql/functions/string-escape-transact-sql.md b/docs/t-sql/functions/string-escape-transact-sql.md
@@ -23,7 +23,7 @@ monikerRange: "= azuresqldb-current||>= sql-server-2016||>= sql-server-linux-201
 
 [!INCLUDE[tsql-appliesto-ss2016-asdb-xxxx-xxx-md](../../includes/tsql-appliesto-ss2016-asdb-xxxx-xxx-md.md)]
 
-  Escapes special characters in texts and returns text with escaped characters. **STRING_ESCAPE** is a deterministic function.  
+Escapes special characters in texts and returns text with escaped characters. **STRING_ESCAPE** is a deterministic function, introduced in SQL Server 2016. 
   
  ![Topic link icon](../../database-engine/configure-windows/media/topic-link.gif "Topic link icon") [Transact-SQL Syntax Conventions](../../t-sql/language-elements/transact-sql-syntax-conventions-transact-sql.md)  
   
diff --git a/docs/t-sql/language-elements/begin-end-transact-sql.md b/docs/t-sql/language-elements/begin-end-transact-sql.md
@@ -83,7 +83,7 @@ WHILE @Iteration <10
 BEGIN  
     SELECT FirstName, MiddleName   
     FROM dbo.DimCustomer WHERE LastName = 'Adams';  
-SET @Iteration += 1  
+    SET @Iteration += 1  
 END;  
   
 ```  
