Erik Darling's questions

bigxml4u

Alguns planos de consulta são muito grandes para serem armazenados adequadamente como XML. Você recebe o erro:XML datatype instance has too many levels of nested nodes. Maximum allowed depth is 128 levels.

O que está bem. Tudo precisa de limitações para evitar o uso indevido. Quem sabe o que aconteceria em 129 níveis aninhados.

Obviamente, com planos de consulta, você pode salvar o XML do formato de texto como um arquivo .sqlplan e reabri-lo como um plano de execução gráfico.

O problema que estou tendo com minha consulta é que quando tento exibir isso, <é alterado para <e >para >. Isso adiciona duas etapas extras antes que você possa salvar o arquivo como um .sqlplan válido, que pode ser reaberto.

No momento, minha consulta faz o seguinte:

    query_plan = 
         CASE
             WHEN TRY_CAST(qsp.query_plan AS XML) IS NOT NULL
             THEN TRY_CAST(qsp.query_plan AS XML)
             WHEN TRY_CAST(qsp.query_plan AS XML) IS NULL
             THEN 
                 (
                     SELECT
                         (
                             SELECT
                                 N''-- '' + NCHAR(13) + NCHAR(10) +
                                 N''-- This is a huge query plan.'' + NCHAR(13) + NCHAR(10) +
                                 N''-- Remove the headers and footers, save it as a .sqlplan file, and re-open it.'' + NCHAR(13) + NCHAR(10) +
                                 N''-- Depending on local factors, you may need to replace "<" and ">" too.'' + NCHAR(13) + NCHAR(10) +
                                 N''-- '' + NCHAR(13) + NCHAR(10) +
                                 REPLACE(qsp.query_plan, N''<RelOp'', NCHAR(13) + NCHAR(10) + N''<RelOp'') +
                                 NCHAR(13) + NCHAR(10) + N''--'' COLLATE Latin1_General_Bin2 AS [processing-instruction(query_plan)]
                         )
                         FOR XML PATH(N''''), 
                                 TYPE
                 )
         END,

Normalmente, eu seguiria meu próprio conselho e adicionaria isso ao final, mas isso me traz de volta ao erro XML original sobre nós e aninhamento e 128, etc.

.value
     (
         './text()[1]', 
         'nvarchar(max)'
     );

Tentei adicionar REPLACEseleções internas e externas para tentar consertar as coisas, mas o blob parece imune aos meus encantos.

Existe uma maneira de impedir ou contornar a conversão desses caracteres para facilitar um pouco mais o salvamento do arquivo?

Se você tiver uma cópia do banco de dados StackOverflow localmente, poderá gerar um plano de consulta que termina nulo em TRY_CASTe gera um erro quando tratado como XML com esta consulta:

WITH
    p0 AS (SELECT pt.* FROM dbo.PostTypes AS pt),
    p1 AS (SELECT pp.* FROM p0 AS p CROSS JOIN p0 AS pp),
    p2 AS (SELECT pp.* FROM p1 AS p CROSS JOIN p1 AS pp),
    p3 AS (SELECT pp.* FROM p2 AS p CROSS JOIN p2 AS pp),
    p4 AS (SELECT pp.* FROM p3 AS p CROSS JOIN p3 AS pp),
    p5 AS (SELECT pp.* FROM p4 AS p CROSS JOIN p4 AS pp),
    p6 AS (SELECT pp.* FROM p5 AS p CROSS JOIN p5 AS pp),
    p7 AS (SELECT pp.* FROM p6 AS p CROSS JOIN p6 AS pp),
    p8 AS (SELECT pp.* FROM p7 AS p CROSS JOIN p7 AS pp),
    p9 AS (SELECT pp.* FROM p8 AS p CROSS JOIN p8 AS pp)
SELECT
    c = COUNT_BIG(*)
FROM p9 AS p
OPTION(RECOMPILE);

Se você quiser apenas ver o absurdo gerado, você pode usar este link principal do GitHub .

Digamos

Você tem um procedimento armazenado que aceita matrizes de data e hora, que são carregadas em uma tabela temporária e usadas para filtrar uma coluna de data e hora em uma tabela.

• Pode haver qualquer número de valores inseridos como datas de início e término.
• Os intervalos de datas podem se sobrepor às vezes , mas não é uma condição com a qual eu contaria regularmente.
• Também é possível fornecer datas com horários.

Qual é a maneira mais eficiente de escrever uma consulta para realizar a filtragem?

configurar

USE StackOverflow2013;

CREATE TABLE
    #d
(
    dfrom datetime,
    dto datetime,
    PRIMARY KEY (dfrom, dto)
)
INSERT
    #d
(
    dfrom,
    dto
)
SELECT
    dfrom = '2013-11-20',
    dto =   '2013-12-05'
UNION ALL
SELECT
    dfrom = '2013-11-27',
    dto =   '2013-12-12'; 

CREATE INDEX
    p
ON dbo.Posts
    (CreationDate)
WITH
    (SORT_IN_TEMPDB = ON, DATA_COMPRESSION = PAGE);

consulta

O melhor que consegui foi usar EXISTSassim:

SELECT
    c = COUNT_BIG(*)
FROM dbo.Posts AS p
WHERE EXISTS
(
    SELECT
        1/0
    FROM #d AS d
    WHERE p.CreationDate BETWEEN d.dfrom
                             AND d.dto
);

O que resulta em um plano de execução bastante triste:

Nested Loops é o único operador de junção disponível, já que não temos um predicado de igualdade.

O que procuro é uma sintaxe alternativa que produza um tipo diferente de junção.

Obrigado!

estendido demais

No SQL Server Extended Events para o relatório de processo bloqueado e XML de deadlock, é possível obter vários valores de SQL Handle de volta para identificar as consultas envolvidas no evento gerado.

Uma vez que 1 ou mais SQL Handles podem estar envolvidos, consultar o XML de forma confiável para recuperá-los pode ser difícil, e também torna a XQuery mais direta incorreta, pois ela apenas recupera o primeiro valor armazenado.

sqlhandle = bd.value('(process/executionStack/frame/@sqlhandle)[1]', 'varchar(130)'),

Um exemplo de fragmento XML para ilustração se parece com isto:

<executionStack>
      <frame line="1" stmtend="108" sqlhandle="0x020000008d18260040e407ba48fc247b0cb6121c21c2cf2b0000000000000000000000000000000000000000" />
      <frame line="1" stmtend="108" sqlhandle="0x02000000dd847b18dcaa4a09a89f56595186fcf91da8a7f70000000000000000000000000000000000000000" />
</executionStack>

Um exemplo mais completo está disponível neste SQL Fiddle .

cheguei até aqui:

SELECT 
    sql_handle = 
        @x.query('for $s in //executionStack/frame return $s');  

Mas isso não é o que eu procuro. Estender essa consulta para usar o @sqlhandleatributo gera um erro:

SELECT 
    sql_handle = 
        @x.query('for $s in //executionStack/frame/@sqlhandle return $s');  

Msg 2396, Level 16, State 1, Line 60 XQuery [query()]: o atributo não pode aparecer fora de um elemento

Como posso consultar XML como este para retornar todos os identificadores SQL listados como uma lista separada por vírgulas?

Configurar

Para esta demonstração, estou usando a versão 2013 do banco de dados Stack Overflow e o SQL Server 2022 CTP2, mas é válido voltar ao SQL Server 2017, que é o mais antigo que eu gostaria de verificar.

Função Um

Para esta função, o SQL Server rastreia o tempo de execução gasto na função:

CREATE OR ALTER FUNCTION
    dbo.ScoreStats
(
    @UserId int
)
RETURNS
    @out table
    (
        TotalScore bigint
    )
WITH SCHEMABINDING
AS 
BEGIN

    INSERT
        @out
    (
        TotalScore
    )
    SELECT
        TotalScore = 
            SUM(x.Score)
    FROM 
    (
        SELECT
            Score = 
                SUM(p.Score)
        FROM dbo.Posts AS p
        WHERE p.OwnerUserId = @UserId

        UNION ALL

        SELECT
            Score = 
                SUM(c.Score)
        FROM dbo.Comments AS c
        WHERE c.UserId = @UserId    
    ) AS x;

    RETURN;

END;

Aqui está o plano de consulta e execução:

SELECT
    u.DisplayName,
    TotalScore = 
        (
            SELECT
                ss.TotalScore
            FROM dbo.ScoreStats(u.Id) AS ss
        )
FROM dbo.Users AS u
WHERE u.Reputation >= 1000000;

Você pode ver que tanto no plano de consulta quanto na propriedade Query Time Stats, o tempo é rastreado com precisão.

Função Dois

Aqui está a segunda função, onde isso não acontece:

CREATE OR ALTER FUNCTION
    dbo.VoteStats()
RETURNS
    @out table
    (
        PostId int,
        UpVotes int,
        DownVotes int,
        UpMultipier AS 
             UpVotes * 2
    )
WITH SCHEMABINDING
AS 
BEGIN

    INSERT
        @out
    (
        PostId,
        UpVotes,
        DownVotes
    )
    SELECT
        v.PostId,
        UpVotes = 
            SUM
            (
                CASE v.VoteTypeId
                     WHEN 2
                     THEN 1
                     ELSE 0
                END
            ),
        DownVotes = 
            SUM
            (
                CASE v.VoteTypeId
                     WHEN 3
                     THEN 1
                     ELSE 0
                END
            )
    FROM dbo.Votes AS v
    GROUP BY 
        v.PostId;

    RETURN;

END;

Aqui está o plano de consulta e execução:

SELECT TOP (100)
     p.Id,
     vs.UpVotes,
     vs.DownVotes
FROM dbo.VoteStats() AS vs
JOIN dbo.Posts AS p
    ON vs.PostId = p.Id
WHERE vs.DownVotes > vs.UpMultipier
AND   p.CommunityOwnedDate IS NULL
AND   p.ClosedDate IS NULL
ORDER BY vs.UpVotes DESC;

Nesta consulta, o tempo não é rastreado com precisão no plano de execução gráfico, mas é rastreado na propriedade Query Time Stats.

Função Dois em MAXDOP 1

Mesmo quando forçado serial, o tempo não é rastreado com precisão:

SELECT TOP (100)
     p.Id,
     vs.UpVotes,
     vs.DownVotes
FROM dbo.VoteStats() AS vs
JOIN dbo.Posts AS p
    ON vs.PostId = p.Id
WHERE vs.DownVotes > vs.UpMultipier
AND   p.CommunityOwnedDate IS NULL
AND   p.ClosedDate IS NULL
ORDER BY vs.UpVotes DESC
OPTION(MAXDOP 1);

El Problema

De volta à questão em questão: Por que o tempo é rastreado em um plano de consulta com precisão, mas não no outro?

Spoolum

No SQL Server existem vários tipos de spools. Os dois que me interessam são Table Spool s e Index spools , fora das consultas de modificação .

Consultas somente leitura, principalmente no lado interno de uma junção de loops aninhados, podem usar um spool de tabela ou índice para reduzir potencialmente a E/S e melhorar o desempenho da consulta. Esses carretéis podem ser Ansiosos ou Preguiçosos . Assim como você e eu.

Minhas perguntas são:

• Quais fatores entram na escolha de Tabela vs. Carretel de Índice
• Quais fatores influenciam na escolha entre Carretéis Ansiosos e Preguiçosos

Ouvi coisas conflitantes sobre concessões de memória para consultas de seleção paralelas:

• As concessões de memória são multiplicadas pelo DOP
• As concessões de memória são divididas pelo DOP

Qual é?

Saco de areia

Enquanto trabalhava no Top Quality Blog Posts® , me deparei com alguns comportamentos do otimizador que achei muito interessantes. Eu não tenho uma explicação imediatamente, pelo menos não uma com a qual eu esteja feliz, então estou colocando aqui caso alguém inteligente apareça.

Se você quiser acompanhar, você pode pegar a versão 2013 do despejo de dados do Stack Overflow aqui . Estou usando a tabela Comentários, com um índice adicional.

CREATE INDEX [ix_ennui] ON [dbo].[Comments] ( [UserId], [Score] DESC );

Consulta Um

Quando eu consulto a tabela assim, recebo um plano de consulta estranho .

WITH x
    AS
     (
         SELECT   TOP 101
                  c.UserId, c.Text, c.Score
         FROM     dbo.Comments AS c
         ORDER BY c.Score DESC
     )
SELECT *
FROM   x
WHERE  x.Score >= 500;

O predicado SARGable em Score não é inserido no CTE. Está em um operador de filtro muito mais tarde no plano.

O que eu acho estranho, já que o ORDER BYestá na mesma coluna que o filtro.

Consulta Dois

Se eu alterar a consulta, ela é enviada.

WITH x
    AS
     (
         SELECT   c.UserId, c.Text, c.Score
         FROM     dbo.Comments AS c
     )
SELECT TOP 101 *
FROM   x
WHERE  x.Score >= 500
ORDER BY x.Score DESC;

O plano de consulta também muda e é executado muito mais rápido, sem derramamento no disco. Ambos produzem os mesmos resultados, com o predicado na varredura de índice não clusterizado.

Consulta três

Isso é o equivalente a escrever a consulta assim:

SELECT   TOP 101
         c.UserId, c.Text, c.Score
FROM     dbo.Comments AS c
WHERE c.Score >= 500
ORDER BY c.Score DESC;

Consulta Quatro

O uso de uma tabela derivada obtém o mesmo plano de consulta "ruim" que a consulta CTE inicial

SELECT *
FROM   (   SELECT   TOP 101
                    c.UserId, c.Text, c.Score
           FROM     dbo.Comments AS c
           ORDER BY c.Score DESC ) AS x
WHERE x.Score >= 500;

As coisas ficam ainda mais estranhas quando...

Eu altero a consulta para ordenar os dados em ordem crescente e o filtro para <=.

Para evitar fazer essa pergunta muito longa, vou colocar tudo junto.

Consultas

--Derived table
SELECT *
FROM   (   SELECT   TOP 101
                    c.UserId, c.Text, c.Score
           FROM     dbo.Comments AS c
           ORDER BY c.Score ASC ) AS x
WHERE x.Score <= 500;


--TOP inside CTE
WITH x
    AS
     (
         SELECT   TOP 101
                  c.UserId, c.Text, c.Score
         FROM     dbo.Comments AS c
         ORDER BY c.Score ASC
     )
SELECT *
FROM   x
WHERE  x.Score <= 500;


--Written normally
SELECT   TOP 101
         c.UserId, c.Text, c.Score
FROM     dbo.Comments AS c
WHERE c.Score <= 500
ORDER BY c.Score ASC;

--TOP outside CTE
WITH x
    AS
     (
         SELECT   c.UserId, c.Text, c.Score
         FROM     dbo.Comments AS c
     )
SELECT TOP 101 *
FROM   x
WHERE  x.Score <= 500
ORDER BY x.Score ASC;

Planos

Link do plano .

Observe que nenhuma dessas consultas tira proveito do índice não clusterizado -- a única coisa que muda aqui é a posição do operador de filtro. Em nenhum caso o predicado é enviado para o acesso ao índice.

Aparece uma pergunta!

Existe uma razão pela qual um predicado SARGable pode ser empurrado em alguns cenários e não em outros? As diferenças dentro das consultas classificadas em ordem decrescente são interessantes, mas as diferenças entre aquelas e as que são ascendentes são bizarras.

Para quem estiver interessado, aqui estão os planos com apenas um índice em Score:

• DESC
• ASC

Eu tenho um banco de dados SQL Server onde as consultas são muito lentas e há muitos bloqueios e bloqueios.

Quando olho para os DMVs de índice ausentes e os planos de consulta, não há sugestões.

Por que é que?

Eu tenho um gatilho de banco de dados que uso para me impedir de criar determinados procedimentos em bancos de dados de usuários.

Ele aparece em sys.triggers, com um object_id, mas não consigo usar a object_idfunção para encontrá-lo.

SELECT OBJECT_ID(t.name, t.type) AS object_id, *
FROM   sys.triggers AS t;

Da mesma forma, posso encontrá-lo em sys.dm_exec_trigger_stats. Não consigo object_nameresolver, mas resolve object_definition.

SELECT OBJECT_NAME(dets.object_id, dets.database_id) AS object_name,
       OBJECT_DEFINITION(dets.object_id) AS object_definition,
       *
FROM   sys.dm_exec_trigger_stats AS dets;

Existe uma função que aceitará o id de objeto de um gatilho de nível de banco de dados e retornará seu nome?

Li que apenas Trivial Plans podem ser Simple Parameterized , e que nem todas as consultas (mesmo quando o plano é Trivial) podem ser Simple Parameterized .

Então, por que esse plano está mostrando Otimização Completa e Parametrização Simples ao mesmo tempo?

[Saudações]

(marque um)

[ ] Well trained professional, [ ] Casual reader, [ ] Hapless wanderer,

Eu tenho um (marque todos que se aplicam)

[ ] query [ ] stored procedure [ ] database thing maybe  

que estava funcionando bem (se aplicável)

[ ] yesterday [ ] in recent memory [ ] at some point 

mas de repente é mais lento agora.

Eu já verifiquei para ter certeza de que não está sendo bloqueado e que não é vítima de alguma tarefa de manutenção de longa duração, relatório ou outro processo fora de banda.

Qual é o problema, o que devo fazer e quais informações posso fornecer para obter ajuda?

[*Insert appropriate closing remarks*]

Muitas vezes vejo consultas escritas com DATEADDe DATEDIFFna WHEREcláusula para definir um intervalo, achatar datetime para 0 horas ou encontrar o último dia de um mês ou ano, mas não entendo como todas as partes funcionam.

Por exemplo, isso encontrará datas desde o início do dia atual até o início do dia 30 dias atrás.

SELECT *
FROM tbl
WHERE datecol >= DATEADD(DAY, DATEDIFF(DAY, 0, GETUTCDATE()), 0)
AND datecol   <  DATEADD(DAY, DATEDIFF(DAY, 0, GETUTCDATE()), -30);

O que todas as diferentes partes disso realizam?

O feedback de concessão de memória do modo de lote faz parte de uma família de recursos do processador de consultas de 2017 que consiste em:

• Junções adaptáveis ​​do modo de lote
• Execução intercalada
• Feedback de concessão de memória do modo de lote

Então, como funciona o feedback de concessão de memória no modo de lote?

A execução intercalada faz parte de uma família de recursos no processador de consultas de 2017 que consiste em:

• Junções adaptáveis ​​do modo de lote
• Execução intercalada
• Feedback de concessão de memória do modo de lote

Então, como funciona a execução intercalada?

As associações adaptáveis ​​de modo de lote fazem parte de uma família de recursos no processador de consultas de 2017 que consiste em:

• Junções adaptáveis ​​do modo de lote
• Execução intercalada
• Feedback de concessão de memória do modo de lote

Então, como funcionam as Adaptive Joins?

Muito foi escrito sobre os perigos das UDFs escalares no SQL Server. Uma pesquisa casual retornará muitos resultados.

Existem alguns lugares onde uma UDF escalar é a única opção.

Como exemplo: ao lidar com XML: XQuery não pode ser usado como definição de coluna computada. Uma opção documentada pela Microsoft é usar uma UDF escalar para encapsular sua XQuery em uma UDF escalar e, em seguida, usá-la em uma coluna computada.

Isso tem vários efeitos e algumas soluções alternativas.

• Executa linha por linha quando a tabela é consultada
• Força todas as consultas na tabela a serem executadas em série

Você pode contornar a execução linha por linha vinculando a função ao esquema e persistindo a coluna computada ou indexando-a. Nenhum desses métodos pode impedir a serialização forçada de consultas que atingem a tabela, mesmo quando a UDF escalar não é referenciada.

Existe uma maneira conhecida de fazer isso?

Ao examinar sys.dm_os_wait_stats , as colunas a seguir são definidas comoBIGINT

• wait_tasks_count
• wait_time_ms
• max_wait_time_ms

Se algum desses valores for acima 9,223,372,036,854,775,807de , os contadores são redefinidos para 0 ou simplesmente param de contar?

Não está claro na definição da tabela o que acontece nos bastidores:

sp_helptext 'sys.dm_os_wait_stats'

Devoluções:

CREATE VIEW sys.dm_os_wait_stats AS  
 SELECT *  
 FROM OpenRowset(TABLE SYSWAITSTATS)  

Então isso é um pouco de uma caixa preta.

Existem alguns DMVs onde números grandes podem se tornar negativos. Um exemplo disso é a total_elapsed_timecoluna em dm_exec_requests.

Perguntas e respostas para SQL Server migradas aqui desta pergunta .

O que acontece se uma restrição "NOT NULL" for adicionada a uma tabela para uma coluna que já possui valores NULL?

Do que não se trata:

Esta não é uma pergunta sobre consultas abrangentes que aceitam entrada do usuário ou usam variáveis.

Isso é estritamente sobre consultas onde ISNULL()é usado na WHEREcláusula para substituir NULLvalores por um valor canário para comparação com um predicado e diferentes maneiras de reescrever essas consultas para serem SARGable no SQL Server.

Por que você não se senta ali?

Nossa consulta de exemplo é em uma cópia local do banco de dados Stack Overflow no SQL Server 2016 e procura usuários com NULLidade ou idade < 18.

SELECT COUNT(*)
FROM dbo.Users AS u
WHERE ISNULL(u.Age, 17) < 18;

O plano de consulta mostra um Scan de um índice não clusterizado bastante cuidadoso.

O operador de varredura mostra (graças às adições ao XML do plano de execução real nas versões mais recentes do SQL Server) que lemos cada linha ruim.

No geral, fazemos 9157 leituras e usamos cerca de meio segundo de tempo de CPU:

Table 'Users'. Scan count 1, logical reads 9157, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

 SQL Server Execution Times:
   CPU time = 485 ms,  elapsed time = 483 ms.

A pergunta: Quais são as maneiras de reescrever essa consulta para torná-la mais eficiente e talvez até SARGable?

Fique à vontade para dar outras sugestões. Eu não acho que minha resposta seja necessariamente a resposta, e existem pessoas inteligentes o suficiente por aí para apresentar alternativas que podem ser melhores.

Se você quiser jogar no seu próprio computador, acesse aqui para baixar o banco de dados SO .

Obrigado!

Isso é definitivamente um bug. Os detalhes estavam no antigo site do Connect e não estão mais disponíveis, pois foram retirados em favor de um número indeterminado de outras soluções, tanto de terceiros quanto de terceiros.

Ao testar algumas mudanças no sp_BlitzCache (divulgação completa, sou um dos autores), me deparei com o que pensei ser um bug em nosso código.

Em um ponto, estamos combinando o Hash do plano de consulta para obter o custo da consulta. Fazemos isso mais ou menos assim: statement.value('sum(/p:StmtSimple[xs:hexBinary(substring(@QueryHash, 3)) = xs:hexBinary(sql:column("b.QueryHash"))]/@ StatementSubTreeCost)', 'float')

Isso tem, tanto quanto eu tenho visto, funcionou. No entanto, em um caso estranho, a substring no XML estava lançando um NULLvalor e o plano estava mostrando um custo de 0, apesar de ser bastante alto.

Investigando o plano de execução , notei que o Hash do Plano de Consulta para o hash do problema tinha 17 caracteres, enquanto o restante tinha 18. Aqui estão alguns exemplos:

QueryPlanHash="0x4410B0CA640CDA89"
QueryPlanHash="0x2262FEA4CE645569"
QueryPlanHash="0xED4F225CC0E97E5" -- Problema!
QueryPlanHash="0xBF878EEE6DB955EA"
QueryPlanHash="0x263B53BC8C14A452"
QueryPlanHash="0x89F5F146CF4B476F"
QueryPlanHash="0xEF47EA40805C8961"
QueryPlanHash="0xB7BE27D6E43677A5"
QueryPlanHash="0x815C54EC43A6A6E9"

O Query Plan Hash está listado como binary 8-- presumivelmente, deve ter sempre o mesmo tamanho, mas o que um cara como eu sabe sobre valores binários?

Brincando um pouco com o XQuery, descobri que, alterando a substring para iniciar na segunda posição, ela geraria um valor de hash válido (embora incorreto).

WITH XMLNAMESPACES('http://schemas.microsoft.com/sqlserver/2004/07/showplan' AS p)
SELECT   
        QueryPlanCost = statement.value('sum(/p:StmtSimple/@StatementSubTreeCost)', 'float'),
        q.n.value('substring(@QueryPlanHash, 2)', 'binary(8)')
FROM    #statements s
CROSS APPLY s.statement.nodes('/p:StmtSimple') AS q(n)
OPTION(RECOMPILE);

WITH XMLNAMESPACES('http://schemas.microsoft.com/sqlserver/2004/07/showplan' AS p)
SELECT   
        QueryPlanCost = statement.value('sum(/p:StmtSimple/@StatementSubTreeCost)', 'float'),
        q.n.value('substring(@QueryPlanHash, 3)', 'binary(8)')
FROM    #statements s
CROSS APPLY s.statement.nodes('/p:StmtSimple') AS q(n)
OPTION(RECOMPILE);

Estou executando o SQL Server 2016, SP1 (13.0.4001).

Alguém já se deparou com isso antes?

17 caracteres é um comprimento válido para um binary 8valor?