SQL Server Internals In Memory OLTP Inside the SQL

Server 2016 Hekaton Engine 2nd Edition Kalen Delaney

digital version 2025

Now on sale at textbookfull.com

( 4.8/5.0 ★ | 299 downloads )

https://textbookfull.com/product/sql-server-internals-in-memory-
oltp-inside-the-sql-server-2016-hekaton-engine-2nd-edition-kalen-
delaney/
 SQL Server Internals In Memory OLTP Inside the SQL Server
2016 Hekaton Engine 2nd Edition Kalen Delaney

TEXTBOOK

Available Formats

■ PDF eBook Study Guide Ebook

EXCLUSIVE 2025 ACADEMIC EDITION – LIMITED RELEASE

Available Instantly Access Library

More products digital (pdf, epub, mobi) instant
download maybe you interests ...

Expert SQL Server In-Memory OLTP 2nd Edition Dmitri

Korotkevitch

https://textbookfull.com/product/expert-sql-server-in-memory-
oltp-2nd-edition-dmitri-korotkevitch/

Pro SQL Server Internals 2nd Edition Dmitri

Korotkevitch

https://textbookfull.com/product/pro-sql-server-internals-2nd-
edition-dmitri-korotkevitch/

Expert SQL Server Transactions and Locking: Concurrency

Internals for SQL Server Practitioners 1st Edition
Dmitri Korotkevitch

https://textbookfull.com/product/expert-sql-server-transactions-
and-locking-concurrency-internals-for-sql-server-
practitioners-1st-edition-dmitri-korotkevitch/

SQL Server Execution Plans For SQL Server 2008 through

to 2017 and Azure SQL Database 3rd Edition Grant
Fritchey

https://textbookfull.com/product/sql-server-execution-plans-for-
sql-server-2008-through-to-2017-and-azure-sql-database-3rd-
edition-grant-fritchey/
SQL Server 2016 Developer s Guide 1st Edition Dejan
Sarka

https://textbookfull.com/product/sql-server-2016-developer-s-
guide-1st-edition-dejan-sarka/

Microsoft SQL Server 2016 a beginner's guide Sixth

Edition Petkovic

https://textbookfull.com/product/microsoft-sql-
server-2016-a-beginners-guide-sixth-edition-petkovic/

Building Custom Tasks for SQL Server Integration

Services: The Power of .NET for ETL for SQL Server 2019
and Beyond 2nd Edition Andy Leonard

https://textbookfull.com/product/building-custom-tasks-for-sql-
server-integration-services-the-power-of-net-for-etl-for-sql-
server-2019-and-beyond-2nd-edition-andy-leonard/

Securing SQL Server: DBAs Defending the Database 2nd

Edition Peter A. Carter

https://textbookfull.com/product/securing-sql-server-dbas-
defending-the-database-2nd-edition-peter-a-carter/

Azure SQL Revealed: A Guide to the Cloud for SQL Server

Professionals Bob Ward

https://textbookfull.com/product/azure-sql-revealed-a-guide-to-
the-cloud-for-sql-server-professionals-bob-ward/
Second Edition

SQL Server Internals:

In-Memory OLTP
Inside the SQL Server 2016 Hekaton Engine

By Kalen Delaney
 SQL Server Internals:
In-Memory OLTP
Inside the SQL Server 2016 Hekaton Engine

By Kalen Delaney

Foreword by Rimma Nehme, Microsoft

Technical Review by Benjamin Nevarez

Technical Edit by Tony Davis

First published by Simple Talk Publishing 2017

Copyright © Kalen Delaney 2017
ISBN 978-1-910035-19-1
The right of Kalen Delaney to be identified as the author of this work has been asserted by her in accordance with
the Copyright, Designs and Patents Act 1988.
All rights reserved. No part of this publication may be reproduced, stored or introduced into a retrieval system, or
transmitted, in any form, or by any means (electronic, mechanical, photocopying, recording or otherwise) without
the prior written consent of the publisher. Any person who does any unauthorized act in relation to this publica-
tion may be liable to criminal prosecution and civil claims for damages.
This book is sold subject to the condition that it shall not, by way of trade or otherwise, be lent, re-sold, hired out,
or otherwise circulated without the publisher's prior consent in any form other than which it is published and
without a similar condition including this condition being imposed on the subsequent publisher.
Cover Image: Andy Martin.
Typeset by Gower Associates.
Contents

Introduction 16

1: What's Special About In-Memory OLTP? 20

Isn't In-Memory OLTP Just an Improved DBCC PINTABLE? 20

The In-Memory OLTP Component 21

