In-Memory OLTP (online transactional processing) provides quick data access to Azure SQL databases by keeping tables in memory. Since the entire table has to fit in memory, In-Memory OLTP Storage must be monitored to avoid running out of memory. Blue Matador automatically monitors the xtp_storage_percent metric for all SQL databases so that you can be warned with free memory is low.
Effects
Running out of in-memory OLTP storage will cause INSERT, UPDATE, ALTER and CREATE operations to fail on tables stored in-memory. Active transactions will abort with error message 41823 for single databases and 41840 for elastic pools.
Fixes
One fix is to free up memory by deleting data from memory-optimized tables and moving it to tables that are stored on disk.
The other fix is to increase capacity by upgrading your service tier. The service tier limits can be found on the following pages:
When using in-memory OLTP storage with elastic pools, it is important to remember that the amount of OLTP storage is tied to the allocated eDTUs or vCore’s for a database. You should configure the minimum eDTU and vCore settings for the databases in your elastic pool to be at least 1, and the maximum to be less than the size of the elastic pool to help control where in-memory OLTP storage will be allocated in an elastic pool.
