电子文档交易市场
安卓APP | ios版本
电子文档交易市场
安卓APP | ios版本

电子商务数据库技术-电子教案-樊颖军 学习情境5 数据库控制技术

31页
  • 卖家[上传人]:E****
  • 文档编号:89472714
  • 上传时间:2019-05-25
  • 文档格式:PPT
  • 文档大小:155.52KB
  • / 31 举报 版权申诉 马上下载
  • 文本预览
  • 下载提示
  • 常见问题
    • 1、主 编 樊颖军 副主编 张 光 主 审 殷锋社,电子商务数据库技术,普通高等教育“十二五”规划教材 电子商务专业项目是教学课题成果,中国水利水电出版社,子学习情境一 事务,事务有3种运行模式: (1)自动提交事务。即每条单独语句都是一个事务。 (2)显式事务。即每个事务均以BEGIN TRANSACTION语句开始,以COMMIT语句或ROLLBACK语句结束。事务通常是以显式模式运行。 (3)隐性事务。即在前一个事务完成时,新事务隐式启动,但每个事务仍以COMMIT语句或ROLLBACK语句显式地表示完成。,任务二 事物的特性 事务具有4个特性:原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)和持续性(Durability),简称为ACID特性。,子学习情境二 并发控制技术,任务一 并发操作带来的不一致性 并发操作带来的数据不一致问题包括3类:丢失修改(Lost Update)、读“脏”数据(Dirty Read)、不可重复读(Non-Repeatable Read)。 1丢失修改 假设在售票系统中有如下操作序列: 甲售票点(甲事务)读出某

      2、车次的剩余车票张数d,设d=50。 乙售票点(乙事务)读出同一车次的剩余车票张数d,同样为50。 甲售票点售出一张车票,修改剩余车票张数dd-1,所以d为49,把d写回数据库。 乙售票点也卖出一张车票,修改剩余车票张数dd-1,所以d为49,把d写回数据库 。,3不可重复读 不可重复读是指甲事务读取数据后,乙事务执行更新操作,使甲无法再现前一次读取结果。具体地讲,不可重复读包括3种情况: 甲事务读取某一数据后,乙事务对其做了修改,当甲事务再次读该数据时,得到与前一次不同的值。 甲事务按一定条件从数据库中读取了某些数据记录后,乙事务删除了其中部分记录,当甲事务再次按相同条件读取数据时,发现某些记录神秘地消失了。 甲事务按一定条件从数据库中读取某些数据记录后,乙事务插入了一些记录,当甲事务再次按相同条件读取数据时,发现多了一些记录。,任务二 基于封锁的并发控制技术 1三级封锁协议 (1)一级封锁协议:事务T在修改数据R之前必须先对其加X锁,直到事务结束才释放。事务结束包括正常结束(COMMIT)和非正常结束(ROLLBACK)。,(2)二级封锁协议:一级封锁协议加上事务T在读取数据R之前必

      3、须先对其加S锁,读完后即可释放S锁。 二级封锁协议除防止了丢失修改外,还可进一步防止读“脏”数据。 (3)三级封锁协议:一级封锁协议加上事务T在读取数据R之前必须先对其加S锁,直到事务结束才释放。,2两段锁协议 所谓两段锁协议是指所有事务必须分两个阶段对数据项加锁和解锁。 (1)在对任何数据进行读、写操作之前,首先要申请并获得对该数据的封锁。 (2)在释放一个封锁之后,事务不再申请和获得任何其他封锁。 “两段”锁的含义是,事务分为两个阶段。第一阶段是获得封锁,也称为扩展阶段。在这个阶段,事务可以申请获得任何数据项上的任何类型的锁,但是不能释放任何锁。第二阶段是释放封锁,也称为收缩阶段。在这个阶段,事务可以释放任何数据项上的任何类型的锁,但是不能再申请任何锁。,任务三 活锁和死锁 1活锁 如果事务T1封锁了数据R,事务T2又请求封锁R,于是T2等待。T3也请求封锁R,当T1释放了R上的封锁之后系统首先批准了T3的请求,T2仍然等待。然后T4又请求封锁R,当T3释放了R上的封锁之后系统又批准了T4的请求T2有可能永远等待,这就是活锁的情形,2死锁 如果事务T1封锁了数据R1,T2封锁了数据

      4、R2,然后T1又请求封锁R2,因T2已封锁了R2,于是T1等待T2释放R2上的锁。接着T2又申请封锁R1,因T1已封锁了R1,T2也只能等待T1释放R1上的锁。这样就出现了T1在等待T2,而T2又在等待T1的局面,T1和T2两个事务永远不能结束,形成死锁,(1)死锁的预防。 在数据库中,产生死锁的原因是两个或多个事务都已封锁了一些数据对象,然后又都请求对已为其他事务封锁的数据对象加锁,从而出现死等待。防止死锁的发生其实就是要破坏产生死锁的条件。预防死锁通常有两种方法:一次封锁法和顺序封锁法。 1)一次封锁法。一次封锁法要求每个事务必须一次将所有要使用的数据全部加锁,否则就不能继续执行,2)顺序封锁法。顺序封锁法是预先对数据对象规定一个封锁顺序,所有事务都按这个顺序实行封锁。例如在表5-9中,可规定封锁的顺序为R1、R2,T1和T2都必须按这个顺序封锁,即T2也必须先封锁R1。当T2请求封锁R1时,由于T1已经封锁了R1,所以T2只能等待,等T1释放R1、R2上的锁后,T2继续执行。这样就不会发生死锁。,(2)死锁的诊断与解除。 数据库系统中诊断死锁一般使用超时法或事务等待图法。 1)超

      5、时法。如果一个事务的等待时间超过了规定的时限,就认为发生了死锁。超时法实现简单,但其不足之处也很明显。一是有可能误判死锁,事务因为其他原因使等待时间超过时限,系统会误认为发生了死锁。二是时限若设置得太长,死锁发生后不能及时发现。 2)事务等待图法。事务等待图是一个有向图G=(T,U)。T为节点的集合,每个节点表示正在运行的事务;U为边的集合,每条边表示事务等待的情况。若T1等待T2,则T1和T2之间划一条有向边,从T1指向T2。事务等待图动态地反映了所有事务的等待情况。并发控制子系统周期性地检测事务等待图,如果发现图中存在回路,则表示系统中出现了死锁。DBMS的并发控制子系统一旦检测到系统中存在死锁,就要设法解除。通常采用的方法是选择一个处理死锁代价最小的事务,将其撤消,释放此事务持有的所有的锁,使其他事务得以继续运行下去。当然,对撤消的事务所执行的数据修改操作必须加以恢复。,子学习情境三 数据库恢复技术,任务一 数据库可能出现的故障种类 数据库可能出现的故障有以下几种: (1)事务内部故障。 事务内部故障是指事务在运行过程中由于种种原因,如运算溢出、并发事务、发生死锁等,使事务未运行

      6、至终止点就中途夭折的情况。事务内部故障有的是可以通过事务本身发现的,有的是非预期的,不能由事务本身处理。事务故障可能使数据库处于不正确状态,恢复程序要在不影响其他事务运行的前提下强行回滚该事务,即撤消该事务已经做出的任何对数据库的修改,使数据库恢复到该事务未发生前的正确状态。 事务内部更多的故障是非预期的,是不能由事务本身处理的。例如,运算溢出、多个并发执行的事务因发生“死锁”而被选中撤消该事务、违反了某些完整性限制等。,(2)系统故障。 系统故障是指在系统运行过程中造成系统停止运行的任何事件,使得系统需要重新启动。系统故障称为软故障,如一些特定的硬件错误,如CPU故障、操作系统故障、突然停电等。这类故障影响正在运行的所有事务,但不破坏数据库。发生系统故障时,主存内容尤其是数据库缓冲区(在内存)中的内容都将丢失,所有运行事务都被非正常终止。发生系统故障时,一些尚未完成的事务的结果可能已送入物理数据库,有些已完成的事务可能有一部分甚至全部留在缓冲区,尚未写回到物理存储设备中,从而造成数据库处于不正确的状态。,(3)介质故障。 介质故障又称为硬故障。硬故障指外存故障,即存放物理数据库的存储

      7、设备发生不可预知的故障。这类故障将破坏整个数据库或部分数据库,并影响正在存取这部分数据的所有事务。此类故障比事务故障和系统故障发生的可能性要小,但一旦发生破坏性极大。,(4)计算机病毒。 计算机病毒是具有破坏性,可以自我复制的计算机程序。计算机病毒已成为计算机系统的主要威胁,同时也威胁着数据库系统的安全。因此,数据库一旦被病毒破坏,需要用数据库恢复技术将数据库恢复。,任务二 数据库恢复技术 一个好的数据库管理系统DBMS应该能够将数据库从不正确的状态(因出现故障)恢复到最近一个正确的状态,DBMS的这种能力称为“可恢复性”。 恢复机制涉及的两个关键问题是: 如何建立冗余数据,即数据库的重复存储。 如何利用这些冗余数据实施数据库恢复。 建立冗余数据最常用的技术是数据转储和登记日志文件。通常在一个数据库系统中,这两种方法一起使用。,1数据转储 数据转储是指数据库管理员DBA定期地将整个数据库复制到磁带或另一个磁盘上保存起来的过程。这些备用的数据文本称为后备副本或后援副本。 当数据库遭到破坏后可以将后备副本重新装入,但重装后备副本只能将数据库恢复到转储时的状态,要想恢复到故障发生时的状态,必

      8、须重新运行转储以后的所有更新事务。转储是十分耗费时间和资源的,不能频繁进行。DBA应该根据数据库使用情况确定一个适当的转储周期。,2登记日志文件 (1)日志文件的格式和内容。 (2)日志文件的作用。 (3)登记日志文件(Logging)。,任务三 数据库恢复策略 当系统运行过程中发生故障时,利用数据库后备副本和日志文件就可以将数据库恢复到故障前的某个一致性状态。不同故障其恢复策略和方法也不一样。 1事务故障的恢复 事务故障是指事务在运行至正常终止点前被终止,这时恢复子系统应利用日志文件撤消此事务已对数据库进行的修改。事务故障的恢复是由系统自动完成的,对用户是透明的。系统的恢复步骤如下: (1)反向扫描文件日志(即从最后向前扫描日志文件),查找该事务的更新操作。 (2)对该事务的更新操作执行逆操作,即将日志记录中“更新前的值”写入数据库。这样,如果记录中是插入操作,则相当于做删除操作(因此时“更新前的值”为空);若记录中是删除操作,则做插入操作;若是修改操作,则相当于用修改前的值代替修改后的值。 (3)继续反向扫描日志文件,查找该事务的其他更新操作,并做同样处理。 (4)如此处理下去,,

      9、2系统故障的恢复 系统的恢复步骤如下: (1)正向扫描日志文件(即从头扫描日志文件),找出在故障发生前已经提交的事务,将其事务标识记入重做队列。通过查找出故障发生时尚未完成提交的事务,将其事务标识记入撤消队列。 (2)对撤消队列中的各个事务进行撤消回滚处理。进行撤消回滚处理的方法是,反向扫描日志文件,对每个撤消事务的更新操作执行逆操作,即将日志记录中“更新前的值”写入数据库。 (3)对重做队列中的各个事务进行重做处理。进行重做处理的方法是,正向扫描日志文件,对每个重做事务重新执行日志文件登记的操作。即将日志记录中“更新后的值”写入数据库。,3介质故障的恢复 发生介质故障后,磁盘上的物理数据和日志文件被破坏,这是最严重的一种故障,恢复方法是重装数据库,然后重做已完成的事务。具体地说就是: (1)装入最新的数据库后备副本(离故障发生时刻最近的转储副本),使数据库恢复到最近一次转储时的一致性状态。对于动态转储的数据库副本,还需要同时装入转储开始时刻的日志文件副本,利用恢复系统故障的方法才能将数据库恢复到一致性状态。 (2)装入相应的日志文件副本(转储结束时刻的日志文件副本),重做已完成的事务。即首先扫描日志文件,找出故障发生时已提交的事务的标识,将其记入重做队列。然后正向扫描日志文件,对重做队列中的所有事务进行重做处理。即将日志记录中“更新后的值”写入数据库。这样就可以将数据库恢复至故障前某一时刻的一致状态了。,拓展知识 数据库新技术,一、数据库技术发展情况 数据库技术最初产生于20世纪60年代中期,根据数据模型的发展,可以划分为以下几个阶段: (1)第一代的数据库系统是层次模型的数据库系统和网状模型的数据库系统。层次数据库的数据模型是有根的定向有序树,网状模型对应的是有向图。这两种数据库奠定了现代数据库发展的基础。 (2)第二代的关系数据库系统主要特征是支持关系数据模型。关系型数据库的数据模型及其理论是在20世纪70年代由E.F.Codd提出的,最初并未引起重视,但是后来人们逐渐发现了它的重要性,现在它已从理论研究走向系统实现,占据了数据库市场的主流地位。 (3)第三代的数据库以面向对象模型为主要特征。,二、面向对象数据库系统 面向对象的程序设计方法使用面向对象程序设计语言可以更好地描述客观

      《电子商务数据库技术-电子教案-樊颖军 学习情境5 数据库控制技术》由会员E****分享,可在线阅读,更多相关《电子商务数据库技术-电子教案-樊颖军 学习情境5 数据库控制技术》请在金锄头文库上搜索。

      点击阅读更多内容
    最新标签
    发车时刻表 长途客运 入党志愿书填写模板精品 庆祝建党101周年多体裁诗歌朗诵素材汇编10篇唯一微庆祝 智能家居系统本科论文 心得感悟 雁楠中学 20230513224122 2022 公安主题党日 部编版四年级第三单元综合性学习课件 机关事务中心2022年全面依法治区工作总结及来年工作安排 入党积极分子自我推荐 世界水日ppt 关于构建更高水平的全民健身公共服务体系的意见 空气单元分析 哈里德课件 2022年乡村振兴驻村工作计划 空气教材分析 五年级下册科学教材分析 退役军人事务局季度工作总结 集装箱房合同 2021年财务报表 2022年继续教育公需课 2022年公需课 2022年日历每月一张 名词性从句在写作中的应用 局域网技术与局域网组建 施工网格 薪资体系 运维实施方案 硫酸安全技术 柔韧训练 既有居住建筑节能改造技术规程 建筑工地疫情防控 大型工程技术风险 磷酸二氢钾 2022年小学三年级语文下册教学总结例文 少儿美术-小花 2022年环保倡议书模板六篇 2022年监理辞职报告精选 2022年畅想未来记叙文精品 企业信息化建设与管理课程实验指导书范本 草房子读后感-第1篇 小数乘整数教学PPT课件人教版五年级数学上册 2022年教师个人工作计划范本-工作计划 国学小名士经典诵读电视大赛观后感诵读经典传承美德 医疗质量管理制度 2 2022年小学体育教师学期工作总结 2022年家长会心得体会集合15篇
    关于金锄头网 - 版权申诉 - 免责声明 - 诚邀英才 - 联系我们
    手机版 | 川公网安备 51140202000112号 | 经营许可证(蜀ICP备13022795号)
    ©2008-2016 by Sichuan Goldhoe Inc. All Rights Reserved.