␡
- Overview of In-Memory OLTP
- In-Memory Optimization Requirements
- Limitations of In-Memory OLTP
- Using In-Memory OLTP
- Using Memory-Optimized Tables
- Logging, Checkpoint, and Recovery for In-Memory OLTP
- Managing Memory for In-Memory OLTP
- Backup and Recovery of Memory-Optimized Databases
- Migrating to In-Memory OLTP
- Dynamic Management Views for In-Memory OLTP
- The Buffer Pool Extension
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
This chapter is from the book
Limitations of In-Memory OLTP
Given its memory-intensive nature, and the fact that this is the first release of the feature, there are a number of restrictions for using the In-Memory OLTP engine. Primarily, a memory-optimized table can only have columns of these supported data types:
- bit
- tinyint, smallint, int, bigint
- money, smallmoney
- float, real
- datetime, smalldatetime, datetime2, date, time
- numeric, decimal
- char(n), varchar(n), nchar(n), nvarchar(n), sysname
- binary(n), varbinary(n)
- Uniqueidentifier
The following data types are not supported by memory-optimized tables:
- datetimeoffset
- geography
- hierarchyid
- image
- ntext, text
- sql_variant
- varchar(max), varbinary(max)
- xml
- User data types (UDTs)
In addition, the maximum row length of a memory-optimized table is limited to 8060 bytes. The 8060 byte limit is enforced at table-creation time, so unlike a disk-based table, a memory-optimized tables with two varchar(5000) columns could not be created.
In addition, there are a number of database features that aren’t supported for memory-optimized databases or tables, including:
- Database mirroring
- Database snapshots
- Using DBCC CHECKDB and DBCC CHECKTABLE
- Computed columns
- Triggers
- FOREIGN KEY, CHECK, and UNIQUE constraints
- FILESTREAM storage
- ROWGUIDCOL
- Clustered indexes
- COLUMNSTORE indexes
- Data compression
- Multiple Active Result Sets (MARS)
- Change Data Capture (CDC)