1. SQL Server In-Memory OLTP: What Every SQL Professional Should Know
6/4/ :26 AM
Decks and demos at
Latch free since 2007
SQL Server In-Memory OLTP: What Every SQL Professional Should Know
@bobwardms, #bobsql
Bob Ward
Principal Architect
Microsoft, Data Group, Tiger Team
© Microsoft Corporation. All rights reserved.

2. How do I use this? The What and Why How does this work? Let’s Do This
6/4/ :26 AM
Based on SQL Server 2016
Let’s Do This
The What and Why
How do I use this?
How does this work?
© Microsoft Corporation. All rights reserved.

3. The What and Why ἑκατόν 6/4/2018 12:26 AM
© Microsoft Corporation. All rights reserved.

4. The Research behind the concept
OLTP Through the Looking Glass, and What We Found There by Stavros Harizopoulos, Daniel J. Abadi, Samuel Madden, Michael Stonebraker , SIGMOD 2008
TPC-C hand-coded on top of the SHORE storage engine
2/17/2008

5. The Path to In-Memory OLTP
Project Verde
2007
“Early” Hekaton
2009/2010
Hekaton becomes In-Memory OLTP
SQL Server 2014
In-Memory OLTP Unleashed
SQL Server 2016

6. Why In-Memory OLTP?
Keep SQL Server relevant in a world of high-speed hardware with dense cores, fast I/O, and inexpensive massive memory
The need for high-speed OLTP transactions at microsecond speed
Reduce the number of instructions to execute a transaction
Find areas of latency for a transaction and reduce its footprint
Use multi-version optimistic concurrency and “lock free” algorithms
Use DLLs and native compiled procs
XTP = eXtreme Transaction Processing
HK = Hekaton

7. Demo: Just Show Us! See In-Memory OLTP in action 6/4/2018 12:26 AM
Use the instructions in readme.md in demo1_just_show_us
© Microsoft Corporation. All rights reserved.

8. What is it Really? Memory-Optimized Tables Memory Optimized FILEGROUP
6/4/ :26 AM
Memory-Optimized Tables
What is it Really?
“Feels” like normal disk-based tables but in memory
Internally completely different
Hash or non-clustered index choices (at least one required)
Memory Optimized FILEGROUP
Checkpoint Files
Engine within an Engine
SQLSERVR.EXE
Query Processor
HK Runtime
Natively Compiled T-SQL Stored Procedure
Storage Engine
HK Compile
Dynamic Linked Library (DLL) HA
HK Engine
Max performance
Latch and lock free
SQLOS
© Microsoft Corporation. All rights reserved.

9. How is this different? Memory I/O Concurrency
6/4/ :26 AM
How is this different?
Can be controlled with Resource Governor
Memory
All data stored in memory separate from Buffer Pool
No “paging” to disk like Buffer Pool under memory pressure
Table data uses different internal structure (no database pages)
I/O
Transaction logging only at COMMIT
Separate checkpoint processing only used to speed startup
None required for SCHEMA_ONLY tables
Concurrency
No locking or latching required
Optimistic (conflict error handling may be required)
Versioning used (but not stored in tempdb)
All data loaded into memory at database startup
© Microsoft Corporation. All rights reserved.

10. 6/4/ :26 AM
How do I use it?
© Microsoft Corporation. All rights reserved.

11. 6/4/ :26 AM
The Process
Create a Memory Optimized FILEGROUP
Decide on an index strategy
Create a Memory-Optimized Table
Create a natively compiled stored procedure
Start running transactions
Tune and manage
© Microsoft Corporation. All rights reserved.

12. Decisions Take a look at NVDIMM 6/4/2018 12:26 AM
Do I have enough Memory?
Estimating Table, Index, Versioning, and Growth. Read here
Hash or Non-clustered index?
Hash = unique row lookup
Non-clustered = range lookups (also called range index)
Durability
SCHEMA_ONLY = Does not persist server restarts; No I/O (even log)
SCHEMA_AND_DATA = Persists server restarts
Use Natively Compiled Stored Procedures?
Ultimate speed vs some limits
Limited diagnostics by default
Physical File Placement
Transaction Log - Transactions only as fast as commit speed
FILEGROUP – One or multiple folders across drives for faster startup
Take a look at NVDIMM
© Microsoft Corporation. All rights reserved.

13. Migrating Existing Data
6/4/ :26 AM
Migrating Existing Data
Transaction Performance Analysis Report
Memory Optimization Advisor
Native Compilation Advisor
Analyze based on DMVs
Recommend changes
Find incompatibilities
Migrate schema, data, and procs
© Microsoft Corporation. All rights reserved.

14. In-Memory OLTP Scenarios
6/4/ :26 AM
In-Memory OLTP Scenarios
High-throughput and low-latency transaction processing
Data Ingestion and IoT
Caching and Session State
Tired of Tempdb?
Staging tables for ETL
© Microsoft Corporation. All rights reserved.

