Microsoft

Services

SQL Server
Performance Tuning and
Optimization
Module: In-
Memory OLTP
Module Overview

Microsoft
Services 4
In-Memory OLTP

In-Memory OLTP Overview

Business Trends

Market • Ever higher throughput

Need in • Lower latency
• At a lower cost
OLTP Space
• Credit Card Transactions: validate, authorize
and complete the transaction
Examples • Online Gaming: ability to place the bet quickly
• Session State: high traffic e-commerce
website
 Hardware Trends
Moore’s Law means more
transistors and therefore
cores, but…

CPU clock rate stalled…

Meanwhile RAM
cost continues
to drop

$ per GB of PC Class Memory

1000000

100000

10000

US$/GB
1000

100

10

1
8
15
22
29
36
43
50
57
64
71
78
85
92
99
106
113
120
127
134
141
148
155
162
169
176
183
190
197
204
Chart reference
http://www.gotw.ca/publications/concurrency-ddj.htm
Myths
• In-Memory OLTP is like DBCC PINTABLE
• In-Memory databases are new separate
products
• You can use In-Memory OLTP in an existing SQL
Server application with NO changes whatsoever
• Since tables are in memory, the data is not
durable or highly available; data is lost after a
server crash
 In-Memory OLTP Pillars
High Efficient Hybrid engine
Custome

Benefits

Frictionless
performance business-logic and integrated
r

scale-up
data operations processing experience

Main-Memory T-SQL Compiled High SQL Server

Architectural Pillars

Optimized to Machine Code Concurrency Integration

• Optimized for in- • T-SQL compiled to • Multi-version • Same manageability,
memory data machine code via C optimistic administration &
• Indexes (hash and code generator and concurrency control development
range) exist only in VC with full ACID experience
memory • Invoking a support • Integrated queries &
• No buffer pool, B- procedure is just a • Core engine uses transactions
trees DLL entry-point lock-free algorithms • Integrated HA and
• Stream-based • Aggressive • No lock manager, backup/restore
storage optimizations at latches or spinlocks
Hardware
compile-timeTrends Business
Drivers

Steadily declining
Stalling CPU clock Many-core
memory price, Non- TCO
rate processors
volatile RAM
In Memory OLTP Architecture
Client App

TDS (Client Server Communications) Handler and Session Management Key

Existing
Parser, SQL
Natively
Native Catalog, Compone
Compiled SPs T-SQL Query Execution
Compiler Optimize In-mem
nt
and Schema
r OLTP
Non- Compone
durable nt
Generate
table T1 T2 T3 Table
d .dll
s
Query Indexe
Memory Optimized Tables & Interop s &
Buffer Pool for Tables
Indexes SQL Server.exe Indexes

T1 T2 T3 T1 T2 T3

Memory Optimized Data

Filegroup Transaction Log Data Filegroup
 Performance Gains
Client App
No improvements in:
TDS (Client Server communication) Handler and Session
communication Management Key
stack, parameter Existing
passing, result set Native Parser, SQL
generation Compil Catalog, Compone
T-SQL Query In-mem
er Optimize nt
Execution OLTP
Natively r
Compiled Compone
10-30x more efficient SPs and nt
Generate
Schema
d .dll
Query
Removes lock and
Engine for Interop
latch contention Buffer Pool for
Memory_optimized
Tables & Indexes Tables & Indexes
Reduced bandwidth, SQL Server.exe
Latency remains

Persistence uses
Memory-
sequential IO optimized Table
Transaction
Data Filegroup
Log
Filegroup
Scalability
ostress.exe -S. –E
-dAdventureWorks2012
-Q"EXEC Demo.usp_DemoInsertSalesOrders
@use_inmem = <0,1>, @order_count=100000
@usenative=<0,1>
"
–n<varies>
Workload Types
• In-Memory OLTP is a good fit for:
• Performance-critical OLTP (think order processing or trading)
• High data-input rate (nicknamed “Shock Absorber”)
• In-Memory OLTP as components of ETL
• Session state management
• Read scale
• In-Memory OLTP is not a good fit for:
• No permission for code changes
• App depends on locking behavior
• Full data warehousing
• Long-running reporting workload (use Columnstore potentially instead)
• Use a lot of XML manipulation/Full-Text searches
• Heavily parallelized query (2014)
• Constrained on memory
Demonstration:
In-Memory
OLTP Scalability
In-Memory OLTP

