Sylvia's questions

Eu tenho uma sessão de evento estendida configurada para rastrear eventos de atenção, para monitorar procedimentos que expiraram. Este é o script de criação:

CREATE EVENT SESSION [ApplicationTimeout3] ON SERVER 
ADD EVENT sqlserver.attention(
ACTION(sqlserver.client_app_name,sqlserver.client_hostname,sqlserver.database_name,sqlserver.session_id,sqlserver.sql_text,sqlserver.tsql_frame,sqlserver.tsql_stack,sqlserver.username)
    WHERE ([package0].[equal_boolean]([sqlserver].[is_system],(0))))
ADD TARGET package0.event_file(SET filename=N'D:\ExtendedEvents\ApplicationTimeout3.xel',max_file_size=(100),max_rollover_files=(5))
WITH (MAX_MEMORY=4096 KB,EVENT_RETENTION_MODE=ALLOW_SINGLE_EVENT_LOSS,MAX_DISPATCH_LATENCY=30 SECONDS,MAX_EVENT_SIZE=0 KB,MEMORY_PARTITION_MODE=NONE,TRACK_CAUSALITY=OFF,STARTUP_STATE=ON)
GO

O problema é que nos tempos limite que recebo, NÃO recebo o sql_text. (Nem recebo tsql_frame ou tsql_stack). Não é retornado quando faço o "Assistir dados ao vivo".

Eu vejo os tempos limite, eles ocorrem ao mesmo tempo que os que vejo quando faço consultas em sys.query_store_runtime_stats (com execução_type_desc = 'Abortado'). No entanto, recebo de volta um conjunto limitado de campos e não são deles que preciso.

Além disso, há muitos MAIS eventos registrados por meio do Evento Estendido do que vejo quando consulto sys.query_store_runtime_stats. Não tenho ideia do que são.

Alguma pista de como eu poderia realmente obter o sql que está sendo executado? Posso obter o nome do procedimento armazenado consultando as tabelas do armazenamento de consultas. O que eu gostaria de obter são os parâmetros com os quais o procedimento armazenado é chamado.

Neste plano de consulta:

https://www.brentozar.com/pastetheplan/?id=HydtQjsO5

...vários nós têm um custo de 100%. Como isso acontece? Como você descobre por onde começar a otimizar quando tantos nós têm o que deve ser um custo errado? Existe algo mais para usar em vez do percentual de custo?

O SQL Agent não foi habilitado acidentalmente em um SQL Server após uma reinicialização e nenhum trabalho foi executado por 3 semanas, incluindo nenhum backup (completo, diff ou log). O SQL Agent está habilitado agora. O backup completo do banco de dados foi executado. Agora, o backup de log está em execução e já está em execução há mais de uma hora (normalmente leva segundos logo após a execução de um backup completo).

Algum problema potencial a ser considerado? O arquivo de log ficou muito grande, como 200 gb.

Já não consegui fazer isso algumas vezes. Na interface do usuário, consigo aumentar com êxito o tamanho do repositório de consultas na configuração de retenção do repositório de consultas de 250 para 1000 mb. Faço a alteração, fecho a janela de propriedades do banco de dados, reabro, e parece que a alteração foi bem sucedida, mostra 1000 mb. Então, quando eu olho para ele novamente (talvez no dia seguinte) ele é revertido para 250 mb.

A versão é Microsoft SQL Server 2017 (RTM-CU13) (KB4466404) - 14.0.3048.4.

O que pode estar acontecendo aqui?

Eu tenho uma sessão de evento estendida para rastrear deadlocks e tenho o armazenamento de dados configurado para Event_File, tamanho máximo de arquivo de 20 MB, número máximo de arquivos é 5, habilitar rollover de arquivo é true.

Parece que não consigo alterar o armazenamento de dados, mesmo depois de interromper a sessão. Está tudo acinzentado. Eu preciso ser capaz de aumentar o número de arquivos, porque por algum motivo não está realmente indo para o tamanho máximo de arquivo de 20 MB. Já tenho 4 arquivos para esta sessão, e o maior tamanho é 47 KB.

Como posso aumentar isso? Só preciso recriar a sessão? Já tenho uma história nele que quero manter.