15. Demo: Tempdb vs Memory-Optimized Tables

16. Management Considerations
6/4/ :26 AM
Management Considerations
Locks the table
Maintain indexes
Used to maintain bucketcount for hash indexes
Natively Compled Procedures are SCHEMABOUND
ALTER memory optimized tables
Auto Update statistics supported (requires db compat level = 130)
Natively Compiled Stored Procedures not recompiled on auto status update
Maintaining Statistics
Need to reduce space? Delete rows or drop tables
Bind to your own RG resource pool with sp_xtp_bind_db_resource_pool
Managing Memory Usage
© Microsoft Corporation. All rights reserved.

17. In-Memory OLTP Capabilities
6/4/ :26 AM
In-Memory OLTP Capabilities
Supported on Always On Availability Groups
Supports ColumnStore Indexes for HTAP applications
Supported in Azure SQL Database
Cross container transactions (disk and in-memory in one transaction)
Table variables supported
SQL surface area expanded in SQL Server Complete support here
LOB data types (ex. Varchar(max)) supported
BACKUP/RESTORE complete functionality
Memory only limited by the OS (24TB in Windows Server 2016)
© Microsoft Corporation. All rights reserved.

18. 6/4/ :26 AM
How does it work?
© Microsoft Corporation. All rights reserved.

19. Architecture 101 The Hekaton Engine
6/4/ :26 AM
Architecture 101
The Hekaton Engine
A pool of threads for garbage collection, checkpoint I/O and Log flush
Compilation of schema and Natively Compiled Procedure DLLs
Engine runtime that is agnostic to table and row formats
The HK Engine code is lock, latch, and spinlock free
Multi-Version Optimistic Concurrency
Pessimistic = locks
Immutable
Rows never change: UPDATE = DELETE + INSERT
Versions
UPDATE and DELETE create versions
Timestamps in rows for visibility and transactions correctness
Optimistic
Assume no conflicts
Snapshots + conflict detection
Guarantee correct transaction isolation at commit
NOT in tempdb
Errors may occur
© Microsoft Corporation. All rights reserved.

20. The Path of In-Memory OLTP Transactions
“Normal” INSERT
In-Memory OLTP INSERT
Maintain index in memory
Insert ROW into memory
Release latches and locks
Update index pages ( more locks and latch )
Modify page
Latch page
Obtain locks
INSERT LOG record
Page Split
Sys Tran = Log Flush
Spinlocks
No latch
No spinlock
No index logging
Notice that log records are not even created until COMMIT.
SCHEMA_ONLY no logging
COMMIT Transaction = Insert HK Log Record and Flush
COMMIT Transaction = Log Record and Flush

21. CHECKPOINT and Memory Optimized Tables
6/4/ :26 AM
CHECKPOINT and Memory Optimized Tables
Log truncation eligible at CHECKPOINT event
Why CHECKPOINT?
Speed up database startup. Otherwise we would have to keep around a huge tlog around.
We only write data based on committed log records
Independent of SQL recovery intervals or background tasks (1.5Gb log increase)
All data written in pairs of data and delta files
Preemptive tasks using WriteFile (async with FILE_FLAG_NO_BUFFERING)
Data is always appended
I/O is continuous but CHECKPOINT event is based on 1.5Gb log growth
Instant File Initialization matters for PRECREATED files
Data = INSERTs and UPDATEs
Delta = filter for what rows in Data are actually deleted
Periodically we will MERGE several Data/Delta pairs.
No WAL protocol
Typically 128Mb but can be 1Gb
Typically 8Mb but can be 128Mb
Read details from database Boot Page (DBINFO)
Load ROOT file for system tables and file metadata
Load ACTIVE DATA files filtered by DELTA streamed in parallel
Redo COMMITED transactions greater than last CHECKPOINT LSN
The Recovery Process =
© Microsoft Corporation. All rights reserved.

22. The Case for In-Memory OLTP
6/4/ :26 AM
The Case for In-Memory OLTP
Want a 30x boost in speed for OLTP?
Transactions are truly lock, latch, and spinlock free
Natively complied stored procedures for super speed
Combine with Columnstore for true HTAP applications
SQL Server 2016 is a major step up from 2014
© Microsoft Corporation. All rights reserved.

23. Resources SQL Server In-Memory OLTP Internals for SQL Server 2016
6/4/ :26 AM
Resources
SQL Server In-Memory OLTP Internals for SQL Server 2016
In-Memory OLTP Videos: What it is and When/How to use it
Explore In-Memory OLTP architectures and customer case studies
In-Memory OLTP in Azure SQL Database Blog
In-Memory OLTP (In-Memory Optimization) docs
Inside In-Memory OLTP SQL 2016 PASS Summit talk
Decks and demos at
© Microsoft Corporation. All rights reserved.

24. 6/4/ :26 AM
© Microsoft Corporation. All rights reserved.