1. In-Memory OLTP for DBA Management
Sunil Agarwal
Principal Program Manager SQL Server

2. Session Objectives And Takeaways
Tech Ready 15
Session Objectives And Takeaways
5/28/2018
Session Objective(s):
Understand Memory/Storage management for in-memory tables as a DBA
Key Takeaway 1
Memory-optimized tables have new kind of indexes and structures and it must fit in memory
Key Takeaway 2
Memory-optimized tables are persisted very differently and require new considerations for storage and recovery
Key Takeaway 3
Familiar integrated experience for managing and configuring memory-optimized tables
This slide is required. Do NOT delete. This should be the first slide after your Title Slide. This is an important year and we need to arm our attendees with the information they can use to Grow Share! Please ensure that your objectives are SMART (defined below) and that they will enable them to go in and win against the competition to grow share. If you have questions, please contact your Track PM for guidance. We have also posted guidance on writing good objectives, out on the Speaker Portal (
This slide should introduce the session by identifying how this information helps the attendee, partners and customers be more successful. Why is this content important?
This slide should call out what’s important about the session (sort of the why should we care, why is this important and how will it help our customers/partners be successful) as well as the key takeaways/objectives associated with the session. Call out what attendees will be able to execute on using the information gained in this session. What will they be able to walk away from this session and execute on with their customers.
Good Objectives should be SMART (specific, measurable, achievable, realistic, time-bound). Focus on the key takeaways and why this information is important to the attendee, our partners and our customers.
Each session has objectives defined and published on please work with your Track PM to call these out here in the slide deck.
If you have questions, please contact your Track PM. See slide 5 in this template for a complete list of Tracks and TPMs.
© 2012 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista 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.

3. In-Memory Data Structures
Rows
New row format
Structure of the row is optimized for memory residency and access
No data page containers
Rows are versioned (payload never updated in place) – Delete/Insert
Indexes
Nonclustered Indexes only
Indexes point to physical rows. No need for covering columns
<nonclustered hash> index for point lookups.
<nonclustered> index for range (inequality) and ordered scans
Not logged and do not exist on disk – maintained online or recreated during recovery
No index fragmentation on disk

4. Memory-optimized Table: Row Format
TechEd 2013
5/28/2018 8:17 AM
Memory-optimized Table: Row Format
Row header
Payload (table columns)
Begin Ts
End Ts
StmtId
IdxLinkCount
8 bytes
4 bytes
2 + 2 (padding)
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 are not supported)
Total index count: hash+range <=8
© 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.

5. Memory Management Data resides in memory at all times
TechEd 2013
Memory Management
5/28/2018 8:17 AM
Data resides in memory at all times
Must configure SQL server with sufficient memory to store memory-optimized tables
Failure to allocate memory will fail transactional workload at run-time
Integrated with SQL Server memory manager and reacts to memory pressure for GC (Garbage Collection)
Guidance for SQL2014 is not to exceed 256GB of in-memory table user data
Integrated with Resource Governor
Recommend using dedicated resource pool
To ensure performance stability for disk-based table workloads
“Bind” a database to a resource pool
Memory-optimized tables cannot exceed the limit of the resource pool
Hard top limit (function of the physical memory) to ensure system remains stable under memory pressure
Describe
Memory allocated to the rows can’t be released. The memory is released when the row is stale (i.e. update or deleted)
Memory allocation is done in chunks of 64K (confirm with the team)
© 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.

6. Garbage Collection Stale Row Versions Garbage Collection (GC)
TechEd 2013
5/28/2018 8:17 AM
Garbage Collection
Stale Row Versions
Updates and deletes create row versions that (eventually) are no longer visible to any transaction
Slow down scans of index structures
Use 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 Design
Non-blocking, Cooperative, Efficient, Responsive, Scalable
Active transactions work cooperatively and pick up parts of GC work
A dedicated system thread for GC
Describe
When a row is deleted, is position in the hash table is not changed. So it can slow down the scan
inserted row is added to the head of the bucket.
How about the updated row? Though it is logged as delete/insert, does it get inserted at the start of the bucket?
© 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.

7. In-Memory Tables: Garbage Cleanup
Timestamps
Chain ptrs
Name
City
Hash index on Name
Hash index on City
f(Jane)
50, ∞
Jane
Prague
f(Prague)
f(John)
100, 200
John
Prague
f(Beijing)
200, ∞
John
Beijing
90, 150
Susan
Bogota
T250: Oldest Active Transaction Timestamp
Select * from <table> where name = ‘John’
Talking points:
A table is a collection of row versions – validity of a row version at a point in time is indicated by the timestamp
The buckets of a hash index are simply memory pointers to the first row in the bucket
All indexes on memory optimized tables are inherently covering
No separate clustered index – table/index structure different from b-trees/heaps in disk-based tables
No bookmark lookup
All row versions in the bucket are chained together into a linked list
Jane and John are in the same bucket “J”; thus the last row version of “John” points to the first row version of “Jane”
A second index is again a collection of pointers to rows. In this case to the cities Beijing and Paris
Again, rows in each bucket are chained through pointers between the rows – as you can see in this example, different indexes can have different chains of row versions in their buckets
The Hekaton Garbage collector periodically removes row versions that are no longer valid for any active transaction – this means, e.g., that long-running transactions can force a lot of old row versions to stay in memory, and, e.g., cause memory pressure – discussed later in the DBA section of this presentation
Automatic Garbage Collection kicks in

