Bringing even with master.

v-alje · v-alje · commit 740419614c94 · 2018-05-22T12:24:08.000-07:00
diff --git a/docs/database-engine/availability-groups/windows/configure-availability-group-for-distributed-transactions.md b/docs/database-engine/availability-groups/windows/configure-availability-group-for-distributed-transactions.md
@@ -1,7 +1,7 @@
 ---
 title: "Configure availability group for distributed transactions | Microsoft Docs"
 ms.custom: ""
-ms.date: "07/19/2017"
+ms.date: "05/22/2018"
 ms.prod: sql
 ms.prod_service: high-availability
 ms.reviewer: ""
@@ -29,7 +29,7 @@ manager: craigg
 In order to guarantee distributed transactions, the availability group must be configured to register databases as distributed transaction resource managers.  
 
 >[!NOTE]
->[!INCLUDE[SQL2016](../../../includes/sssql15-md.md)] also supports distributed transactions, however support in [!INCLUDE[SQL2016](../../../includes/sssql15-md.md)] is limited. In [!INCLUDE[SQL2016](../../../includes/sssql15-md.md)] a distributed transaction with a database in an availability group is not supported if it includes more than one database on the same server. [!INCLUDE[SQL2017](../../../includes/sssqlv14-md.md)] does not have this limitation. 
+>[!INCLUDE[SQL Server 2016]](../../../includes/sssql15-md.md)] Service Pack 2 and later provides full support for distributed transactions in availability groups. In [!INCLUDE[SQL Server 2016]](../../../includes/sssql15-md.md)] versions prior to Service Pack 2, cross-database distributed transactions (i.e. transaction using databases on the same SQL Server instance) involving a database in an availability group are not supported. [!INCLUDE[SQL2017](../../../includes/sssqlv14-md.md)] does not have this limitation. 
 >
 >In [!INCLUDE[SQL2016](../../../includes/sssql15-md.md)] the configuration steps are the same as in [!INCLUDE[SQL2017](../../../includes/sssqlv14-md.md)].
 
@@ -51,7 +51,7 @@ Configure an availability group to support distributed transactions. Set the ava
 
 You can create an availability group for distributed transactions on  [!INCLUDE[SQL2016](../../../includes/sssql15-md.md)] or later. To create an availability group for distributed transactions, include `DTC_SUPPORT = PER_DB` in the availability group definition. The following script creates an availability group for distributed transactions. 
 
