The document discusses performance improvements in different versions of SQL Server using in-memory OLTP technologies. SQL Server 2012 saw 12,000 batch requests/second limited by latch contention. SQL Server 2014 improved to 300,000 requests/second using memory-optimized tables but was still CPU-bound. SQL Server 2016 achieved 1,200,000 requests/second using memory-optimized tables with LOB support and natively compiled stored procedures. A production system at Bwin saw similar performance gains moving from a 19-node caching solution to a single SQL Server 2016 node.

1. jodebrui@microsoft.com

2. Microsoft Confidential
Version SessionState Performance Technology Bottleneck
SQL Server 2012 12,000 batch requests/sec SQL Server Interpreted T-SQL Latch contentions
SQL Server 2014 300,000 batch requests/sec Memory-Optimized Table, Interpreted T-SQL,
Handling of Split LOBs
CPU
SQL Server 2016 1,200,000 batch requests/sec Memory-Optimized Table with LOB support,
Natively Compiled stored procedures
CPU
In-Memory OLTP performance (bwin)
Source: https://blogs.msdn.microsoft.com/sqlcat/2016/10/26/how-bwin-is-using-sql-server-2016-in-memory-oltp-to-achieve-unprecedented-performance-and-scale/
Version Cache System Performance Hardware nodes
Mid-Tier Cache solution without SQL Server 150,000 batch requests/sec 19
Solution using SQL Server 2016 1,200,000 batch requests/sec 1

3. Microsoft Confidential
Version SessionState Performance Technology Bottleneck
SQL Server 2012 12,000 batch requests/sec SQL Server Interpreted T-SQL Latch contentions
SQL Server 2014 300,000 batch requests/sec Memory-Optimized Table, Interpreted T-SQL,
Handling of Split LOBs
CPU
SQL Server 2016 1,200,000 batch requests/sec Memory-Optimized Table with LOB support,
Natively Compiled stored procedures
CPU
In-Memory OLTP performance (bwin)
Source: https://blogs.msdn.microsoft.com/sqlcat/2016/10/26/how-bwin-is-using-sql-server-2016-in-memory-oltp-to-achieve-unprecedented-performance-and-scale/
Version Cache System Performance Hardware nodes
Mid-Tier Cache solution without SQL Server 150,000 batch requests/sec 19
Solution using SQL Server 2016 1,200,000 batch requests/sec 1

7. CREATE TABLE [Customer](
[CustomerID] INT NOT NULL
PRIMARY KEY NONCLUSTERED,
[Name] NVARCHAR(250) NOT NULL,
[CustomerSince] DATETIME2 NULL,
INDEX [ICustomerSince] NONCLUSTERED
(CustomerID, CustomerSince)
)
WITH (MEMORY_OPTIMIZED = ON,
DURABILITY = SCHEMA_AND_DATA);
This table is durable (default).
Non-durable tables:
DURABILITY=SCHEMA_ONLY

