问然后，数据库系统将足够的信息写入磁盘。

EN

交易日志的概念已经在70年代S由伯恩斯坦和格雷发布。所使用的算法是基于白羊座的所有关系数据库管理系统。

做这件事的方法很简单。数据库中必须发生的每一次写入(插入、更新、删除，但也创建、更改、删除、授予.)需要一个安全网，直到所有的工作都完成。为此，修改数据库状态之前的值在物理上被复制到一个称为“事务日志”的特殊存储中。在内存中修改数据之后，如果没有引发异常，则在事务日志中将此事务标记为“完成”。这就是承诺。在出现异常(或写入的自动取消)的情况下，将在内存中替换回滚和以前的值。

我说数据是写在记忆里的。不是在磁盘上。但问题是，服务器通常没有足够的内存存储在RAM中的所有数据。

检查点一般发生在不同的目标上:数据量的限制、时间的限制和内存压力的限制。

如果我不清楚，或者你需要一些补充性的解释，请告诉我。

我正在写一本关于SQL和关系数据库的法文书，它解释了所有的人.

要完成任务，请阅读“数据库管理系统第三版，约翰·罗摩克里希南·拉格胡第536页”

这一切都是关于事务的“提交时刻”。事务是对数据所做的一个或多个更改的套件:插入新行、删除现有行、更新现有行。它甚至可以做一些事情，比如插入一行，然后更新它。所有这些变化合在一起形成了一个“事务”。

事务具有由缩写ACID描述的众所周知的属性(例如，请参见https://en.wikipedia.org/wiki/ACID)：

• 原子性
• 一致性
• 隔离
• 耐久性

原子性意味着必须应用事务中的所有更改--否则必须不应用:您不能让事务执行一些更改，然后失败，并将这些更改留在数据库中。这将使数据库处于不一致的状态。原子性通常要归功于日志，通常称为“撤销日志”：在将更改写入实际表之前，将更改数据的“前”图像保存在日志中。如果有任何不好的事情发生(应用程序失败，数据库失败，.)，那么数据库系统将通过读取日志自动将数据恢复到其先前的状态。这被称为“先写日志”原则，意思是在将数据写入实际表之前保存前图像。一旦事务被提交，那么该事务的撤消日志就会被遗忘。

持久性进一步保证，一旦事务被提交，则该事务(所有更改)的效果将保证是永久的。这就是重做日志发挥作用的地方。重做日志是为了保证，如果您丢失任何媒体--比如磁盘崩溃--您将永远不会丢失任何数据。当然，您可以从备份恢复媒体:但是在运行所有这些事务之前，这将使数据库返回到一个状态。因此，恢复包括两个阶段:恢复备份，然后通过读取重做日志向前滚动，基本上，重播所有应用程序自备份以来所做的所有更改，直到出现故障为止。

下面是你引用的有趣之处：

然后，数据库系统将足够的信息写入磁盘，即使在发生故障时，事务执行的更新也可以在系统故障后重新启动时重新创建。当写入该信息的最后一个信息时，事务将进入提交状态。

提交事务的传统方法是等待将所有更改写入到该事务中更新的所有表。这实际上是相当慢的，因为这些写可以是随机的。实际上，这并不是绝对必要的:一旦将更改写入重做日志，那么它们就和写入实际表一样好:如果发生了一些糟糕的事情(系统崩溃，媒体崩溃)，则事务执行的更新可以从写入重做日志的信息中重新创建。对实际表的写入仍在进行--但在日志被写入之后(或者在日志被写入时)，这是很懒散的。但它们最终会被写出来。

这种方法的好处是日志写入是连续的。它们可以在内存中缓冲，并按顺序写入，比许多随机写入更新实际表的过程更快。另外，由于所有并发事务都写入同一个全局重做日志，所以可以组合所有这些日志写入:这些更改在内存缓冲区中累积，而这些缓冲区被推送到重做日志中。每个缓冲区可以包含来自多个事务的更改。

另一件好事是，它使识别提交时刻变得非常容易:在事务生命周期中的非常精确的时刻，可以保证事务的持久性。这必须是原子操作:保证完全失败或完全成功的单个操作。该操作是一个“刷新”I/O:将包含我所有更改的缓冲区刷新到重做日志中。更广泛地说，它是最终缓冲区的最终写入。一旦完成(= I/O子系统返回“成功”)，数据库系统就可以自信地从commit()调用返回到应用程序。应用程序现在可以确定这些更改是持久化的--它们可能还没有在数据库表中，但它们在重做日志中，这才是最重要的。