Select Page

Top 2 LOBs Enhancements with Memory Optimized and Native Compilations

Author: Eric Russo | | June 15, 2016

SQL Server 2014 was the first release of SQL Server with the In-Memory OLTP feature. This feature allows us to create a table in the database that would reside in the memory. Even though it is a memory resident table, it would comply with ACID properties of a transaction and be guaranteed to provide a “no-data-loss” scenario. There were two ways to access In-Memory tables via T-SQL: either use an adhoc query called “interpreted method”, or use a stored procedure called “natively compiled”. As per Microsoft marketing sessions, this can create a performance boost of up to 30 times if In-Memory tables are accessed using a natively compiled stored procedure, but the codeword used is Heckaton (100 times faster). We all know how marketing works and I took a conservative 30 times as acceptable.

There were many limitations when this feature was first release in SQL Server 2014. This was one of the most marked and incompletely cooked features and was called as version 1 (v1) of In-Memory OLTP. Here is quick list of a few of the limitations in SQL Server 2014:

  • High-throughput limitations
    • No DML triggers
    • No XML and no CLR data types
  • Column limitations
    • Rows are at most 8060 bytes – no off row data
    • No Large Object (LOB) types like varchar(max)
  • 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
    • A maximum of 8 indexes, including the index supporting the PRIMARY KEY

There are many limitations which are being lifted by SQL Server 2016. This blog will demonstrate two of the most wanted features: LOBs and Native Compilation.

LOBs enhancement

LOB stands of Large Objects which can be defined in SQL Server which is used to store binary data, image data etc. There are various data types which support large objects such as TEXT, NTEXT, IMAGE, VARCHAR(MAX), NVARCHAR(MAX), VARBINARY etc.

If we try to create the below In-Memory table in SQL Server 2014, it would fail with an error.



       [ID] [int] IDENTITY(1,1)NOTNULL,

       [Date] [datetime] NOTNULL,

       [Status] [tinyint] NOTNULL,

       [Tax] [money] NOTNULL,

       [Comment] [nvarchar](max)NULL,


       WITH (BUCKET_COUNT= 10000)




Msg 10794, Level 16, State 84, Line 1

The type ‘nvarchar(max)’ is not supported with memory optimized tables.

SQL SERVER 2016Since VARCHAR(MAX) is now supported, the table is created without any error.

This enhancement would allow architects to move tables which have VARCHAR(MAX) data types to be in-memory tables.

Native Compilation Enhancements

As explained in brief, we can access In-memory tables using Interpreted method or via natively compiled stored procedures. Here is the sample of natively compiled stored procedure.

create table dbo.OrderTable

(OrderNumber integer not null primary key nonclustered,

CustomerCode datetime not null,

OrderDate nvarchar(5) not null,

comments varchar(max)


with (memory_optimized=on)


create procedure dbo.SampleNativelyCompiled(@OrderNo integer, @CustomerCode varchar(100))

with native_compilation, schemabinding, execute as self


begin atomic with

(transaction isolation level = snapshot,

language = N'English')

declare @OrderDate datetime = getdate();

declare @Comments varchar(max) = 'From WebSite';

insert into dbo.OrderTable(OrderNumber, CustomerCode, OrderDate, Comments) values (@OrderNo, @CustomerCode, @OrderDate,@Comments);



If we run above piece of code in a database which is enabled for In-Memory, we get below error

Msg 10794, Level 16, State 84, Procedure SampleNativelyCompiled, Line 18

The type ‘varchar(max)’ is not supported with natively compiled stored procedures.

If we create same procedure in SQL Server 2016, it works without any error.

In short, along with column name in table, SQL Server 2016 also supports LOB types [varchar(max), nvarchar(max), and varbinary(max)] for parameters and variables for natively compiled stored procedures.

Datavail Script: Terms & Conditions

By using this Oracle upgrade software script (“Script”), you are agreeing to the following terms and condition, as a legally enforceable contract, with Datavail Corporation (“Datavail”). If you do not agree with these terms, do not download or otherwise use the Script. You (which includes any entity whom you represent or for whom you use the Script) and Datavail agree as follows:

1. CONSIDERATION. As you are aware, you did not pay a fee to Datavail for the license to the Script. Consequently, your consideration for use of the Script is your agreement to these terms, including the various waivers, releases and limitations of your rights and Datavail’s liabilities, as setforth herein.

2. LICENSE. Subject to the terms herein, the Script is provided to you as a non-exclusive, revocable license to use internally and not to transfer, sub-license, copy, or create derivative works from the Script, not to use the Script in a service bureau and not to disclose the Script to any third parties. No title or other ownership of the Script (or intellectual property rights therein) is assigned to you.

3. USE AT YOUR OWN RISK; DISCLAIMER OF WARRANTIES. You agree that your use of the Script and any impacts on your software, databases, systems, networks or other property or services are solely and exclusively at your own risk. Datavail does not make any warranties, and hereby expressly disclaims any and all warranties, implied or express, including without limitation, the following: (1) performance of or results from the Script, (2) compatibility with any other software or hardware, (3) non-infringement or violation of third party’s intellectual property or other property rights, (4) fitness for a particular purpose, or (5) merchantability.


You hereby release Datavail from any claims, causes of action, losses, damages, costs and expenses resulting from your downloading or other use of the Script.

5. AGREEMENT. These terms and conditions constitute your complete and exclusive legal agreement between you and Datavail.

How to Solve the Oracle Error ORA-12154: TNS:could not resolve the connect identifier specified

The “ORA-12154: TNS Oracle error message is very common for database administrators. Learn how to diagnose & resolve this common issue here today.

Vijay Muthu | February 4, 2021

Data Types: The Importance of Choosing the Correct Data Type

Most DBAs have struggled with the pros and cons of choosing one data type over another. This blog post discusses different situations.

Craig Mullins | October 11, 2017

How to Recover a Table from an Oracle 12c RMAN Backup

Our database experts explain how to recover and restore a table from an Oracle 12c RMAN Backup with this step-by-step blog. Read more.

Megan Elphingstone | February 2, 2017

Subscribe to Our Blog

Never miss a post! Stay up to date with the latest database, application and analytics tips and news. Delivered in a handy bi-weekly update straight to your inbox. You can unsubscribe at any time.

Work with Us

Let’s have a conversation about what you need to succeed and how we can help get you there.


Work for Us

Where do you want to take your career? Explore exciting opportunities to join our team.