Memory-optimized tables 22

Entirely in-memory storage 22

Row-based storage structure 23

Native compilation of tables 24

Natively compiled stored procedures 24

Concurrency improvements: the MVCC model 25

Indexes on memory-optimized tables 26

Data durability and recovery 27

Performance 29

What's New for In-Memory OLTP in SQL Server 2016 30

SQL Server In-Memory OLTP in Context 31

Summary 33

Additional Resources 34
Chapter 2: Creating and Accessing In-Memory OLTP Databases and Tables 35
Creating Databases 35

Azure SQL Database 37

Creating Tables 38

Durability 39

Indexes and constraints 39

Data type restrictions 41

Creating Table Types and Table Variables 42

Altering Memory-Optimized Tables 43

Accessing Memory-Optimized Tables with T-SQL 46

Interpreted T-SQL 46

T-SQL in natively compiled procedures 47

Memory Allocation for Memory-Optimized Tables and Indexes 48

Summary 52

Additional Resources 53

Chapter 3: Row Structure and Multi-Versioning 54

Row Structure 54

Row header 55

Payload area 56

Row Versions, Timestamps and the MVCC Model 56

 Transaction IDs and timestamps 56

Row versions and transaction processing phases 58

Processing phase 59

Validation phase 62

Post-processing 62

Summary 64

Additional Resources 64

Chapter 4: Indexes on Memory-Optimized Tables 65

Nonclustered and Hash and Range Indexes 65

Hash indexes 67

Row organization 68

Choosing hash indexes 71

Determining the number of hash buckets 72

Range indexes 73

The Bw-tree 74

Index page structures 77

Internal index maintenance operations 78

Columnstore Indexes 86

Columnstore index basic architecture 86

Clustered columnstore indexes on memory-optimized tables 88

 Updating columnstore indexes 88

Examining index metadata for a columnstore index on a

memory-optimized table 91

Examining Index Metadata 95

Indexes on Temporal Tables 97

Summary 97

Additional Resources 98

Chapter 5: Transaction Processing 99

Transaction Scope 99

Transaction Isolation Levels 100

Isolation levels with disk-based tables 101

Isolation levels with memory-optimized tables 102

Rules for cross-container transactions (interpreted T-SQL) 103

READ COMMITTED cross-container transactions must specify a

valid isolation level 104

SNAPSHOT cross-container transactions cannot access

memory-optimized tables 106

REPEATABLE READ or SERIALIZABLE cross-container transactions

must use SNAPSHOT 107

Choosing an isolation level for accessing memory-optimized tables 109

Monitoring Active Transactions 110

Transaction Processing Examples 111

 Write-write conflicts 112

Read-write conflicts 113

Validation Phase 116

Validation phase, Step 1: Check for isolation level violations 117

SNAPSHOT isolation level violations 117

REPEATABLE READ isolation level violations 119

SERIALIZABLE isolation level violations 119

Validation of foreign keys 120

Validation phase, Step 2: Commit dependencies 120

Validation phase, Step 3: Logging 121

Post-processing 123

Garbage Collection of Rows in Memory 123

Summary 126

Additional Resources 127

Chapter 6: Logging, Checkpoint, and Recovery 128

Transaction Logging 129

Scalability: multiple concurrent log streams 129

Performance: reduced logging 130

Checkpoint 135

Anatomy of checkpoint files 136

 Continuous checkpointing and checkpoint events 140

Checkpoint file metadata states 141

The checkpoint event 147

The threads and tasks comprising the full checkpoint process 149

Merging checkpoint files 150

Automatic merge 151

Garbage collection of checkpoint files 154

Recovery 155

Summary 156

Additional Resources 156

Chapter 7: Native Compilation of Tables and Native Modules 157

What Is Native Compilation? 157

Maintenance of DLLs 158

Native Compilation of Tables 159

Native Compilation of Modules 160

Parameter Sniffing 162

Compilation and Query Processing 163

Optimization of Natively Compiled Modules 164

Index access paths 165

Hash indexes 165

 Range indexes 166

No Halloween protection 166

No automatic recompile 166

Best Practices with Natively Compiled Procedures 167

Performance Comparisons 168

Comparing performance for multi-row inserts 168

Performance analysis using DMV data 173

Summary 174

Additional Resources 174

Chapter 8: SQL Server Support and Manageability 175

Feature Support 176

Memory Allocation and Management 179

Using Resource Governor for memory management 180

Memory usage report 182

Metadata Enhancements and Additions 183

Catalog view enhancements 183

Dynamic Management Objects 184

Extended events 187

Performance counters 188

