Eu uso eventos estendidos para armazenar erros de banco de dados, assim:
CREATE EVENT SESSION [ErrorCapture]
ON SERVER
ADD EVENT sqlserver.error_reported
(
ACTION
(
sqlserver.client_hostname,
sqlserver.database_id,
sqlserver.sql_text,
sqlserver.username
)
WHERE
(
[severity] >= (11)
)
)
ADD TARGET package0.asynchronous_file_target
(
SET filename='J:\ServerXmlOutput\ErrorCapture.xel'
)
WITH
(
MAX_MEMORY=4096 KB,
EVENT_RETENTION_MODE=ALLOW_SINGLE_EVENT_LOSS,
MAX_DISPATCH_LATENCY=10 SECONDS,
MAX_EVENT_SIZE=0 KB,
MEMORY_PARTITION_MODE=NONE,
TRACK_CAUSALITY=OFF,
STARTUP_STATE=ON
);
Isso me ajuda a rastrear facilmente qual aplicativo os está causando. Eu tenho algo semelhante para rastrear consultas lentas e outros casos especiais. No entanto, notei nos perfis do SQL Server que um aplicativo PHP/Laravel não está enviando algumas instruções diretamente, mas usando RPC:Completed: elas parecem instruções preparadas, recebendo o argumento em tempo de execução. Como faço para expandir meu ErrorCapture para incluir erros causados por instruções executadas via RPC:Completed?
O código que você tem retorna erros de instruções preparadas. O PowerShell abaixo executa uma instrução preparada no SQL Server que falhará intencionalmente. Isso aparece no Profiler com RPC:Completed como você descreveu:
Quando executo isso com o Profiler e sua sessão Extended Events em execução, posso ver o erro relatado em ambas as ferramentas:
Eventos estendidos:
Analisador:
Um problema pode ser que as mensagens estejam abaixo da gravidade 11 e, portanto, sua sessão de EE está excluindo-as. Se você executar um rastreamento do Profiler usando o modelo TSQL_Replay e incluir "Mensagens de erro do usuário" em Erros e avisos , seus erros de instruções preparadas aparecerão?
Se sim, verifique o erro no Profiler e execute o abaixo no SQL Server substituindo 8134 pelo número do erro do Profiler:
Verifique a coluna de gravidade para identificar a gravidade do erro retornado por suas declarações preparadas.