Início / dba / Perguntas / 278067
Accepted
Peter Tilsted
Asked: 2020-10-15 07:18:03 +0800 CST

SQLServer Query Store não salva consultas com falha executadas por SP_ExecuteSQL

  • 772

Estamos no SQL Server 2016

O Query Store está ativado no banco de dados em questão.

Tivemos alguns problemas de tempo limite relatados em um batchjob noturno e localizamos a consulta em questão.

A consulta é de uma aplicação .Net, gerada por algum framework

Eu também encontrei a consulta no Query Store. Mas se eu usar 'consultas rastreadas', todas as execuções são relatadas como boas, sem tempos limite (e sem erros)

E se eu consultar o QueryStore para esse queryID específico, todas as execuções terão resultado 'Regular'

Se eu configurar uma sessão de eventos estendidos para capturar tempos limite, os tempos limite da consulta são realmente coletados e posso ver que a chamada real da consulta é feita com

EXEC SP_EXECUTESQL N'querystring'

isso de alguma forma engana o querystore para pensar que está tudo bem, não importa qual seja o resultado?

Saudações

Peter

sql-server sql-server-2016

1 respostas

  1. Best Answer

    isso de alguma forma engana o querystore para pensar que está tudo bem, não importa qual seja o resultado?

    As consultas executadas com sys.sp_executesqlpodem definitivamente ser registradas no Query Store como "Aborted" ou "Exception". Aqui está uma pequena reprodução. Primeiro, criei um banco de dados com configurações impraticáveis ​​do Query Store:

    USE [master];
GO
DROP DATABASE IF EXISTS [278067];
GO
CREATE DATABASE [278067];
ALTER DATABASE [278067] SET QUERY_STORE = ON;
ALTER DATABASE [278067] 
SET QUERY_STORE 
(
    OPERATION_MODE = READ_WRITE, 
    DATA_FLUSH_INTERVAL_SECONDS = 30, 
    INTERVAL_LENGTH_MINUTES = 1
);
GO
USE [278067];
GO

    Em seguida, executei algum código .NET que exercia os seguintes cenários:

    1. Execute uma consulta normal bem-sucedida
    2. Execute uma consulta com erro (neste caso, foi uma divisão por zero)
    3. Execute uma consulta que retorne milhões de linhas e cancele o lado do cliente antes que todos os resultados sejam consumidos
    4. Execute uma consulta que retorne milhões de linhas e feche a conexão antes que todos os resultados sejam consumidos
    5. Execute uma consulta que é bloqueada e passa por um tempo limite de bloqueio do lado do servidor

    Veja como isso aconteceu no evento Extended Events "rpc_completed":

    Captura de tela da saída do evento estendido, mostrando dois oks e três aborts

    Incorporei um comentário de /* Track Me */em cada uma das consultas para poder encontrá-las no repositório de consultas:

    SELECT
    qsrs.execution_type,
    qsrs.execution_type_desc,
    qsrsi.start_time,
    qsrsi.end_time,
    qsqt.query_sql_text,
    qsp.query_plan
FROM sys.query_store_plan qsp
INNER JOIN sys.query_store_query qsq
    ON qsp.query_id = qsq.query_id
INNER JOIN sys.query_store_query_text qsqt
    ON qsqt.query_text_id = qsq.query_text_id
INNER JOIN sys.query_store_runtime_stats qsrs
    ON qsrs.plan_id = qsp.plan_id
INNER JOIN sys.query_store_runtime_stats_interval qsrsi
    ON qsrsi.runtime_stats_interval_id = qsrs.runtime_stats_interval_id
WHERE
    qsqt.query_sql_text LIKE '%Track Me%'
    AND qsqt.query_sql_text NOT LIKE '%sys.query_store_plan%';

    Captura de tela dos resultados da consulta do repositório de consultas

    Como esperado, vemos Regular, Exception e, em seguida, três consultas Aborted.

    Tudo isso para dizer que não acho que a discrepância possa ser explicada pelo uso de sys.sp_executesql.

    Se puder detalhar mais:

    • suas configurações de armazenamento de consultas (talvez as consultas com tempos limite não estejam sendo registradas)
    • que tipo específico de tempo limite a consulta experimentou (conexão do lado do cliente ou tempo limite de comando, tempo limite de bloqueio, outra coisa)
    • o evento estendido que você usou para identificar o tempo limite

    Então você pode conseguir mais ajuda para rastrear isso.

    • 2

relate perguntas