通过

监视 Azure SQL 托管实例中的内存中 OLTP 存储

  • 项目

适用于：Azure SQL 托管实例

通过内存中 OLTP，内存优化表中的数据和表变量驻留在内存中 OLTP 存储内。

确定数据是否在内存中 OLTP 存储容量限制范围内

“业务关键”服务层包括一定数量的最大内存中 OLTP 内存，由 vCore 数量决定。

估计内存优化表的内存要求的方式与在 Azure SQL 托管实例中估计 SQL Server 的内存要求的方式一样。 需要几分钟时间来查看估计内存要求。

表和表变量行以及索引都将计入最大用户数据大小。 此外，ALTER TABLE 需要足够的空间来创建新版的完整表及其索引。

一旦超过此限制，插入和更新操作可能会开始失败，并出现错误 41823。

更正内存不足 OLTP 存储的情况 - 错误 41823

数据库达到内存中 OLTP 存储上限会导致 INSERT、UPDATE、ALTER 和 CREATE 操作失败，并出现错误 41823。 该错误会导致活动的事务中止。

错误 41823 指示实例中的内存优化表和表变量已达到最大的内存中 OLTP 存储大小。

若要解决此错误，请执行以下操作之一：

  • 从内存优化表中删除数据，为此，可以将数据卸载到传统的基于磁盘的表；或者，
  • 为需要保留在内存优化表中的数据更新 vCore 计数，并添加内存中存储。

注意

在极少数情况下，错误 41823 可能是暂时的，即内存中 OLTP 存储的空间是足够的，重试后该操作成功。 因此，我们建议既要监视总体的可用内存中 OLTP 存储，又要在首次遇到错误 41823 时重试。 有关重试逻辑的详细信息，请参阅内存中 OLTP 的冲突检测和重试逻辑。

使用 DMV 进行监视

  • 通过定期监视内存消耗，可以确定内存消耗量的增长方式以及资源限制中留下的头空间量。 标识您的数据库或实例中对象所使用的内存量。 例如，DMV sys.dm_db_xtp_table_memory_stats 或 sys.dm_os_memory_clerks。

    • 您可以通过查询 sys.dm_db_xtp_table_memory_stats，查找所有用户表、索引和系统对象的内存使用情况：

      SELECT object_name(object_id) AS [Name], *  
   FROM sys.dm_db_xtp_table_memory_stats;

    • 管理分配给内存中 OLTP 引擎和内存优化对象的内存的方式与管理数据库中任何其他内存消耗者的方式完全相同。 MEMORYCLERK_XTP 类型的内存分配器计算分配给内存中 OLTP 引擎的所有内存。 对 ‭sys.dm_os_memory_clerks‬ 使用以下查询查找内存中 OLTP 引擎使用的所有内存，包括专用于特定数据库的内存。

      -- This DMV accounts for all memory used by the in-memory engine  
SELECT [type], [name]
     , memory_node_id  
     , pages_kb/1024 AS pages_MB   
FROM sys.dm_os_memory_clerks 
WHERE [type] LIKE '%xtp%';

      type                 name       memory_node_id pages_MB  
-------------------- ---------- -------------- --------------------  
MEMORYCLERK_XTP      Default    0              18  
MEMORYCLERK_XTP      DB_ID_5    0              1358  
MEMORYCLERK_XTP      Default    64             0

  • 还可以使用动态管理视图 sys.dm_os_out_of_memory_events 获取有关Azure SQL 托管实例内存不足错误的详细信息。 例如：

    SELECT * FROM sys.dm_os_out_of_memory_events ORDER BY event_time DESC;

    有关详细信息，请参阅监视和排查内存中 OLTP 内存使用情况问题。

相关内容