事务类型以及恢复

• T1 完成了提交（COMMIT）并不需要恢复。
• T2 在最后一个检查点之后提交，需要重做（redo）。
• T3 在系统崩溃时正在进行中，需要撤销（undo）并重启。
• T4 与T2相同，也需要重做。
• T5 在崩溃时也正在进行中，需要撤销并重启。

系统崩溃前的最后一个检查点以及事务是否完成了提交在图表上以虚线标记。提交的事务（如T1、T2和T4）在系统恢复后通常不需要进一步的操作，或者根据它们是否在最后一个检查点之后完成，可能需要重做以保证它们的效果被持久化。未完成的事务（如T3和T5）在系统恢复后需要撤销并重启，以确保数据库状态的一致性。

在数据库系统中，提交的事务是指已经完成并被确认为永久更改数据库状态的事务。当一个事务完成提交操作（COMMIT），其更改就被视为持久化的，即使系统随后发生故障，这些更改也应保持有效。

对于T1这样已经提交且在系统故障前不需要恢复的事务来说，因为它们的更改已经保存，系统在重启后不需要对这些事务做任何操作。

而对于T2和T4这样在最后一个检查点之后提交的事务，尽管它们已经完成提交，但如果故障发生在事务提交和系统记录检查点之间，这些事务可能还没有完全写入持久存储。在这种情况下，系统恢复后会根据事务日志来重做（redo）这些事务，确保所有提交的更改都反映在数据库中。这个过程是自动的，确保所有在最后一个检查点后提交的更改都得到了持久化。

所以，当说提交的事务在系统恢复后通常不需要进一步的操作时，意味着这些事务的更改已经被确认，并且系统将确保这些更改在重启后仍然存在。如果需要的话，通过日志来重做更改，以保证一致性和持久性。这一切都是自动发生的，是数据库事务管理的一部分。
T3和T5这样在系统故障时还在进行中的事务的撤销和重启通常也是自动的。数据库的事务管理系统会在重启后使用事务日志来确定哪些事务在故障时仍在进行中。然后，它会自动执行以下步骤：

1. 撤销（Undo）：对于那些在系统故障时未完成的事务，数据库管理系统会根据事务日志中记录的信息来撤销它们的操作，以确保这些未完成事务的影响不会留在数据库中。
2. 重启（Restart）：事务撤销后，如果这些事务是因为系统故障而未完成，而不是因为事务本身出现了错误，它们通常会被重启。在某些情况下，这意味着整个事务从开始就重新执行；在其他情况下，事务可能会从某个安全点或中间状态重新开始。

数据库系统的设计旨在尽量减少人工干预，确保数据的完整性和一致性，即使在面临故障的情况下。自动撤销和重启事务的过程是事务管理系统复杂性的一个例证，它展示了数据库系统如何能够从故障中自我恢复。

事务恢复

• 两个事务列表

  1. UNDO：所有在上一个检查点时正在进行中的事务
  2. REDO：空列表

• 对日志中的每一条记录进行操作（在上一个检查点时）：

  • 如果为事务T找到了BEGIN TRANSACTION的条目，那么将T添加到UNDO列表
  • 如果为事务T找到了COMMIT的条目，那么将T从UNDO列表移动到REDO列表

这个恢复过程是数据库在系统故障后确保数据一致性和完整性的自动步骤。它根据事务日志来决定哪些事务需要撤销（因为它们还没有完成），以及哪些事务需要重做（因为它们已经提交但可能未被完全写入到持久存储中）。通过这种方法，数据库能够在系统恢复后返回到最近的一致状态。

在数据库系统中，UNDO和REDO列表是用来在系统故障后恢复数据库一致性的两个关键工具。

• UNDO（撤销）：这个列表用来跟踪在系统崩溃时尚未完成的所有事务。恢复过程中，数据库管理系统（DBMS）将查看这个列表，并撤销列表中的所有事务所做的更改。撤销操作确保了数据库回到了这些未完成事务开始前的状态，从而不会留下不一致的数据。
• REDO（重做）：这个列表用于跟踪在上一个检查点之后成功提交的事务，但由于系统故障，这些更改可能没有被完全写入到持久存储。在恢复过程中，DBMS会执行REDO列表中的事务所做的更改，即使这些更改在系统崩溃时已经部分写入。这确保了即使在故障发生时，所有提交的事务所做的更改都能够被完全和正确地应用到数据库中。

