2

从耐用性

一旦用户发出提交命令，则首先将事务写入存储在诸如硬盘之类的非易失性介质上的数据库文件中，这是在向用户确认已发生保存之前完成的。如果数据库在保存之前崩溃，则下次重新启动数据库时数据仍在事务日志中，但任何未提交的更改都将撤消或回滚。

  1. 说我开始交易
  2. 触发第一个插入语句；
  3. 触发第二个插入语句；
  4. 犯罪;
  5. 交易结束

现在，当用户在第 4 步提交时，

  1. 所有插入语句都在时间 T1 写入文件系统中的事务日志
  2. 确认发送给用户事务已提交，尽管它将在时间 T2 在步骤 3 中完成
  3. 现在交易在时间 T3 异步进行

以上理解正确吗？如果是，我的问题是为什么在第 3 步之后不发送确认信息？另外，如果 DB 机器在 T2 之前崩溃，那么事务将不持久怎么办？因此，使用日志，我们只是确保数据库是否在 T2 和 T3 时间崩溃，然后我们可以确保持久性

第二个理解 我相信所有事务语句都可以在语句被触发后立即写入日志，而不是在提交时执行。一旦提交完成，事务日志将被标记为提交并发送确认。现在即使数据库在确认后崩溃，数据库也会确保从事务日志中写入数据库文件。因此，基本上，Db 不是在提交时一次性编写所有事务语句，而是在它们触发时在日志中写入语句。在提交时，它只是将这些事务标记为提交，最终将写入日志中的数据库块

从 oracle 的角度来看这个问题

4

1 回答 1

1

你的第二个理解很接近。

正如你提到的文章还说

现代关系数据库系统中的持久性通常是通过事务日志来实现的——可回收文件——用于在会话中存储所有数据库事务的文件

不提交完成后，

  1. 第一个数据库供应商，标记该会话提交中的所有事务。
  2. 然后将这些事务数据永久存储在数据库文件中。
  3. 然后将确认发送给用户
  4. 现在即使在第 1 步之后 DB 崩溃，DB 供应商在启动时可以读取该事务已在日志中提交，但完整的事务未写入 DB 块。所以将完成那些事务并回滚未提交的日志

但是是的，如果数据库在步骤 1 之前崩溃，那么即使在启动时它也不会被持久化，因为它没有写入事务日志

于 2017-02-26T13:05:36.047 回答