1. In-Memory Optimization (OLTP) enhancements overview
Mission-critical performance with Microsoft SQL Server 2016
Speaker Name

2. 6/5/2018 4:35 PM
Learning objectives
Overview of In-Memory OLTP Enhancements to In-Memory OLTP Benefits and best practices In-Memory OLTP hands-on lab
© 2013 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

3. Overview of In-Memory OLTP

4. Why In-Memory OLTP?
Customers are demanding ever-higher concurrency and lower latency, at a lower cost
Hardware trends demand architectural changes to the relational database management system (RDBMS) to meet those demands
In-Memory Online Transaction Processing (OLTP), a key new feature of SQL Server 2016, offers:
High performance
Memory-optimized OLTP engine
SQL Server integration
Modern hardware architecture
Objective: This slide describes the design considerations and purpose for developing the In-Memory OLTP by SQL Server.
Talking points:
The move to produce a true main-memory database has been driven by two basic motivating trends and needs, including:
Market demands for lower latency time and high concurrency for data operations, and specialized workload like In-Memory OLTP.
Demands from recent hardware changes that allow fitting most or all of the data required by a workload into main memory, requiring specialized database engines that target specific types of workloads need to be tuned just for those workloads.
SQL Server was originally designed at a time when it could be assumed that main memory was very expensive, so data needed to reside on disk except when it was needed for processing. This assumption is no longer valid, as memory prices have dropped enormously over the last 30 years. At the same time, multi-core servers have become affordable, so that today one can buy a server with 32 cores and 1 TB of memory for under $50,000. Since many, if not most, of the OLTP databases in production can fit entirely in 1 TB, we need to re-evaluate the benefit of storing data on disk and incurring the I/O expense when the data needs to be read into memory to be processed.
In addition, OLTP databases also incur expenses when this data is updated and needs to be written back out to disk. If reading from disk isn’t required, the optimizer can use a different costing algorithm. In addition, if there is no wait time required for disk reads, other wait statistics―such as waiting for locks to be released, waiting for latches to be available, or waiting for log writes to complete―can become disproportionately large. In- Memory OLTP addresses all of these issues. In-Memory OLTP removes the issues of waiting for locks to be released, using a new type of multi-version optimistic concurrency control. Hence latency and concurrency improves a lot with these In-Memory OLTP architectural changes.

5. Why In-Memory OLTP? (continued)
6/5/2018 4:35 PM
Why In-Memory OLTP? (continued)
In-Memory OLTP is a memory-optimized database engine integrated into the SQL Server engine, optimized for OLTP, that can significantly improve database application performance
Features of In-Memory OLTP include:
Memory-optimized tables
Natively compiled stored procedures
Objective: This slide introduces SQL Server In-Memory OLTP and its feature sets.
Talking points:
In-Memory OLTP is the in-memory processing technology from Microsoft. It can significantly improve OLTP database application performance. In-Memory OLTP is a memory-optimized database engine integrated into the SQL Server engine, and can be used in the exact same manner as any other database engine component.
In-Memory OLTP originally shipped with SQL Server 2014 and features two new data structures, including memory-optimized tables and natively compiled stored procedures.
Memory-optimized tables
Memory-optimized tables store their data into memory using multiple versions of the data from each row. Memory-optimized tables are fully transactional, durable, and are accessed using Transact-SQL in the same manner as disk-based tables. A query can reference both memory-optimized and disk-based tables. A transaction can update data in memory-optimized and disk-based tables. (This will be discussed more on the next slide.)
Natively compiled stored procedures
A natively compiled stored procedure is a SQL Server object that can access only memory-optimized data structures such as memory-optimized tables, table variables, etc. SQL Server can natively compile stored procedures that access memory-optimized tables. Native compilation allows faster data access and more efficient query execution than interpreted (traditional) Transact-SQL.
Natively compiled stored procedures are parsed and compiled when they are loaded to native DLLs. This is in contrast to other stored procedures which are compiled on first run, have an execution plan created and reused, and use an interpreter for execution. (This will be discussed more on the next slide.)
© 2013 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

