主页 / dba / 问题 / 308059
Accepted
Lukas.Navratil
Asked: 2022-03-01 03:39:30 +0800 CST

仅在使用 SESSION_CONTEXT 时在 Azure 中进行非并行计划

  • 772

我正在观察本地计算机和 Azure SQL 上的查询计划之间的奇怪差异。我正在尝试实现行级安全性，我从 SESSION_CONTEXT 读取用户标识符，然后在 TVF 中检查用户是否具有访问权限。

在我的本地机器上 - SQL Server 2019 Developer edition，兼容级别为 150 的数据库，查询计划符合预期。但是，当我在也是 150 兼容级别的 Azure DB 上运行它时，我只能获得带有NonParallelPlanReason="NonParallelizableIntrinsicFunction". 我尝试了一个超大规模数据库以及弹性池中的一个数据库，结果在两个数据库上都是相同的。

您可以使用以下代码重现它：

CREATE TABLE Users (
    UserIdentifier nvarchar(100) PRIMARY KEY CLUSTERED
)

INSERT INTO Users (UserIdentifier) VALUES ('MyUserIdentifier')

CREATE TABLE TableWithRLS (
    Id int NOT NULL IDENTITY(1,1) PRIMARY KEY CLUSTERED,
    DataColumn nvarchar(100) NULL
)

INSERT INTO TableWithRLS (DataColumn) 
SELECT TOP 10000000 A.[name] FROM sys.all_columns  AS A
CROSS JOIN sys.all_columns  AS B
CROSS JOIN sys.all_columns  AS C


CREATE OR ALTER FUNCTION CheckAccess (@userIdentifier varchar(100))
RETURNS TABLE
WITH SCHEMABINDING
AS
RETURN
    SELECT TOP 1 1 AS HasAccess FROM dbo.Users WHERE UserIdentifier = @userIdentifier

EXEC sp_set_session_context N'UserIdentifier', N'MyUserIdentifier', 1

-- This query gets always non-parallel query plan on Azure
SELECT MAX(DataColumn) FROM TableWithRLS AS X
CROSS APPLY CheckAccess(CAST(SESSION_CONTEXT(N'UserIdentifier') AS nvarchar(100)))

当我首先将会话上下文中的值选择到变量中时，即使在 Azure 中它也会生成可并行化的查询计划。

DECLARE @userIdentifier AS nvarchar(100) = CAST(SESSION_CONTEXT(N'UserIdentifier') AS nvarchar(100))
SELECT MAX(DataColumn) FROM TableWithRLS AS X
CROSS APPLY CheckAccess(@userIdentifier)

不幸的是，我不能这样做（或者至少我不知道该怎么做），因为我需要一个内联 TVF。

Azure 的查询计划：https ://www.brentozar.com/pastetheplan/?id=ByxZm45e9

本地查询计划：https ://www.brentozar.com/pastetheplan/?id=BylHXV9lc

Azure 中的 SESSION_CONTEXT 实现有什么不同可能导致这种情况吗？或者有没有人有任何其他想法可能是什么问题？

sql-server performance

2 个回答

  1. Best Answer

    Azure 中的 SESSION_CONTEXT 实现有什么不同可能导致这种情况吗？

    是的。尽管 Azure SQL 数据库和 SQL Server 是从一个通用代码库构建的，但一个领先于另一个的情况并不少见。尽管微软在过去几年进行了营销，但并不总是领先于 Azure 版本。

    使用时禁止并行计划是当前在 Azure 中启用SESSION_CONTEXT的功能标志 ( DisableSessionContextParallelPlan )，无法将其关闭。它可以在 SQL Server 上使用未记录的跟踪标志 11042 在查询、会话、全局和启动级别启用。

    使用 Stack Overflow 演示数据库（任何并行查询都可以）：

    EXECUTE sys.sp_set_session_context 
    @key = N'key', 
    @value = 123,
    @read_only = 1;

SELECT COUNT_BIG(*) 
FROM dbo.Badges AS B 
WHERE B.UserId = CONVERT(integer, SESSION_CONTEXT(N'Key'))
OPTION (QUERYTRACEON 11042);

    查询是并行的，没有 SQL Server 上的跟踪标志。

    这些选项通常添加到预览功能中，作为对罕见错误情况或存在安全风险的响应。

    SQL Server 2019 CU14 中发布了在并行计划中使用时错误结果的错误修复。SESSION_CONTEXT

    修复存在问题，在CU16 的文档中报告：

    SQL Server 2019 CU14 引入了一个修复程序，以解决内置 SESSION_CONTEXT 返回的并行计划中的错误结果。但是，此修复可能会在重置 SESSION 以供重用时导致访问冲突转储文件。要缓解此问题，您可以禁用原始修复，并禁用内置 SESSION_CONTEXT 的并行性以避免错误结果。为此，请使用以下跟踪标志：

    11042 - 此跟踪标志禁用内置 SESSION_CONTEXT 的并行性。

    9432 - 此跟踪标志禁用 SQL Server 2019 CU14 中引入的修复。

    Microsoft 正在努力解决此问题，该问题将在未来的 CU 中提供。

    • 7

  2. 来自 AzureDB 计划的 XML：NonParallelPlanReason="NonParallelizableIntrinsicFunction"

    这是由于使用了上下文内在函数，并且 Azure SQL DB 专门设置为禁用这些内在函数的并行性（但对于 box 而言，除非启用了特定项目，否则情况并非如此）。有很多方法可以使盒装产品（本地）工作相同，但我相信你会喜欢它。

    本质上，这就是当前配置 Azure SQL DB 的方式，我不知道是否有办法在您的订阅中解决这个问题（我通常不使用 Azure SQL DB）。我在当前文档中找不到任何东西来描述这种行为。

    • 4

相关问题