Merge pull request #23613 from rwestMSFT/rw-0808-includes-in-memory-oltp

[Bulk] INCLUDE file maintenance: in-memory OLTP

Author: LJSpiller

docs/includes/hek-1-md.md

@@ -48,7 +48,7 @@ ms.author: mathoma
 
      Online piecemeal restores can involve deferred transactions. When only a subset of filegroups has been restored, transactions in the database that depend on online filegroups might become deferred. This is typical, because the whole database must be consistent. For more information, see [Deferred Transactions (SQL Server)](../../relational-databases/backup-restore/deferred-transactions-sql-server.md).  
 
--   [!INCLUDE[hek_1](../../includes/hek-1-md.md)] piecemeal restore scenario  
+-   [!INCLUDE[inmemory-md](../../includes/inmemory-md.md)] piecemeal restore scenario  
 
      For information on Piecemeal Restores of In-Memory OLTP databases see [Piecemeal Backup and Restore of Databases With Memory-Optimized Tables](../../relational-databases/in-memory-oltp/piecemeal-restore-of-databases-with-memory-optimized-tables.md).  
 

docs/includes/hek-2-md.md docs/includes/inmemory-md.mddocs/includes/hek-2-md.md renamed to docs/includes/inmemory-md.md

@@ -41,7 +41,7 @@ However, the following [!INCLUDE[tsql](../../includes/tsql-md.md)] constructs ar
 
 ## Table Hints
 
-For more information about table hints, see. [Table Hints (Transact-SQL)](../../t-sql/queries/hints-transact-sql-table.md). The SNAPSHOT was added to support [!INCLUDE[hek_2](../../includes/hek-2-md.md)].  
+For more information about table hints, see. [Table Hints (Transact-SQL)](../../t-sql/queries/hints-transact-sql-table.md). The SNAPSHOT was added to support [!INCLUDE[inmemory](../../includes/inmemory-md.md)].  
 
 The following table hints are not supported when accessing a memory-optimized table using interpreted [!INCLUDE[tsql](../../includes/tsql-md.md)].  
 

docs/relational-databases/backup-restore/piecemeal-restores-sql-server.md

@@ -17,7 +17,7 @@ monikerRange: "=azuresqldb-current||>=sql-server-2016||>=sql-server-linux-2017||
 
 [!INCLUDE [SQL Server Azure SQL Database Azure SQL Managed Instance](../../includes/applies-to-version/sql-asdb-asdbmi.md)]
 
-[!INCLUDE[hek_2](../../includes/hek-2-md.md)] supports an application design pattern that lavishes performance resources on relatively current data. This pattern can apply when current data is read or updated far more frequently than older data is. In this case, we say the current data is *active* or *hot*, and the older data is *cold*.
+[!INCLUDE[inmemory](../../includes/inmemory-md.md)] supports an application design pattern that lavishes performance resources on relatively current data. This pattern can apply when current data is read or updated far more frequently than older data is. In this case, we say the current data is *active* or *hot*, and the older data is *cold*.
 
 The main idea is to store *hot* data in a memory-optimized table. On a weekly or monthly basis, older data that has become *cold* is moved to a partitioned table. The partitioned table has its data stored on a disk or other hard drive, not in memory.
 

docs/relational-databases/in-memory-oltp/accessing-memory-optimized-tables-using-interpreted-transact-sql.md