6. Why In-Memory OLTP? (continued)
6/5/2018 4:35 PM
Why In-Memory OLTP? (continued)
Memory-optimized table
A memory-optimized table has one representation of itself in active memory, in addition to standard representation on hard drive
Business transactions against a table run faster because they directly interact with only representation in active memory
Natively compiled stored procedures
A natively compiled stored procedure is a SQL Server object that can access only memory-optimized data structures (memory-optimized tables, table variables, etc.)
Natively compiled stored procedures require fewer machine instructions during runtime than they would if they were created as traditional interpreted stored procedures
Objective: This slide gives more insight on memory-optimized tables and natively compiled stored procedures.
Talking point:
The features of In-Memory OLTP include memory-optimized tables and natively compiled stored procedures.
A memory-optimized table has one representation of itself in active memory, in addition to the standard representation on a hard drive. Business transactions against the table run faster because they directly interact with only the representation that is in active memory. The main features of a memory-optimized table are:
Rows in tables are read from, and written to, memory. The entire table resides in memory.
It uses latch-free data structures and optimistic, multi-version concurrency control.
It maintains a second copy on disk for durability (if enabled). Data in memory-optimized tables is only read from disk during database recovery. It is interoperable with disk-based tables.
A natively compiled stored procedure is a SQL Server object that can access only memory-optimized data structures such as memory-optimized tables, table variables, etc. Natively compiled stored procedures require fewer machine instructions during runtime than they would if they were created as traditional interpreted stored procedures. The main features of a natively compiled stored procedure are:
It is compiled to native code (DLL) upon its creation (the interpreted stored procedures are compiled at first execution).
Its aggressive optimization takes time during compilation.
It can only interact with memory-optimized tables.
The call to a natively compiled stored procedure is actually a call to its DLL entry point.
© 2013 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

7. In-Memory OLTP value proposition
Target scenarios: OLTP apps with high throughput and low-latency requirements
Extreme OLTP performance (up to 30x) due to two factors:
High scalability through lock- and latch-free architecture enables linear scaling
Low latency through efficient data access and query processing: memory-optimized data structures and native compilation
Integrated into SQL Server for low total cost of ownership (TCO)
Part of Enterprise Edition
Same databases can have in-memory and on-disk
Integrated developer and DBA experience: same T-SQL, client stack, tooling, backup/restore, AlwaysOn
Objective: This slide highlights the value proposition of In-Memory OLTP, such as high performance and low total cost of ownership (TCO).
Talking point:
The target scenario In-Memory OLTP includes OLTP apps with high throughput and low-latency requirements.
Extreme OLTP performance
SQL Server In-Memory OLTP is a new data-processing technology that allows a many-fold improvement in performance for OLTP applications that demands high throughput and low-latency. The In-Memory OLTP engine is designed for extremely high session concurrency for OLTP-type transactions driven from a highly scaled-out middle-tier. You can gain performance improvement up to 30x due to two factors:
It uses latch-free data structures and optimistic, multi-version concurrency control. The result is predictable, sub-millisecond low latency and high throughput with linear scaling for database transactions.
A transaction can update data in memory-optimized tables and disk-based tables. Stored procedures that only reference memory-optimized tables can be natively compiled into machine code for further performance improvements.
Integrated into SQL Server for low TCO
Another impressive thing about In-Memory OLTP is that it achieves breakthrough improvement in transactional processing capabilities without requiring a separate data management product or new programming model. It is still SQL Server!
This allows for an integrated developer and database administrator (DBA) experience with the same T-SQL, client stack, tooling, backup and restore, and AlwaysOn capabilities. By offering in-memory functionality within SQL Server, your total cost of ownership is lower than if you had to purchase, manage, and maintain a separate system for handling in-memory processing.

