1. SQL Server 2014 In-Memory OLTP
Mikael Colliander
Principal TSP - Application Platform
Microsoft Enterprise & Partner Group

2. Session Objective(s):
Understand the SQL Server 2014 In-Memory OLTP value proposition
Understand how In-memory OLTP helps make applications faster, and what some of the limitations are
Key Takeaway 1
SQL Server in-memory OLTP can make applications run very fast on commodity hardware
Key Takeaway 2
SQL Server in-memory OLTP is designed for OLTP style workloads, and does require some code modifications.

3. Business Trends Market need in OLTP space Examples
- Ever higher throughput
- Lower latency
- at a lower cost
Examples
- Credit-card transactions: validate, authorize and complete the transaction
- Online-betting: Ability to place the bet quickly
- Stock trading: microsecond
- ETL/ELT high load scenarios
- Handle volume spikes / Chock absorber

4. Hardware Trends
Moore’s Law means more transistors and therefore cores, but…
CPU clock rate stalled…
Meanwhile RAM cost continues to drop
Chart reference

5. What is SQL Server In-Memory OLTP?
1. High performance
2. Main memory-optimized
3. OLTP scenarios
4. Integrated into SQL Server
5. Architected for modern hardware trends

6. In-Memory OLTP – Architectural Pillars
Customer Benefits
High performance data operations
Efficient business-logic processing
Frictionless scale-up
Hybrid engine and integrated experience
Architectural Pillars
Main-Memory Optimized
T-SQL Compiled to Machine Code
High Concurrency
SQL Server Integration
Optimized for in-memory data
Indexes (hash and range) exist only in memory
No buffer pool, B-trees
Stream-based storage
T-SQL compiled to machine code via C code generator and VC
Invoking a procedure is just a DLL entry-point
Aggressive compile-time
Multi-version optimistic concurrency control with full ACID support
Core engine uses lock-free algorithms
No lock manager, latches or spinlocks
Same manageability, administration & development experience
Integrated queries & transactions
Integrated HA and backup/restore
Drivers
Hardware trends
Business
Steadily declining memory price, NVRAM
Stalling CPU clock rate
Many-core processors
TCO

7. In-Memory OLTP Integration and Application Migration
Client App
TDS Handler and Session Management
Key
SQL Server.exe
Parser, Catalog, Optimizer
Existing SQL Component
T-SQL Query Execution
Natively Compiled SPs and Schema
Native Compiler
In-mem OLTP Component
Non-durable table
Query Interop
Memory Optimized Tables & Indexes
Buffer Pool for Tables & Indexes T1 T2
Generated .dll T3
Tables
Indexes
Memory Optimized Data Filegroup
Transaction Log
Data Filegroup T1 T2 T3 T1 T2 T3

8. Demo 1 – Traditional Table

9. Create Table DDL Hash Index Secondary Indexes are specified inline
CREATE TABLE [Customer](
[CustomerID] INT NOT NULL
PRIMARY KEY NONCLUSTERED HASH WITH (BUCKET_COUNT = ),
[Name] NVARCHAR(250) NOT NULL
INDEX [IName] HASH WITH (BUCKET_COUNT = ),
[CustomerSince] DATETIME NULL )
WITH (MEMORY_OPTIMIZED = ON, DURABILITY = SCHEMA_AND_DATA);
Hash Index
Secondary Indexes are specified inline
This table is memory optimized
This table is durable

10. Memory Optimized Table Creation
CREATE TABLE DDL
Code generation and compilation
Table DLL produced
Table DLL loaded

11. Create Procedure DDL
CREATE PROCEDURE DATETIME
WITH
NATIVE_COMPILATION,
SCHEMABINDING,
EXECUTE AS OWNER AS
BEGIN ATOMIC
(TRANSACTION
ISOLATION LEVEL = SNAPSHOT,
LANGUAGE = 'us_english')
-- insert T-SQL here
END
This proc is natively compiled
Native procs must be schema-bound
Execution context is required
Atomic blocks
Create a transaction if there is none
Otherwise, create a savepoint
Session settings are fixed at create time

12. Procedure Creation CREATE PROC DDL Query optimization
Code generation and compilation
Procedure DLL produced
Procedure DLL loaded

