并发控制(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可以的,但是无法实现。