Implementation
Create Filegroup FileGroup Container
CREATE DATABASE [Hekaton]
ON PRIMARY
(NAME = N'Hekaton_data', FILENAME = N'C:\Data\Hekaton_data.mdf'),
FILEGROUP [Hekaton_InMemory] CONTAINS MEMORY_OPTIMIZED_DATA
(NAME = N'Hekaton_mem', FILENAME = N'C:\Data\Mem\Hekaton_Lun1')
LOG ON
(NAME = N'Hekaton_log', FILENAME = N'C:\Data\Log\Hekaton_log.ldf')

ALTER DATABASE [Hekaton]

ADD FILE (NAME = N'Hekaton_mem',
FILENAME = N'C:\Data\Mem\Hekaton_Lun2')
TO FILEGROUP [Hekaton_InMemory]
Create Memory Optimized Table
Hash
CREATE TABLE [Customer] ( Index
[CustomerID] INT NOT NULL
PRIMARY KEY NONCLUSTERED HASH WITH (BUCKET_COUNT = 1000000),
[AddressID] INT NOT NULL INDEX [IxName] HASH WITH (BUCKET_COUNT =
1000000), Collation
[LName] NVARCHAR(250) COLLATE Latin1_General_100_BIN2 NOT NULL BIN2
INDEX [IXLName] NONCLUSTERED (LName) Range
) Index
WITH (MEMORY_OPTIMIZED = ON, DURABILITY = SCHEMA_AND_DATA);

This table is
memory This table is
optimized durable
Memory Optimized Table Limitations
• Optimized for high-throughput OLTP
• No DML triggers*
• No XML and no CLR data types
• Optimized for in-memory
SQL
• Rows are at most 8060 bytes – no off row data Server
• No Large Object (LOB) types like varchar(max)* 2016
• Scoping limitations
• No FOREIGN KEY and no CHECK constraints*
• No schema changes (ALTER TABLE) – need to drop/recreate table*
• No add/remove index – need to drop/recreate table*
• No Computed Columns
• No Cross-Database Queries
Data Access to Memory Optimized
Tables
Interpreted T-SQL Access Natively Compiled Procs

• Access both memory and • Access only memory

disk based tables optimized tables
• Less performant • Maximum performance
• Virtually full T-SQL • Limited T-SQL surface
surface area
• When to use • When to use
• Ad-hoc queries • OLTP-style operations
• Reporting-style queries • Optimize performance critical
• Speeding up app migration business logic
• More the logic embedded,
better the performance
improvement
Natively Compiled Procedures
CREATE PROCEDURE [dbo].[InsertOrder](@id INT, @date DATETIME)
WITH
This proc is natively compiled
NATIVE_COMPILATION,
SCHEMABINDING, Native procs must be schema-
EXECUTE AS OWNER bound
AS Execution context is required
BEGIN ATOMIC (SQL 2014)
WITH Atomic blocks
(TRANSACTION ISOLATION LEVEL = SNAPSHOT, • Create a
LANGUAGE = N'us_english') transaction if
-- Insert T-SQL here… there is none
END • Otherwise, create
a savepoint
Session settings are
fixed at create time
Natively Compiled Procedure
Performance
• To avoid the server having to map parameter
names and convert types:
• Use ordinal (nameless) parameters, do not use named parameters
• Match parameter types passed.
• Use Extended Event
‘natively_compiled_proc_slow_parameter_passing’ to identify

24
Memory Optimized Table Valued Parameters and
Variables
• Usage Scenarios
• Storing Intermediate Result Sets
• Replacement for table variables
• Passing TVP to Natively compiled procedures
• Advantages
• Always in memory, never spills to disk
• No TempDB utilization
• Data access is efficient

