1.1 事物的基本概念

●概念：一个操作序列，要么都做，要么都不做，是不可分割的逻辑工作单位。

●定义语句：
BEGINTRANSACTION/ENDTRANSACTION：事务开始/事务结束。
ROLLBACK：事务回滚，表示事务非成功地结束。
COMMIT：事务提交，表示事务成功地结束。

●ACID特性
原子性：事务是原子的，要么做，要么都不做。
一致性：事务执行的结果必须保证数据库从一个一致性状态变到另一个一致性状态。
隔离性：事务相互隔离。当多个事务并发执行时，任一事务的更新操作直到其成功提交的整个过程，对其它事物都是不可见的。
持久性：一旦事务成功提交，即使数据库崩溃，其对数据库的更新操作也永久有效。

●状态
活动状态：事务的初始状态，事务执行时处于这个状态。
部分提交状态：当操作序列的最后一条语句自动执行后，事务处于部分提交状态。部分提交状态并不等于事务成功执行。
失败状态：由于错误使得事务不能继续正常执行，事务就进入了失败状态。
中止状态：事务回滚并且数据库已被恢复到事务开始执行前的状态。
提交状态：当事务成功完成后，称事务处于提交状态。

1.2 数据库的并发控制

1.2.1 事务调度概念

调度：事务的执行次序。

串行调度：多个事务依次串行执行，且只有当一个事务的所有操作都执行完后才执行另一个事务的所有操作。
并行调度：利用分时的方法同时处理多个事务。

调度错误的定义是结果算错了才叫错，并行的结果要和任意串行结果一致。—>可串行化的调度
多个事务的并发执行是正确的， 当且仅当其结果与某一次序串行地执行它们的结果相同， 称这种调度策略是可串行化的调度。
可串行性是并发事务正确性的准则。 即： 一个给定的并发调度， 当且仅当它是可串行化的才认为是正确调度

错误的调度及产生错误的原因：丢失修改/不可重复读/读脏数，破坏了事务的隔离性

1.2.2 并发操作带来的问题

丢失修改、不可重复读、读脏数据，幻读。
幻读是按照相同条件查询，两次查到不一样。
不可重复读是两个查询同数据，读取数据不一样。
都是违反了隔离性

1.2.3 并发控制技术

封锁（X锁、S锁）、三级封锁协议、两阶段封锁协议。
X锁（排它锁）：工作类流程和串行调度一样
S锁（共享锁）：只读不改
三级封锁协议：

两阶段封锁协议：

加锁阶段（Growing Phase）：事务开始后，可以对任何数据项加锁（读锁或写锁），但不能释放任何锁。
解锁阶段（Shrinking Phase）：事务提交（COMMIT）时，释放所有锁；事务回滚（ROLLBACK）时，也必须释放已获取的所有锁。
满足两段锁协议—>可串行化—>并发事务正确执行–x->不能保证不发生死锁

1.2.4 隔离级别：

1、READ UNCOMMITTED（读未提交）：可避免丢失修改。
2、READ COMMITTED＜读已提交）：可避免丢失修改、读脏数据。
3、REPEATABLE READ(可重复读）：可避免丢失修改、读脏数据，不可重复读。
4、SERIALIZABLE（串行化）：最高级别，可避免丢失修改、读脏数据、不可重复读、幻读。

幻读：事务A查询得到N条数据，然后事务B又插入了M条数据，或者改变了这N条数据之外的N条符合事务A搜索条件的数据，导致事务A再次搜索发现有N+W条数据了，就产生了幻读。

1.3 数据库的备份和恢复

1.3.1 故障种类

1、 事务故障： 是由于程序执行错误而引起事务非预期的、 异常终止的故障。 通常有如下两类错误引起事务执行失败：
（1） 逻辑错误。 如非法输入、 找不到数据、 溢出、 超出资源限制等原因引起的事务执行失败。
（2） 系统错误。 系统进入一种不良状态（如死锁） ， 导致事务无法继续执行

2、 系统故障（通常称为软故障）：是指硬件故障、 软件（如DBMS、 OS或应用程序） 漏洞的影响， 导致丢失了内存中的信息， 影响正在执行的事务， 但未破坏存储在外存上的信息。

3、 介质故障（通常称为硬故障）：是指外存故障，例如磁盘损坏、磁头碰撞，瞬时强磁场干扰等。

1.3.2 备份方法

静态转储：是指在转储期间不允许对数据库进行任务存取、修改操作。用来恢复
动态转储：是在转储期间允许对数据库进行存取、修改操作，转储和用户事务可并行执行。
海量转储：是指每次转储全部数据库。
增量转储：是指每次只转储上次转储后更新过的数据。

1.3.3 日志文件

日志文件是用来记录事务对数据库的更新操作的文件。
数据库镜像。 为了避免磁盘介质出现故障影响数据库的可用性， 许多DBMS提供数据库镜像功能用于数据库恢复

1.3.4 恢复

UNDO：撤销事务，将未完成的事务撤消，使数据库回复到事务执行前的正确状态。
撤销事务的过程： 反向扫描日志文件（由后向前扫描） ， 查找事务的更新操作； 对该事务的更新操作执行逆操作， 用日志文件记录中更新前的值写入数据库， 插入的记录从数据库中删除， 删除的记录重新插入数据库中； 继续反向扫描日志文件， 查找该事务的其它更新操作并执行逆操作直至事务开始标志。
REDO：重做事务，将已经提交的事务重新执行。
重做事务的过程： 从事务的开始标志起， 正向扫描日志文件， 重新执行日志文件登记的该事务对数据库的所有操作， 直至事务结束标识。

检查点机制（CHECKPOINT)： 在日志中设置检查点， 当发生故障需要利用日志文件恢复时， 反向扫描日志文件， 找到检查点， 确认检查点时刻正在执行的事务（活动事务） ， 即检查点前有事务开始标志但没有事务结束标志。
对于检查点后提交的事务， 执行REDO（重做）
对于检查点后未提交的事务， 执行UNDO（撤销）

（1） 事务故障的恢复： 事务故障是事务在运行至正常终止点（SUMMIT或ROLLBACK） 前终止， 日志文件只有该事务的开始标识而没有结束标识。
恢复：撤销（UNDO）
具体做法：
1、 反向扫描日志文件， 查找该事务的更新操作。
2、 对事务的更新操作执行逆操作。
3、 继续反向扫描日志文件， 查找该事务的其他更新操作， 并做同样的处理， 直到事务的开始标志。
注： 事务故障的恢复是由系统自动完成的， 对用户是透明的。
（2） 系统故障的恢复： 系统故障会使数据库的数据不一致：
一是未完成的事务对数据库的更新可能已经写入数据库；
二是已提交的事务对数据库的更新可能还在缓冲区没来得及写入数据库。
恢复：
1、 未完成的事务（UNDO）
2、 已经提交 commit 的事务（REDO）
（3） 介质故障的恢复： 介质故障时数据库遭到破坏， 需要重装数据库， 一般需要DBA的参与， 装载故障前最近一次的备份和故障前的日志文件副本，
恢复：
1、 未完成的事务（UNDO）
2、 已经提交 commit 的事务（REDO）