-```transact-sql
+```sql
 CREATE AVAILABILITY GROUP MyAG
    WITH (
       DTC_SUPPORT = PER_DB  
@@ -77,7 +77,7 @@ CREATE AVAILABILITY GROUP MyAG
 
 You can alter an availability group for distributed transactions on [!INCLUDE[SQL2017](../../../includes/sssqlv14-md.md)] or later. To alter an availability group for distributed transactions, include `DTC_SUPPORT = PER_DB` in the `ALTER AVAILABILITY GROUP` script. The example script changes the availability group to support distributed transactions. 
 
-```transact-sql
+```sql
 ALTER AVAILABILITY GROUP MyaAG
    SET (
       DTC_SUPPORT = PER_DB  
@@ -162,19 +162,19 @@ Run only one of the following scripts:
 
    * To commit the transaction, update and run the following script - replace the `yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy` with the in-doubt transaction UOW from the previous error message, and run:
 
-      ```transact-sql
-      KILL 'yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy' WITH COMMIT
-      ```
+   ```sql
+   KILL 'yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy' WITH COMMIT
+   ```
 
    * To roll back the transaction, update and run the following script - replace the `yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy` with the in-doubt transaction UOW from the previous error message, and run:
 
-      ```transact-sql
-      KILL 'yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy' WITH ROLLBACK
-     ```
+   ```sql
+   KILL 'yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy' WITH ROLLBACK
+   ```
 
 After you commit or roll back the transaction, you can use `ALTER DATABASE` to set the database online. Update and run the following script - set the database name for the name of the suspect database:
 
-   ```transact-sql
+   ```sql
    ALTER DATABASE [DB1] SET ONLINE
    ```
 
diff --git a/docs/database-engine/availability-groups/windows/transactions-always-on-availability-and-database-mirroring.md b/docs/database-engine/availability-groups/windows/transactions-always-on-availability-and-database-mirroring.md
@@ -1,7 +1,7 @@
 ---
 title: "Transactions - Always On availability groups and database mirroring | Microsoft Docs"
 ms.custom: ""
-ms.date: "11/01/2017"
+ms.date: "05/22/2018"
 ms.prod: sql
 ms.prod_service: high-availability
 ms.reviewer: ""
@@ -24,14 +24,16 @@ manager: craigg
 # Transactions - availability groups and database mirroring
 [!INCLUDE[appliesto-ss-xxxx-xxxx-xxx-md](../../../includes/appliesto-ss-xxxx-xxxx-xxx-md.md)]
 
-This topic describes cross-database and distributed transactions support for Always On availability groups and database mirroring.  
+This article describes cross-database and distributed transactions support for Always On availability groups and database mirroring.  
 
 ## Support for distributed transactions
 
 SQL Server 2017 supports distributed transactions for databases in availability groups. This support includes databases on the same instance of SQL Server or databases on different instances of SQL Server. Distributed transactions are not supported for databases configured for database mirroring.
 
 >[!NOTE]
->[!INCLUDE[SQL Server 2016]](../../../includes/sssql15-md.md)]SQL Server 2016 included limited support for distributed transactions in for databases in an availability group. Distributed transactions using databases in an availability group were supported as long as no other databases in the transaction were in the same instance of SQL Server. For more information, see [SQL Server 2016 DTC Support In Availability Groups](http://blogs.technet.microsoft.com/dataplatform/2016/01/25/sql-server-2016-dtc-support-in-availability-gr)
+>[!INCLUDE[SQL Server 2016]](../../../includes/sssql15-md.md)] Service Pack 2 and later provides full support for distributed transactions in availability groups. 
+>
+>In [!INCLUDE[SQL Server 2016]](../../../includes/sssql15-md.md)] versions prior to Service Pack 2, cross-database distributed transactions (i.e. transaction using databases on the same SQL Server instance) involving a database in an availability group are not supported.
 
 To configure an availability group for distributed transactions, see [Configure Availability Group for Distributed Transactions](configure-availability-group-for-distributed-transactions.md).
 
@@ -41,33 +43,33 @@ See more information at:
 - [DTC Developers Guide](http://msdn.microsoft.com/library/ms679938.aspx)
 - [DTC Programmers Reference](http://msdn.microsoft.com/library/ms686108.aspx)
 
-## SQL Server 2016 and before: Support for cross-database transactions within the same SQL Server instance  
+## SQL Server 2016 SP1 and before: Support for cross-database transactions within the same SQL Server instance  
 
-In SQL Server 2016 and before, cross-database transactions within the same SQL Server instance are not supported for availability groups. This means that no two databases in a cross-database transaction may be hosted by the same SQL Server instance. This is true even if those databases are part of the same availability group.  
+In SQL Server 2016 SP1 and before, cross-database transactions within the same SQL Server instance are not supported for availability groups. No two databases in a cross-database transaction may be hosted by the same SQL Server instance if either or both databases are in an availability group. This limitation also applies when those databases are part of the same availability group.  
   
 Cross-database transactions are also not supported for database mirroring.  
   
-##  <a name="dtcsupport"></a> SQL Server 2016: Support for distributed transactions  
-Distributed transactions are supported with availability groups. This applies to distributed transactions between databases hosted by two different SQL Server instances. It also applies to distributed transactions between SQL Server and another DTC-compliant server.  
+##  <a name="dtcsupport"></a> SQL Server 2016 SP1 and before: Support for distributed transactions  
+Distributed transactions are supported with availability groups when databases are hosted by different SQL Server instances. It also applies to distributed transactions between SQL Server instances and other DTC-compliant server.  
  
-Microsoft Distributed Transaction Coordinator (MSDTC or DTC) is a Windows service that provides transaction infrastructure for distributed systems. MSDTC permits client applications to include multiple data sources in one transaction which then is committed across all servers included in the transaction. For example, you can use MSDTC to coordinate transactions that span multiple databases on different servers.
+Microsoft Distributed Transaction Coordinator (MSDTC or DTC) is a Windows service that provides transaction infrastructure for distributed systems. MSDTC permits client applications to include multiple data sources in one transaction, which then is committed across all servers included in the transaction. For example, you can use MSDTC to coordinate transactions that span multiple databases on different servers.
 
 SQL Server 2016 introduces the capability to use distributed transactions where one or more of the databases in the transaction are in an availability group. Prior to SQL Server 2016 distributed transactions were not supported for databases in availability groups. SQL Server 2016 can register a resource manager per database. This new capability is why distributed transactions can include databases in availability groups.
   
  The following requirements must be met:  
   
--   Availability groups must be running on Windows Server 2016 or Windows Server 2012 R2. For Windows Server 2012 R2, you must install the update in KB3090973 available at [https://support.microsoft.com/en-us/kb/3090973](https://support.microsoft.com/en-us/kb/3090973).  
+-   Availability groups must be running on Windows Server 2012 R2 or later. For Windows Server 2012 R2, you must install the update in KB3090973 available at [https://support.microsoft.com/en-us/kb/3090973](https://support.microsoft.com/en-us/kb/3090973).  
   
 -   Availability groups must be created with the **CREATE AVAILABILITY GROUP** command and the **WITH DTC\_SUPPORT = PER_DB** clause. You cannot currently alter an existing availability group.  
 
-- All instances of SQL Server  that will participate in the availability group must be SQL Server 2016 or later.
+- All instances of SQL Server that participate in the availability group must be SQL Server 2016 or later.
  
  ## Non-support for distributed transactions
  Specific cases where distributed transactions are not supported include:
  
- - In SQL Server 2016 and prior, where more than one database involved in the transaction is in the same availability group.
+ - In SQL Server 2016 SP1 and prior, where more than one database involved in the transaction is in the same availability group.
  
- - In SQL Server 2016 and prior, where at least one database is in an availability group and another database is on the same instance of SQL Server. 
+ - In SQL Server 2016 SP1 and prior, where at least one database is in an availability group and another database is on the same instance of SQL Server. 
  
  - Where the availability group was not created with enable distributed transaction.
  
@@ -79,12 +81,12 @@ SQL Server 2016 introduces the capability to use distributed transactions where
 ## Example scenario with database mirroring  
  The following database mirroring example illustrates how a logical inconsistency could occur. In this example, an application uses a cross-database transaction to insert two rows of data: one row is inserted into a table in a mirrored database, A, and the other row is inserted into a table in another database, B. Database A is being mirrored in high-safety mode with automatic failover. While the transaction is being committed, database A becomes unavailable, and the mirroring session automatically fails over to the mirror of database A.  
   
- After the failover, the cross-database transaction might be successfully committed on database B but not on the failed-over database. This would occur if the original principal server for database A had not sent the log for the cross-database transaction to the mirror server before the failure. After the failover, that transaction would not exist on the new principal server. Databases A and B would become inconsistent, because the data inserted in database B remains intact, but the data inserted in database A has been lost.  
+ After the failover, the cross-database transaction might be successfully committed on database B but not on the failed-over database. For example, if the original principal server for database A had not sent the log for the cross-database transaction to the mirror server before the failure. After the failover, that transaction would not exist on the new principal server. Databases A and B would become inconsistent, because the data inserted in database B remains intact, but the data inserted in database A has been lost.  
   
- A similar scenario can occur while using a MS DTC transaction. For example, after failover, the new principal contacts MS DTC. But MS DTC has no knowledge of the new principal server, and it terminates any transactions that are "preparing to commit," which are considered committed in other databases.  
+ A similar scenario can occur while using an MS DTC transaction. For example, after failover, the new principal contacts MS DTC. But MS DTC has no knowledge of the new principal server, and it terminates any transactions that are "preparing to commit," which are considered committed in other databases.  
   
 > [!NOTE]  
->  Using Database Mirroring with DTC or using availability groups with DTC in ways not approved in this topic is not supported.  This does not imply that aspects of the product unrelated to DTC are unsupported; however, any issues arising from the improper use of distributed transactions will not be supported.  
+>  Using Database Mirroring with DTC or using availability groups with DTC in ways not approved in this article is not supported.  This does not imply that aspects of the product unrelated to DTC are unsupported; however, any issues arising from the improper use of distributed transactions are not supported.  
   
 ## Next steps  
  [Always On availability groups: Interoperability &#40;SQL Server&#41;](../../../database-engine/availability-groups/windows/always-on-availability-groups-interoperability-sql-server.md)  
diff --git a/docs/integration-services/packages/run-integration-services-ssis-packages.md b/docs/integration-services/packages/run-integration-services-ssis-packages.md
@@ -30,6 +30,9 @@ manager: craigg
 ---
 # Run Integration Services (SSIS) Packages
   To run an [!INCLUDE[ssISnoversion](../../includes/ssisnoversion-md.md)] package, you can use one of several tools depending on where those packages are stored. The tools are listed in the table below.  
+
+> [!NOTE]
+> With the release of SQL Server for Linux, you can run SSIS packages on Linux. For more info, see [Extract, transform, and load data on Linux with SSIS](../../linux/sql-server-linux-migrate-ssis.md).
   
  To store a package on the [!INCLUDE[ssISnoversion](../../includes/ssisnoversion-md.md)] server, you use the project deployment model to deploy the project to the server. For information, see [Deploy Integration Services (SSIS) Projects and Packages](../../integration-services/packages/deploy-integration-services-ssis-projects-and-packages.md).  
   
diff --git a/docs/relational-databases/performance/TOC.md b/docs/relational-databases/performance/TOC.md
@@ -2,9 +2,10 @@
 # [Performance Center for SQL Server Database Engine and Azure SQL Database](performance-center-for-sql-server-database-engine-and-azure-sql-database.md)  
 # [Configuring Storage Spaces with a NVDIMM-N write-back cache](configuring-storage-spaces-with-a-nvdimm-n-write-back-cache.md)  
 
-# [Adaptive Query Processing](adaptive-query-processing.md)
 # [Automatic Tuning](../automatic-tuning/automatic-tuning.md)
 # [Cardinality Estimation](cardinality-estimation-sql-server.md)  
+# [Intelligent Query Processing](intelligent-query-processing.md)
+## [Adaptive Query Processing](adaptive-query-processing.md)
 
 # [Monitor and Tune for Performance](monitor-and-tune-for-performance.md)  
 ## [Monitor SQL Server Components](monitor-sql-server-components.md)  
diff --git a/docs/relational-databases/performance/intelligent-query-processing.md b/docs/relational-databases/performance/intelligent-query-processing.md
@@ -0,0 +1,38 @@
+---
+title: "Intelligent query processing in Microsoft SQL databases | Microsoft Docs"
+description: "Intelligent query processing features to improve query performance in SQL Server and Azure SQL Database."
+ms.custom: ""
+ms.date: "05/22/2018"
+ms.prod: sql
+ms.prod_service: "database-engine, sql-database"
+ms.reviewer: ""
+ms.suite: "sql"
+ms.technology: 
+ms.tgt_pltfrm: ""
+ms.topic: conceptual
+helpviewer_keywords: 
+ms.assetid: 
+author: "joesackmsft"
+ms.author: "josack"
+manager: craigg
+monikerRange: "= azuresqldb-current || >= sql-server-2016 || = sqlallproducts-allversions"
+---
+# Intelligent query processing in SQL databases
+[!INCLUDE[appliesto-ss-asdb-xxxx-xxx-md](../../includes/appliesto-xx-asdb-xxxx-xxx-md.md)]
+
+The **Intelligent query processing** feature family contains features with broad impact that improve performance of existing workloads with minimal implementation effort.   This includes improvements of pre-existing constructs and also the introduction of adaptive methods and capabilities.  
+
+## Adaptive query processing
+Within the intelligent query processing feature family is the adaptive query processing feature family introduced in SQL Server 2017 and Azure SQL Database which added overall new query processing capabilities that adapt optimization strategies to your application workload’s runtime conditions:
+- **Batch mode adaptive joins**. This feature allows your plan to dynamically switch to a better join strategy during execution using a single cached plan.
+- **Batch mode memory grant feedback**. This feature recalculates the actual memory required for a query and then updates the grant value for the cached plan, reducing excessive memory grants that impact concurrency and fixing underestimated memory grants that cause expensive spills to disk.
+- **Interleaved execution for multi-statement table valued functions (MSTVFs)**. With interleaved execution, we use the actual row counts from the function to make better-informed downstream query plan decisions. 
+
+For more information about adaptive query processing, refer to the [Adaptive query processing in SQL databases](../../relational-databases/performance/adaptive-query-processing.md).
+
+## See also
+[Performance Center for SQL Server Database Engine and Azure SQL Database](../../relational-databases/performance/performance-center-for-sql-server-database-engine-and-azure-sql-database.md)     
+[Query Processing Architecture Guide](../../relational-databases/query-processing-architecture-guide.md)    
+[Showplan Logical and Physical Operators Reference](../../relational-databases/showplan-logical-and-physical-operators-reference.md)    
+[Joins](../../relational-databases/performance/joins.md)    
+[Demonstrating Adaptive Query Processing](https://github.com/joesackmsft/Conferences/blob/master/Data_AMP_Detroit_2017/Demos/AQP_Demo_ReadMe.md)        