8. In-Memory OLTP enhancements
6/5/2018 4:35 PM
In-Memory OLTP enhancements
Better T-SQL coverage, including:
Full collations support in native modules
Query surface-area improvements
Nested stored procedures (EXECUTE)
Natively compiled scalar user-defined functions
Query Store support
Other improvements:
Full schema change support: add/alter/drop column/constraint
Increased size allowed for durable tables
ALTER TABLE support
Multiple Active Results Sets (MARS) support
ALTER TABLE Sales.SalesOrderDetail
ALTER INDEX PK_SalesOrderID
REBUILD
WITH (BUCKET_COUNT= )
T-SQL surface area: New
{LEFT|RIGHT} OUTER JOIN
Disjunction (OR, NOT)
UNION [ALL]
SELECT DISTINCT
Subqueries (EXISTS, IN, scalar)
Objective: This slide highlights the In-Memory OLTP enhancements in SQL Server 2016.
Talking points
In-Memory OLTP was introduced in SQL Server 2014 and has been enhanced for SQL Server You will find numerous enhancements to the technology, with some limitations removed. Many of these changes are described below. We will talk more on this in the coming slides:
SQL Server 2014 does not allow any changes to memory-optimized tables after creation. In SQL Server 2016, ALTER TABLE can be used on memory-optimized tables to add, drop, or alter columns, or to add, drop, or rebuild indexes.
SQL Server 2016 has better coverage of T-SQL query surface area, adding support for left outer joins, union all, and distinct syntax. It also includes support for the nesting of natively compiled stored procedures and other increases in the T-SQL surface area. Other T-SQL native compilation improvements include:
Full collations support in native modules
Natively compiled scalar user-defined functions (UDFs)
Access from both native and interop
Improved performance of scalar UDFs in traditional workloads, if no table access is required
Query Store support
Scaling has also been improved by including a large increase to the total size of durable tables and improved throughput, with increased socket availability and larger log generation capacity for AlwaysOn configuration.
Other improvements include:
T-SQL table improvements through:
Collations
Full collations support in index key columns
All code pages supported for (var)char columns
Constraints
FOREIGN KEY
CHECK
UNIQUE constraints
DML triggers on memory-optimized tables (AFTER; natively compiled)
Row-Level Security
Temporal tables (history is disk-based)
In-Memory OLTP now supports Multiple Active Result Sets (MARS) using queries, as well as parallel plans in interop for reporting queries and Transparent Data Encryption (TDE).
Enhancements also include support for the Transaction Performance Analysis report in SQL Server Management Studio to evaluate In-Memory OLTP and improve database application performance. You can access lightweight migration reports and checklists that show unsupported features used in current disk-based tables and interpreted T-SQL stored procedures.
© 2013 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

9. Enhancements to In-Memory OLTP

10. Altering memory-optimized tables
6/5/2018 4:35 PM
Altering memory-optimized tables
| ADD {
<column_definition>
| <table_constraint>
| <table_index>
} [ ,...n ]
| DROP
[ CONSTRAINT ]
constraint_name
| COLUMN
column_name
| INDEX
index_name
| ALTER INDEX index_name
REBUILD (WITH <rebuild_index_option>) }
<rebuild_index_option> ::=
BUCKET_COUNT = bucket_count )
ALTER TABLE syntax is used for making changes to table schema, as well as for adding, deleting, and rebuilding indexes
Indexes are considered part of table definition
Ability to change the BUCKET_COUNT with an ALTER INDEX statement
Objective: This slide shows one of the important enhancements in SQL Server 2016 in-memory technology. You can now perform ALTER operations on memory-optimized tables.
Talking points:
In SQL Server 2014, once a memory-optimized table was created, it needed to be dropped and recreated if a change was required. With SQL Server 2016, ALTER TABLE statements on index and schema changes are now supported. The database application can continue to run, and any operation that is accessing the table is blocked until the alteration process is completed. In the previous release of SQL Server, you had to manually complete several steps to update memory-optimized tables.
The ALTER TABLE syntax is used for making changes to the table schema, as well as for adding, deleting, and rebuilding indexes. Indexes are considered part of the table definition. The syntax ALTER TABLE … ADD/DROP/ALTER INDEX is supported only for memory-optimized tables. In SQL Server 2016, ALTER TABLE is an offline operation only.
One of the key advantages is that you can change the BUCKET_COUNT with an ALTER INDEX statement. A bucket count that is too high wastes memory while one that is too low hurts performance. So you can now adjust the BUCKET_COUNT as per the requirement.
© 2013 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