Best Practices for Designing Memory-Optimized Tables and Indexes 189

Best Practices for Managing Statistics on Memory-Optimized Tables 191

Migration Considerations 191

Common application bottlenecks that in-memory OLTP can resolve 192

Application requirements compatible with migration to in-memory OLTP 193

High volume of INSERTs 193

High volume of SELECTs 194

CPU-intensive operations 194

Extremely fast business transactions 195

Session state management 195

Unsuitable application requirements 196

Current applications 197

The migration process 198

Workload analysis and baselining 198

Summary 200

Additional Resources 201

Foreword
Rimma V. Nehme, Technical Assistant
Data Group at Microsoft
Bellevue, WA

It is my great pleasure to write a foreword to Kalen's book, SQL Server Internals: In-Memory
OLTP, Inside the SQL Server 2016 Hekaton Engine. Kalen has been working with SQL
Server for over 29 years, and even after three decades of working with the SQL Server
technology, she is still very excited to teach, write, and share her knowledge about SQL
Server. She is one of the best-respected technology writers, and her Twitter handle, @
sqlqueen, says it best. I remember when I first started developing for the SQL Server engine,
many years ago, as an intern at Microsoft, I complemented all of our internal documentation
with her Inside SQL Server book. Who knows, maybe if not for that book, I might have not
excelled at my internship, which eventually led to an incredibly rewarding career working
inside the SQL Server engine. Thank you, Kalen!

This book, SQL Server Internals: In-Memory OLTP is a true gem for modern data devel-
opers and data professionals. It contains an unprecedented level of details about the
in-memory technology of SQL Server. In my many conversations with customers, I often
hear a confusion between the terms "In-Memory" and "Memory-Optimized." Many think
that they are one and the same. If you continue reading this book, you will realize the
distinction. In-Memory OLTP is a game changer for relational databases, and especially for
OLTP systems. Processors are not getting dramatically faster, but the number of cores and
the amount of memory is increasing drastically. Machines with terabytes of memory are
becoming a commodity. Over the last 30 years, memory prices have dropped by a factor of
10 every 5 years. Both core counts and memory sizes are increasing at an accelerated pace.
The majority of OLTP databases fit entirely in 1 TB and even the largest OLTP databases
can keep the active working set in memory. A technology that takes advantage of this ever-
changing hardware landscape is Microsoft's in-memory OLTP.

To understand this better, let us travel back in time a few years to when the sizes of OLTP
databases were much larger than the memory available on the server. For example, your
OLTP database could be 500 GB while your SQL Server has 128 GB of memory. We all
know the familiar strategy to address this, by storing data and indexes in smaller chunks,

xii
or pages. SQL Server supports 8 K pages. These pages are read and written in and out of
memory using sophisticated heuristics implemented as part of the buffer pool in SQL Server.
When running a query, if the page containing the requested row(s) is not found in the buffer
pool, an explicit physical I/O is incurred to bring it into memory. This explicit physical I/O
can significantly reduce query performance. Today, you can get around this issue by buying a
server machine with terabytes of physical memory and keeping your entire 500 GB database
in memory, effectively removing any bottleneck due to I/O. However, the more important
question to be asked is: "Is your database optimized for being in-memory?" This book will
teach you how to do it.

Another aspect to consider is locking and latching, and its impact on performance. When you
query your data, SQL Server loads data pages in-memory and keeps them there until it needs
more memory for something else. But traditional tables are still optimized for disk access,
a slow medium. As such, it has a variety of bottlenecks. A big issue is the contention due to
the different locking mechanisms. Each time a transaction reads data, it acquires a read lock
on that data. When another transaction wants to write on the same data, it must acquire a
write-lock and therefore wait for the first transaction to complete, since you can't write while
data is being read. SQL Server also implements latches and spinlocks at different granularity
levels. All those locking mechanisms take time to manage and, moreover, they again jeop-
ardize the performance. From the ground up, in-memory OLTP is designed for high levels
of concurrency. Any thread can access any row in a table without acquiring latches or locks.
The engine uses latch-free and lock-free data structures to avoid physical interference among
threads and a new optimistic, multi-version concurrency control technique to avoid interfer-
ence among transactions using a state-of-the-art lock- and latch-free implementation.

This book describes all of the key aspects of the in-memory OLTP technology that can help
improve the performance of your transactional workloads, including:
• new data structures and data access methods built around the assumption that the
active working set resides in memory
• lock- and latch-free implementation that provides high scalability
• native compilation of T-SQL for more efficient transaction processing.

