Início / dba / Perguntas / 337678
Accepted
Joe Obbish
Asked: 2024-03-13 03:53:24 +0800 CST

Como posso evitar que o SQL Server registre o início e a interrupção das sessões XE nos arquivos de log do servidor?

  • 772

Eu tenho um processo que inicia e interrompe sessões de eventos estendidos para transferir dados de arquivos de eventos para tabelas SQL. Em um servidor SQL Server 2022 RTM, vejo muitas linhas gravadas nos arquivos de log por este processo:

insira a descrição da imagem aqui

Gostaria que o início e a interrupção das sessões XE não fossem gravados no arquivo de log porque meus arquivos de log agora estão esmagadoramente preenchidos com essas entradas. Esse comportamento não ocorre em uma instância do Microsoft SQL Server 2019 (RTM-CU22-GDR).

Como posso evitar que o SQL Server registre o início e a interrupção das sessões XE nos arquivos de log do servidor?

sql-server

1 respostas

  1. Best Answer

    Nota do leitor: Isso foi feito com símbolos públicos do Microsoft Symbols Server .

    Os itens de início e parada do log de erros estão sendo gerados nas funções XEventController::AlterEventSessione XEventController::VLR_StopXESession::CommitAndRelease, respectivamente, no sqllang.dllSQL Server 2022 RTM.

    Iniciar gravações

    Olhando primeiro para a função start, que é uma função muito grande, a chamada antes de 0x107e:

    sqllang!XEventController::AlterEventSession+0x106d:
00007ff8`d1fa940d 488d95c80a0000  lea     rdx,[rbp+0AC8h]
00007ff8`d1fa9414 b999640000      mov     ecx,6499h
00007ff8`d1fa9419 e8a2f62301      call    sqllang!scierrlog

    O movinto ecxestá carregando 0x6499a passagem sqllang!scierrlogque podemos deduzir é o número do erro para escrever a mensagem, que de fato 0x6499( 0n25753) corresponde à documentação pública .

    25753 Sessão XE '%s' iniciada.

    Olhando para os itens que podem executar o código, há uma única ramificação que aponta nessa direçãosqllang!XEventController::AlterEventSession+0x101f

    00007ff8`d1fa93d5 488d542468      lea     rdx,[rsp+68h]
00007ff8`d1fa93da 488d8d900a0000  lea     rcx,[rbp+0A90h]
00007ff8`d1fa93e1 ff1551e52a02    call    qword ptr [sqllang!XE_API::sm_ClientAPI+0xa8 (00007ff8`d4257938)]
00007ff8`d1fa93e7 85c0            test    eax,eax
00007ff8`d1fa93e9 7522            jne     sqllang!XEventController::AlterEventSession+0x106d

    Não parece haver um sinalizador de rastreamento ou outra verificação facilmente definida; na verdade, parece depender do retorno de um ponteiro de função em sqllang!XE_API::sm_ClientAPI+0xa8. Eu diria que para o item start errorlog, não haveria uma maneira facilmente configurável de desligá-lo.

    Dado que agora você sabe onde encontrar isso, você pode injetar seu próprio código e NOP(ou jmp) a chamada para scierrloga qual claramente não seria suportada.

    Observando uma instância CU24 do SQL Server 2019, a mesma função não tem referências ao log de erros e tem muitas alterações diferentes. Parece que em 2022 foram feitas adições a esta função que não foram retroportadas para 2019.

    Parar gravações

    É interessante que stop não esteja na mesma função, visto que start era onde AlterEventSessionse pensaria que seria usado para ALTERcomandos T-SQL para sessões de eventos 🤷‍♂️

    Felizmente sqllang!XEventController::VLR_StopXESession::CommitAndReleaseé uma função muito menor. Usando o que aprendemos na investigação da função anterior, haverá um carregamento de ecxcom o número de erro correspondente e, em seguida, uma chamada para scierrlog. Com certeza, está lá e é muito fácil de identificar logo no início da função!

    00007ff8`d1fa8105 488d9570020000  lea     rdx,[rbp+270h]
00007ff8`d1fa810c 488b4938        mov     rcx,qword ptr [rcx+38h]
00007ff8`d1fa8110 ff152af82a02    call    qword ptr [sqllang!XE_API::sm_ClientAPI+0xb0 (00007ff8`d4257940)]
00007ff8`d1fa8116 488d95a8020000  lea     rdx,[rbp+2A8h]
00007ff8`d1fa811d b99a640000      mov     ecx,649Ah
00007ff8`d1fa8122 e899092401      call    sqllang!scierrlog

    Aqui podemos ver no ecxvalor de 32 bits de 0x649A( 0n25754) carregado e depois uma chamada para scierrlog, curiosamente antes disso existe uma chamada semelhante a sqllang!XE_API::sm_ClientAPImas com um deslocamento muito diferente. Independentemente disso, não há teste condicional em torno do retorno da chamada, portanto, ele sempre gravará isso no log de erros e não parece ser controlado por um traceflag ou outro mecanismo. Isso é muito mais simples do que a montagem inicial.

    25754 Sessão XE '%s' parando.

    A mesma opção se aplica aqui, substitua a instrução de chamada por NOPs.

    Verificar esta função em relação à mesma instância SQL 2019 CU24 mencionada anteriormente também mostra um pouco de código diferente no início da função, que, novamente, não parece ter a chamada de log de erros nem ser portado (para melhor ou para pior).

    Maior esforço

    Uma maneira que poderia ser suportada seria criar um driver de filtro de sistema de arquivos muito pequeno para verificar se há gravações de arquivos especificamente no arquivo de log de erros e verificar se os dados que estão sendo gravados são algo que você realmente não deseja. Você poderia então jogá-lo fora silenciosamente e ninguém saberia, o log não o mostraria e, esperançosamente, o driver do filtro não teria bugs ou quebraria qualquer outra coisa no ambiente.

    Menor esforço

    Abra um ticket de suporte com a Microsoft e solicite que seja feita uma alteração no produto para uma opção de desligar o registro das mensagens para que haja uma forma suportada.

    • 5

relate perguntas