11. Altering natively compiled stored procedures
6/5/2018 4:35 PM
Altering natively compiled stored procedures
CREATE PROCEDURE [dbo].[usp_1]
WITH NATIVE_COMPILATION, SCHEMABINDING, EXECUTE AS OWNER
AS BEGIN ATOMIC WITH (
TRANSACTION ISOLATION LEVEL = SNAPSHOT, LANGUAGE = N'us_english' )
SELECT c1, c2 from dbo.T1
END GO
ALTER PROCEDURE [dbo].[usp_1]
SELECT c1 from dbo.T1
You can now perform ALTER operations on natively compiled stored procedures using ALTER PROCEDURE statement
Use sp_recompile to recompile stored procedures on next execution
Objective: This slide shows another enhancement, which is how you can now alter natively compiled stored procedures with SQL Server 2016.
Talking points:
In SQL Server 2016, you can perform ALTER operations on natively compiled stored procedures using the ALTER PROCEDURE statement. In the previous release of SQL Server, you had to complete manual steps to modify a natively compiled stored procedure.
When executing ALTER PROCEDURE on a natively compiled stored procedure, the procedure is recompiled using a new definition. While recompilation is in progress, the old version of the procedure continues to be available for execution. Once compilation completes, procedure executions are drained, and the new version of the procedure is installed.
You can execute sp_recompile on a natively compiled stored procedure, which causes the stored procedure to recompile on the next execution.
© 2013 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

12. Greater Transact-SQL coverage
6/5/2018 4:35 PM
Greater Transact-SQL coverage
CREATE PROCEDURE (Transact-SQL)
DROP PROCEDURE (Transact-SQL)
ALTER PROCEDURE (Transact-SQL)
SELECT (Transact-SQL) and INSERT SELECT statements
SCHEMABINDING and BEGIN ATOMIC (required for natively compiled stored procedures)
NATIVE_COMPILATION
Parameters and variables can be declared as NOT NULL
Table-valued parameters.
GRANT and DENY permissions on tables and procedures.
Nesting natively compiled stored procedures
RIGHT OUTER JOIN, LEFT OUTER JOIN, INNER JOIN, and CROSS JOIN in SELECT statements
NOT, OR, and IN operators in SELECT, UPDATE and DELETE statement
UNION ALL and UNION
SELECT DISTINCT
GROUP BY clause with no aggregate functions in the SELECT clause (<select> list).
COLUMNSTORE
COLLATE
Objective: This slide shows the new Transact-SQL coverage areas in SQL Server 2016 for In-Memory Optimization OLTP.
Talking Points: SQL Server 2016 also has almost full coverage of T-SQL query surface area, adding support for left outer joins, union all, and distinct syntax. Support for nesting of natively compiled stored procedures, and other increases in the Transact-SQL surface area. In SQL Server 2016 CTP2, natively compiled procedures will support a wider range of features, including the following constructs:
LEFT and RIGHT OUTER JOIN
SELECT DISTINCT
OR and NOT operators
Subqueries in all clauses of a SELECT statement
Nested stored procedure calls
UNION and UNION ALL
All built-in math functions
The list of full coverage of T-SQL query surface area in shown in the slide:
CREATE PROCEDURE (Transact-SQL)
DROP PROCEDURE (Transact-SQL)
ALTER PROCEDURE (Transact-SQL)
SELECT (Transact-SQL) and INSERT SELECT statements
SCHEMABINDING and BEGIN ATOMIC (required for natively compiled stored procedures)
NATIVE_COMPILATION
Parameters and variables can be declared as NOT NULL
Table-valued parameters.
EXECUTE AS OWNER, SELF, and user.
GRANT and DENY permissions on tables and procedures.
Nesting natively compiled stored procedures
RIGHT OUTER JOIN, LEFT OUTER JOIN, INNER JOIN, and CROSS JOIN in SELECT statements
NOT, OR, and IN operators in SELECT, UPDATE and DELETE statement
UNION ALL and UNION
GROUP BY clause with no aggregate functions in the SELECT clause (<select> list).
COLUMNSTORE
COLLATE
© 2013 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

