Lukas.Navratil's questions

Descobri que as consultas abaixo retornam resultados diferentes em dois bancos de dados de hiperescala do Azure que estão executando o mesmo nível de compatibilidade, as mesmas opções de conjunto etc.

IF CAST(ServerProperty('Edition') AS nvarchar(128)) = 'SQL Azure' BEGIN
    SELECT 1
END
IF ServerProperty('Edition') = 'SQL Azure' BEGIN
    SELECT 2
END
IF 'SQL Azure' = ServerProperty('Edition') BEGIN
    SELECT 3
END

Em um banco de dados, ele retorna apenas 1, em outro banco de dados retorna 1,2 e 3.

Eu investiguei a causa raiz e parece ser causada por diferentes agrupamentos dos bancos de dados.

Para as seguintes consultas:

SELECT SQL_VARIANT_PROPERTY(ServerProperty('Edition'), 'Collation')
SELECT name, collation_name, compatibility_level FROM sys.databases

O banco de dados que retorna apenas uma linha, o resultado é:

-----------------------------
SQL_Latin1_General_CP1_CI_AS

name         collation_name                   compatibility_level
------------ -------------------------------- -------------------
master       SQL_Latin1_General_CP1_CI_AS     140
my_database  SQL_Latin1_General_CP850_CI_AS   150

E o resultado do banco de dados que retorna 1,2,3 é:

-----------------------------
SQL_Latin1_General_CP1_CI_AS

name         collation_name                   compatibility_level
------------ -------------------------------- -------------------
master       SQL_Latin1_General_CP1_CI_AS     140
my_database  SQL_Latin1_General_CP1_CI_AS     150

Portanto, a comparação simples sem o elenco está comparando sql_variantcom varchar(não há diferença quando eu uso N'SQL Azure') onde o subjacente nvarchardo sql_varianttem em um caso um agrupamento diferente do banco de dados que eu consulto e, em outro caso, é correspondente.

Em primeiro lugar, eu diria que a comparação de duas strings com agrupamento diferente falharia como falha quando você tenta unir duas colunas com agrupamento diferente, mas aparentemente não é o caso aqui.

De qualquer forma, qual é a melhor maneira de comparar com segurança a saída de uma função que pode estar sql_variantcom um varchar?

Estou observando uma estranha diferença entre os planos de consulta que estou recebendo na minha máquina local e no Azure SQL. Estou tentando implementar segurança em nível de linha, onde leio o identificador do usuário de SESSION_CONTEXT e depois no TVF verifico se o usuário tem acesso.

Na minha máquina local - edição SQL Server 2019 Developer, DB no nível de compatibilidade 150, os planos de consulta são os esperados. Mas quando o executo no Azure DB, que também tem nível de compatibilidade de 150, só recebo planos de consulta não paralelos com NonParallelPlanReason="NonParallelizableIntrinsicFunction". Eu tentei um banco de dados Hyperscale, bem como um banco de dados que está no Elastic Pool e o resultado é o mesmo em ambos os bancos de dados.

Você pode reproduzir isso com o seguinte código:

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)))

Quando seleciono o valor do contexto da sessão em uma variável primeiro, ele gera um plano de consulta paralelizável mesmo no 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)

Infelizmente não posso fazer isso (ou pelo menos não sei como fazer isso) porque preciso de um TVF inline.

Plano de consulta do Azure: https://www.brentozar.com/pastetheplan/?id=ByxZm45e9

Plano de consulta do local: https://www.brentozar.com/pastetheplan/?id=BylHXV9lc

Existe alguma diferença na implementação de SESSION_CONTEXT no Azure que possa estar causando isso? Ou alguém tem alguma outra idéia do que poderia ser o problema?