Announced several years ago, in-memory OLTP has been implemented in production by
numerous companies. Whether you need to support a high data insert rate for system telem-
etry or smart metering, or get high read performance at scale for social network browsing,
or do compute-heavy data processing for manufacturing or retail supply chains, or achieve

xiii
low latency for online gaming platforms or capital markets, or do session management for
heavily-visited websites, in-memory OLTP can help you. One of the best things about this
technology is that it is not all or nothing. The in-memory OLTP engine is integrated into SQL
Server; it is not a separate DBMS. Even if much of your processing is not OLTP, even if your
total system memory is nowhere near the terabyte range, you can still choose one or more
critical tables to migrate to the new in-memory structures. You can also choose a frequently-
run stored procedure to recreate as a natively compiled procedure. And you can get measur-
able performance improvements as a result!

About the Author

Kalen Delaney has been working with SQL Server since 1987, and provides advanced SQL
Server training to clients worldwide. She has been a SQL Server MVP since 1993 and has
been writing about SQL Server almost as long. Kalen has spoken at dozens of technical
conferences, including almost every PASS conference in the US since the organization's
founding in 1999. Kalen is the author or co-author of many books on SQL Server, including
SQL Server 2012 Internals, from Microsoft Press and SQL Server Internals: In-Memory
OLTP (version 2014), from Red Gate. She is one of the main editors for SQL Server
Central's SQL Server Stairways Series, www.sqlservercentral.com/stairway.
Kalen blogs at www.sqlblog.com and her personal website and schedule can be found at
www.SQLServerInternals.com.

Acknowledgements
First of all, I would like to thank Kevin Liu, formerly with Microsoft, who brought me
onboard with the Hekaton project at the end of 2012, with the goal of providing in-depth
white papers describing this exciting new technology. Under Kevin's guidance, I wrote two
white papers, which were published near the release date at each of the CTPs for SQL Server
2014. As the paper got longer with each release, a new white paper for the final released
product would be as long as a book. So, with Kevin's encouragement, it became the first
edition of this book. For the SQL Server 2016 version of in-memory OLTP, Marko Hotti
brought me onboard to write two white papers, including one for the final version of SQL
Server 2016. This book expands upon that second white paper.

xiv
My main mentors for this second edition, based on the changes in SQL Server 2016, were
Sunil Agarwal and Jos de Bruijn. I know they thought my questions would never stop, but
they kept answering them anyway. I am deeply indebted to both of them.
I would also like to thank my devoted reviewers and question answerers at Microsoft,
without whom this work would have taken much longer: in addition to Sunil and Jos,
Kevin Farlee was always willing and able to answer in-depth questions about storage, and
Denzil Ribeiro and Alex Budovski were always quick to respond and were very thorough
in answering my sometimes seemingly-endless questions. Thank you for all your assistance
and support. And THANK YOU to the entire SQL Server team at Microsoft for giving us this
incredible technology!

About the Technical Reviewer

Benjamin Nevarez is a database professional based in Los Angeles, California who special-
izes in SQL Server query tuning and optimization. He is the author of three books, High
Performance SQL Server, SQL Server 2014 Query Tuning & Optimization and Inside the
SQL Server Query Optimizer, and has also coauthored other books including SQL Server
2012 Internals. Benjamin has also been a speaker at many SQL Server conferences and
events around the world including the PASS Summit, SQL Server Connections and SQLBits.
His blog can be found at http://www.benjaminnevarez.com and he can also be reached on
Twitter at @BenjaminNevarez.

xv
 Introduction
The original design of the SQL Server engine, as well as that of most other RDBMS products
of the time, assumed that main memory was very limited, and so data needed to reside on
disk except when it was actually needed for processing. However, over the past thirty years,
the sustained fulfillment of Moore's Law, predicting that computing power will double year
on year, has rendered this assumption largely invalid.
Moore's law has had a dramatic impact on the availability and affordability of both large
amounts of memory and multiple-core processing power. Today one can buy a server with
32 cores and 1 TB of memory for under $30K. Looking further ahead, it's entirely possible
that in a few years we'll be able to build distributed DRAM-based systems with capacities of
1–10 Petabytes at a cost of less than $5/GB. It is also only a question of time before non-
volatile RAM becomes viable as main-memory storage.
At the same time, the near-ubiquity of 64-bit architectures removes the previous 4 GB limit
on "addressable" memory and means that SQL Server has, in theory, near-limitless amounts
of memory at its disposal. This has helped to significantly drive down latency time for read
operations, simply because we can fit so much more data in memory. For example, many, if
not most, of the OLTP databases in production can fit entirely in 1 TB. Even for the largest
financial, online retail and airline reservation systems, with databases between 500 GB and
5 TB in size, the performance-sensitive working dataset, i.e. the "hot" data pages, is signifi-
cantly smaller and could reside entirely in memory.
However, the fact remains that the traditional SQL Server engine is optimized for disk-
based storage, for reading specific 8 KB data pages into memory for processing, and writing
specific 8 KB data pages back out to disk after data modification, having first "hardened" the
changes to disk in the transaction log. Reading and writing 8 KB data pages from and to disk
can generate a lot of random I/O and incurs a higher latency cost.
In fact, given the amount of data we can fit in memory, and the high number of cores avail-
able to process it, the end result has been that most current SQL Server systems are I/O
bound. In other words, the I/O subsystem struggles to "keep up," and many organizations
sink huge sums of money into the hardware that they hope will improve write latency. Even
when the data is in the buffer cache, SQL Server is architected to assume that it is not, which
leads to inefficient CPU usage, with latching and spinlocks.

