《系统实现技术》PPT课件PPT课件下载推荐.ppt
《《系统实现技术》PPT课件PPT课件下载推荐.ppt》由会员分享，可在线阅读，更多相关《《系统实现技术》PPT课件PPT课件下载推荐.ppt（82页珍藏版）》请在冰豆网上搜索。
ROLLBACK语句表示事务执行不成功地结束（应该“回退”），此时告诉系统，已发生错误，数据库可能处在不正确的状态，该事务对数据库的所有更新必须被撤消，数据库应恢复该事务到初始状态。
7,7.1.1事务的定义
（2）,例7.1设银行数据库中有一转账事务T，从账号A转一笔款子（$50）到账号B，其操作如下：
T：
read（A）；
A:
=A50；
write（A）；
read（B）；
B:
=B+50；
write（B）.,组织成如下事务：
BEGINRANSACTION；
=A-50；
if（A0）ROLLBACK；
elseread（B）；
write（B）；
COMMIT；
8,7.1.1事务的定义（3）,对数据库的访问是建立在读和写两个操作的基础上的：
read（X）：
把数据X，从磁盘的数据库中读到内存的缓冲区中。
write（X）：
把数据X，从内存缓冲区中写回磁盘的数据库。
在系统运行时，write操作未必导致数据立即写回磁盘，很可能先暂存在内存缓冲区中，稍后再写回磁盘。
这件事情是DBMS实现时必须注意的问题。
9,7.1.2事务的ACID性质,性质原子性（Atomicity）:
事务是一个不可分割的工作单元。
一致性（Consistency）:
即数据不会应事务的执行而遭受破坏。
隔离性（Isolation）:
在多个事务并发执行时，系统应保证与这些事务先后单独执行时的结果一样。
持久性（Durability）:
一个事务一旦完成全部操作后，它对数据库的所有更新应永久地反映在数据库中。
10,7.1.3事务的状态变迁图,11,7.2数据库的恢复,7.2.1存储器结构7.2.2恢复的基本原则和实现方法7.2.3故障类型和恢复方法7.2.4检查点技术7.2.5SQL对事务的支持,12,7.2.1存储器结构
（1）,1.存储器类型易失性存储器（volatilestorage）内存、cache存储器非易失性存储器（nonvolatilestorage）磁盘和磁带稳定存储器（stablestorage）这是一个理论上的概念。
存储在稳定存储器中的信息是决不会丢失的。
2.稳定存储器的实现数据备份数据银行,13,7.2.1存储器结构
（2）,3.数据访问块、物理块和缓冲块块的操作input（A）：
把物理块A的内容传送到内存的缓冲块中。
Output（B）：
把缓冲块B的内容传送到磁盘中恰当的物理块中,14,7.2.1存储器结构（3）,15,7.2.1存储器结构（4）,4.恢复和原子性的联系,16,7.2.2恢复的基本原则和实现方法,基本原则：
“冗余”，即数据库重复存储。
具体实现方法平时做好两件事：
转储和建立日志周期地（比如一天一次）对整个数据库进行拷贝，转储到另一个磁盘或磁带一类存储介质中。
建立日志数据库。
记录事务的开始、结束及数据每一次插入、删除和修改前后的值，并写到“日志”库中。
一旦发生数据库故障，分两种情况进行处理如果数据库已被破坏，则装入last数据库备份，再利用日志库将这两个数据库状态之间的所有更新重新做一遍。
如果数据库未被破坏，但某些数据不可靠，则撤消所有不可靠的修改，把数据库恢复到正确的状态。
17,7.2.3故障类型和恢复方法
（1）,1.事务故障可以预期的事务故障，如存款余额透支等非预期事务故障，如运算溢出、数据错误、死锁等2.系统故障：
硬件故障、软件错误或掉电等重新启动时，具体处理分两种情况考虑。
对未完成事务作UNDO处理；
对已提交事务但更新还留在缓冲区的事务进行REDO处理。
18,7.2.3故障类型和恢复方法
（2）,3介质故障在发生介质故障和遭受病毒破坏时，磁盘上的物理数据库遭到毁灭性破坏。
此时恢复的过程如下：
重装最近转储的后备副本到新的磁盘，使数据库恢复到转储时的一致状态。
在日志中找出最近转储以后所有已提交的事务。
对这些已提交的事务进行REDO处理，将数据库恢复到故障前某一时刻的一致状态。
在实际中，系统故障通常称为软故障（SoftCrash），介质故障通常称为硬故障（HardCrash）。
19,7.2.4检查点技术
（1）,1检查点方法在DBS运行时，DBMS定时设置检查点。
在检查点时刻才真正做到把对DB的修改写到磁盘，并在日志文件写入一条检查点记录（以便恢复时使用）。
当DB需要恢复时，只有那些在检查点后面的事务需要恢复。
事务T1不必恢复；
事务T2和事务T4必须重做（REDO）；
事务T3和事务T5必须撤消（UNDO）。
20,7.2.4检查点技术
（2）,2检查点方法的恢复算法：
分成两步。
（1）根据日志文件建立事务重做队列和事务撤销队列。
此时，从头扫描日志文件（正向扫描）。
（2）对重做队列中的事务进行REDO处理，对撤销队列中的事务进行UNDO处理。
进行REDO处理的方法是：
正向扫描日志文件，根据重做队列的记录对每一个重做事务重新实施对数据库的更新操作。
进行UNDO处理的方法是：
反向扫描日志文件，根据撤销队列的记录对每一个撤销事务的更新操作执行逆操作。
21,7.2.5SQL对事务的支持,无begintransactionCommitRollback游标,22,7.3数据库的并发控制,7.3.1并发操作带来的三个问题7.3.2封锁技术7.3.3封锁带来的问题7.3.4并发操作的调度7.3.5SQL对事务处理的支持7.3.6基于时标的并发控制,23,7.3.1并发操作带来的三个问题
（1）,图7.5在时间t7丢失了事务T1的更新（FIND表示从DB中读值，UPD表示把值写回到DB）,1丢失更新问题（例7.2）,24,7.3.1并发操作带来的三个问题
（2）,图7.6事务T2在时间t4读了未提交的A值（70）,2读脏数据问题（例7.3，用户读了“脏数据”，但没有破坏数据库的完整性）,25,7.3.1并发操作带来的三个问题（3）,图7.7事务T2在时间t4读了未提交的A值，并在时间t8丢失了自己的更新,2读脏数据问题（例7.4，用户读了“脏数据”，引起自身的更新操作被丢失，破坏了数据库的完整性）,26,7.3.1并发操作带来的三个问题（4）,图7.8事务T1两次读取A的值，却得到了不同的结果,3.不可重复读问题（例7.5）,27,7.3.1并发操作带来的三个问题（5）,解决方法：
28,7.3.2封锁技术
（1）,定义7.3锁（lock）是一个与数据项相关的变量，对可能应用于该数据项上的操作而言，锁描述了该数据项的状态。
通常在数据库中每个数据项都有一个锁。
锁的作用是使并发事务对数据库中数据项的访问能够同步。
封锁技术中主要有两种封锁：
排他型封锁共享型封锁。
29,7.3.2封锁技术
（2）,1.排他型封锁（X锁，写锁）X锁定义：
如果事务T对某个数据R（可以是数据项、记录、数据集乃至整个数据库）实现了X锁，那么在T对数据R解除封锁之前，不允许其他事务T再对该数据加任何类型的锁。
这种锁称为“X锁”。
X锁的操作有两个：
封锁操作“XFINDR”解锁操作“XRELEASER”X锁的解除操作应该合并到事务的结束（COMMIT或ROLLBACK）操作中。
30,7.3.2封锁技术（3）,例7.6使用X锁技术，可以解决图7.5的丢失更新问题。
图7.9等事务T1更新完成后再执行事务T2,31,2共享型封锁（S锁，读锁）定义7.5如果事务T对某数据加上S锁后，仍允许其他事务再对该数据加S锁，但在对该数据的所有S锁都解除之前决不允许任何事务对该数据加X锁。
S锁的操作有三个：
封锁操作“SFINDR”升级和写操作“UPDXR”解锁操作“SRELEASER”可以看出，获准S锁的事务只能读数据，不能更新数据，若要更新，则先要把S锁升级为X锁。
另外，由于S锁只允许读数据，因此解除S锁的操作不必非要合并到事务的结束操作中去，可以随时根据需要解除S锁。
7.3.2封锁技术（4）,32,7.3.2封锁技术（5）,例7.7使用S锁技术,也可以解决图7.5的丢失更新问题。
图7.10更新未丢失,但在时间t6发生了死锁,33,注：
N=NO，不相容的请求Y=YES，相容的请求X、S、：
分别表示X锁，S锁，无锁如果两个封锁是不相容的，则后提出封锁的事务要等待。
7.3.2封锁技术（6）,3封锁的相容矩阵,34,4封锁的粒度定义7.6封锁对象的大小称为封锁的粒度（granularity）。
封锁的对象逻辑单元:
属性值、属性值集合、元组、关系、索引项、整个索引、整个数据库物理单元:
页（数据页或索引页）、块封锁粒度与系统并发度和并发控制开销密切相关。
粒度越大，系统中能被封锁的对象就越少，并发度就越小，但同时系统的开销也就越小；
相反，粒度越小，并发度越高，系统开销越大。
7.3.2封锁技术（7）,35,5封锁协议：
三级封锁协议，分别在不同程度上解决了并发操作带来的各种问题，为并发操作的正确调度提供一定的保证。
7.3.2封锁技术（8）,36,7.3.3封锁带来的问题
（1）,1“活锁”问题定义7.7系统可能使某个事务永远处于等待状态，得不到封锁的机会，这种现象称为“活锁”（LiveLock）。
解决活锁问题的一种简单的方法是采用“先来先服务”的策略，也就是简单的排队方式。
如果运行时，事务有优先级，那么很可能使优先级低的事务，既使排队也很难轮上封锁的机会。
此时可采用“升级”方法来解决，也就是当一个事务等待若干时间（譬如5分钟）还轮不上封锁时，可以提高其优先级别，这样总能轮上封锁。
37,7.3.3封锁带来的问题
（2）,2“饿死”问题定义7.8有可能存在一个事务序列，其中每个事务都申请对某数据项加S锁，且每个事务在授权加锁后一小段时内释放封锁，此时若另有一个事务T2欲在该数据项上加X锁，则将永远轮不上封锁的机会。
这种现象称为“饿死”（starvation）。
可以用下列方式授权加锁来避免事务饿死。
当事务T2中请对数据项Q加S锁时，授权加锁的条件是：
不存在在数据项Q上持有X锁的其他事务；
不存在等待对数据项Q加锁且先于T2申请加锁的事务。
38,7.3.3封锁带来的问题（3）,3.“死锁”问题定义7.9系统中有两个或两个以上的事务都处于等待状态，并且每个事务都在等待其中另一个事务解除封锁，它才能继续执行下去，结果造成任何一个事务都无法继续执
升级会员 