Merge pull request #4383 from MicrosoftDocs/FromPublicRepo

Confirm merge from FromPublicRepo to master to sync with https://github.com/MicrosoftDocs/sql-docs (branch live)

Author: v-alje

docs/relational-databases/indexes/enable-indexes-and-constraints.md

@@ -71,7 +71,9 @@ ms.workload: "On Demand"
     |ALTER INDEX REBUILD.|The action fails.|The action succeeds.|  
     |DROP INDEX.|The action succeeds.|The action succeeds.|  
     |CREATE INDEX WITH DROP_EXISTING.|The action fails.|The action succeeds.|  
-  
+
+-   When rebuilding disabled compressed nonclustered indexes, data_compression will default to 'none', meaning that indexes will be uncompressed. This is due to compression settings metadata is lost when nonclustered indexes are disabled. To work around this you must specifiy explicit data compression in rebuild statement.
+
 ###  <a name="Security"></a> Security  
 
 ####  <a name="Permissions"></a> Permissions  

docs/relational-databases/tables/primary-and-foreign-key-constraints.md

@@ -42,7 +42,7 @@ ms.workload: "Active"
 
  When you specify a primary key constraint for a table, the [!INCLUDE[ssDE](../../includes/ssde-md.md)] enforces data uniqueness by automatically creating a unique index for the primary key columns. This index also permits fast access to data when the primary key is used in queries. If a primary key constraint is defined on more than one column, values may be duplicated within one column, but each combination of values from all the columns in the primary key constraint definition must be unique.  
 
- As shown in the following illustration, the **ProductID** and **VendorID** columns in the **Purchasing.ProductVendor** table form a composite primary key constraint for this table. This makes sure that that every row in the **ProductVendor** table has a unique combination of **ProductID** and **VendorID**. This prevents the insertion of duplicate rows.  
+ As shown in the following illustration, the **ProductID** and **VendorID** columns in the **Purchasing.ProductVendor** table form a composite primary key constraint for this table. This makes sure that every row in the **ProductVendor** table has a unique combination of **ProductID** and **VendorID**. This prevents the insertion of duplicate rows.  
 
  ![Composite PRIMARY KEY constraint](../../relational-databases/tables/media/fund04.gif "Composite PRIMARY KEY constraint")  
 

docs/t-sql/statements/set-deadlock-priority-transact-sql.md

@@ -72,7 +72,7 @@ SET DEADLOCK_PRIORITY { LOW | NORMAL | HIGH | <numeric-priority> | @deadlock_var
 
  Which session is chosen as the deadlock victim depends on each session's deadlock priority:  
 
--   If both sessions have the same deadlock priority, the instance of [!INCLUDE[ssNoVersion](../../includes/ssnoversion-md.md)] chooses the session that is less expensive to roll back as the deadlock victim. For example, if both sessions have set their deadlock priority to HIGH, the instance will choose as a victim the session it estimates is less costly to roll back.  
+-   If both sessions have the same deadlock priority, the instance of [!INCLUDE[ssNoVersion](../../includes/ssnoversion-md.md)] chooses the session that is less expensive to roll back as the deadlock victim. For example, if both sessions have set their deadlock priority to HIGH, the instance will choose as a victim the session it estimates is less costly to roll back. The cost is determined by comparing the number of log bytes written to that point in each transaction. (You can see this value as "Log Used" in a deadlock graph).
 
 -   If the sessions have different deadlock priorities, the session with the lowest deadlock priority is chosen as the deadlock victim.