简而言之，UNDO用来回滚未完成的事务以避免数据不一致，而REDO用来重做已经提交但可能未完全保存的更改，以确保所有提交的更改都被正确地记录在数据库中。这两个操作都是自动进行的，是事务恢复过程中的标准步骤，旨在确保数据库的完整性和一致性。

前向和后向恢复

• 后向恢复

  • 我们需要撤销一些事务
  • 通过倒序遍历日志，我们撤销UNDO列表中的事务操作
  • 这使数据库返回到一致的状态

• 前向恢复

  • 一些事务需要重新做
  • 通过顺序遍历日志，我们重新做REDO列表中的事务操作
  • 这使数据库得到最新的更新

重做（REDO）操作并不意味着重复提交事务，而是确保已经提交的事务对数据库所做的更改在故障后仍然存在。这是因为以下几个原因：

1. 提交并未完全持久化：在某些情况下，事务虽然已经提交，并且更改已经部分写入到数据库，但由于系统故障，这些更改可能没有完全持久化到硬盘上。
2. 检查点（Checkpoint）：系统经常会创建检查点，即在这个时间点，所有提交的事务都已完全写入到持久存储。如果故障发生在检查点之后，那些在检查点和系统故障之间提交的事务可能还未完全写入到持久存储。

在恢复过程中，数据库系统会检查日志来确定哪些提交的事务的更改可能由于故障而没有完全写入。REDO过程就是确保这些事务的更改完全和正确地反映在数据库的数据中，即使它们在故障时已部分写入。因此，REDO不是重新执行事务的逻辑，而是确保事务的结果是持久的。

数据库系统设计有保障机制以避免真正的重复提交。这些机制通常包括使用唯一的事务标识符和日志记录来跟踪哪些操作已经完成，哪些需要在故障后重新应用。

“撤销”（UNDO）和“重做”（REDO）在术语上看起来相似，因为它们都包含“做”这个动作，但在数据库事务恢复中，它们的含义和作用是不同的。

1. UNDO（撤销）：

   • 用于处理那些在故障发生时未完成的事务。
   • 目的是将数据库恢复到这些事务开始之前的状态。
   • 它涉及取消所有未完成事务的操作，这些操作可能已部分修改了数据库，但未提交。
   • 如果事务日志中有一个事务开始但未有相应的提交记录，该事务需要被UNDO。

2. REDO（重做）：

   • 用于确保已经提交但可能未完全持久化到存储媒体的事务能够反映其更改。
   • 目的是重新应用那些在系统故障时已经提交但可能未完全写入到磁盘的更改。
   • 这涉及到重复已提交事务的操作以确保数据的一致性和持久性。
   • 如果事务日志中有一个事务已经提交（即使这些更改已部分写入），在恢复时这个事务的更改将需要REDO。

总结来说，UNDO用于“回滚”或“撤销”未完成事务的操作，而REDO用于“确认”或“重做”已提交事务的操作。UNDO关注于回到过去，将数据库状态回滚到事务开始之前；REDO关注于保持进度，确保所有已决定的更改得到持久化。这两个过程共同确保数据库能够在系统故障后，无论是硬件还是软件故障，都能恢复到一个正确和一致的状态。

介质故障

• 系统故障并不太严重

  • 只有自上一个检查点以来的信息受到影响
  • 这可以从事务日志中恢复

• 介质故障（例如硬盘崩溃）更为严重

  • 存储在硬盘上的数据受损
  • 事务日志本身可能也会受损

备份

• 需要备份来从介质故障中恢复

  • 事务日志和数据库的全部内容被写入到次级存储（例如：磁带）
  • 耗时并因此通常需要停机时间

• 备份频率

  • 足够频繁以最小化信息丢失
  • 不要太频繁以至于引起问题
  • 日常备份（例如：夜间）是常见的

从介质故障中恢复

1. 使用最后的备份来恢复数据库

2. 使用事务日志来重做自上次备份以来所做的任何更改

   • 如果事务日志损坏，我们不能执行第二步
   • 将事务日志和数据库存储在不同的物理设备上
   • 这最小化了同时丢失两者的风险

备份是数据库维护的重要组成部分，特别是在介质故障（如硬盘损坏）的情况下。定期的备份可以帮助最小化数据丢失，并确保在灾难发生时，可以恢复到最近的备份。事务日志用于在备份之后和故障之前发生的事务中重做更改，以保持数据的一致性和完整性。将事务日志和数据库存储在不同的物理介质上是一种常见的最佳实践，以减少单点故障的风险。