25
Memory Optimized Table Valued
Parameters
CREATE TYPE InMemTVP AS TABLE
(ProductID INT NOT NULL PRIMARY KEY NONCLUSTERED HASH(ProductID)
WITH (BUCKET_COUNT = 100))
WITH (MEMORY_OPTIMIZED = ON)
GO

CREATE PROCEDURE [dbo].[GetProductDetails_Native](@tvp dbo.InMemTVP READONLY)

WITH
NATIVE_COMPILATION,
SCHEMABINDING,
EXECUTE AS SELF
AS
BEGIN ATOMIC WITH (TRANSACTION ISOLATION LEVEL = SNAPSHOT, LANGUAGE = N'English')
SELECT a.ProductID, Name, ListPrice FROM Production.Product_inmem a
INNER JOIN @tvp b ON a.ProductID = b.ProductID
END
GO

26
Demonstration:
Creating Memory
Optimized Tables
Demonstration:
Accessing Memory
Optimized Tables
In-Memory OLTP

Native Compilation
Memory Optimized Table Creation
Summary

Code Table DLL

Create Table Table DLL is
Generated loaded in
DDL created
and Compiled memory
Native Compilation Files

Database ID
Module loaded
sys.dm_os_loaded_mod
ules

Databa
se ID

Table Object ID
Other Considerations
• Parameter sniffing
• For Natively compiled procedures, UNKNOWN parameter value
assumed
• Still at play for Interpreted T-SQL
• Recompilation for Natively compiled procedures
• No automatic recompilation, requires a drop and recreate
• Recompiled on first execution after restart of the Server or failover
In-Memory OLTP

In-Memory Storage Layout

In-Memory OLTP Structures
• Rows
• Row structure is optimized for memory access
• There are no Pages
• Rows are versioned and there are no in-place updates
• Indexes
• There is no clustered index, only non-clustered indexes
• Indexes point to rows, access to rows is via an index
• Indexes do not exist on disk, only in memory, recreated during recovery
• Hash indexes for point lookups
• Range indexes for ordered scans and range scans
In-Memory Row Format
Row Header Row Data

Begin Ts End Ts StmtID

IdsLinkC
ount
Index1
ptr
Index2
ptr … IndexN
ptr

8 bytes 8 bytes 4 bytes 2 bytes + 8 bytes * Number of

2 for Indexes
padding
• Begin/End timestamp determines row’s version validity and visibility
• No concept of data pages, only rows exist
• Row size limited to 8060 bytes (@table create time) to allow data to be moved to
disk-based table
Hash Indexes
Hash index with Hash function f:
(bucket_count=8): • Maps values to buckets
• Built into the system
Hash mapping:

f(Jane) 0
Array of 1
f(John) 2 f(Prague)
8-byte f(Susan) 3 Hash
Memory 4 Collisions
5 f(Bogota), f(Beijing)
pointers 6
7
Range Index Page Format
Payload
Page Header
Values Offsets Keys

Page Right PageSt High

PageID Height
Type PID ats Watermark

Maps to Leaf Page to Distance Count of High

page Table Internal the right of to leaf records & Watermark Key
Delta current level other (upper limit of
Special page statistics values on
page)
Index Guidelines Summary
• Hash index
• Point Lookups
• Full index key
•Non-clustered
• Range Lookups
• Sorted datasets
• Both Range and Point Lookups
• Create two indexes
• Hash and non-clustered
Demonstration:
Hash and Range
Indexes
In-Memory OLTP

On-Disk Storage Layout

Storage
• Filestream container is the underlying storage
mechanism
• Checksums and single-bit correcting ECC on files
• Data files
• ~128MB in size, write 256KB chunks at a time
• Stores only the inserted rows (i.e. table content)
• Chronologically organized streams of row versions
• Delta files
• File size is not constant, write 4KB chunks at a time (16MB if Server has
> 16GB RAM)
• Stores IDs of deleted rows
Data and Delta Files
0 100Transaction Timestamp Range