8. Demo – Memory Management

9. Memory Usage and Monitoring
TechReady 16
5/28/2018
Memory Usage and Monitoring
Table Data
Rule of thumb: 2 x data_size for physical memory allocation due to versioning overhead
Index Data
Nonclustered Hash index:
Fixed size (bucket_count*8B)
Nonclustered (Range) index:
Variable size (Key columns+8B)
Considerations
Configuration
Use resource governor
Monitoring
Use DMVs, SMO, SSMS and SSMS reports
Management
Regular SQL table can be larger in size than size of memory, but not memory optimized tables. Table data must fit in memory
Data size is (row size) x (number of rows).
Overhead per row: row header, nulls, offsets for variable length columns.
Overhead for memory allocation: system allocates in chunks.
Headroom for row versions: depends on workload; consider if application has of lot of updates, long running transactions, lag in garbage collector.
Indexes store only memory pointers – no copies of index keys or primary keys.
Binding can be created between database and Resource Governor resource pool.
Max and Min Memory can be configured for the resource pool.
Binding governs memory used by “Hekaton” objects only.
Certain percentage of available memory is always reserved for non-Hekaton usage.
New DMVs for memory consumed by “Hekaton” at table, database and server levels, Existing DMVs for memory consumed by SQL.
New/existing properties in SMO/SSMS for memory consumed by “Hekaton” at table, database and server levels.
New reports for memory consumed at Server and Database levels.
sys.sp_xtp_bind_db_resource_pool database_name pool_name  
© 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.

10. Disk-Based Tables – Storage Revisited
Page based
Latch contention due to concurrent access
Random IO when modified page is flushed to disk
Checkpoint can flood the IO and can cause temporary glitch in the workload
Transaction Log
Each change to the data and index row is logged separately

11. Durability Memory-optimized tables can be durable or non-durable
TechEd 2013
5/28/2018 8:17 AM
Durability
Memory-optimized tables can be durable or non-durable
Default is ‘durable’
Non-durable tables are useful for transient data (“relational” cache scenario)
Only Committed transactions are logged
A common system bottleneck; SSD or Fusion-IO recommended
Index changes are not logged
Delayed durability support – define at the SP/Transaction level
Durable tables are persisted in memory-optimized filegroup
File Stream based with checksum
Filegroup can have multiple containers (volumes) and with multiple files in each container
Storage used for memory-optimized has a different access pattern (Sequential IO)
Recommend SSD or fast (15K e.g.) SAS drives
© 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.

12. Storage in Memory-Optimized Filegroup
TechReady 17
Storage in Memory-Optimized Filegroup
5/28/2018
Data files
For machines <=16GB memory – size 16MB.
For larger machines – 128MB
Writes in 256KB chunks at a time
Stores only the inserted rows (i.e. table content)
Chronologically organized streams of row versions
Delta files
For machines <=16GB memory – size 1MB. For larger machines – 8MB
Writes in 4KB chunks at a time.
Stores IDs of deleted rows
© 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.

13. Storage: Data and Delta Files
TechEd 2013
Storage: Data and Delta Files
5/28/2018 8:17 AM
100
Transaction 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
Data file contains rows inserted
within a given transaction range
Checkpoint File Pair
Delta File
TS (ins)
RowId
TS (del)
Delta file contains deleted rows
within a given transaction range
© 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.

14. Populating Data/Delta files
TechEd 2013
5/28/2018 8:17 AM
Populating Data/Delta files
SQL Transaction log (from LogPool)
Del Tran1(TS150)
Del Tran1 (row TS150)
Log in disk Table
Del Tran2 (row TS 450)
Del Tran2 (TS 450)
Del Tran3 (row TS 250)
Del Tran3 (TS 250)
Insert into T1
Insert into Hekaton T1
Data file has pre-allocated size (128 MB or 16 MB on smaller systems)
Engine switches to new data file when the current file is full
Transaction does not span data files
Once a data file is closed, it becomes read-only
Row deletes are tracked in delta file
Files are append only
Offline Checkpoint Thread
Delete 150 TS
Delete 250 TS
Delete 450 TS
New Inserts
Memory-optimized Table Filegroup
Range
Range
Range
Range
Range 500-
Data file with rows generated in timestamp range
IDs of Deleted Rows (height indicates % deleted)
Most of the time, the checkpoint will be reading log from memory
Rows inserted as part of 1 transaction is contained in 1 data files and deletes across multiple delta
© 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.

