Sql server sql server中的事务回滚机制是什么？

sql server中的事务回滚机制是什么

回滚显式或隐式 事务处理到事务的开始 事务，或到内部的保存点 交易

---

就操作方式而言，事务中的所有数据修改都存储在事务日志中，如果必须回滚，日志中还为撤消记录保留了额外的空间。 每个事务日志中都有足够的信息，可以在进行更改时撤消更改，以便在需要时撤消更改。（以及在灾难恢复场景中重播）

如果我们以一个简单的删除操作为例（因为我已经将其作为日志内容的一个示例），那么被删除的记录存储在LOP_delete_行的事务日志条目中，您可以通过一些非常简单的工作来解码并证明整行都在日志条目中

---

如果要回滚事务，则将使用日志中保留的撤消空间，并重新插入该行。撤消保留空间的原因是为了确保事务日志不能在事务进行期间填满，从而使其没有空间完成或回滚。

数据库中的每次更新都会首先在日志中写入一个包含更改描述的条目。例如，如果将列值从a更新为B，日志将包含更新记录，类似于：在表T中，id为I的事务将键为K的记录的列C从a更改为B。如果回滚事务，引擎将开始向后扫描日志，查找事务完成的工作记录，并将撤消工作：当它找到从A到B的更新记录时，将值更改回A。插入操作将通过删除插入的行来撤消。删除操作将通过向后插入行来撤消。这在和中进行了描述

---

这是一个高层次的解释，确切的内部细节是如何发生的，没有记录在案，不需要你检查也不需要修改。

模棱两可的问题，你是说语法是什么，还是它实际上是如何做到的，例如，通过事务日志。我想知道它实际上是如何做到的。我知道它的语法。感谢Andrew的帮助。如何从日志表中获取存储的数据？在查看数据时，请选择*from:：fn_dblog（null，null）。在实际解释数据时，您确实无法做到这一点，因为它不是任何真实形式的人类可读数据。有一些第三方工具可以读取日志，或者你可以从“兴趣/理解”的角度阅读一些奇怪的条目，但是在这个层面上几乎没有关于这个主题的文档。因此，关于未记录的，我有一只母马正在尝试解码LOP\u MODIFY\u列：）