Data File
TS (ins) RowId TableId Row pay load
TS (ins) RowId TableId Row pay load
TS (ins) RowId TableId Row pay load
Checkpoint File Pair

Data file contains rows inserted

within a given transaction range

Delta File
TS (ins) RowId TS (del)
TS (ins) RowId TS (del)
TS (ins) RowId TS (del)

Delta file contains deleted rows

within a given transaction range
 Populating Data and Delta Files
Del Tran1 Log in disk Del Tran2 Del Tran3 Insertinto
intoT1
SQL Transaction log (row )
TS150)
(TS150) Table (row
(TSTS 450)
450) (row
(TSTS 250)
250)
Insert
Hekaton T1
(LogPool)

Offline Checkpoint Thread

• Data file has pre-allocated
size (128 MB)
• Engine switches to new Delete 150
data file when the current TS Delete 250 Delete 450 New Inserts
TS TS
file is full
• Transaction does not span

Range 500-
Range 300-
Range 100-

Range 200-

Range 400-
data files
• Once a data file is closed,

299

399

499
199
it becomes read-only
• Row deletes are tracked in
delta file
• Files are append only
Memory-optimized Table Filegroup

Data file with rows generated in timestamp IDs of Deleted Rows (height indicates %
range deleted)
Merge Operation
• What is a Merge Operation?
• Merges two or more adjacent data/delta files pairs into 1 pair

• Need for Merge

• Deleting rows causes data files to have stale rows
• DMV: sys.dm_xtp_checkpoint_files can be used to find inserted/deleted rows and free space

• Benefits of Merge
• Reduces storage (i.e. fewer data/delta files) required to store active data rows
• Improves the recovery time as there will be fewer files to load

• When is Merge done?

• 2 or more consecutive CFPs can be consolidated, after accounting for deleted rows, such that
the resultant rows can fit into 1 CFP of ideal size
• Single CFP can be self-merged the data file exceeds 256 MB
and over half of the rows are deleted
• Manual Merge invoked calling
sys.sp_xtp_merge_checkpoint_files
Demonstration:
Data and Delta Files
and Merge
Logging
• Uses SQL transaction log to store content
• Each In-Memory OLTP log record contains a log record header followed
by memory optimized-specific log content
• All logging for memory-optimized tables is
logical
• No log records for physical structure modifications
• No index-specific / index-maintenance log records
• Log records are written only on a commit, no UNDO information is
logged
• Latency
• Latency is absolutely critical, recommend SSDs
• Recovery Models
• All three recovery models are supported
Diagnostics
• Log not being truncated
• sys.databases log_reuse_wait_desc=’XTP_CHECKPOINT’.
• DMVs / DMFs
• sys.dm_db_xtp_checkpoint_stats
• sys.dm_db_xtp_checkpoint_files
• sys.fn_dblog_xtp()/sys.fn_dump_log_xtp()
• Manual merge
• sys.sp_merge_xtp_checkpoint_files
Recovery – Memory Optimized Tables
Analysis Phase • Finds the last completed checkpoint

• Instantiate memory optimized tables

• Load from set of data/delta files from the last
Data Load completed checkpoint
• Parallel Load by reading data/delta files using 1 thread /
file

• Apply the transaction log from last checkpoint

Redo phase • Concurrent with REDO on disk-based tables

No UNDO • Since only committed transactions are logged

phase
Recovery Progress and Diagnostics
• Progress
• Extended Event xtp_recover_table
• Extended Event xtp_recover_done
• Errorlog
• Recovery Failures
• Due to compilation
• Due to memory availability/configured to load the data
• Checksum failure on checkpoint files
• Table size limitation (checkpoint files limit is 8192)
• Other normal recovery failure reasons
In-Memory OLTP

Memory Management
 Memory Problem?
Available
Memory
Memory
Max Server Memory

Memory Optimized Memory