13. What is a latch? It’s all about “physical” protection
Introduced in SQL 7.0 for database pages
What is a latch?
It’s all about “physical” protection
Thread synchronization for important data structures or concurrency sensitive code
No isolation level or transaction semantics
Ownership and Waiters
Compatibility Matrix (Modes)
Not directly under user control
EX, SH, ….
There is no latch hint

14. Some page changes are just in header (Ex. Checksum, torn page bits)
Why aren’t locks enough?
Some page changes are just in header (Ex. Checksum, torn page bits)
INSERT VALUES (3,300)
Page 100 96 1
Page 100
m_freedata=126
100 2
200
111
EX_LATCH
IX Page 100
m_freedata=126
156
141 1
100 2
200 3 4
400
300 4
400
INSERT VALUES (4,400)
141
126
111 96
EX_LATCH
IX Page 100

15. Demo 2 – Introducing Mem. Opt. Tables

16. Demo 3 – Introducing Natively Com. Proc.

17. Performance Gains
Client App
SQL Server.exe
TDS Handler and Session Management
Key
No improvements in communication stack, parameter passing, result set generation
Existing SQL Component
Parser, Catalog, Optimizer
T-SQL Query Execution
Native Compiler
In-mem OLTP Component
Natively Compiled SPs and Schema
10-30x more efficient
Generated .dll
Query Interop
Removes lock and latch contention
Engine for Memory_optimized Tables & Indexes
Buffer Pool for Tables & Indexes
Reduced bandwidth. Latency remains
Memory-optimized Table Filegroup
Transaction Log
Data Filegroup
Persistence uses sequential IO

18. In-Memory Data Structures
Rows
New row format
Structure of the row is optimized for memory residency and access
No page containers
Rows are versioned (payload never updated in place)
Indexes
Nonclustered Indexes only
Indexes point to rows, they do not duplicate them
Nonclustered hash index for point lookups
Memory-optimized nonclustered index for range and ordered scans (In CTP2)
Not logged and do not exist on disk – maintained online or recreated during recovery

19. Payload (table columns)
Memory-optimized Table: Row Format
Row header
Payload (table columns)
Begin Ts
End Ts
StmtId
IdxLinkCount
8 bytes
4 bytes
2 bytes
8 bytes * (IdxLinkCount)
Key Points
Begin/End timestamp determines row’s version validity and visibility
No data pages; just rows
Row size limited to 8060 bytes create time) to allow data to be moved to disk-based table
Not every SQL table schema is supported (for example LOB and sqlvariant)

20. Hash index with (bucket_count=8):
Hash Indexes
Hash index with (bucket_count=8):
Hash function f:
Maps values to buckets
Built into the system
Hash mapping:
f(Jane) 4 5 6 7 1 2 3
Array of
8-byte
Memory
pointers
f(John)
f(Prague)
Hash
Collisions
f(Susan)
f(Bogota), f(Beijing)

21. Memory Optimized Tables and Indexes
Timestamps
Chain ptrs
Name
City
Hash index on City
Hash index on Name
f(Jane)
50, ∞
Jane
Prague
f(Prague)
f(Susan)
f(Bogota)
90, ∞
Susan
Bogota

22. Memory Optimized Tables and Indexes
Timestamps
Chain ptrs
Name
City
Hash index on City
Hash index on Name
50, ∞
Jane
Prague
f(Prague)
f(John)
100, ∞
John
Prague
90, ∞
Susan
Bogota
T100: INSERT (John, Prague)

23. Memory Optimized Tables and Indexes
Timestamps
Chain ptrs
Name
City
Hash index on City
Hash index on Name
50, ∞
Jane
Prague
100, ∞
John
Prague
90, ∞
Susan
Bogota
90, 150
T150: DELETE (Susan, Bogota)

24. Memory Optimized Tables and Indexes
Timestamps
Chain ptrs
Name
City
Hash index on City
Hash index on Name
50, ∞
Jane
Prague
f(John)
100, 200
100, ∞
John
Prague
f(Beijing)
200, ∞
John
Beijing
90, 150
Susan
Bogota
T200: UPDATE (John, Prague) to (John, Beijing)