No plano de consulta a seguir - https://www.brentozar.com/pastetheplan/?id=H1dwOCHed (tem 3 seções, a última é o problema), há um nó na parte inferior que consome 37% dos recursos . Este é o plano de consulta real, não o plano de consulta estimado. No entanto, a tabela a que ela faz referência não aparece, ao analisar as leituras lógicas por meio do Set Statistics IO. Isso inclui as 2 seções para ActivityFeedTeamCache e ActivityFeedCache.

No passado, consegui usar Logical Reads como um proxy muito bom para desempenho. Reduza as leituras lógicas e você terá feito a coisa certa para o desempenho.

No entanto, como nesse caso, não há leituras lógicas para os blocos que são os piores (ActivityFeedTeamCache, ActivityFeedCache, Locales), qual é um bom proxy para testar o desempenho? Só que o % de custo no Plano de Execução Real diminui?

Estou revisando um procedimento armazenado que tem sido um problema de desempenho. E acabei de perceber que algumas das tabelas que são usadas no procedimento armazenado nem aparecem nos resultados do Set Statistics I/O?

Isso é normal ou é um bug? É um pouco perturbador porque eu uso muito os resultados do Set Statistics I/O, ao descobrir o que indexar.

As tabelas que não aparecem na saída de Set Statistics I/O estão em uma subseleção na consulta principal, como a tabela ActivityFeedCache abaixo:

SELECT *
FROM (
    SELECT AF.ActivityFeedID
        ,A.ActivityType AS ActivityType
        ,A.IconClass
        ,AF.SubscriptionID
        ,AF.ObjectID
        ,AF.ObjectType
        ,(
            SELECT L.Locale
                ,AFC.LocalizedMessage
            FROM ActivityFeedCache AFC
            JOIN Locales L
                ON AFC.LocaleID = L.LocaleID
            WHERE ActivityFeedID = AF.ActivityFeedID
            FOR JSON PATH
            ) AS MessageJSON
    FROM ActivityFeed AF
    ETC 
    ETC    
    ) AS Results    

Este é o SQL Server 2017 (RTM-CU13).

EDIT: Eu reduzi a uma pequena consulta que mostra uma tabela ausente na saída de E/S de Estatísticas. A tabela Locales está ausente em Statistics I/O, mas aparece no plano de execução. Aqui está:

-- Locales table doesn't show in statistics i/o output
SELECT AF.ActivityFeedID
        ,(
            SELECT L.Locale
                ,AFC.LocalizedTeamMessage AS LocalizedMessage
            FROM ActivityFeedTeamCache AFC
            JOIN Locales L
                ON AFC.LocaleID = L.LocaleID
            WHERE ActivityFeedID = AF.ActivityFeedID
            FOR JSON PATH
            ) AS TeamMessageJSON
    FROM ActivityFeed AF
Where AF.ActivityFeedID = (select top 1 ActivityFeedID from ActivityFeed)

Aqui está a saída de Estatísticas de E/S:

(1 row affected)
Table 'Worktable'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'ActivityFeedTeamCache'. Scan count 1, logical reads 4, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'ActivityFeed'. Scan count 1, logical reads 6, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

E aqui está um pequeno pedaço do XML do plano de execução real, apenas para que você possa ver que a tabela Locales está realmente sendo usada:

  <IndexScan Ordered="true" ScanDirection="FORWARD" ForcedIndex="false" ForceSeek="false" ForceScan="false" NoExpandHint="false" Storage="RowStore">
    <DefinedValues>
      <DefinedValue>
        <ColumnReference Database="[Database1]" Schema="[dbo]" Table="[Locales]" Alias="[L]" Column="Locale" />
      </DefinedValue>
    </DefinedValues>
    <Object Database="[Database1]" Schema="[dbo]" Table="[Locales]" Index="[PK_Locales]" Alias="[L]" IndexKind="Clustered" Storage="RowStore" />
    <SeekPredicates>
      <SeekPredicateNew>
        <SeekKeys>
          <Prefix ScanType="EQ">
            <RangeColumns>
              <ColumnReference Database="[Database1]" Schema="[dbo]" Table="[Locales]" Alias="[L]" Column="LocaleID" />
            </RangeColumns>
            <RangeExpressions>
              <ScalarOperator ScalarString="[Database1].[dbo].[ActivityFeedTeamCache].[LocaleID] as [AFC].[LocaleID]">