13. Improved scaling Other enhancements include:
Multiple threads to persist memory-optimized tables
Multi-threaded recovery
MERGE operation
Dynamic management view improvements to sys.dm_db_xtp_checkpoint_stats and sys.dm_db_xtp_checkpoint_files
Objective: This slide shows scaling improvements done for the In-Memory OLTP engine in SQL Server 2016.
Talking points:
SQL Server 2014 had limited scalability with multiple socket machines. In SQL Server 2016, you can expect efficient scaling with a 4-socket machine. This is not due to particular features being changed or added, but just to improvements in the existing algorithms. This includes better partitioning of worktime queues and more capacity in the threads assigned to do garbage collection of the in-memory data.
Other scaling enhancements include:
Multiple threads to persist memory-optimized tables: In the previous release of SQL Server, a single offline checkpoint thread scanned the transaction log for changes to memory-optimized tables and persisted them in checkpoint files (such as data and delta files). With a larger number of COREs, the single offline checkpoint thread could fall behind. In SQL Server 2016, there are multiple concurrent threads responsible to persist changes to memory-optimized tables.
Multi-threaded recovery: In the previous release of SQL Server, the log apply was part of a single-threaded recovery operation. In SQL Server 2016, the log apply is multi-threaded.
MERGE operation: The MERGE operation is now multi-threaded.
Dynamic management views: sys.dm_db_xtp_checkpoint_stats (Transact-SQL) and sys.dm_db_xtp_checkpoint_files (Transact-SQL) have been changed significantly.
Note that Manual Merge has been disabled, as the multi-threaded merge is expected to keep up with the load.
The In-Memory OLTP engine continues to use a memory-optimized filegroup based on FILESTREAM, but the individual files in the filegroup are decoupled from FILESTREAM. These files are fully managed (such as for create, drop, and garbage collection) by the In-Memory OLTP engine. DBCC SHRINKFILE (Transact-SQL) is not supported.
Source:
Further benefits of the improved In-Memory OLTP engine include:
Optimize existing workloads without migration to memory-optimized tables: Use a tempdb replacement (using SCHEMA_ONLY tables and memory-optimized table variables) and speed up scalar UDF execution through native compilation.
Simplify your application architecture: In-Memory OLTP can potentially simplify your application architecture. For scaled-out implementations, you can typically reduce the number of shards, or potentially even consolidate all shards into one machine, with SQL Server For example, one customer was able to consolidate a deployment of 18 servers into one server using In-Memory OLTP, resulting in cost savings of up to $100,000 per year.
Eliminate the caching layer: If you are currently using a caching layer in your architecture because the database could not keep up with user requests, either there was not enough CPU, or there were locking/blocking issues. You can potentially eliminate this caching layer by using In-Memory OLTP, which uses less CPU to do the same work and removes locking/blocking issues through its lock-free architecture.
Source: sql2016-ctp3.aspx
The In-Memory OLTP engine has been enhanced to scale linearly on servers up to four sockets

