This document discusses in-memory technologies in Microsoft SQL Server including: 1) In-memory columnstore indexes that can provide over 100x faster query speeds and significant data compression. 2) In-memory OLTP that provides up to 30x faster transaction processing. 3) Using memory technologies to provide faster insights, queries, and transactions for analytics and operational workloads.

2. Velkommen og Microsoft har en
touchskærm :-D
ErlingSkaale
TSP
Microsoft
eskaale@microsoft.com

3. Todays menu
• In-memory tables
• Who and when
• What and how
• Updateable columnstore
• Clustered
• Hybrid and the Cloud

4. Drive Real-Time Business with Real-Time Insights
Over 100x query speed and
significant data compression with
In-Memory ColumnStore
Up to 30x faster transaction
processing with In-Memory OLTP
Greater
performance
with In-Memory
Analysis Services
Billions of rows
per second with
PowerPivot
In-Memory for
Excel
4
Faster Insights
IN-MEMORY ANALYTICS
Faster Queries
IN-MEMORY DW
Faster Transactions
IN-MEMORY OLTP

5. Key Benefits
Optimized table structures
No locks or latches with
100% data durability
Up to 30x transactional
performance gains
In-Memory for Increased Throughput & Speed
16x
faster transactions
“To describe Hekaton
in two words, it’s wicked fast.”
Rick Kutschera, Bwin
Before After
Greater throughput
with no locks or latches
OLTP
Stored
Procedures
30x faster
transactions
Natively compile
stored procedures
in-memory
App
5
35x
faster transactions

6. Business Challenge
Key Benefits

7. SQL Server Integration
• Same manageability,
administration &
development experience
• Integrated queries &
transactions
• Integrated HA and
backup/restore
Main-Memory
Optimized
• Optimized for in-memory
data
• Indexes (hash and range)
exist only in memory
• No buffer pool
• Stream-based storage for
durability
High Concurrency
• Multi-version optimistic
concurrency control with full
ACID support
• Core engine uses lock-free
algorithms
• No lock manager, latches or
spinlocks
T-SQL Compiled to
Machine Code
• T-SQL compiled to machine
code via C code generator
and VC
• Invoking a procedure is just
a DLL entry-point
• Aggressive optimizations @
compile-time
Steadily declining memory
price, NVRAM
Many-core processors Stalling CPU clock rate TCO
Hardware Trends Business
Hybrid Engine and
Integrated Experience
High Performance Data
Operations
Frictionless Scale-Up Efficient, Business-Logic
Processing
BenefitsIn-MemoryOLTPTechPillarsDrivers
In-Memory OLTP arkitektur

8. Main-Memory
Optimized
• Optimized for in-memory
data
• Indexes (hash and range)
exist only in memory
• No buffer pool
• Stream-based storage for
durability
Steadily declining memory
price, NVRAM
Hardware trends
Table Constructs
Fixed schema – no ALTER TABLE, must drop/recreate/reload
No LOB datatypes; row size limited 8060
No constraints support (PK only)
No Identity or Calculated columns, CLR etc…
Data and table size considerations
Size of tables = (row size * # of rows)
Size of hash index = (bucket_count * 8-bytes)
Max size SCHEMA_AND_DATA = 512 GB
IO for Durability
SCHEMA_ONLY vs. SCHEMA_AND_DATA
Memory Optimized Filegroup
Data and Delta files
Transaction Log
Database Recovery
Memory Optimized Tables – Design Considerations
8
High performance data
operations
BenefitsIn-MemoryOLTPTechPillarsDrivers

9. Memory optimeret table vs
normal

10. Indexing Memory-Optimized Tables
Memory Optimized tables support two types of indexes:
•Non-Clustered Hash Index: This is a memory optimized index, it does not support inequality
operators as well as sort-order matching operations.
•Non-Clustered Index: This is a disk based index, fully supports all normal index operations.
The bucket_count index parameter on a Non-Clustered Hash Index dictates the size of the Hash table
allocated for the index. This parameter needs to be set carefully, as it will affect the performance of the
Memory Optimized table. Higher bucket count could lead to larger memory utilization and longer scans,
lower bucket count could lead to performance degredation on lookups and inserts. Microsoft
recommends the bucket_count should be twice the maximum number of unique index keys.

11. Indexing Memory-Optimized Tables
There are a few stipulations for creating indexes on Memory-Optimized tables:
•Only 8 indexes are allowed on a Memory Optimized table
•Indexes cannot be added to a Memory Optimized table, instead the table has to be dropped and re-created
with the new index.
•Primary Key is a requirement for Memory Optimized tables.
•All indexes are covering, which means they include all columns in a table.
•Indexes reference the (hashed) row directly, rather than referencing the Primary Key.

12. Statistics Maintenance on Memory-Optimized
Tables
Statistics behaves slightly differently on In-Memory tables compared to disk-based tables, there are a few things
to remember here:
•Statistics are not updated automatically, it is recommended to setup a manual regular statistics update
operation on your Memory-Optimized table.
•sp_updatestats always runs a statistics update, unlike disk-based table were sp_updatestats only updates
statistics if there has been modifications since last run.
•Statistics update must always be specified as FULLSCAN update, rather than SAMPLED.
•Index key statistics are created when the table is empty, it is recommended to always update statistics after
ETL.
• Natively Compiled stored procedures need to be recreated when statistics are updated, this is because
execution plans for Natively Compiled stored procedures consider statistics only once, when the SPs are
created.

13. Native Compiled Stored Proc - Migration

14. Accessing Memory Optimized
Tables
• Natively compiled stored
procedures
• Access only memory optimized tables
• Maximum performance
• Limited T-SQL surface area
• When to use
• OLTP-style operations
• Optimize performance critical business logic
• Interpreted T-SQL access
• Access both memory- and disk-based tables
• Less performant
• Virtually full T-SQL surface area
• When to use
• Ad hoc queries
• Reporting-style queries
• Speeding up app migration

15. Clustered Columnstore Index

16. Clustered Columnstore Index

17. Clustered Columnstore Index

18. Cloud Backup (SQL Server 2014)
• What’s being delivered
• An agent that manages and automates SQL Server backup policy
• Main benefit
• Large scale management and no need to manage backup policy
• Context-aware – e.g. workload/throttling
• Minimal knobs – control retention period
• Manage whole instance, or particular DBs
• Leverage Backup to Azure
• Inherently off-site
• Geo-redundant
• Minimal storage costs
• Zero hardware management
Example:
EXEC smart_admin.sp_set_db_backup
@database_name='TestDB',
@storage_url=<storage url>,
@retention_days=30,
@credential_name='MyCredential',
@enable_backup=1

19. Hybrid Cloud Solutions

20. • An event can cause on-premises SQL Server to become unavailable
• Temporarily (e.g. gateway failure)
• Permanently (e.g. flooding)
• A disaster recovery site is expensive
• Site rent + maintenance
• Hardware
• Ops
Why Do We Need Cloud DR for
SQL Server?