数据库原理与技术(第二版)程学先电子教案 第9章.pptVIP

数据库原理与技术（第二版） 程学先 程传慧 曾 玲 陈永辉 郑秋华 杨晓艳 六、 更新传播 在分布式数据库系统中是支持数据复制的，这样应用程序就可以在本地的数据副本上进行操作，而避免了远程通信带来的一些问题。 但是复制存在的最大的问题就在于当一个复制对象被修改后，这个对象的所有副本都必须进行修改，这就是更新传播问题。 更新传播 R 常用的解决方法是主副本方法。主副本方法的具体处理有以下几个要点： 被复制对象的一个副本被指定为主副本，剩下的都是从属副本。 不同数据对象的主副本存储在不同的节点中。 R 更新传播 在实际系统中，采用了一种延迟传播的方法。 也就是说主副本对其他副本的修改可以延迟执行，甚至可以在用户指定的某个时候再修改。 这种方法的问题在于数据库无法保证数据在任何时候都是一致的，甚至用户在使用不同的副本时所操作的数据的值都是不同的。 R 更新传播 数据库在更大范围的应用必须依赖因特网，面对不同计算机、不同操作系统、不同数据库、不同语言，要实现更大规模的数据共享，必须解决数据交换问题，必须克服物理上、逻辑上各种数据异构问题。Web语言是最早成功解决该问题的方案，继而又出现了SGML、HTML、XML等语言。 XML R P253 可扩展标记语言XML（Extensible Markup Language）是由万维网协会（W3C）（World Wide Web Consortium）的XML工作组推出的新一代数据交换标准，用于定义Web网页上的文档，其特点是将数据结构化，允许在Web上的更多工作以目前HTML的方式进行。 XML R * 多数协议,每个节点维护自己的锁管理器，这时的锁管理器是负责管理存储在该节点上的数据项的封锁和解锁请求。如果数据项在多个节点中存有副本，则封锁请求必须送到存储有该数据项副本的所有的节点中。 R 分布式数据库系统中的事务处理 这种方式以一种分散的方式处理数据的副本，可以避免集中控制的缺点。 但是对于死锁的处理更加复杂，尤为突出的一个问题是即使只有一个数据项被封锁时也可能发生死锁。 可以对所有节点按照相同的预定顺序请求数据项副本上的封锁，以避免死锁。 R 分布式数据库系统中的事务处理 有偏协议,类似多数协议。不同之处在于，共享锁请求比排它锁请求的实现要方便一些。 系统同样在每个节点上维护一个锁管理器，锁管理器管理存储在该节点上的所有数据项上的锁。 R 分布式数据库系统中的事务处理 主副本方式,是选择一个副本作为主副本，对每个数据项而言它的主副本位于一个节点上，这个节点称之为主节点。 事务要对一个数据项封锁时，只在该数据项所在的主节点上请求封锁就可以了。 但是当主节点发生故障时，即使包含数据项的其它接点的副本是可用的，该数据项也不能被访问了。 R 分布式数据库系统中的事务处理 （2）时间戳 分布式系统是采用给每个事务一个唯一的时间戳的方式实现事务的可串行化的。 在分布式系统中，产生唯一时间戳的方法有两种: R 分布式数据库系统中的事务处理 一种是集中式的，即由一个节点来分发时间戳的，这个节点可以利用一个逻辑计数器或自己本地的时钟来达到这个目的。 另一种是分布式的，每个节点利用逻辑计数器或本地时钟产生唯一的局部时间戳，通过将唯一的局部时间戳和唯一的节点标识符结合起来产生一个唯一的全局时间戳。 R 分布式数据库系统中的事务处理 （3）死锁处理 由于在分布式系统中事务的执行是分布的，封锁的方法会引起全局死锁的问题，全局死锁涉及两个或两个以上节点的死锁。 R 分布式数据库系统中的事务处理 对于全局死锁，采用任何一个节点的内部信息来进行死锁检测是无法检测出来的。 在实际分布式系统中，采用了其他的死锁检测方法，如超时机制，在这种机制中假设在预定时间内不工作的事务发生了死锁。 R 分布式数据库系统中的事务处理 2. 恢复控制 在分布式数据库系统中，是采用两阶段提交协议完成恢复控制的。 对于一个事务，系统要求对不同的独立的分布的DBMS中的数据处理要么执行提交（COMMIT）,要么执行回滚（ROLLBACK），对一个DBMS执行提交而对另一个DBMS执行回滚是没有意义的。 R 分布式数据库系统中的事务处理 因此，事务需要发出一个全局范围内的提交或回滚。 该全局范围内的提交或回滚由一个称作协调者的系统部件控制，协调者保证参与事务的资源管理器（也称作参与者）对它们各自的更新操作所作的提交或回滚是一致的，正是两阶段提交协议使协调者提供了这样的保证。 R 分布式数据库