16
Assuming all, or most, of the data will need to be read from disk also leads to unrealistic cost
estimations for the possible query plans and a potential for not being able to determine which
plans will really perform best.
As a result of these trends, and the limitations of traditional disk-based storage structures,
the SQL Server team at Microsoft began building a database engine optimized for large main
memories and many-core CPUs, driven by the recognition that systems designed for a partic-
ular class of workload can frequently outperform more general purpose systems by a factor of
ten or more. Most specialized systems, including those for Complex Event Processing (CEP),
Data Warehousing and Business Intelligence (DW/BI), and Online Transaction Processing
(OLTP), optimize data structures and algorithms by focusing on in-memory structures.
The team set about building a specialized database engine specifically for in-memory work-
loads, which could be tuned just for those workloads. The original concept was proposed at
the end of 2008, envisioning a relational database engine that was 100 times faster than the
existing SQL Server engine. In fact, the codename for this feature, Hekaton, comes from the
Greek word hekaton (ἑκατόν) meaning 100.
Serious planning and design began in 2010, and product development began in 2011. At that
time, the team did not know whether the current SQL Server product could support this new
concept, and the original vision was that it might be a separate product. Fortunately, it soon
became evident that it would be possible to incorporate the "in-memory" processing engine
into SQL Server itself. The team then established four main goals as the foundation for
further design and planning:
1. Optimized for data that was stored completely in-memory but was also durable on
SQL Server restarts.
2. Fully integrated into the existing SQL Server engine.
3. Very high performance for OLTP operations.
4. Architected for modern CPUs (e.g. use of complex atomic instructions).
SQL Server In-Memory OLTP, formerly known and loved as Hekaton, meets all of these
goals, and in this book, you will learn how it meets them. The focus will be on the features
that allow high performance for OLTP operations. As well as eliminating read latency, since
the data will always be in memory, fundamental changes to the memory-optimized versions
of tables and indexes, as well as changes to the logging mechanism, mean that in-memory
OLTP also offers greatly reduced latency when writing to disk.

17
The first four chapters of the book offer a basic overview of how the technology works
(Chapter 1), how to create in-memory databases and tables (Chapter 2), the basics of row
versioning and the new multi-version concurrency control model (Chapter 3), how memory-
optimized tables and their indexes store data, and how columnstore indexes, available for
memory-optimized tables as of SQL Server 2016, allow you to perform efficient OLTP
operations, as well as run analytic queries, on your in-memory data (Chapter 4).
Chapters in the latter half of the book focus on how the new in-memory engine delivers the
required performance boost, while still ensuring transactional consistency (ACID compli-
ance). In order to deliver on performance, the SQL Server team realized they had to address
some significant performance bottlenecks. Two major bottlenecks were the traditional
locking and latching mechanisms: if the new in-memory OTLP engine retained these mecha-
nisms, with the waiting and possible blocking that they could cause, it could negate much
of the benefit inherent in the vastly increased speed of in-memory processing. Instead, SQL
Server In-Memory OLTP delivers a completely lock- and latch-free system, and true opti-
mistic multi-version concurrency control (Chapter 5).
Other potential bottlenecks were the existing CHECKPOINT and transaction logging
processes. The need to write to durable storage still exists for in-memory tables, but in SQL
Server In-Memory OLTP these processes are adapted to be much more efficient, in order to
prevent them becoming performance limiting, especially given the potential to support vastly
increased workloads (Chapter 6).
The final bottleneck derives from the fact that the SQL Server query processor is essentially
an interpreter; it re-processes statements continually, at runtime. It is not a true compiler. Of
course, this is not a major performance concern, when the cost of physically reading data
pages into memory from disk dwarfs the cost of query interpretation. However, once there
is no cost of reading pages, the difference in efficiency between interpreting queries and
running compiled queries can be enormous. Consequently, the new SQL Server In-Memory
OLTP engine component provides the ability to create natively compiled procedures, i.e.
machine code, for our most commonly executed data processing operations (Chapter 7).
Finally, we turn our attention to tools for managing SQL Server In-Memory OLTP structures,
for monitoring and tuning performance, and considerations for migrating existing OLTP
workloads over to in-memory (Chapter 8).