14. Improvements in Management Studio
6/5/2018 4:35 PM
Improvements in Management Studio
Lightweight performance analysis
Transaction Performance Analysis report pinpoints hot spots in app
Migration checklists
Migration checklists show unsupported features used in current disk-based tables and interpreted T-SQL stored procedures
Generates checklists for all or some tables and procedures
Uses GUI or PowerShell
Objective: This slide shows enhancements in SSMS for In-Memory OLTP in SQL Server 2016.
Talking points:
Enhancements in SSMS for In-Memory OLTP include:
Support of Transaction Performance Analysis report in SSMS to evaluate In-Memory OLTP and improve your database application’s performance. The report also indicates how much work you must do to enable In-Memory OLTP in your application. The transaction analysis report no longer requires the configuration of data collectors or management data warehouse. The report can now run directly on a production database. Simply right-click the database and select Reports -> Standard Reports -> Transaction Performance Analysis Report.
Migration checklists show unsupported features used in current disk-based tables and interpreted T-SQL stored procedures. Checklists are generated for all or some tables and procedures. Generate migration checklists by right-clicking a database, and then selecting Tasks -> Generate In-Memory OLTP migration checklists.
You can also use PowerShell Cmdlet for Migration Evaluation for evaluating the migration fitness of multiple objects in a SQL Server database.
© 2013 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

15. New transaction performance analysis overview report
New report replaces need to use Management Data Warehouse to analyze which tables and stored procedures are candidates for In-Memory OLTP
Objective: This slide shows the support of Transaction Performance Analysis report in SSMS to evaluate In- Memory OLTP and improve your database application’s performance.
Talking points:
Note that in SQL Server 2014 you needed to set up a Management Data Warehouse (MDW) in order to run the In-Memory OLTP reports. SQL Server 2016 now includes lightweight reports available in SSMS without setting up the MDW. You can simply right-click the database and select Reports -> Standard Reports -> Transaction Performance Analysis Overview.
This presents you with a prioritized plot chart that graphs the amount of potential gain against the amount of potential work to migrate the top tables to In-Memory OLTP. This helps you see the highest potential gain, with the lowest potential amount of migration work required.
This report replaces the need to use the MDW to analyze which tables and stored procedures are candidates for In-Memory Optimization.

16. Using multiple active result sets
6/5/2018 4:35 PM
Using multiple active result sets
Setup MARS connection for memory optimized tables using MultipleActiveResultsSets=True in your connection string
Data Source=MSSQL; Initial Catalog=AdventureWorks; Integrated Security=SSPI; MultipleActiveResultSets=True
Objective: This slide shows the support of Multiple Active Result Sets (MARS) in In-Memory OLTP.
Talking points:
In earlier versions of SQL Server, database applications could not maintain multiple active statements on a connection. When using SQL Server default result sets, the application had to process or cancel all result sets from one batch before it could execute any other batch on that connection.
In-Memory OLTP supports MARS using queries and natively compiled stored procedures. MARS enables requesting data from multiple queries, without the need to completely retrieve each result set before sending a request to fetch rows from a new result set. To successfully read from multiple open result sets, one must use a MARS-enabled connection.
MARS is disabled by default, so you must explicitly enable it by adding MultipleActiveResultSets=True to a connection string. The example on the slide demonstrates how to connect to an instance of SQL Server and specify that MARS is enabled.
© 2013 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