Optimized Tables Optimized Memory
Tables Tables Optimized
Tables
Memory Memory
Internal Internal
Structures Structures Memory
Internal
Memory
Structures
Internal
Buffer Pool Buffer Pool Structures
Buffer Pool
Buffer Pool
Memory Considerations
Scenario Symptom Diagnosis Solution

Inserting more Transactions Read error Free up

rows than start failing log memory
rows that can
fit in memory
Identify Add
via DMVs, memory
Recovering Database does SSMS
database that not come whether Identify
does not fit in online In-Memory and stop
memory OTLP is long
using running
Memory Operations in
most transactio
pressure due other memory ns
to In-Memory workloads
OLTP on other start failing
Memory Considerations
• Data resides in memory at all times
• Configure SQL server with sufficient memory to store memory-
optimized tables
• Failure to allocate memory will fail transactional workload at run-time
• Other SQL workloads can slow down to unacceptable performance
• Sizing
• Table Size: rule of thumb 2* size of data
• Hash Indexes: 8KB * [actual bucket count]
• Non clustered index: variable size

• Management
• Limit memory consumption using Resource Governor
• DMVs, Perfmon
• Freeing memory is not synchronous in most cases
Resource Governor Integration
• Limits max memory allocation for In-Memory
OLTP
• Prevents performance degradation
Internal pool of regular
%available of
target dedicated pool before
SQL workloads memory OOM notification
• Implementation:
<= 8 GB 70%
• Define dedicated pool for In-Memory
• Bind DB to resource pool defined <= 16GB 75%
via sys.sp_xtp_bind_db_resource_pool
• Set database offline and Online <= 32GB 80%

<= 96GB 85%

>= 96 GB 90%
Monitoring

Memory Usage DMV

Memory Optimized Table size sys.dm_db_xtp_table_memory_stat
s
Database IM-OLTP memory usage sys.dm_db_xtp_memory_consumer
s
Non-Database IM-OLTP memory sys.dm_xtp_system_memory_cons
usage umers
Overall IM-OLTP memory usage sys.dm_os_memory_brokers
In-Memory OLTP

Garbage Collection
Garbage Collection
• Stale Row Versions
• Updates, deletes, and aborted insert operations
create row versions that (eventually) are no
longer visible to any transaction
• Slow down scans of index structures
• Create unused memory that needs to be reclaimed (i.e. Garbage
Collected)
• Garbage Collection (GC)
• Analogous to version store cleanup task for disk-based tables to
support Read Committed Snapshot (RCSI)
• System maintains ‘oldest active transaction’ hint
GC Diagnostics
• DMV’s
• sys.dm_xtp_gc_stats
• sys.dm_xtp_gc_queue_stats
• Performance counters – XTP Garbage Collection
• Extended Events – xtpengine.gc_*
Demonstration:
Garbage Collection
In-Memory OLTP

Concurrency Control and

Isolation Levels
 Concurrency Control
Multi-version Snapshot-based
data store transaction
isolation
Multi-version

No TempDB

No locks, no Conflict
latches, detection to
minimal context ensure isolation
Optimistic switches

No blocking No deadlocks
Isolation Levels Supported

• Reads are consistent as of start of the transaction

SNAPSHOT • Writes are always consistent

REPEATABLE • Read operations yield same row versions if

READ repeated at commit time

• Transaction is executed as if there are no

SERIALIZAB concurrent transactions – all actions happen at a
LE single serialization point (commit time)
 Write Conflict
Time Transaction T1 (SNAPSHOT) Transaction T2 (SNAPSHOT)
1 BEGIN
2 BEGIN
3 UPDATE t SET c1=‘value2’ WHERE
c2=123
4 UPDATE t SET c1=‘value1’
WHERE c2=123 (write
conflict)

First
writer
wins
Validation Errors and Retry Logic
Err Err Message
Number
41302 The current transaction attempted to update a record that has been
updated since the transaction started
41305 The current transaction failed to commit due to a repeatable read
validation failure
41325 The current transaction failed to commit due to a serializable validation
failure

41301 A previous transaction that the current transaction took a dependency