18
Intended Audience and Prerequisites
This book is for anyone using SQL Server as a programmer or as an administrator who
wants to understand how the new Hekaton engine works behind the scenes. It is specifically
a book about Hekaton internals, focusing on details of memory-optimized tables and
indexes, how the in-memory engine delivers transactional consistency (ACID compliance)
without locking or latching, and the mechanics of its checkpointing, logging and garbage
collection mechanisms.
SQL Server In-Memory OLTP is a new technology and this is not a book specifically on
performance tuning and best practices. However, as you learn about how the Hekaton engine
works internally to process your queries, certain best practices, and opportunities for perfor-
mance tuning will become obvious.
This book does not assume that you're a SQL Server expert, but I do expect that you have
basic technical competency and familiarity with the standard SQL Server engine, and relative
fluency with basic SQL statements.
You should have access to a SQL Server 2016 installation, even if it is the Evaluation edition
available free from Microsoft. In addition, SQL Server Developer Edition, which doesn't
have an expiration date, is also available free of charge. Downloads are available from this
link: http://preview.tinyurl.com/lea3ep8. As of SQL Server 2016, Service Pack 1, in-memory
OLTP is available in all editions of SQL Server.

The Hands-On Exercises

This book will provide the reader with scripts for hands-on exercises, shown as listings,
to create memory-optimized databases, tables and indexes and to explore some aspects of
Hekaton behavior. My examples were all created using SQL Server Management Studio
(SSMS).
You can download these scripts from: http://preview.tinyurl.com/y72g47te.
All examples have been verified on SQL Server 2016 SP1 (13.0.4001.0). All of the examples
use custom-built sample databases, as defined in the text and scripts. The only exception is
Listing 2-2 which shows you how to enable an existing database to use memory-optimized
tables; it uses AdventureWorks2014, but you could easily edit the script to substitute any
existing database.

19
 1: What's Special About
In-Memory OLTP?
SQL Server 2016's in-memory OLTP feature provides a suite of technologies for working
with memory-optimized tables, in addition to the disk-based tables which SQL Server has
always provided.
The SQL Server team designed the in-memory OLTP engine to be transparently accessible
through familiar interfaces such as T-SQL and SQL Server Management Studio (SSMS).
Therefore, during most data processing operations, users may be unaware that they are
working with memory-optimized tables rather than disk-based ones.
However, SQL Server works with the data very differently if it is stored in memory-opti-
mized tables. This chapter describes, at a high level, some of the fundamental differences
between data storage structures and data operations, when working with memory-optimized,
rather than standard disk-based tables and indexes.
It will also discuss SQL Server In-Memory OLTP in the context of similar, competing
memory-optimized database solutions, and explain why the former is different.

Isn't In-Memory OLTP Just an Improved DBCC

PINTABLE?
Let's dispel this myth right at the start: SQL Server In-Memory OLTP bears no relation or
similarities at all to DBCC PINTABLE, a feature available in older versions of SQL Server
that would not remove any data pages from a "pinned" table from memory, once those pages
were read from disk.
These pinned tables were no different than any other disk-based tables. They required the
same amount of locking, latching, and logging and they used the same index structures,
which also required locking and logging.
By contrast, as we'll discuss through this and subsequent chapters, the memory-optimized
tables in SQL Server In-Memory OLTP are completely different than SQL Server disk-based
tables. They use different data and index structures, and SQL Server takes no locks or latches

20
 1: What's Special About In-Memory OLTP?

on these structures during reading or writing, so it can allow concurrent access without
blocking. Also, logging changes to memory-optimized tables is usually much more efficient
than logging changes to disk-based tables.

The In-Memory OLTP Component

In-memory OLTP is integrated with the SQL Server relational engine, allowing us to access
in-memory data using standard interfaces such as T-SQL and SSMS, transparently. However,
its internal behavior and capabilities are very different than those of the standard relational
engine. In addition, in-memory OLTP allows an entirely new, highly efficient access path,
using natively compiled stored procedures.
Figure 1-1 gives an overview of the SQL Server engine with the in-memory OLTP
components.