9. CREATE PROCEDURE [dbo].[InsertOrder] @id INT, @date DATETIME2
WITH
NATIVE_COMPILATION,
SCHEMABINDING
AS
BEGIN ATOMIC
WITH
(TRANSACTION
ISOLATION LEVEL = SNAPSHOT,
LANGUAGE = N‘Dutch')
-- insert T-SQL here
END

11. Durability
level
Configuration Pros/Cons Scenarios
Full
durability
Default
DURABILITY=SCHEMA_AND_DATA
Pro:
• Every committed change is
guaranteed to survive failure
Con:
• Latency impact: every commit
requires log IO
Default: most scenarios need full
durability
Delayed
durability
• Transaction commit time
COMMIT WITH (DELAYED_DURABILITY=ON)
• Atomic block of native procedure
BEGIN ATOMIC WITH
(DELAYED_DURABILITY=ON, …)
• Database level
ALTER DATABASE CURRENT SET
DELAYED_DURABILITY=FORCED
Pro:
• Low latency due to no log IO in
transaction execution path
• Efficient log IO due to batching
Con:
• Limited data loss on failure (usually
~60K or ~1ms worth)
Low latency requirements
Can accept some data loss
OR
Copy of recent data exists
elsewhere in case of failure
AlwaysOn auto-failover (sync
replicas) with low latency
Non-
durable
tables
Table creation
DURABILITY=SCHEMA_ONLY
Pro:
• No IO at all
Con:
• Lose data on failure
• Transient data such as session
state
• Caching
• ETL (staging tables)

12. Durability
level
Configuration Pros/Cons Scenarios
Full
durability
Default
DURABILITY=SCHEMA_AND_DATA
Pro:
• Every committed change is
guaranteed to survive failure
Con:
• Latency impact: every commit
requires log IO
Default: most scenarios need full
durability
Delayed
durability
• Transaction commit time
COMMIT WITH (DELAYED_DURABILITY=ON)
• Atomic block of native procedure
BEGIN ATOMIC WITH
(DELAYED_DURABILITY=ON, …)
• Database level
ALTER DATABASE CURRENT SET
DELAYED_DURABILITY=FORCED
Pro:
• Low latency due to no log IO in
transaction execution path
• Efficient log IO due to batching
Con:
• Limited data loss on failure (usually
~60K or ~1ms worth)
Low latency requirements
Can accept some data loss
OR
Copy of recent data exists
elsewhere in case of failure
AlwaysOn auto-failover (sync
replicas) with low latency
Non-
durable
tables
Table creation
DURABILITY=SCHEMA_ONLY
Pro:
• No IO at all
Con:
• Lose data on failure
• Transient data such as session
state
• Caching
• ETL (staging tables)

13. Durability
level
Configuration Pros/Cons Scenarios
Full
durability
Default
DURABILITY=SCHEMA_AND_DATA
Pro:
• Every committed change is
guaranteed to survive failure
Con:
• Latency impact: every commit
requires log IO
Default: most scenarios need full
durability
Delayed
durability
• Transaction commit time
COMMIT WITH (DELAYED_DURABILITY=ON)
• Atomic block of native procedure
BEGIN ATOMIC WITH
(DELAYED_DURABILITY=ON, …)
• Database level
ALTER DATABASE CURRENT SET
DELAYED_DURABILITY=FORCED
Pro:
• Low latency due to no log IO in
transaction execution path
• Efficient log IO due to batching
Con:
• Limited data loss on failure (usually
~60K or ~1ms worth)
Low latency requirements
Can accept some data loss
OR
Copy of recent data exists
elsewhere in case of failure
AlwaysOn auto-failover (sync
replicas) with low latency
Non-
durable
tables
Table creation
DURABILITY=SCHEMA_ONLY
Pro:
• No IO at all
Con:
• Lose data on failure
• Transient data such as session
state
• Caching
• ETL (staging tables)

14. In-Memory OLTP perf demo

16. •
•
•
•
•
•
•
•
•

17. •
•
•
•
•
•
•
•
•
•
•
•

20. order processing workload

21. Domain controllers

22. Domain controllers

27. Sensors
Temporal memory-
optimized table

28. release source code

29. Applications / Web servers

30. LineItem1
LineItem2
…

31. ##temp

32. LineItem1
LineItem2
…
dbo.temp

33. Memory-optimized table variables and temp tables

34. Data Warehouse – SQL Server 2016

36. Resources
• Samples
Perf demo
WideWorldImporters sample DB
IoT sample leveraging temporal tables release page
Azure DB Sample
Enable database for In-Memory OLTP
SQL Server Samples GitHub Repository
• Documentation
Blog on In-Memory OLTP in SQL 2016
Memory-optimized table variables and temp tables
MSDN Documentation for In-Memory OLTP
Azure DB documentation for In-Memory
What’s new in SQL2016
• Migrating apps
In-Memory OLTP Common Workloads and Migration Considerations
Migrating to In-Memory OLTP
Guidelines for using Indexes
• Related videos
Microsoft Virtual Academy talks
Recent investments in In-Memory OLTP

38. jodebrui@microsoft.com