25. Memory Optimized Tables and Indexes
Timestamps
Chain ptrs
Name
City
Hash index on City
Hash index on Name
f(Jane)
50, ∞
Jane
Prague
f(Prague)
f(John)
100, 200
John
Prague
f(Beijing)
200, ∞
John
Beijing
90, 150
Susan
Bogota
T250: Garbage collection

26. Limitations on Tables in SQL 2014
Optimized for high-throughput OLTP
No DML triggers
No XML and no CLR data types
Optimized for in-memory
Rows are at most 8060 bytes – no off row data
No Large Object (LOB) types like varchar(max)
Scoping limitations
No FOREIGN KEY and no CHECK constraints
No IDENTITY
No schema changes (ALTER TABLE) – need to drop/recreate table
No add/remove index – need to drop/recreate table

27. Suitable Application Characteristics
Application is suited for in-memory processing
All performance critical data already fits in memory
Transaction locking or physical latching causing stalls and blocking
Application is “OLTP-Like”
Relatively short-lived transactions
High degree of concurrent transactions from many connections
Examples: Stock trading, travel reservations, order processing
Application migration simplified if
Stored procedures used
Performance problems isolated to subset of tables and SPs

28. Assess workload for migration
Not all scenarios can take advantage of In-memory OLTP
Resource Commitment/Ability to change code
Hardware limitations
Bottleneck cannot be addressed by migration (outside of In-memory OLTP Engine)
Workload – Complete Data Warehouse, Long Running Reporting, XML/Full-Text
Establish performance baseline and goals
Identify perf bottlenecks
Utilize AMR (Analyze, Migrate, Report) to help migration
Targeted, staged migration
Migrate only necessary pieces
Start with tables, then T-SQL code and iterate
Validate against perf goals

29. Summary: Key Takeaway 1 Key Takeaway 2
Understand the SQL Server 2014 In-Memory OLTP value proposition
Understand how In-memory OLTP helps make applications faster, and what some of the limitations are
Key Takeaway 1
SQL Server in-memory OLTP can make applications run very fast on commodity hardware
Key Takeaway 2
SQL Server in-memory OLTP is designed for OLTP style workloads, and does require some code modifications.

30. Appendix

31. Internals Whitepaper:
SQL Server In-Memory OLTP Internals Overview for CTP2

32. TechReady 17
9/14/2018
Retrieve BLOB
CREATE PROCEDURE varbinary(max) OUTPUT
AS BEGIN
int=0
bit=0
varbinary(7000)=0x01
-- Set output variable to NULL, so NULL returned if the item does not exist
@Chunk OUTPUT
@Chunk)
BEGIN
exec GetLongItemPart_Hekaton OUTPUT
END GO
© 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.

33. Handling Referential Integrity
TechReady 17
9/14/2018
Handling Referential Integrity
CREATE PROCEDURE evs.usp_EventID_FKCHK @EventID INT
WITH EXECUTE AS OWNER, NATIVE_COMPILATION, SCHEMABINDING
AS BEGIN ATOMIC WITH (TRANSACTION ISOLATION LEVEL = SNAPSHOT, LANGUAGE = 'english')
nvarchar(200)
BEGIN TRY IF
BEGIN
BIT = 0
= 1 FROM [evs].[event] WHERE
IF = 0)
= N'Foreign key violation for column EventID';
THROW 1
END
BEGIN CATCH
THROW;
END CATCH
END TRY
© 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.

34. Workaround Example: IDENTITY
Before migration:
After migration:
CREATE TABLE t1
( c1 INT NOT NULL IDENTITY ...,
c2 INT,
c3 DATE)
CREATE TABLE t1
( c1 INT NOT NULL ...,
c2 INT,
c3 DATE)
WITH (MEMORY_OPTIMIZED=ON)
CREATE SEQUENCE usq_t1 AS
INT START WITH 1 INCREMENT BY 1
CREATE PROC INT, c3 DATE AS
BEGIN
INSERT INTO t1
END
CREATE PROC INT, c3 DATE AS
BEGIN
INT = NEXT VALUE FOR usq_t1
INSERT INTO
END
© 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.