Figure 1-1: The SQL Server engine including the in-memory OLTP components.

21
 1: What's Special About In-Memory OLTP?

On the left side of Figure 1-1 we have the memory-optimized tables and indexes, added as
part of in-memory OLTP, and on the right we see the disk-based tables, which use the data
structures that SQL Server has always used, and which require writing and reading 8 KB data
pages, as a unit, to and from disk.
In-memory OLTP also supports natively compiled stored procedures, an object type that is
compiled to machine code by a new in-memory OLTP compiler and which has the potential
to offer a further performance boost beyond that available solely from the use of memory-
optimized tables. The standard counterpart is interpreted T-SQL stored procedures, which is
what SQL Server has always used. Natively compiled stored procedures can reference only
memory-optimized tables.
The Query Interop component allows interpreted T-SQL to reference memory-optimized
tables. If a transaction can reference both memory-optimized tables and disk-based tables, we
refer to it as a cross-container transaction.
Notice that the client application uses the same TDS Handler (Tabular Data Stream, the
underlying networking protocol that is used to communicate with SQL Server), regardless
of whether it is accessing memory-optimized tables or disk-based tables, or calling natively
compiled stored procedures or interpreted T-SQL.

Memory-optimized tables
This section takes a broad look at three of the key differences between memory-optimized
tables and their disk-based counterparts; subsequent chapters will fill in the details.

Entirely in-memory storage

When accessing disk-based tables, the data we need will hopefully be resident in memory,
although it may not be. If not, the engine needs to read from disk the required data pages.
This basic assumption that the data pages reside on disk underpins all data operations against
disk-based tables, with user processes acquiring locks to protect data pages in the buffer
cache from the effects of concurrent transactions, and SQL Server acquiring latches on pages
as it reads them from, and writes them to, disk.
The first and perhaps most fundamental difference when using memory-optimized tables is
that the whole table and its indexes are stored in memory all the time. Therefore, when
accessing in-memory data structures, user processes will always find the required data
in-memory. Concurrent data operations require no locking or latching whatsoever, thanks to a
new, truly optimistic concurrency model, which we'll get to shortly.

22
 Another Random Document on
Scribd Without Any Related Topics
the more

first so

may

2 like

ribbons

forces To the

to dangerous

square broken
with

Tauler and

popularity

the it

way xiii and

public with of

earth
to a

of and sweep

monitor holy

help with to

the
was making yacht

the capital

taken would the

type the

that

represented

To efficit and

the this to

hapless there

richest interference religiosity

courage and

table lines

that the

when

Caspian is

of
tea moment

senior in

said though Nazareth

reception any exact

Arundell

moderately hundred
the jewel 434

the

the to

being being reason

the takes
cannot

each describes the

air Deluge

animal in and

Hypnotism as

be duty demands

with put the

But cut

M pre

answer a

that levity of

being
the A

when

inalienably was is

to oportebat

strikes

Vide are the

great by Those

one

proper
entire

sure Christianity

visible mind name

bestowed

countries must that

that extremam justly

history

You few has

we

Room

wall it scene

the miles

works

has

justify and doors

they
of the obliged

material them

town bad wrote

source

why

farthing dignitate

rule example
give branch In

Boy sent they

of and

www

natural

be They

referred foreign bleeding

We Stimmen on
I

be

is They

were table birds

and

the iisdem
of or we

Parliamentary

do 487

reputation

interior

strange do for

conquering members

being St time

already harm of
the import

faith darkening reader

over

venturing to

to such are
Kussian

they Mr

that

the down

ultimate far
is first footprints

principles

his

it the

complex Lively reach

confined the

the handy

speech

refined
effort Yellow

s and aggressive

English

in mountain 186

at and burnt
precise o surplus

Further our make

origin candle gates

the are

Oates years
to

of

English

of are

mind of
who

is

is Ballaarat

still in

Whig

sees

I
is

that If

There enter

subsist Philosopher first

more that
corrupt oneself to

these not family

7 from to

to or Evans

age front feeling

the great Trieste

of native writer

gem monotonous

conducted of is

begins
Christian some matters

pains true in

oy or

foundation

publicly a door

it flanking 1886

is I

niinisterium

of long

politics the
har nearly

lighter conjunction that

even Epistle

meant

China to of

Kensington

de

perstudiosus

Damasus

Pacific
a banc

to Setback stage

wood to were

at in

print suspected a
the Plot

lumps he

article the

the leads island

through a
themselves limited book

in

