工程数据库系统报告.docx

  1. 1、本文档共8页,可阅读全部内容。
  2. 2、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
  3. 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  4. 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
查看更多
工程数据库系统报告

工程数据库系统报告教师:XXX 学院:XXXXXXX姓名:XXX学号:XXXXXXXX时间:XXXXXXXX工程数据库管理中的长事务及并发控制1.工程数据库管理中的长事务1.1 事务事务是数据库中工作的最小单位,两次连续成功的提交事务(Commit)或回滚事务(Rollback)之间的操作,称为一个事务。一个事务可以由一个或多个完成一组相关行为的SQL语句组成,通过相应机制保证这组语句所作的操作要么全做,要么全部都不做。事务是由相关操作构成的一个完整的操作单元,是一个不可分割的整体,如果一个操作出错,整个事务会结束,保证完整性。在一个事务内,数据的修改一起提交或撤销,如果发生故障或系统错误,整个事务也会自动撤销。一组SQL语句操作要成为事务,数据库管理系统必须保证这组操作的原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)和持久性(Durability),这就是事务的ACID特性。1.2长事务在数据库中,事务是应用在不发生故障的情况下,应用程序成功执行完毕后( 该事务由系统自动提交);但在工程设计环境中,工程对象的某些部件的设计过程可能持续很长时间,或者工程师需要在交互状态下使用一组数据工作数小时,甚至数天,这时事务处理不仅是为了故障恢复,更多的则是为了方案的优化组合,所以引入长事务的概念,侧重于长事务的处理。对长事务而言,系统关闭或应用结束并不意味着事务的提交,要求工程数据库管理系统提供管理长事务的功能,能妥善解决与长事务有关的并发、共享和完整性约束等问题。1.3工程数据库管理中长事务的特性交互式工程长事务具有如下重要特性:(1)持续时间长。一旦人介入到活动事务中,从计算机的观点看,事务的持续时间就会很长,因为人的响应时间比计算机的长的多;而且在设计类的应用中,人的活动可能持续数小时,甚至数天。(2)未提交数据的曝光。长事务所产生并显示用户的数据是未提交的数据,因为事务可能中止,因此用户和由此而导致的其他事务,可能被迫去读取未提交的数据。多个用户合作一项设计,他们可能需要在事务提交之前交换数据。(3)子任务。一个交互式的事务可能由用户启动一组子任务构成,用户可能希望中止一个子任务,而不是中止整个事务。(4)可恢复性。由于系统崩溃而使一个交互式的长事务中止,这是不能接受的。活动事务必须恢复到系统崩溃前不久的某个状态,这样丢掉的工作较少。(5)性能。交互式事务系统中性能优良的表现之一是响应时间快。2.工程数据库管理中长事务的并发控制2.1 并发控制在多用户和网络环境下,数据库是一个共享资源,多个用户或应用程序同时对数据库的同一数据对象进行读写操作,这种现象称为对数据库的并发操作。显然并发操作可以充分利用系统资源,提高系统效率。虽然如此,若对并发操作不加控制就可能会发生读取和写入不正确的数据,破坏数据库的一致性。所以数据库管理系统必须提供并发控制机制。并发控制是指使用正确的方式实现事务的并发操作,避免数据的不一致性。因此,一个数据库管理系统性能的优劣,很大一部分取决于并发控制,并发控制机制是衡量一个数据库管理系统(DBMS)的重要性能指标之一。在多用户的数据库系统中,并发控制是必须解决的一个重要问题,它将保证多个用户同时运行一个数据库时的正确性。在多个用户同时运行各自的事务时,为了提高运行效率,数据库管理系统并非简单地安排这些事务一个接一个地串行执行,而是让各个事务语句交错地执行,即多个事务同时运行。这样,这些事务就有多种可能的执行顺序,从而需要确定一种各事务的语句交错执行能与某种串行执行效果相同的串行化调度。这些可通过并发控制机制来实现可串行化的调度,控制事务间的相互影响。2.2 传统并发控制方法的分析数据库并发控制的基本目标是为了维护事务并发执行时数据库的一致性。目前,已提出多种并发控制协议来保证可串行化。然而,这些协议对长事务都有消极的影响。(1)一阶段加锁。事务在修改数据之前先加写锁,直到事务结束才释放,可以有效防止“丢失更新”问题。但没有要求对读数据进行加锁,因此不能保证可重复读取和不读“脏“数据。(2)两阶段封锁。当一事务请求封锁而得不到时,必须被迫等待所要求的数据项上的锁释放。等待时间的长短与持有锁的事务的持续时间成比例。如果数据项被一个长事务封锁了则会发生长时间的等待,导致响应时间长,增大发生死锁的可能性。(3)基于图的协议。该协议使得锁释放比两阶段封锁协议早,并且能避免死锁。然而,它对数据项强加了一个顺序,事务对数据项的封锁必须与该顺序一致,其结果可能是事务封锁的数据比它实际需要的多。在事务确信某个锁不会再被使用之前,始终会保持该封锁,易发生长时间的锁等待。(4)基于时间戳的协议。时间戳协议不需要事务等待,然而,在某种情况下,它需要事务中止,如果一个长事务中止了

您可能关注的文档

文档评论(0)

haihang2017 + 关注
实名认证
内容提供者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档