系统实现技术课件

,单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,系统实现技术,数据库技术,系统实现技术,DBMS,对,DB,的监控，称为数据库的管理，有时也称为数据库的保护。对数据库的管理主要通过四个方面实现：数据库的恢复、并发控制、完整性控制和安全性控制。每一方面构成了,DBMS,的一个子系统。,1.1.1,事务的定义,定义,6-1,事务（,transaction,）是构成单一逻辑工作单元的操作集合。,DBS,的主要意图是执行“事务”。事务是数据库环境中一个逻辑工作单元，相当于操作系统环境中的“进程”概念。一个事务由应用程序中的一组操作序列组成，在程序中，事务,BEGIN TRANSACTION,语句开始，以,COMMIT,语句或,ROLLBACK,语句结束。,COMMIT,语句表示事务执行成功地结束（提交）,ROLLBACK,语句表示事务执行不成功地结束（应该“回退”,1.1.2,事务的,ACID,性质,1,原子性（,Atomicity,）,:,一个事务对数据库的所有操作，是一个不可分割的工作单元。这些操作要么全部执行，要么什么也不做。,2,一致性（,Consistency,）,:,一个事务独立执行的结果，应保持数据库的一致性，即数据不会应事务的执行而遭受破坏。,3,隔离性（,Isolation,）,:,在多个事务并发执行时，系统应保证与这些事务先后单独执行时的结果一样，此时称事务达到了隔离性的要求。,4,持久性（,Durability,）,:,一个事务一旦完成全部操作后，它对数据库的所有更新应永久地反映在数据库中。,例,6-1:,设银行数据库中有一转账事务,T,，从账号,A,转一笔款子（,$50,）到账号,B,，其操作如下：,T,：,read,（,A,）；,A:=A50,；,write,（,A,）；,read,（,B,）；,B:=B+50,；,write,（,B,）,.,（一致性）在事务,T,执行结束后，要求数据库中,A,的值减,50,，,B,的值增加,50,，也就是,A,与,B,的和不变，此时称数据库处于一致状态。,（原子性）从事务的一致性可以看出，事务中所有操作应作为一个整体，不可分割，要么全做，要么全不做。,（持久性）一旦事务成功地完成执行，并且告知用户转账已经发生，系统就必须保证以后任何故障都不会再引起与这次转账相关的数据的丢失。,（隔离性）多个事务并发执行时，相互之间应该互不干扰。对数据库的访问是建立在读和写两个操作的基础上的：,read,（,X,）：把数据,X,，从磁盘的数据库中读到内存的缓冲区中。,write,（,X,）：把数据,X,，从内存缓冲区中写回磁盘的数据库。,1.1.3,事务的状态变迁图,活动状态,局部提交状态,提交状态,失败状态,异常中止状态,read/write,图,6-1,事务的状态变迁图,1,活动状态,:,在事务开始执行后，立即进入“活动”状态（,active,）。在活动状态，事务将执行对数据库的读,/,写操作。,2,局部提交状态,:,事务的最后一个语句执行之后，进入“局部提交”状态（,partially committed,）。事务是执行完了，但是对数据库的修改，很可能还留在内存的系统缓冲区中。,3,失败状态,:,处于活动状态的事务还没到达最后一个语句就中止执行，此时称事务进入“失败”状态（,failed,）。,4,异常中止状态,:,（,1,）事务重新启动。由硬件错误、软件错误造成的、而不是由事务内部逻辑造成的异常中止时，可以重新启动事务。重新启动的事务是一个新的事务。,2,）取消事务。如果发现事务的内部逻辑有错误，那么应该取消原事务，重新改写应用程序。,5,提交状态,:,事务成功地结束，事务进入“提交”状态（,committed,）。,1.2,数据库的恢复,定义,6-2,系统能把数据库从被破坏、不正确的状态、恢复到最近一个正确的状态，,DBMS,的这种能力称为数据库的可恢复性。,1.2.1,存储器结构,1,存储器类型,:,易失性存储器；非易失性存储器；稳定存储器,2,稳定存储器的实现,:,数据备份；数据银行,3,数据访问,B,内存,A,B,磁盘,input,（,A,）,output,（,B,）,图,6-2,块操作,input,（,A,）,Output,（,B,）,x,i,X,事务工作区,磁盘缓冲区,write,（,X,）,read,（,X,）,图,6-3,数据的,read,和,write,操作,read,（,X,）,write,（,X,）,1.2.2,恢复的基本原则和方法,平时做好两件事：转储和建立日志,一旦发生数据库故障，如果数据库已被破坏装入最近一次拷贝的数据库备份到新的磁盘，然后利用日志库执行“重做”处理，如果数据库未被破坏只要通过日志库执行“撤消”处理,1.2.3,故障类型和恢复方法,事务故障,:,执行,UNDO,处理,系统故障,:,对未完成事务作,UNDO,处理；对已提交事务但更新还留在缓冲区的事务进行,REDO,处理,介质故障,:,重装转储的后备副本到新的磁盘,在日志中找出转储以后所有已提交的事务,对这些已提交的事务进行,REDO,处理,1.2.4,检查点技术,1.DBMS,定时设置检查点,在检查点时刻才真正做到把对,DB,的修改写到磁盘，并在日志文件写入一条检查点记录,当,DB,需要恢复时，只有那些在检查点后面的事务需要恢复,。,t,c,检查点,tf,故障点 检查点 时间,t,事务,T1,T2,T3,T4,T5,图,6-4,与检查点和系统故障有关的事务的可能状态,事务,T1,不必恢复。事务,T2,和事务,T4,必须重做（,REDO,）。事务,T3,和事务,T5,必须撤消（,UNDO,）。,2,检查点方法的恢复算法,根据日志文件建立事务重做队列和事务撤消队列,对重做队列中的事务进行,REDO,处理，对撤消队列中的事务进行,UNDO,处理,3,运行记录优先原则,至少要等相应运行记录已经写入运行日志后，才能允许事务往数据库中写记录；,直至事务的所有运行记录都已经写入到运行日志后，才能允许事务完成,COMMIT,处理。,1.3,数据库的并发控制,1.3.1,并发操作带来的三个问题,1.,丢失更新问题,图,6-5,在时间,t7,丢失了事务,T1,的更新,（,FIND,表示从,DB,中读值，,UPD,表示把值写回到,DB,）,时间,更新事务,T1,数据库中,A,的值,更新事务,T2,t0,100,t1,FIND A,t2,FIND A,t3,A:=A-30,t4,A:=A*2,t5,UPD A,t6,70,UPD A,t7,200,2.,依赖于未提交更新的问题,时间,更新事务,T1,数据库中,A,的值,读事务,T2,t0,100,t1,FIND A,t2,A:=A-30,t3,UPD A,t4,70,FIND A,t5,*ROLLBACK*,t6,100,图,6-6,事务,T2,在时间,t4,读了未提交的,A,值（,70,）,时间,更新事务,T1,数据库中,A,的值,更新事务,T2,t0,100,t1,FIND A,t2,A:=A-30,t3,UPD A,t4,70,FIND A,t5,A:=A*2,t6,UPD A,t7,140,t8,*ROLLBACK*,t9,100,图,6-7,事务,T2,在时间,t4,读了未提交的,A,值，并在时间,t8,丢失了自己的更新,时间,读事务,T1,数据库中,A,、,B,、,C,的值,更新事务,T2,t0,40,，,50,，,30,t1,FIND A,t2,SUM:=A,t3,FIND B,t4,SUM:=SUM+B,t5,FIND C,t6,C:=C-10,t7,UPD C,t8,40,，,50,，,20,FIND A,t9,A:=A+10,t10,UPD A,t11,50,，,50,，,20,COMMIT,t12,FIND C,t13,SUM:=SUM+C,图,6-8,事务,T1,进行了不一致的分析,（在时间,t13,求得,SUM=110,，而不是,120,）,3,不一致分析问题,1.3.2,封锁技术,排他型封锁（,X,锁）,:,如果事务,T,对某个数据（可以是数据项、记录、数据集乃至整个数据库）实现,X,锁，那么其他事务,T,要等,T,解除,X,锁以后，才能对这个数据进行封锁,PX,协议,:,任何企图更新记录,R,的事务必须先执行“,XFIND R”,操作，以获得对,R,的,X,锁，才能读或写记录,R,；如果未获准,X,锁，那么这个事务进入等待状态。一直到获准,X,锁，事务才能继续做下去。,PXC,协议,:X,锁的解除操作应该合并到事务的结束（,COMMIT,或,ROLLBACK,）操作中,例,6-6,时间,更新事务,T1,数据库中,A,的值,更新事务,T2,t0,100,t1,XFIND A,t2,XFIND A,（失败）,wait,（等待）,t3,A:=A-30,wait,t4,wait,t5,UPD A,wait,t6,70,wait,t7,COMMIT,（包括解锁）,wait,t8,XFIND A,（重做）,t9,A:=A*2,t10,UPD A,t11,140,COMMIT,（包括解锁）,图,6-9,等事务,T1,更新完成后再执行事务,T2,共享型封锁（,S,锁）,:,如果事务,T,对某数据加上,S,锁后，仍允许其他事务再对该数据加,S,锁，但在对该数据的所有,S,锁都解除之前决不允许任何事务对该数据加,X,锁。,PS,协议,:,任何要更新记录,R,的事务必须先执行“,SFIND R”,操作，以获得对,R,的,S,锁。当事务获准对,R,的,S,锁后，若要更新记录,R,必须用“,UPDX R”,操作,PSC,协议,:S,锁的解除操作应该合并到事务的结束,例,6-7,时间,更新事务,T1,数据库中,A,的值,更新事务,T2,t0,100,t1,SFIND A,t2,SFIND A,t3,A:=A-30,t4,A:=A*2,t5,UPDX A,（失败）,t6,wait,UPDX A,（失败）,t7,wait,Wait,t8,wait,Wait,图,6-10,更新未丢失，但在时间,t6,发生了死锁,*,封锁的相容矩阵,注：,N=NO,，不相容的请求,Y=YES,，相容的请求,X,、,S,、：分别表示,X,锁，,S,锁，无锁,如果两个封锁是不相容的，则后提出封锁,的事务要等待。,T2,T1,X S,X,S,N N Y,N Y Y,Y Y Y,图,6-11,封锁类型的相容矩阵,封锁的粒度,:,封锁对象的大小称为封锁的粒度,封锁的粒度越大，系统中能够被封锁的对象就越少，并发度也就越小，但同时系统的开销也就越小；相反，封锁的粒度越小，并发度越高，但系统开销也就越大,1.3.3,封锁带来的问题,“活锁”问题,:,系统可能使某个事务永远处于等待状态，得不到封锁的机会,解决活锁问题的一种简单的方法是采用“先来先服务”的策略，也就是简单的排队方式,“饿死”问题,:,有可能存在一个事务序列，其中每个事务都申请对某数据项加,S,锁，且每个事务在授权加锁后一小段时内释放封锁，此时若另有一个事务,T1,欲在该数据项上加,X,锁，则将永远轮不上封锁的机会,避免事务饿死的方法是当事务,T2,中请对数据项,Q,加,S,锁时，授权加锁的条件是：,不存在在数据项,Q,上持有,X,锁的其他事务；,不存在等待对数据项,Q,加锁且先于,T2,申请加锁的事务。,“,死锁”问题,:,系统中有两个或两个以上的事务都处于等待状态，并且每个事务都在等待其中另一个事务解除封锁，它才能继续执行下去，结果造成任何一个事务都无法继续执行，这种现象称系统进入了“死锁”状态,DBMS,中有一个死锁测试程序，每隔一段时间检查并发的事务之间是否发生死锁。如果发生死锁，那么只能抽取某个事务作为牺牲品，把它撤消，做回退操作，解除它的所有封锁，恢复到该事务的初始状态。释放出来的资源就可以分