您的位置:首页 > 数据库

数据库系统概念第十二章 事务

2016-06-10 16:14 302 查看

事务(Transaction)

事务是作为单个逻辑工作单元执行的一系列数据库操作,这些操作可能会修改多个表中的多个元组

事务正常执行的结构是:

begin;
SQL execution 1
SQL execution 2
...
SQL execution N
commit;


begin标志开始一个事务,多个SQL语句就是事务逻辑工作单元,commit(提交)是结束当前事务并提交事务内数据变更,让其生效

数据库一致性在事务上表现的比较特殊,具体来说:事务执行的过程中可以让数据库处于不一致状态,但一旦提交(commit)数据库必须回到一致的状态(一致性是指广义上的一致性,即真实世界的数据一致性,如A和B转帐他们的总账户余额不变等)。

ACID性质

Atomicity:原子性,一个事务要么所有操作被执行,要么全部都不被执行

Consistency:一致性,独立地看待一个事务,它必须保证数据库一致性

Isolation:独立性,多个事务允许并发的执行,但是必须保证事务之间不会互相干扰,并且一个事务执行过程对其他事务应该是透明的

Durability:持久性,当事务成功完成时,它对数据库的更改必须持久化

银行转账是介绍事务时最喜欢用的例子,账户A向账户B转账M元,表达成事务(抽象,非SQL,把update分成多步)就是:

read(A)
A = A - M
write(A)
read(B)
B = B + M
write(B)


这个转账过程是银行数据库经常需要完成的业务逻辑,我们可以把这样经常调用的事务封装成存储过程以供频繁调用(见存储过程一章)

ACID性质具体体现在这个存储过程上就是:

A:要么转账过程的6个步骤全被完成要么全部不被完成,若A的账户不足M元,第三步write写失败(完整性约束),必须保证之前的操作对数据库均不产生影响

C:A和B之和必须保证不变

I:其他和A、B相关的并发转账事务或其他事务对当前转账不产生影响

D:一旦A和B这两个账户持有者收到了转账成功的信息,那么该事务必须永久性生效,即使系统故障(权责划分明确,转账无误,即使故障不可恢复也应该由银行系统负责)

事务管理

了解事务管理之前必须了解一个事务在执行过程中可能处于状态:

Active:事务初始状态,执行时保持该状态

Partially committed:最后一个操作被执行后的状态(还未commit)

Failed:发现错误,停止执行

Aborted:事务被回滚(rollback)数据库恢复到事务执行前的状态, - Aborted后有两个选择:重新执行(如果事务内部没有逻辑错误)、kill该事务

Committed:事务成功执行完成后的状态

事务状态转换关系如下图:



从ACID性质以及上面的事务状态关系可以看出,数据库事务管理主要处理两件事情:

错误/失败:事务执行失败(逻辑错误、系统崩溃、断电等等异常)时恢复处理

并发执行:多个事务能够并发执行(并发的意义在于提高CPU和磁盘利用率,提高吞吐率,以及降低平均响应时间),并且防止并发事务间互相影响对数据库一致性的破坏

并发调度



冲突可串行化(Conflict Serialisability)

调度不同,事务执行结果也不同。我们必须有一个标准来判断某种调度是否正确。这个标准就是事务串行——先执行事务1的所有指令,再执行事务2的所有指令——后的结果。如果调度结果与串行结果相同,则调度正确;反之则错误。此概念与操作系统中多线程的执行类似。



优先图判断是否是冲突可串行化:

先画出每个 transaction(T1 T2 T3…)

找到所有的 读写操作,按照先后顺序,将 read—>write, write—>read, write—>write 连起来,都是前指向后,这些读写都是不同 transaction之间,相同的 transaction 内部不管,如果是相同路径的线段重复多条,只画一条。

如果画完了有环,则是非冲突可串行化,就是有冲突,但是不能串行化的。



画完图,拓扑排序后得到

内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签:  数据库