sqlserver回滚到前一小时

使用Transact-SQL。1.连接到您要还原数据库的服务器实例。2.执行使用 NORECOVERY 选项的 RESTORE DATABASE 语句。如果部分还原顺序不包括任何 FILESTREAM 文件组，则不支持时间点还原。 可以强制该还原顺序以继续执行 *** 作。 但在 RESTORE 语句中省略的 FILESTREAM 文件组将永远无法还原。 若要强制执行时点还 原，请指定 CONTINUE_AFTER_ERROR 选项以及 STOPAT、STOPATMARK 或 STOPBEFOREMARK 选项，还必须在随后的 RESTORE LOG 语句中指定后面的三个选项。 如果指定 CONTINUE_AFTER_ERROR，则部分还原顺序将成功，但 FILESTREAM 文件组将不可恢复。3.还原上次差异数据库备份（如果有），而不恢复数据库 (RESTORE DATABASE database_name FROM backup_device WITH NORECOVERY)。4.应用每个事务日志备份中相同的顺序在其中创建了它们，指定想要停止还原日志的时间 (RESTORE DATABASE database_name FROM WITH STOPAT = time ， 恢复)。

我们经常会遇到 *** 作一张大表，发现 *** 作时间过长或影响在线业务了，想要回退大表 *** 作的场景。在我们停止大表 *** 作之后，等待回滚是一个很漫长的过程，尽管你可能对知道一些缩短时间的方法，处于对生产环境数据完整性的敬畏，也会选择不做介入。最终选择不作为的原因大多源于对 *** 作影响的不确定性。实践出真知，下面针对两种主要提升事务回滚速度的方式进行验证，一种是提升 *** 作可用内存空间，一种是通过停实例，禁用 redo 回滚方式进行进行验证。

仔细阅读过官方手册的同学，一定留意到了对于提升大事务回滚效率，官方提供了两种方法：一是增加 innodb_buffer_pool_size 参数大小，二是合理利用 innodb_force_recovery=3 参数，跳过事务回滚过程。第一种方式比较温和，innodb_buffer_pool_size 参数是可以动态调整的，可行性也较高。第二种方式相较之下较暴力，但效果较好。

两种方式各有自己的优点，第一种方式对线上业务系统影响较小，不会中断在线业务。第二种方式效果更显著，会短暂影响业务连续，回滚所有没有提交的事务。

先看看你的更新是怎麼更新的，是不是可以再直接update 回去。

如果不能直接update 恢复，就要看有没有备份资料，如有备份是不是可以恢复到测试数据库再将资料导回正式数据库

如果此表的数据有经常变化的，测试资料的数据也不全，就要看你的数据库有没有选中truncate log on checkpoint 选项，如果没有勾选，则可以将日志备份下来，在测试库进行恢复，先恢复前一个完整备份，再恢复日志备份，恢复日志备份时指定恢复的时间点。

---