使用 Azure SQL 数据库中的内存中 OLTP 提高应用程序性能

项目
11/11/2024

内存中 OLTP 可以用来提高事务处理、数据引入以及暂时性数据应用场景的性能，而不会增加数据库或弹性池的服务目标。

高级 (DTU) 和业务关键 (vCore) 服务层级中的数据库和弹性池支持内存中 OLTP。
超大规模服务层级支持内存中 OLTP 对象的子集，但不包括内存优化表。有关详细信息，请参阅超大规模限制。

请按照以下步骤开始在现有数据库中使用内存中 OLTP。

步骤 1：确保使用的是高级和业务关键层数据库

如果以下查询的结果是 1（而不是 0），则支持内存中 OLTP：

SELECT DATABASEPROPERTYEX(DB_NAME(), 'IsXTPSupported');

XTP 代表极端事务处理，这是内存中 OLTP 功能的非正式名称。

步骤 2：标识要迁移到 In-Memory OLTP 的对象

SQL Server Management Studio (SSMS) 包含可以针对具有活动工作负荷的数据库运行的“事务性能分析概述”报告。该报告识别要迁移到内存中 OLTP 的候选表和存储过程。

若要在 SSMS 中生成报告，请执行以下操作：

在“对象资源管理器”中，右键单击数据库节点。
单击“报告”>“标准报告”>“事务性能分析概述”。

有关评估内存中 OLTP 优势的详细信息，请参阅确定表或存储过程是否应移植到内存中 OLTP。

步骤 3：创建可比较的测试数据库

假设报告指出数据库的某个表在转换成内存优化的表后会带来好处。我们建议先进行测试，以确认这项指示。

需要创建生产数据库的测试副本。测试数据库应当位于与生产数据库相同的服务层级级别。

为了简化测试，请按以下方式调整测试数据库：

使用 SQL Server Management Studio (SSMS) 连接到测试数据库。
若要避免在查询中用到 WITH (SNAPSHOT) 选项，请按照以下 T-SQL 语句中所示设置当前数据库的 MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT 选项：
```
ALTER DATABASE CURRENT SET MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT = ON;
```

步骤 4：迁移表

必须创建并填充想要测试的表的内存优化副本。可以使用以下方式之一来创建该副本：

SSMS 中的内存优化向导。
使用 T-SQL 命令。

SSMS 中提供的内存优化向导

若要使用此迁移选项，请执行以下操作：

使用 SSMS 连接到测试数据库。
在“对象资源管理器”中，右键单击该表，然后选择“内存优化顾问”。

此时将显示“表内存优化顾问”向导。
在向导中，选择“迁移验证”（或“下一步”按钮），查看该表是否包含任何在内存优化表中不受支持的功能。有关详细信息，请参阅：
- 内存优化顾问中的内存优化清单。
- 内存中 OLTP 不支持的 Transact-SQL 构造。
- 迁移到内存中 OLTP。
如果该表没有不受支持的功能，顾问可执行实际的架构和数据迁移。

手动 T-SQL

若要使用此迁移选项，请执行以下操作：

使用 SSMS 连接到测试数据库。
获取表及其约束和索引的完整 T-SQL 脚本。
- 在 SSMS 中，右键单击表节点。
- 选择“编写表脚本为”>“创建到”>“新建查询窗口”。
在脚本窗口中，将 WITH (MEMORY_OPTIMIZED = ON) 添加到 CREATE TABLE 语句。有关详细信息，请参阅内存优化表的语法。
如果存在 CLUSTERED 索引，请将其更改为 NONCLUSTERED。
使用 sp_rename 重命名现有表。
通过运行已编辑的 CREATE TABLE 脚本，创建新的内存优化表副本。

使用 INSERT...SELECT * INTO 将数据复制到内存优化表：

INSERT INTO [<new_memory_optimized_table>]
SELECT * FROM [<old_disk_based_table>];

步骤 5（可选）：迁移存储过程

内存中 OLTP 还支持本机编译的存储过程，这可提高 T-SQL 性能。

本机编译存储过程的注意事项

本机编译存储过程的 T-SQL WITH 子句必须包含以下选项：

NATIVE_COMPILATION：表示过程中的 Transact-SQL 语句都编译为本机代码，以便高效执行。
SCHEMABINDING：意味着存储过程中引用的表的定义不能以任何会影响存储过程的方式发生改变，除非删除该存储过程。

本机编译的模块必须使用一个 ATOMIC 块进行事务管理。没有使用显式 BEGIN TRANSACTION 或 ROLLBACK TRANSACTION 语句。代码可以使用 THROW 语句终止 ATOMIC 块，例如如果它检测到业务规则违规。

本机编译的存储过程示例

创建本机编译存储过程的 T-SQL 类似于以下模板：

CREATE PROCEDURE schemaname.procedurename
    @param1 type1, ...
    WITH NATIVE_COMPILATION, SCHEMABINDING
    AS
        BEGIN ATOMIC WITH
            (
            TRANSACTION ISOLATION LEVEL = SNAPSHOT,
            LANGUAGE = N'<desired sys.syslanuages.sysname value>'
            )
        ...
        END;

对于 TRANSACTION_ISOLATION_LEVEL，SNAPSHOT 是本机编译存储过程最常用的值。但是，也支持其他值的子集：
- REPEATABLE READ
- SERIALIZABLE
值 LANGUAGE 必须存在于 sys.syslanguages 视图的 name 列中。例如，N'us_english'。

如何迁移存储过程以使用本机编译

迁移步骤如下：

获取常规（解释）存储过程的 CREATE PROCEDURE 脚本。
重写其标头以符合前面的模板。
确定存储过程 T-SQL 代码是否使用了任何不支持本机编译存储过程的功能。根据需要实施应对措施。有关详细信息，请参阅本机编译存储过程的迁移问题。
使用 sp_rename 重命名旧的存储过程，或者将其删除。
执行已编辑的 CREATE PROCEDURE T-SQL 脚本。

步骤 6：在测试环境中运行工作负荷

在测试数据库中，运行与在生产数据库中运行的工作负荷类似的工作负荷。这样，将内存中 OLTP 用于表和存储过程所达到的性能提升应可体现出来。

工作负荷的主要属性包括：

并发连接数。
读/写比率。

若要定制和运行测试工作负载，请考虑使用 RML 实用程序组中的 ostress.exe 工具。有关详细信息，请参阅 Azure SQL 数据库中的内存中示例。

为了最大限度地减少网络延迟，请在与数据库相同的 Azure 区域中运行 ostress.exe。

步骤 7：实施后的监视

建议监视在生产环境中实施内存中 OLTP 后的性能影响：

通过