Estou revisando sys.fn_dump_dblog e posso ver os estados antigos dos registros, mas não consigo ver quais usuários estão fazendo as operações. As colunas SPID, Transaction SID são sempre nulas, como corrigi-lo ou alguma opção?
Estou usando o SQL Server 2016.
Minha consulta:
SELECT
*
FROM sys.fn_dump_dblog(NULL, NULL, NULL, 1, 'E:\LogBackup\blabla.trn', NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL)
WHERE (
[operation] IN ('LOP_INSERT_ROWS', 'LOP_DELETE_ROWS', 'LOP_MODIFY_ROW')
AND (
([context] IN ('LCX_HEAP', 'LCX_CLUSTERED', 'LCX_MARK_AS_GHOST'))
OR ([context] = 'LCX_TEXT_MIX'
AND (DATALENGTH([RowLog Contents 0]) IN (0, 14, 28)))
)
AND [PartitionID] IN (72057595034533888)
)
OR ([operation] = 'LOP_HOBT_DDL')
Por referência a @Kin, cheguei à solução com a consulta.
O log de transações não foi projetado para acompanhar quem fez o quê em seu banco de dados. Se você precisar auditar o comportamento do usuário no SQL Server, use o SQL Server Auditing .
Você também pode usar eventos estendidos, mas, como Nic aponta nesta resposta , a auditoria é mais adequada para esse cenário.
Se você não quiser usar auditoria (para ser claro, recomendo auditar porque resolverá o problema que você tem sem ter que ler manualmente o log de transações), você pode criar gatilhos em suas tabelas para monitorar a atividade do usuário, mas isso é muito mais trabalho e é propenso a bugs.
Usar auditoria.