@@ -157,9 +157,9 @@ GO
 ```  
 
 ##  <a name="bkmk_PercentAvailable"></a> Percent of memory available for memory-optimized tables and indexes  
- If you map a database with memory-optimized tables and a [!INCLUDE[ssNoVersion](../../includes/ssnoversion-md.md)] workload to the same resource pool, the Resource Governor sets an internal threshold for [!INCLUDE[hek_2](../../includes/hek-2-md.md)] use so that the users of the pool do not have conflicts over pool usage. Generally speaking, the threshold for [!INCLUDE[hek_2](../../includes/hek-2-md.md)] use is about 80% of the pool. The following table shows actual thresholds for various memory sizes.  
+ If you map a database with memory-optimized tables and a [!INCLUDE[ssNoVersion](../../includes/ssnoversion-md.md)] workload to the same resource pool, the Resource Governor sets an internal threshold for [!INCLUDE[inmemory](../../includes/inmemory-md.md)] use so that the users of the pool do not have conflicts over pool usage. Generally speaking, the threshold for [!INCLUDE[inmemory](../../includes/inmemory-md.md)] use is about 80% of the pool. The following table shows actual thresholds for various memory sizes.  
 
- When you create a dedicated resource pool for the [!INCLUDE[hek_2](../../includes/hek-2-md.md)] database, you need to estimate how much physical memory you need for the in-memory tables after accounting for row versions and data growth. Once you estimate the memory needed, you create a resource pool with a percent of the commit target memory for SQL Instance as reflected by column 'committed_target_kb' in the DMV [`sys.dm_os_sys_info`](../../relational-databases/system-dynamic-management-views/sys-dm-os-sys-info-transact-sql.md). For example, you can create a resource pool P1 with 40% of the total memory available to the instance. Out of this 40%, the [!INCLUDE[hek_2](../../includes/hek-2-md.md)] engine gets a smaller percent to store [!INCLUDE[hek_2](../../includes/hek-2-md.md)] data.  This is done to make sure [!INCLUDE[hek_2](../../includes/hek-2-md.md)] does not consume all the memory from this pool.  This value of the smaller percent depends upon the Target committed Memory. The following table describes memory available to [!INCLUDE[hek_2](../../includes/hek-2-md.md)] database in a resource pool (named or default) before an OOM error is raised.  
+ When you create a dedicated resource pool for the [!INCLUDE[inmemory](../../includes/inmemory-md.md)] database, you need to estimate how much physical memory you need for the in-memory tables after accounting for row versions and data growth. Once you estimate the memory needed, you create a resource pool with a percent of the commit target memory for SQL Instance as reflected by column 'committed_target_kb' in the DMV [`sys.dm_os_sys_info`](../../relational-databases/system-dynamic-management-views/sys-dm-os-sys-info-transact-sql.md). For example, you can create a resource pool P1 with 40% of the total memory available to the instance. Out of this 40%, the [!INCLUDE[inmemory](../../includes/inmemory-md.md)] engine gets a smaller percent to store [!INCLUDE[inmemory](../../includes/inmemory-md.md)] data.  This is done to make sure [!INCLUDE[inmemory](../../includes/inmemory-md.md)] does not consume all the memory from this pool.  This value of the smaller percent depends upon the Target committed Memory. The following table describes memory available to [!INCLUDE[inmemory](../../includes/inmemory-md.md)] database in a resource pool (named or default) before an OOM error is raised.  
 
 |Target Committed Memory|Percent available for in-memory tables|  
 |-----------------------------|---------------------------------------------|  
@@ -169,7 +169,7 @@ GO
 |\<= 96 GB|85%|  
 |>96 GB|90%|  
 
- For example, if your 'target committed memory' is 100 GB, and you estimate your memory-optimized tables and indexes need 60GB of memory, then you can create a resource pool with MAX_MEMORY_PERCENT = 67 (60GB needed / 0.90 = 66.667GB - round up to 67GB; 67GB / 100GB installed = 67%) to ensure that your [!INCLUDE[hek_2](../../includes/hek-2-md.md)] objects have the 60GB they need.  
+ For example, if your 'target committed memory' is 100 GB, and you estimate your memory-optimized tables and indexes need 60GB of memory, then you can create a resource pool with MAX_MEMORY_PERCENT = 67 (60GB needed / 0.90 = 66.667GB - round up to 67GB; 67GB / 100GB installed = 67%) to ensure that your [!INCLUDE[inmemory](../../includes/inmemory-md.md)] objects have the 60GB they need.  
 
  Once a database has been bound to a named resource pool, use the following query to see memory allocations across different resource pools.  
 

docs/relational-databases/in-memory-oltp/application-pattern-for-partitioning-memory-optimized-tables.md

@@ -23,7 +23,7 @@ After you determine the size, you must provide disk space sufficient to hold the
 A good starting point for sizing storage for this area is to reserve four times the size of durable, in-memory tables. Monitor the space usage and be prepared to expand the storage that's available to it if necessary.
 
 ## Storage IOPS  
- [!INCLUDE[hek_2](../../includes/hek-2-md.md)] can significantly increase your workload throughput. Therefore, it is important to ensure that IO is not a bottleneck.  
+ [!INCLUDE[inmemory](../../includes/inmemory-md.md)] can significantly increase your workload throughput. Therefore, it is important to ensure that IO is not a bottleneck.  
 
 -   When migrating disk-based tables to memory-optimized tables, make sure that the transaction log is on a storage media that can support increased transaction log activity. For example, if your storage media supports transaction log operations at 100 MB/sec, and memory-optimized tables result in five times greater performance, the transaction log's storage media must be able to also support five times performance improvement, to prevent the transaction log activity from becoming a performance bottleneck.  
 

docs/relational-databases/in-memory-oltp/bind-a-database-with-memory-optimized-tables-to-a-resource-pool.md

@@ -15,7 +15,7 @@ monikerRange: "=azuresqldb-current||>=sql-server-2016||>=sql-server-linux-2017||
 # Creating and Managing Storage for Memory-Optimized Objects
 [!INCLUDE [SQL Server Azure SQL Database Azure SQL Managed Instance](../../includes/applies-to-version/sql-asdb-asdbmi.md)]
 
-  The [!INCLUDE[hek_2](../../includes/hek-2-md.md)] engine is integrated into [!INCLUDE[ssNoVersion](../../includes/ssnoversion-md.md)], which lets you have both memory-optimized tables and (traditional) disk-based tables in the same database. However, the storage structure for memory-optimized tables is different from disk-based tables.  
+  The [!INCLUDE[inmemory](../../includes/inmemory-md.md)] engine is integrated into [!INCLUDE[ssNoVersion](../../includes/ssnoversion-md.md)], which lets you have both memory-optimized tables and (traditional) disk-based tables in the same database. However, the storage structure for memory-optimized tables is different from disk-based tables.  
 
  Storage for disk-based table has following key attributes:  
 

docs/relational-databases/in-memory-oltp/configuring-storage-for-memory-optimized-tables.md

@@ -13,12 +13,12 @@ ms.assetid: d304c94d-3ab4-47b0-905d-3c8c2aba9db6
 # Durability for Memory-Optimized Tables
  [!INCLUDE [SQL Server](../../includes/applies-to-version/sqlserver.md)]
 
-  [!INCLUDE[hek_2](../../includes/hek-2-md.md)] provides full durability for memory-optimized tables. When a transaction that changed a memory-optimized table commits, [!INCLUDE[ssNoVersion](../../includes/ssnoversion-md.md)] (as it does for disk-based tables), guarantees that the changes are permanent (will survive a database restart), provided the underlying storage is available. There are two key components of durability: transaction logging and persisting data changes to on-disk storage.  
+  [!INCLUDE[inmemory](../../includes/inmemory-md.md)] provides full durability for memory-optimized tables. When a transaction that changed a memory-optimized table commits, [!INCLUDE[ssNoVersion](../../includes/ssnoversion-md.md)] (as it does for disk-based tables), guarantees that the changes are permanent (will survive a database restart), provided the underlying storage is available. There are two key components of durability: transaction logging and persisting data changes to on-disk storage.  
 
  For details on any size limitations for durable tables see [Estimate Memory Requirements for Memory-Optimized Tables](../../relational-databases/in-memory-oltp/estimate-memory-requirements-for-memory-optimized-tables.md). 
 
 ## Transaction Log  
- All changes made to disk-based tables or durable memory-optimized tables are captured in one or more transaction log records. When a transaction commits, [!INCLUDE[ssNoVersion](../../includes/ssnoversion-md.md)] writes the log records associated with the transaction to disk before communicating to the application or user session that the transaction has committed. This guarantees that changes made by the transaction are durable. The transaction log for memory-optimized tables is fully integrated with the same log stream used by disk-based tables. This integration allows existing transaction log backup, recover, and restore operations to continue to work without requiring any additional steps. However, since [!INCLUDE[hek_2](../../includes/hek-2-md.md)] can increase transaction throughput of your workload significantly, log IO may become a performance bottleneck. To sustain this increased throughput, ensure the log IO subsystem can handle the increased load.  
+ All changes made to disk-based tables or durable memory-optimized tables are captured in one or more transaction log records. When a transaction commits, [!INCLUDE[ssNoVersion](../../includes/ssnoversion-md.md)] writes the log records associated with the transaction to disk before communicating to the application or user session that the transaction has committed. This guarantees that changes made by the transaction are durable. The transaction log for memory-optimized tables is fully integrated with the same log stream used by disk-based tables. This integration allows existing transaction log backup, recover, and restore operations to continue to work without requiring any additional steps. However, since [!INCLUDE[inmemory](../../includes/inmemory-md.md)] can increase transaction throughput of your workload significantly, log IO may become a performance bottleneck. To sustain this increased throughput, ensure the log IO subsystem can handle the increased load.  
 
 ## Data and Delta Files  
  The data in memory-optimized tables is stored as free-form data rows in an in-memory heap data structure, and are linked through one or more indexes in memory. There are no page structures for data rows, such as those used for disk-based tables. For long term persistence and to allow truncation of the transction log, operations on memory-optimized tables are persisted in a set of data and delta files. These files are generated based on the transaction log, using an asynchronous background process. The data and delta files are located in one or more containers (using the same mechanism used for FILESTREAM data). These containers are part of a memory-optimized filegroup.  

docs/relational-databases/in-memory-oltp/creating-and-managing-storage-for-memory-optimized-objects.md

@@ -17,7 +17,7 @@ monikerRange: "=azuresqldb-current||>=sql-server-2016||>=sql-server-linux-2017||
 
 Memory-optimized tables require that sufficient memory exist to keep all of the rows and indexes in memory. Because memory is a finite resource, it's important that you understand and manage memory usage on your system. The topics in this section cover common memory use and management scenarios.
 
-Whether you're creating a new memory-optimized table or migrating an existing disk-based table to an [!INCLUDE[hek_2](../../includes/hek-2-md.md)] memory-optimized table, it's important to have a reasonable estimate of each table's memory needs so you can provision the server with sufficient memory. This section describes how to estimate the amount of memory that you need to hold data for a memory-optimized table.  
+Whether you're creating a new memory-optimized table or migrating an existing disk-based table to an [!INCLUDE[inmemory](../../includes/inmemory-md.md)] memory-optimized table, it's important to have a reasonable estimate of each table's memory needs so you can provision the server with sufficient memory. This section describes how to estimate the amount of memory that you need to hold data for a memory-optimized table.  
 
 If you're contemplating migrating from disk-based tables to memory-optimized tables, before you proceed in this topic, see the topic [Determining if a Table or Stored Procedure Should Be Ported to In-Memory OLTP](../../relational-databases/in-memory-oltp/determining-if-a-table-or-stored-procedure-should-be-ported-to-in-memory-oltp.md) for guidance on which tables are best to migrate. All the topics under [Migrating to In-Memory OLTP](./plan-your-adoption-of-in-memory-oltp-features-in-sql-server.md) provide guidance on migrating from disk-based to memory-optimized tables. 
 
@@ -125,7 +125,7 @@ SELECT COUNT(DISTINCT [Col2])
 
 If you're creating a new table, you'll need to estimate the array size or gather data from your testing prior to deployment.  
 
-For information on how hash indexes work in [!INCLUDE[hek_2](../../includes/hek-2-md.md)] memory-optimized tables, see [Hash Indexes](/previous-versions/sql/sql-server-2016/dn133190(v=sql.130)).  
+For information on how hash indexes work in [!INCLUDE[inmemory](../../includes/inmemory-md.md)] memory-optimized tables, see [Hash Indexes](/previous-versions/sql/sql-server-2016/dn133190(v=sql.130)).  
 
 #### Setting the hash index array size