Failures on has aborted, and the current transaction
Aborted can no longer commit
Solution:
causing transactions implement
transaction need to be retry logic
abort retried
Server-side
retry avoids
Write changes to
Retry Logic for Transaction Failures
CREATE PROCEDURE usp_my_procedure @param1 type1, @param2 type2, ...
AS
BEGIN
DECLARE @retry INT = 10
WHILE (@retry > 0)
BEGIN
BEGIN TRY

EXEC usp_my_native_proc @param1, @param2, ...

SET @retry = 0 Hekaton-specific Deadlock

END TRY error codes (for disk-based tables)
BEGIN CATCH
SET @retry -= 1
IF (@retry > 0 AND error_number() IN (41302, 41305, 41325, 41301, 1205))
IF (@@TRANCOUNT>0) ROLLBACK TRANSACTION
ELSE
THROW
END CATCH
END
END
Demonstration:
Transaction
Semantics
In-Memory OLTP

Query Performance Diagnostics

Plan Cache
• Natively compiled procedures
• Cannot be returned by sys.dm_exec_query_plan DMF
• CACHESTORE_OBJCP/CACHESTORE_SQLCP does not account for them
• DBCC FREEPROCCACHE/ Free System Cache not applicable
• Requires drop and recreate as compiled plan is a DLL
Execution Statistics Collection
• Natively compiled procedures
• By default no collection in sys.dm_exec_query_stats /
sys.dm_exec_procedure_stats
• Reset to off on SQL Server restart
• Performance impact if you enable stats collection
• Procedure stats enabled server wide with
sp_xtp_control_proc_exec_stats
• Query Stats enabled per procedure with
sp_xtp_control_query_exec_stats
• Only sp_statement_completed (no starting) event produced in Xevent
XTP (In-Memory OLTP) Performance
Counters
Performance
Description
Object
The XTP Cursors performance object contains counters related to internal
XTP engine cursors. Cursors are the low-level building blocks the XTP
XTP Cursors
engine uses to process Transact-SQL queries. As such, you do not typically
have direct control over them.
XTP Garbage The XTP Garbage Collection performance object contains counters related
Collection to the XTP engine's garbage collector.
The XTP Phantom Processor performance object contains counters related
XTP Phantom to the XTP engine's phantom processing subsystem. This component is
Processor responsible for detecting phantom rows in transactions running at the
SERIALIZABLE isolation level.
XTP Transaction The XTP Transaction Log performance object contains counters related to
Log XTP transaction logging in SQL Server.
The XTP Transactions performance object contains counters related to XTP
XTP Transactions
engine transactions in SQL Server.
sys.dm_os_wait_stats
• Global Wait stats
• WAIT_XTP_*

• Native Procedure
• XTPPROC_*
Demonstration:
Query Diagnostics
In-Memory OLTP

Hardware and Configuration

Storage Considerations
Capacity Performance

Capacity needed is 2-3 x size Sequential IO bandwidth

of durable memory optimized sufficient to meet RTO
tables 64KB NFTS Cluster
Data Spread into multiple containers
Around 250GB max per (Odd number)
database SSD or Fast Spinning media (15K
SAS array)
On-disk size maybe larger
than size in memory Latency is VERY important for
durable tables
Per transaction log
Log consumption is less than disk SSDs (PCIe)
based tables
Consider Delayed Durability or
Non Durable consideration
Memory Considerations
Size of in-memory table +
indexes + row versions

Configure Max Server Consider other workloads on

Sizing memory appropriately the instance

Short transactions
(versions)

Short transactions
Resource Governor
Managing Define dedicated pool
(versions)
Force Garbage Collection
Other Considerations

Number of Cores/Sockets
Resource Governor can
CPU 2-4 Socket boxes
help here as well
< 60 cores

Instant File Initialization

Configuratio Anti-Virus Exclusions
n
Lab:
Exploring In-
Memory Click icon to add picture

OLTP in SQL
Server 2014
/ 2016
© 2015 Microsoft Corporation. All rights reserved.