SQL Server表执行UPDATE后数据5-7分钟自动回滚，无日志报错求排查

• 未提交事务：若操作处于显式事务环境中（如SSMS开启了隐式事务、应用代码包含未完成的事务块），未执行COMMIT提交时，数据库会在会话超时或断开后自动回滚事务，导致数据恢复原样。
• 定时同步/ETL作业覆盖：存在定时运行的SQL Agent作业、第三方ETL工具任务，定期从其他数据源（如主数据系统、生产库）同步数据到APP_RecipeIngredients表，覆盖了你的更新操作。
• 应用程序逻辑回滚：业务系统存在缓存刷新、数据重载逻辑，会定期从原始数据源拉取数据覆盖该表；或应用内的事务逻辑在特定条件触发后，回滚了你的更新操作。
• 数据库同步机制冲突：数据库配置了事务复制、Always On可用性组、镜像等同步方案，同步源的数据仍为旧值，同步延迟结束后将旧数据推送过来，覆盖本地更新。
• 会话冲突或误操作：其他会话同时对目标数据执行更新/回滚操作，或你在多窗口操作时，未提交的事务被其他操作触发回滚。

• 检查并提交事务：执行SELECT @@TRANCOUNT查看当前事务计数，若大于0，立即执行COMMIT TRANSACTION提交；若使用SSMS，可在「工具-选项-查询执行-SQL Server-ANSI」中关闭“隐式事务”选项，避免自动开启未提交的事务。
• 排查定时作业：查看SQL Server Agent的作业列表，筛选与APP_RecipeIngredients表相关的定时任务，核对执行时间是否与数据回滚时间匹配；同时检查第三方ETL工具（如SSIS、Talend）的同步任务。
• 验证应用逻辑：联系开发团队确认系统是否存在自动刷新数据、缓存更新或事务回滚的逻辑，排查是否有其他业务模块会修改该表的目标数据。
• 检查数据库同步配置：确认数据库是否启用了复制、Always On等同步机制，查看同步源的APP_RecipeIngredients表数据状态，验证同步规则是否会覆盖本地更新；若为只读副本，需确认更新操作是否提交到了主库。
• 跟踪数据变更：使用SQL Server扩展事件（Extended Events）或SQL Server Profiler，跟踪APP_RecipeIngredients表的UPDATE操作，记录操作发起者、时间及执行语句，定位数据回滚的来源。
• 加锁测试验证：执行更新后，运行以下语句保持事务锁定：

  BEGIN TRANSACTION;
  SELECT * FROM APP_RecipeIngredients 
  WHERE BOMCode IN ('088100','088088') 
    AND Revision IN (2,3) 
    AND Deleted = 'N' WITH (HOLDLOCK);
  

  保持会话打开，观察数据是否仍会回滚。若不再回滚，说明是其他会话的操作覆盖了你的更新。

内容的提问来源于stack exchange，提问作者Rohmun Bikram Shahi