17. Support for Transparent Data Encryption
Transparent Database Encryption (TDE) architecture
Windows Operating System
level-data protection
SQL Server
instance level
User database level
Database Encryption Key
Service Master Key
DPAPI encrypts Service Master Key
Master database level
Service Master Key encrypts Database Master Key for master database
Database Master Key of master database creates certificate in master database
Certificate encrypts Database Encryption Key in user database
Entire user database is secured by Database Encryption Key of user database with transparent database encryption
Created at time of SQL Server setup
Statement: CREATE MASTER KEY…
Statement: CREATE CERTIFICATE…
Statement: CREATE DATABASE ENCRYPTION KEY…
Statement: ALTER DATABASE… SET ENCRYPTION0.
In SQL Server 2016, storage for memory-optimized tables will be encrypted as part of enabling TDE on database
Simply follow same steps as you would for a disk-based database
Objective: This slide shows the support for TDE for memory-optimized tables in SQL Sever 2016.
Talking Points:
In SQL Server 2016, the storage for memory-optimized tables will be encrypted as part of enabling TDE on the database. In SQL Server 2014, an encryption-enabled database would not encrypt data stored on a MEMORY_OPTIMIZED_DATA filegroup. That limitation goes away in SQL Server 2016 and memory-optimized tables data on disk will be encrypted, following the same steps as you would do for a disk-based database:
Create a master key.
Create or obtain a certificate protected by the master key.
Create a database encryption key and protect it by the certificate.
Set the database to use encryption.

18. Benefits and best practices

19. 6/5/2018 4:35 PM
Benefits
This table summarizes workload patterns that may benefit most with In-Memory OLTP
Implementation scenario
Benefits of In-Memory OLTP
High-data insertion rate from multiple concurrent connections
Primarily append-only store
Unable to keep up with insert workload
Eliminate contention
Reduce logging
Read performance and scale with periodic batch inserts and updates
High-performance read operation, especially when each server request has multiple read operations to perform
Unable to meet scale-up requirements
Eliminate contention when new data arrives
Lower latency data retrieval
Minimize code execution time
Intensive business logic processing in database server
Insert, update, and delete workload
Intensive computation inside stored procedures
Read and write contention
Minimize code execution time for reduced latency and improved throughput
Low latency
Low-latency business transaction required, which typical database solutions can’t achieve
Low-latency code execution
Efficient data retrieval
Session state management
Frequent insert, update, and point lookups
High-scale load from numerous stateless web servers
Option IO reduction or removal, when using non-durables tables
Objective: This slide depicts the various scenarios in which In-Memory OLTP will result in the greatest performance gains.
Talking point:
The table summarizes those workload patterns that may benefit most by using In-Memory OLTP.
© 2013 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

20. Other benefits and best practices
6/5/2018 4:35 PM
Other benefits and best practices
When to use In-Memory OLTP to improve performance
Short-running transactions
Programming patterns including concurrency scenarios, point lookups, and workloads in which there are many inserts and updates, and business logic in stored procedures
How In-Memory OLTP improves performance and scalability
Optimized algorithms to access memory-resident data
Optimistic concurrency control that eliminates logical locks
Natively compiled stored procedures, with better performance than interpreted stored procedures for accessing memory-optimized tables
Objective: This slide highlights considerations and situations for In-Memory OLTP usage, and how to achieve significant performance and scalability gains.
Talking points:
Consider using In-Memory OLTP in the following situations:
In-Memory OLTP will improve performance best in OLTP with short-running transactions, including programming patterns such as concurrency scenarios, point lookups, and workloads in which there are many inserts and updates, and business logic in stored procedures.
Integration with SQL Server means you can have both memory-optimized tables and disk-based tables in the same database, and query across both types of tables.
In SQL Server 2014, limitations exist in the Transact-SQL surface area supported for In-Memory OLTP.
In-Memory OLTP achieves significant performance and scalability gains by using:
Optimized algorithms to access memory-resident data.
Optimistic concurrency control that eliminates logical locks.
Lock-free objects that eliminate all physical locks and latches (threads that perform transactional work don’t use locks or latches for concurrency control).
Natively compiled stored procedures, which have significantly better performance than interpreted stored procedures when accessing a memory-optimized table.
© 2013 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

21. Hands-on lab (HOL)

22. ESP Sales Presentation for Mobility
4/10/2013
© 2015 Microsoft Corporation. All rights reserved. Microsoft, Windows, Microsoft Azure, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION
Microsoft Corporation