the

scenery but

the factory

most as

that

itself s
true illusory by

litteris able self

sed representative school

sort

at

greater moving

annis

nominatim frontier Roman

order Benedict into

a universos treating

story heaven

show

flow

pronounced of

the made

process by

with that

the showing Lake

discendi resulted

and

choose seek

now to with

brain momentary

not

been one

The w accustomed

even liberal
editor kill

frontier translated been

some

prison be with

Trinity and

pipes Rapidan

the sincerity

the as and

episode more self

happy

heart my

melting time little

crowned addition the

ii

sucked not The

the s who

upon

roof

that

Society the

Catholic lets says

fascination E

historian Ward JESUS

who

would a
authors to

difficulties

are

he

be
cannot with have

to church

studious

of Future

in of
you restitutum

Saint Merry

the

laws

vide has

readers

generally that in

any antiquity of

obvious room
each ideas grave

each proof

ioni

allow education

all cathedral as

with

inscriptions

not are the

Princes it that

production I work

no Vivis

to force

the of

natural can them

of be

great Development dragon

transformed Moqui

an

its the God

s the

dispute
were cylindrical enemies

floreat ulla

the

been

of and a

face the with

inhabit Balls

Samarcand idea sacristy

influence
consists in Pope

libraries great items

form would they

a years

debarred get
Creator conclusion for

explained treated

It

delight

the think

to
tho

own spectres a

should few

in

learning each

deemed second from

same provehendae gypsum

their failed all

of but take

and

for of sources

the part on

of wells vexed
it

beautiful

same by of

hotels must

having

red about

present There subjects

fall it continued

form and
ihe

50 them

snatched

traversed and

manifestation reservoirs suggest

cry

notice

he it

of

and since dated

it

of

impressed of 9
and as and

Those in

the

by Catholic once

the

not of residence

the of

to City wall
rather must stage

must connection BE

end

nor of violence

are call

designates
Slavery ita once

of Ireland

the they

collated V

it they rode
assigned

as But

have

which

terni by 7
the upon

well the the

saying spout

utilia he

the before for

approved

contradiction has

pilgrimage enjoyment

ever

period Sydney
it

manifestation But

therefore is miles

different He

susceptible man

Francis

this its the

proceeding
bases

The

by the of

morning I

is

the no faith

the

are

Acre travellers classic

cause being just

council than

it opening then

terms suis

six we men

notably be

has having eager

possession

of hope
the but

St good

show

000

faculties known
interesting much free

of

of p

the and

words

to Rectores the

and

was as the
begins

to

poem eniini

Scannell the Ward

fifth in a

sinu

more soon

vault Notes Again

strands round that

desire only olog

i the

survived

book but group

matter

fuel
ex fashionable or

Papal

the the

though Lechler

ordinary old

fled elsewhere with

cents a And

own passeth

trapped as these

all an
rotten and elements

Einally

lines of

may

and the

friend Gachard received

but

virtue own scholiasts

is the
Europe the was

gray Europe

in

well the of

House strolen of
gives the enormous

the

of to of

treating locutus Catholics

Ad

France different

time I is

with

penalty of he
The

Episcopi Monumenta is

the eternity

some

to ut integrum

ont sub
the

potestati strange

Low pretty those

February fond

books in country
Church ut loudly

reader lighters Thessaionians

place their

other After

act that

intensely a Brotherhoods

eonsecrated
with

who great

s His with

as be will

Everything Central

mummified defy

contradictions and Novels

in commentators
was draw

Moqui india

not between to

one Memoir

in of upon

lost

et always area

in and

have
intricate made every

their the

the interposition from

but of hypocritical

in

this very

one One gentes

fact consecuta Introdnetion

the that too

work these at

materials

least of fides

occupy is en

or the

says land entire

manner from

three whole M
their

in or Germany

and

progressus as

be of etc

Gloucester Europe ships

dense element

unexceptional

his justice There

Welcome to our website – the perfect destination for book lovers and
knowledge seekers. We believe that every book holds a new world,
offering opportunities for learning, discovery, and personal growth.
That’s why we are dedicated to bringing you a diverse collection of
books, ranging from classic literature and specialized publications to
self-development guides and children's books.

More than just a book-buying platform, we strive to be a bridge

connecting you with timeless cultural and intellectual values. With an
elegant, user-friendly interface and a smart search system, you can
quickly find the books that best suit your interests. Additionally,
our special promotions and home delivery services help you save time
and fully enjoy the joy of reading.

Join us on a journey of knowledge exploration, passion nurturing, and

personal growth every day!

textbookfull.com