Como posso monitorar mais de perto esta tabela na produção para descobrir por que as linhas estão desaparecendo?

Se você não espera que nenhuma linha seja excluída dessa tabela, a maneira mais simples e menos impactante de capturar alguém executando exclusões seria um gatilho de exclusão. Você pode usar um gatilho INSTEAD OF se quiser registrar e impedir, ou um gatilho posterior se quiser apenas registrar. Primeiro, uma tabela de registro:

CREATE TABLE dbo.CatchTheDoNoGooders
(
  [JOB_NAME] [nvarchar](200),
  [JOB_GROUP] [nvarchar](200),
  [SCHED_NAME] [varchar](120),
  UserName SYSNAME,
  HostName SYSNAME,
  Program NVARCHAR(4000),
  IP VARCHAR(15),
  EventDate DATETIME
);

Agora, um gatilho INSTEAD OF INSERT, poderia registrar os DELETEs, mas não realizar:

CREATE TRIGGER dbo.InsteadDelete_QRTZ_JOB_DETAILS
  ON dbo.QRTZ_JOB_DETAILS
  INSTEAD OF DELETE
AS
BEGIN
  SET NOCOUNT ON;

  DECLARE @ip VARCHAR(15), @hn SYSNAME, @prog NVARCHAR(4000);

  SELECT TOP (1) @ip = client_net_address 
    FROM sys.dm_exec_connections
    WHERE session_id = @@SPID;

  SELECT TOP (1) @hn = [host_name], @prog = LEFT([program_name],4000)
    FROM sys.dm_exec_sessions
    WHERE session_id = @@SPID;

  INSERT dbo.CatchTheDoNoGooders
  SELECT JOB_NAME, JOB_GROUP, SCHED_NAME,
    SUSER_SNAME(), @hn, @prog, @ip, CURRENT_TIMESTAMP
    FROM deleted;
END
GO

Mude INSTEAD OFpara FORe agora você tem um gatilho AFTER que ainda permitirá que a exclusão aconteça, mas registrará todos eles de qualquer maneira. Isso pode ser melhor se você tiver algumas exclusões legais acontecendo, mas quiser determinar quem está excluindo as coisas erradas.

A beleza é que, em ambos os casos, isso só tem algum impacto se e quando uma exclusão for realmente emitida na tabela.

Eu depuraria isso usando um rastreamento do lado do servidor . Essencialmente, o motivo pelo qual o Profiler é problemático na produção é porque ele é um aplicativo cliente. Se você tentar rastrear muito e o SQL Server estiver tentando gerenciar essa comunicação entre o servidor e o cliente, isso poderá atrapalhar as coisas. Então, em vez disso, você pode criar o script do rastreamento como um script T-SQL e executá-lo no próprio servidor. Ele irá capturar as informações para um arquivo de rastreamento, então você pode levar esse arquivo de rastreamento para outro lugar e revisá-lo.

Para fazer o script do rastreamento, abra o Profiler e selecione seus eventos. Como você está preocupado com a possibilidade de as declarações não serem confirmadas/concluídas, eu recomendaria

• RPC: Iniciando/concluído
• SP: Iniciando/Concluído
• SQL: BatchStarting/BatchCompleted

Colunas relevantes incluídas. Filtre conforme necessário (como nome do banco de dados, talvez duração)

Em seguida, clique em 'Executar', mas pare imediatamente. Neste ponto, vá para a barra de ferramentas e selecione: Arquivo->Exportar->Definição de rastreamento de script->Para SQL Server... Isso solicitará que você salve um script em algum lugar. Depois de salvá-lo, abra-o.

Antes de executá-lo, especifique um nome de arquivo e um caminho (substitua InsertFileNameHere). Em seguida, execute para iniciar o rastreamento. O rastreamento continuará a ser executado até que você o interrompa. Para pará-lo, certifique-se de saber o ID de rastreamento, que é retornado quando você executa o script. Se você não consegue se lembrar, veja sys.traces. Depois de obter a ID de rastreamento, você pode interrompê-lo usando sp_settracestatus para definir o status como 0 para interrompê-lo. Uma vez definido como 0, você pode defini-lo como 2 para excluí-lo.

Depois de pará-lo, você deve ter um arquivo de rastreamento para revisar e identificar o que está acontecendo com seus processos. O arquivo de rastreio pode ser visualizado por meio do aplicativo Profiler.