并发控制（concurrency control）
恢复（recovery)
理论支持：基于事务的ACID
Atomicity: All actions in the txn happend, or none happen. “All or nothing”
Consistency: IF each txn is consistent and the DB starts consistent, then it ends up consistent. “It looks corrects to me”
Isolation: Execution of one txn is isolated from that of other txns. “As if alone”
Durability: If a txn commits, its effects persist. “Survive failures”
事务是执行一系列的操作以完成一个更高级的功能。 事务是数据库的最小执行单位。这一系列的操作要么都成功，要么都失败。
并发的执行会提高效率，但是会造成永久性的错误，所以需要设计一定的规则以保证并发运行的正确性。
事务从 BEGIN 开始，COMMIT / ABORT 结束。ABORT 回滚，可以是事务逻辑决定，也有可能是数据库发现错误回滚。
Atomicity：
事务有两种执行结果： commit 或者 abort， 一个是成功执行，一个是失败回滚。
方法1：日志（Logging）
日志的作用：
Undo，回滚日志；监控审计；提高效率
方法2：备份（Shadow Paging）
只备份修改的页。
Consistency：
数据库一致性：考虑整体数据库的一致性；
事务一致性：这个需要业务负责，sql语句是符合逻辑的；
Isolation：
为了实现隔离性，需要并发控制理论。
怎么判断事务并发执行的时候是正确的？
如果并发执行的结果能等效成串行时的结果，那么就是正确的。
Serial Schedule 真正串行的安排；
Serializeable Schedule 可串行化的安排，执行的结果等价与Seribal Schedule；
Conflictiing Operations：（冲突操作）
如果两个操作来自不同的事务，并且至少其中一个是写，那么这两个操作就是冲突的。
读写冲突
写读冲突：
写写冲突
知道冲突的目的是判断一个schedules是否是正确的。
基于冲突的可串行化：
冲突等效的：两个事务包含相同的操作，并且每一对冲突行为是按照相同顺序排列的。
冲突可串行化的：一个操作执行安排和一个串行化的操作是冲突等效的。那么就是冲突可串行化的。
Dependency Graphs（依赖图）
如果T1有个操作冲突在T2之前，那么就有一个T1到T2的边。
如果图中有环，就没有办法使用交换顺序的方法来实现可串行化。
但是冲突不可串行化不一定意味这个业务不可串行化。所以View Serializability可以的，但是无法实现。