15. Merge Operations What is a Merge Operation? Need for Merge
TechReady 17
5/28/2018
Merge Operations
What is a Merge Operation?
Merges one 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 freespace
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
Merge is a (non-blocking) background operation
© 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.

16. Merge Operation Files as of Time 500 Files as of Time 600 TechEd 2013
5/28/2018 8:17 AM
Merge Operation
Files as of Time 500
Files as of Time 600
Memory-optimized data Filegroup
Memory-optimized data Filegroup
Range
Range
Range
Range
Range
Range
Range
Range
Range
Range
Range
Range
Merge
Data file with rows generated in timestamp range
IDs of Deleted Rows (height indicates % deleted)
Files Under Merge
Deleted Files
© 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.

17. Backup for Memory-Optimized Tables
TechEd 2013
5/28/2018 8:17 AM
Backup for Memory-Optimized Tables
Integrated with SQL Database Backup
Memory-Optimized file group is backed up as part SQL database backup
Differential backup supported – only new data files since last full backup
Piecemeal backups supported
Existing backup scripts work with no changes
Transaction log backup includes memory-optimized log records transparently
© 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.

18. In-Memory OLTP: Recovery
TechReady 17
5/28/2018
In-Memory OLTP: Recovery
Impact on RTO
Load speed (IO) of data & Size of durable tables
Hash index with heavy collision (bucket count too low) and large nonclustered (Range) index have additional recovery overhead.
Memory
Optimized Tables
Recovery Data Loader
Recovery Data Loader
Recovery Data Loader
filter
filter
filter
Delta map
Delta map
Delta map
Data
File1
Delta
File1
Data
File2
Delta
File2
Data
File3
Delta
File3
Memory Optimized Container - 1
Memory Optimized Container - 2
© 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.

19. Storage Considerations
TechReady 16
5/28/2018
Storage Considerations
Capacity
Capacity needed up to 4x size of durable memory optimized tables
Performance
Use sequential bandwidth sufficient to meet RTO
SSD Array or high end spinning media (15K SAS Array e.g.)
Data
Capacity
Log size is less than disk based tables but still ~ size of data change
Performance
Latency is important
(PCIe) SSD Array
Consider Delayed Durability for higher latency devices
Log
Size of file is fixed (128MB) and max number of data files is fixed (4096). So 512 GB of data storage.
Additional headroom: for delta files, for result of merge.
Sequential I/O bandwidth is sufficient to read all data and delta files within the desired RTO .
Files can be loaded in parallel; spread checkpoint files across multiple disks to reduce recovery time;
“Hekaton” Log Record
Not created for non durable memory optimized tables, index operations.
Created for committed transactions only.
Stored in same transaction log as regular SQL tables.
Insert logs entire row, Delete logs primary key, Update logs primary key and entire updated row.
Per transaction log consumption is less than current SQL Server – UNDO information is not stored
For perf-sensitive workloads, latency is key; use SSD for log.
© 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.

20. In-Memory OLTP: High Availability
AlwaysOn Failover Clustering
Fully Supported
AlwaysOn Availability Group
All configuration Supported
Data is kept in-memory on the Secondary Replica. Instant failover
Offload query workload to Readable Secondary
Backups can be offloaded to Secondary Replica
Transaction Replication
Only supported as subscriber

21. Demo- Storage

22. Session Objectives And Takeaways
Tech Ready 15
Session Objectives And Takeaways
5/28/2018
Session Objective(s):
Understand Memory/Storage management for in-memory tables as a DBA
Key Takeaway 1
Memory-optimized tables have new kind of indexes and structures and it must fit in memory
Key Takeaway 2
Memory-optimized tables are persisted very differently and require new considerations for storage and recovery
Key Takeaway 3
Familiar integrated experience for managing and configuring memory-optimized tables
This slide is required. Do NOT delete. This should be the first slide after your Title Slide. This is an important year and we need to arm our attendees with the information they can use to Grow Share! Please ensure that your objectives are SMART (defined below) and that they will enable them to go in and win against the competition to grow share. If you have questions, please contact your Track PM for guidance. We have also posted guidance on writing good objectives, out on the Speaker Portal (
This slide should introduce the session by identifying how this information helps the attendee, partners and customers be more successful. Why is this content important?
This slide should call out what’s important about the session (sort of the why should we care, why is this important and how will it help our customers/partners be successful) as well as the key takeaways/objectives associated with the session. Call out what attendees will be able to execute on using the information gained in this session. What will they be able to walk away from this session and execute on with their customers.
Good Objectives should be SMART (specific, measurable, achievable, realistic, time-bound). Focus on the key takeaways and why this information is important to the attendee, our partners and our customers.
Each session has objectives defined and published on please work with your Track PM to call these out here in the slide deck.
If you have questions, please contact your Track PM. See slide 5 in this template for a complete list of Tracks and TPMs.
© 2012 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista 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.