基于数据库复制技术的数据转移方案设计与实现-毕业论文

本科毕业论文本科毕业论文(科研训练、毕业设计)题题 目：目：基于数据库复制技术的数据转移方案设计与实现姓 名：学 院：软件学院系：专 业：软件工程年 级：级二学位学 号：指导教师（校内）： 职称：教授指导教师（校外）： 职称：2005 年 05 月 31 日基于数据库复制技术的数据转移方案设计与实现基于数据库复制技术的数据转移方案设计与实现摘要 数据库复制是分布式环境中的一项关键技术。同时在分布式环境中，数据库异构现象越来越普遍，研究异构数据库复制无论在理论上还是在实际运用中上都具有非常重要的意义。作为全部工作的基础，本文从数据库复制技术的发展与现状，数据库复制技术的主要步骤等方面对数据库复制实现的关键方法和技术做了分析和归纳。基于前面的分析总结，根据实际项目的特点，本文提出一种与数据库系统无关，完全异构，具有一定通用性的数据库复制技术基于 SQL 的复制技术，并在此基础上提出数据转移方案。本文重点介绍了基于SQL 的数据库复制技术的数据转移方案，包括设计思路、技术特点及存在问题等。基于这些内容的研究，开发了 Transbuilder 数据转移工具，对基于 SQL 的数据库复制技术进行了实验。最后，本文总结了课题的研究成果，概述了要进一步研究和实践的工作。关键词 数据库复制 异构数据库 数据转移 数据转换基于数据库复制技术的数据转移方案设计与实现Design and Implementation of Data Integration Based on Database ReplicationAbstract Database replication is one of the key techniques in distributed environment. However, Heterogeneity is one of the important features in distributed environment. The development of heterogeneous database address concerns in the research on heterogeneous database replication system. Firstly, this thesis introduces database replication technique and its current application, and analyzes several replication solution provided by diffident database corporations. It is found that in some extents those solutions lack of low compatibility and generality. Based on the study on data replication, the thesis advances a fully heterogeneous database replication method, a replication method based on SQL. This thesis also sums up the advantages and disadvantage of this technique. The author integrates this technique with practice in Xiamen University data integration project. The result proved that this technique is feasible. It would benefits for many fields. At last, this thesis sums up the productions of this subject and plans the future analysis. Key Words Database Replication; Heterogeneous Database; Data Integration; Data Transform基于数据库复制技术的数据转移方案设计与实现目录第 1 章 引言.11.1课题背景.11.2课题研究的理论的实际意义.11.3相关领域的研究进展和成果.11.4课题研究内容.21.5本文的组织.2第 2 章 数据库复制技术.32.1相关概念.32.2数据库复制技术.42.3主要环节.72.4发展与现状.92.5本章小结.10第 3 章 现有异构数据库复制方案.113.1ORACLE的转换器方案 .113.2SYBASE 复制服务器方案 .113.3IBM DB2 信息集成解决方案 .123.4MICROSOFT的出版者/订阅者方案 .123.5本章小结.13第 4 章 基于数据库复制技术的数据转移方案.144.1基础概念.144.2设计思路.154.3技术特点.174.4可能存在问题.184.5本章小结.18第 5 章 技术实现.195.1实验环境.195.2应用背景.195.3设计与功能分析.215.4原型实现.235.5本章小结.30第 6 章 结论.31基于数据库复制技术的数据转移方案设计与实现 1第 1 章引言引言1.1 课题背景信息化是当今世界经济和社会发展的大趋势，以信息技术为达标的科学技术的迅猛发展，对人类的生产方式、思维方式以及学习方式等都产生了重大的影响。信息时代的学习与以多媒体和网络技术为核心的信息技术的发展密切相关。那么我国的高等教育如何迎接信息化所提出的挑战？如何充分利用新技术所提供的巨大潜力构件二十一世纪的高等教育模式？数字化校园正是在这样的环境和形势下被高校作为了自身不断发展的必要性建设。然而，由于学校各个部门学院在数字化校园建设前都普遍存有自己的系统，出现了一个现象单独的部门系统建设比较强，互联互通苦难。如何有效整合现有系统及数据是数字校园建设的一个重要问题。数据整合是信息化建设过程经常遇到的一个现实问题。这也是制约高校信息化建设和数据共享程度的一个重要因素。数据整合包括数据转换和数据迁移，也就是本文所提到的数据转移。根据实际项目及一些理论研究，作者提出了基于异构数据库复制技术的数据转移方案。1.2 课题研究的理论和实际意义由于经济、技术、人为等因素的影响，高校信息化建设中的各个子系统数据库间存在着很大的异构性，这又给数据整合带来了更大的挑战。异构数据库复制技术可以有效地解决这一问题。异构数据库复制就是异构数据库与数据库复制的结合。异构数据库复制技术是一种与数据库系统无关，完全异构的复制技术，可以保证数据迁移的完整性和准确性，也可以保证数据整合项目的顺利进行。1.3 相关领域的研究进展和成果目前在这个数据转移领域已经有了一些研究。大多数数据库生产厂商对数据转移均提出相应方案并且开发相关工具，比如 Microsoft DTS 转换工具、ORACLE 的移植工作台、Informix 的 InfoMover 等。这些工具都在一定范围内解决了数据的提取和转换等工作。但这些工具基本都不能自动完成数据的抽取，用户还需利用这些工具编写适当的转换程序1。这些工具都可以从多个不同的业务系统，多个平台的数据源中抽取数据，完成转换和清洗等。但是这些方案，一般形式单一，且都基于厂商的实际利益出发，希望用户把其他数据库都移植到自己的产品上来，而且一般价格昂贵，这给用户带来很大的不便。在第三方产品中，Ascential Software 公司的 DataStage 是一套相对比较完善的产品. DataStage 可以从多个不同的业务系统中，从多个平台的数据源中抽取数据，完成转换和清洗，装载到各种系统里面。其中每步都可以在图形化工具里完成，同样可以灵活的被外部系统调度，提供专门的设计工具来设计转换规则和清洗规则等，实现了增量抽取、任务调度等基于数据库复制技术的数据转移方案设计与实现多种复杂而实用的功能。2005 年 4 月日立数据推出首款动态多维数据迁移解决方案具有较大的突破性。这个方案可根据访问形式的变化来管理数据的迁移，为需要不同类型数据管理的应用提供信息访问。1.4 课题研究内容作者有幸参加了厦门大学信息化建设项目，项目组成立于 2004 年 5 月。作者所在的科研管理系统开发小组由七位开发人员组成，其组织如下图 1-1 所示。图 1-1 科研管理系统开发团队协作图作者在项目中负责数据转换移植工具开发，在本文，其主要研究内容包括两个方面:1. 数据库复制实现方法和技术的归纳和总结。作为整个论文工作的基础，本文首先介绍了数据库复制技术的基本概念，然后分析讨论了数据库复制的主要环节及发展与现状，并且分析比较目前多数数据库厂商提出并实现了异构数据库复制方案。2. 基于异构数据库复制技术的数据转移方案的提出、设计与实现。从项目背景、需求分析、系统设计与实现详细介绍了对基于异构数据库复制技术的数据转移方案，并分析其技术特点及不足。1.5 本文的组织本文共分六章。文章的结构安排如下:第1章引言，阐明了本研究课题的产生背景、研究的理论与实际意义、相关领域的研究进展和成果及主要研究内容。第2章对数据库复制的相关概念做了简单介绍，对复制技术实现的关键方法和技术进行了归纳和总结，最后对现有异构数据库复制技术做了介绍。第3章分析并总结了目前最常用的四种异构数据库复制方案。第4章详细介绍了基于SQL的异构数据库复制技术的数据转移方案，提出了设计思路、技术特点等。第5章介绍了技术的原型实现:Transbuilder系统，总结了系统的优点与不足。最后，对本课题研究的结论进行了总结，并谈了对进一步工作的构想。基于数据库复制技术的数据转移方案设计与实现第 2 章数据库复制技术针对数据库复制，研究界和产业界多年来进行了深入的研究，取得了许多成果。本章在分析研究这些成果的基础上，对其中的关键方法和技术进行了总结归纳，以此作为全文工作的基础，内容主要包括数据库复制的发展和现状，以及数据库复制的两个组成环节:变化捕获与数据分发。2.1 相关概念本节对数据库复制的一些相关概念做简单介绍。2.1.1分布式数据库系统 分布式数据库系统是由若干个站集合而成。这些站又称为节点，它们在通讯网络中联接在一起，每个节点都是一个独立的数据库系统，它们都拥有各自的数据库、中央处理机、终端，以及各自的局部数据库管理系统。因此分布式数据库系统可以看作是一系列集中式数据库系统的联合。它们在逻辑上属于同一系统，但在物理结构上是分布式的。2.1.2异构数据库由于不同的数据库系统是由不同的生产厂商生产的，为了保证各自的应用特性、完整性控制和安全性控制，各个数据库系统间往往表现出很大的异构性。异构数据库系统的异构性主要体现在以下几个方面： 1. 计算机体系结构的异构。各个参与的数据库可以分别运行在大型机、小型机、工作站、个人计算机或嵌入式系统中。 2. 基础操作系统的异构。各个数据库系统的基础操作系统可以是 Unix、Windows NT、Linux 等。3. 数据库系统本身的异构。数据库系统可以是同为关系型数据库系统的Oracle、Microsoft SQL Server 等，也可以是不同数据模型的数据库，如关系、模式、层次、网络、面向对象、函数型数据库等共同组成一个异构数据库系统。2.1.3数据库复制数据库复制是将一组数据从一个数据源拷贝到多个数据源的技术，是将一份数据发布到多个存储站点上的有效方式。使用复制技术，用户可以将一份数据发布到多台服务器上，从而使不同的服务器用户都可以在权限的许可的范围内共享这份数据。复制技术可以确保分布在不同地点的数据自动同步更新，从而保证数据的一致性。基于数据库复制技术的数据转移方案设计与实现2.1.4事务事务就是一个单元的工作，包括一系列的操作这些操作要么全部成功，要么全部失败。事务必须满足 ACID 属性。ACID 的含义就是原子性（Atomic）、一致性（Consistent）、隔离性（Isolated）、和持久性（Durable）等属性。2.1.5主节点与从节点节点:在复制系统中，每台数据库服务器称为一个节点。主节点:运行主数据库的节点。从节点:运行从数据库的节点。2.1.6主数据库与从数据库主数据库:具有自主数据表和相应支持对象、对客户端提供数据服务的数据库服务器。从数据库:没有自主数据表，而是通过建立数据库连接与主数据库建立联系，存放主数据库的部分或全部数据的副本的数据库，也称为复制数据库。2.2 数据库复制技术本节首先从复制分类和体系结构等方面对数据库复制技术做一个大概的介绍。2.2.1复制分类数据库复制通常可被划分为两种类型：同步复制和异步复制。1. 同步复制（Synchronous Replication）同步复制采用同步分发数据库技术，复制数据在任何时间、任何复制节点均保持一致。如果复制环境中的任何一个节点的复制数据发生了更新操作，这种变化会立刻反映到其它所有复制节点。为了保证源数据和目标数据的一致性，在复制过程中采用了两阶段提交协议；若目标数据库有多个，则只有当相互连接的每个目标数据库都同意接受该更新事务时，作用在源数据上的修改事务和作用在各目标数据库的修改事务才算提交成功，否则，均回滚。同步复制可以保证复制环境中没有数据冲突的存在。但由于在同步复制环境中，要求硬件设备和网络要随时可用，否则，一旦网络不稳定或硬件设备出现故障，则对源数据的修改和对目的数据的复制均会失败。因此同步复制要耗费更多的硬件和网络资源。基于数据库复制技术的数据转移方案设计与实现2. 异步复制（Asynchronous Replication）异步复制，对执行时间的要求就相对要比较松一些。异步复制采用异步分发数据库技术，也称为存储转发复制，所有复制节点的数据在一定时间内是不同步的。如果复制环境中的其中的一个节点的复制数据发生了更新操作，这种改变将在不同的事务中被传播和应用到其它所有复制节点。这些不同的事务间可以间隔几秒，几分钟，几小时，也可以是几天。复制节点之间的数据临时是不同步的，但传播最终将保证所有复制节点间的数据一致。在异步复制环境中，对任何一个复制节点上复制数据的更新将会在本地被捕捉到，生成一个延迟事务放入延迟事务队列。在预定的时间间隔或是根据需要，延迟事务队列中的延迟事务被传播到其它复制节点，并在节点上执行。如果事务在一个复制节点执行不成功，只有该节点的事务被回滚，复制数据不进行更新，不会影响到其它的复制节点。异步复制环境相对于同步复制环境而言，要求比较少的网络和硬件资源，并且提供了更好的可用性和性能。一个复制节点的失效不会影响到整个系统的正常运行，应用可以从其它的复制节点获取数据。异步复制环境中，由于事务的延迟提交会导致系统中复制数据的暂时不一致，甚至有时候会产生冲突，如何处理冲突是设计异步复制方案时要考虑的问题。这两种复制类型的差别是:同步复制是指在事务提交之前，更新操作在所有副本完成，它的优点是可以保障副本之间的一致性及较强的容错性，但它也带来一系列问题，其中包括:死锁、通信量增加、节点规模的限制及事务响应时间延长;而异步复制是在事务提交之后，更新操作才被传播到其它节点，它的优点是降低了通信量且缩短了响应时间，因而采用这种方法可提高系统效率，但是它最大的缺点是:先提交，后更改，有可能在不同节点的副本之间存在不一致性。2.2.2体系结构数据库复制技术的体系结构体现了数据复制过程中数据源和数据目的之间的关系，有以下三种基本的体系结构,2，3，4 。1. 主/从结构(Master-slaver Model)主/从结构是数据只能从主数据库中复制到复制数据库中，如图 2-1。更新数据的操作只能在主节点进行，从节点仅供用户读取数据。但当主节点出现故障时，更新数据的应用可以转到其中一个从节点上去。这种复制方式实现起来比较简单，易于维护数据一致性。这是一种最简单的结构。基于数据库复制技术的数据转移方案设计与实现图 2-1 主从结构2. 对等结构(Peer to peer Model)对等结构就是各个节点的地位是平等的，可以互相复制数据，如图 2-2。用户可以在任何节点读取和更新全局数据，在某一节点更新全局数据时，数据库会将数据传送到所有其它复制节点。图 2-2 对等结构这种复制的体系结构一般会出现两种情况，一是需要复制的源数据分布在多个数据库中，但对每个数据而言，全系统只有一个主数据库，每个主数据库有自己的数据，主数据库更新自己的数据，然后按约定复制到其它各复制数据库；二是需要复制更新的源数据分布在系统的多个数据库中，每个需要复制的数据在本地更新，本地数据库就是主数据库，然后按约定复制到其它复制数据库。在这种结构中会产生更新冲突，应用程序必须有办法解决更新冲突。3. 联接结构(Cascade Model)级联结构是主/从结构的一个扩展，从主节点复制过来的数据又从该节点再次复制到其它复制节点，即A节点把数据复制到B节点，B节点又把这些数据或其中的部分数据基于数据库复制技术的数据转移方案设计与实现再复制到其它节点，如图2-3所示。这种结构可以平衡当前各种数据需求对网络通信的压力。图 2-3 联接结构比较上述三种结构，主/从结构在管理上最简便，数据只能从主数据库中复制到复制数据库中。更新数据只能在主节点上进行，从节点供用户读取数据。这种结构实现起来比较简单，易于维护数据一致性，但由于数据只能在主数据库进行更新，降低了整个大系统的自治性。对等结构是最灵活的一种结构，它充分体现了分布式数据库的分布特性，各节点高度自治，可用性好，但它必须在解决修改冲突后才能使复制有效，然而解决修改冲突的难度较大、算法复杂、系统开销大，因而其管理的代价也很高。联接结构在复制过程中能降低网络开销，但在复制链上的任一环节的问题都会引起复制失败，使其后的所有节点都无法获得复制数据。这种结构通常与其它两种结构混合使用。2.3 主要环节数据库复制就是通过将源数据库中指定的数据复制到目标数据库中，以保持源数据库与目标数据库中指定数据的同步，一般包括对源节点的变化捕获及数据分发两个主要环节。 2.3.1变化捕获变化捕获是数据库复制的基础，它直接决定了数据库复制的更新方式和选时方式。变化捕获要获得复制对象的变化序列。通过对当前使用的变化捕获方法的综合分析，本文总结出五种基本变化捕获形式，分别是基于快照法、基于触发器法、基于日志法、基于时间戳和基于 API 法4。1. 基于快照法基于快照法是最简单的变化捕获方法，可以在任何数据库甚至是其他结构化和半结构化的数据源上实现。它不需要以来特别的机制，不占用额外的系统资源，管理和操作也非常容易，而且在复制初始化和崩溃恢复时是必须的。但由于无法区分复制对象中哪些记录具体发生改变，因此效率很低。Oracle 和 Microsoft SQL Server 提供了基于快照的捕获方法。基于数据库复制技术的数据转移方案设计与实现2. 基于触发器法在源数据库为复制对象创建相应的触发器，当对复制对象进行修改、插入和删除等DML 命令时，触发器被唤醒，将变化传播到目标数据库。基于触发器法克服了基于快照法的主要缺点，极大提高了效率，可用于同步复制、增量复制，但是触发器捕获法占用系统资源较多。Oracle 和 IBM DB2 都提供了基于触发器的捕获方法。3. 基于日志法数据库事物日志是维护数据完整性和数据库恢复的重要工具，其中包含了全部成功提交的数据库操作记录信息，基于日志法就是通过分析数据库事务日志的信息来捕获复制对象的变化序列。因为大多数数据库都有事务日志，利用日志方便，也不会站用太多额外的系统资源，该方法对任何类型的复制都使用， ；利用事务日志，复制对象的变化很容易在其他节点再现，这能提高效率和保证数据的完整性；但基于日志法也存在一些缺点，首先一些数据库系统不公开日志的格式，除非厂家提供响应的日志分析工具或借口，否则要开发一个基于日志的变化捕获程序非常困难；其次，尽管都是利用数据库事务日记捕获变化，但不同数据库系统在具体细节上还是存在很大差异，这给异构数据库复制带来了新的麻烦。在实际运用中，基于日志法是最普遍的变化捕获方法。Microsoft SQL Server、Sybase、IBM DB2 都提供了基于日志法的捕获方法。4. 基于时间戳法基于时间戳法需要相关应用系统中的每个表中都有一个时间戳字段，以记录每个表的修改时间。这种方法不影响原有应用的运行效率，但却需要对原有系统做较大的调整，而且不能捕获到那些并非通过应用系统引起的操作数据变化。5. 基于 API 法一些小型数据库和非关系型数据库没有触发器和日志机制，还有另一些数据则因为某些原因不能使用上上述的捕获方法，此时还可以在应用程序和数据库间引入一类中间件，由它提供一系列 API（包括 ODBC 驱动程序） ，这些中间件在完成应用程序对数据库修改的同时也把复制对象的变化序列记录下来，从而达到变化捕获的目的。在某种意义上基于 API 法可以看承是基于日志法的一个变种，它能够实现基于日记法的大多数优点，而且给异构数据库复制带来便利。但它存在着两个严重的缺点，一是对那些不经过 API 的操作，如在控制台命令行方式下执行的 update、delete、insert等语句，所引起的变化是无法被 API 捕获的；二是应用程序的可移植性差，当从一种运行环境移植到另一种运行环境时，往往需要重新编写应用程序，甚至改变数据库模式，尤其当 API 不是 ODBC 驱动程序的时候。表 31 是对上述五种变化捕获方法，从更新方式、适用范围、占用资源、依赖机制、同步复制、异步复制及可移植性进行对比。表 21 五种变化捕获方法比较5捕获方法更新方式适用范围占用资源依赖机制同步复制异构复制可移植性基于快照完整拷贝广少无否是高基于触发器增量修改一般多触发器是困难低基于日志法增量修改一般一般日志是困难低基于时间戳法增量修改一般少时间戳困难苦难低基于 API 法增量修改窄一般中间件是是低基于数据库复制技术的数据转移方案设计与实现2.3.2数据分发分发有时也称传播(Propagate)，负责节点之间数据的发送和接收。一般情况下，它把副本的更新信息从源节点传输到目标节点，分发器在不同场合还有一些其它作用，例如在同步复制时分发器要承担协调者的任务，对等复制时如果发现复制冲突，分发器还负责传递控制信息和仲裁结果。由于数据分发是通过网络来进行的，网络连接方式的不一样直接影响了数据分发。就网络连接方式而言，有基于消息(message-based)式和基于会话(session-based)式两种。基于消息的连接，又称为消息队列(message queuing)式或保存并转发(store-and-forward)连接，是早期的数据库复制方案广泛采用的连接方式。源节点事先把要分发的数据保存在本地的历史文件(如日志)中，到时再按照发送和接收消息包的方式来传递数据。传递消息包通过源节点和目标节点的出/入(Outbound/Inbound)消息队列来完成，在对等复制时还需要再提供一对反方向的出/入消息队列。这种方式一般对网络要求较高，有时必须管理传输路径和复制的拓扑结构。基于会话的连接也称点对点(point-to-point)连接，这种方式不需要事先准备分发数据，因此可以在分发时才捕获变化。节点之间的数据传播以会话的方式进行，每个节点都可以同时发送和接受数据。基于会话的连接方式对网络环境没有特别要求，适用于各种拓扑结构，基于会话式连接在可靠性、效率及可标量性等方面具有优势，从发展前景看，它有逐渐取代基于消息式连接的趋势，不过在同步复制时它不如基于消息式连接可靠。5分发工作由不同的节点承担会形成不同的分发模型，从而影响复制的组织形式和效率。如果由源节点承担分发任务，表现为数据由源节点主动地发送给目标节点，这就是“推出”模型（Push Model） ，如图 24;而如果由目标节点承担分发任务，表现为由目标节点向源节点申请而得到数据，这就是“拉回”模型（Pull Model）,如图 25。两种模型都有其利弊，只有由源节点担任分发工作的“推出”模型，主动分发数据，无视目标节点是否可以接受，而目标则会处于被动等待状态，什么时候会有数据分发不得而知；“拉回”模型虽然使得目标服务器有主动申请的权利，但是要等待源服务器的响应。如果能很好地让两种模型结合起来，将可以大大提供数据分发的效率。目前大多数复制方案都同时支持这两种模型,称为“推-拉”模型， 如图 26。图 2-4 推出模型图 2-5 拉回模型基于数据库复制技术的数据转移方案设计与实现图 2-6 推-拉模型2.4 发展与现状几家大型数据库厂商在其主流数据库产品同构复制的基础上，进一步地提出了各自的异构数据库复制方案，其中包括 Oracle 主张通过数据库转换器，Sybase 利用 LTM (日志传输器)，IBM 使用数据变化表（Consistent-Change Data Table） ，微软则提出出版者/订阅者方案等。这些方案各有所长，但在一定程度上还存在着局限性。各个数据库厂商由于要体现自己产品的特点及其他一些原因，由他们各自提出的方案都采用与数据库系统核心关系紧密的实现技术，因此不一定适用于其它数据库系统，彼此之间的兼容性较差。再者，各方案普遍存在着符合某种体系结构或标准的前提，因此导致对系统资源的要求较高而应用范围却受到限制。总体说来目前的状况是不能让用户满意的。国内对数据库复制的研究与国际上相比还存在一定的差距，对异构数据库复制的研究则更少。作者只在一些文献中发现部分相关内容，其中比较系统的有中国人民大学的移动数据库系统金仓系统(KingBase)、东南大学的 Galaxy 系统及国防科技大学的李霖等提出面向移动领域的 TTR(三级复制体系结构，Three-Tier Replication Architecture)。2.5 本章小结作为后面工作的基础，本章通过分析研究数据库复制技术，对数据库复制技术的主要步骤的变化捕获，数据分发等方面进行了总结归纳，最后简单介绍异构数据库的复制技术的发展现状。基于数据库复制技术的数据转移方案设计与实现第 3 章现有异构数据库复制方案目前已有多数数据库厂商提出并实现了异构数据库复制方案。本文重点关注数据库复制方案包括Oracle的转换器方案、Sybase的复制服务器方案、IBM DB2信息集成解决方案和微软的出版者/订阅者方案。3.1 Oracle 的转换器方案Oracle 主张通过数据库转换器来实现异构数据库复制。如图 3-1 所示。复制是对称的方向.可以是 Oracle 数据库到非 Oracle 数据库，也可以是非 Oracle 数据库到 Oracle 数据库。图 3-1 Oracle 转化器方案 实现简单和整体性程度高是转换器方案的主要优点。其缺点是在 UNIX 系统下 Oracle 与 SQL Server 间的数据复制无法实现，需要另一台 Windows 下的 Oracle 9i 来做透明网关服务器。因为 SQL Server 本身不支持 UNIX，所以 Oracle 也无法直接在 UNIX 下访问 SQL Server。再者，由于数据库透明网关/转换器的复杂性，这种方案的运行性能受到限制，而且成本高。3.2 SYBASE 复制服务器方案6Sybase 的复制方案是基于日志的，它的系列服务器产品中包含了专用于复制的复制服务器。 Sybase 复制方案的关键成分是 LTM (Log Transfer Manager 日志传输管理器)，它是一个在源节点检测数据库日志的进程或线程，一旦 LTM 发现源数据发生变化，就立即通知本地的复制服务器，将变化序列尽快地分发给远程节点，那里的复制服务器接收到以后，同步目标数据库而完成复制过程，如图 32。基于数据库复制技术的数据转移方案设计与实现图 3-2 SYBASE 的 LTM 方案LTM 进程，是一个由 SYBASE Open Server/Open Client 编写的应用程序，这个进程可以驻留在单独的机器上。正是原因 SYBASE 复制服务器才使用户将复制系统对主数据库施加的负担降低到最小限度。又因为 Sybase 提供了 RCL(复制命令语言)，所以 LTM 方案的适用范围广而且易于移植。然而，它的主要缺点在于受 C/S 体系的限制，LTM 方案一般只支持主从式复制；再者，LTM 方案的传播只支持 ASAP (as soon as possible)方式，缺乏选时、调度等方面的选择；还有当通过 WAN 复制时，需要事先人工规划网络路径，同时对网络质量的要求也比较高 5 。3.3 IBM DB2 信息集成解决方案IBM 的异构复制方式是基于触发器的，通过触发器捕获复制源的变化信息并存入变化数据表(Consistent-Change Data Table)7；实施程序根据复制周期从变化数据表读取内容并根据它们来修改目标数据库。IBM 的变化数据表方案的优点在于，IBM 的数据库家族庞大及 IBM 开发了一系列的辅助工具，因此它的支持面广；再者，由于提供的复制数据字典非常完善，变化数据表方案的数据库模式转换功能优于其它数据库厂商的方案。不过变化数据表方案也有一些缺点，比如变化数据表要占用较多的系统资源，如存储空间、进程等。3.4 Microsoft 的出版者/订阅者方案Microsoft SQL Server 的复制方案称为“出版者/订阅者”方案7，其中有三个主要角色:出版者、订阅者和分发者。源数据所在的服务器是出版者，负责发表数据。出版服务器把要发表的数据的所有改变情况的拷贝复制到分发服务器，分发服务器包含有一个分发数据库，可接收数据的所有改变，并保存这些改变，再把这些改变分发给订阅服务器。出版者/订阅者方案建立在 ODBC 或 OLE DB 标准上，要实现 SQL Server 数据库到非 SQL Server 数据库的复制或从非 SQL server 到 SQL server 的复制，但是必须是在由 SQL Server 担任分发者的前提下，为非 SQL Server 数据库创建相应的角色和代理。 “出版者/订阅者”方案的优点主要表现在，复制方式最全面，不仅提供了异步复制，还有用于同步复制的选项；框架和构造规范且明确，方便使用。基于数据库复制技术的数据转移方案设计与实现不过该方案也有一些缺点妨碍了它的进一步应用，比如必须由 SQL Server 服务器担任分发器角色；还有 Microsoft SQL Server 只能运行 windows 平台。3.5 本章小结本章通过对现有成功的异构数据库复制方案的研究，得出结论，这些异构数据库复制方案优势突出，但同时也存在问题。数据库厂商提供的复制方案依赖于厂商自己的数据库系统核心关系紧密的实现技术，不一定适用于其它数据库系统，复制方案不是完全异构的。基于数据库复制技术的数据转移方案设计与实现第 4 章基于数据库复制技术的数据转移方案前面通过对现有成功的数据库复制方案的研究及分析得到的结论表明，这些异构数据库复制方案优势突出，比如在运行性能和整体性方面都有着明显的优势，而且产商大多提供了一些辅助工具可以协助用户更好地完成复制任务等；但同时也存在问题，数据库产商提供的复制方案依赖于产商自己的数据库系统核心关系紧密的实现技术，不一定适用于其它数据库系统，也就是说复制方案不是完全异构的。作者结合自己参与项目的实际情况，为解决完全异构及数据转移问题，提出了基于 SQL的据库复制技术的数据转移方案，其核心思想是通过 SQL 语句取得源数据库中的复制对象(源表或视图)，根据中央数据库规范进行转化，设置复制周期，定时复制到目标数据库，即中央数据库。本章将从工作原理、设计思路、技术特点以及存在问题的解决方案等几个方面介绍作者的思想。4.1 基础概念4.1.1复制源一个复制源就是一张用户欲从中拷贝数据的表或视图，当定义一个复制源时，可以指定要复制的列和行。4.1.2任务集任务集：一个任务集定义复制源数据库与目标数据库之间的关系及复制源与目标的数据库连接信息。4.1.3源服务器、目标服务器与实施服务器源服务器是驻留变化将要被捕捉的表的数据库服务器。目标服务器是从数据源复制过来的数据将要驻留的数据库服务器。实施服务器是分发控制数据驻留的数据库服务器。实施服务器可以是源服务器、目标服务器或网络上的其它服务器。但是，为了性能考虑，通常实施服务器与目标服务器相同，数据可以通过网络“拉回”目标数据库。4.1.4源列与目标列源列是复制源表中要复制的列。基于数据库复制技术的数据转移方案设计与实现目标列是要插入的目标数据库列。4.1.5转化转化，是把所有数据按中央数据库规范转化。4.2 设计思路4.2.1工作原理1. 数据转换数据转换，根据目标数据库的规范，对源数据进行数据格式及数据内容标准化转换。2. 数据复制数据复制根据 2.3 节提到可以分为变化捕获和数据分发。变化捕获是捕获源表的变化序列的过程。本文的基于 SQL 的异构数据库复制技术的变化捕获思想是为多个相关源表(极端的情况可能是一张源表或整个数据库的所有表)创建相应的 SQL 语句存放在实施服务器上，根据用户所设定的任务调度时间适时进行数据分发。数据分发是指将源表的变化信息实施到相应的目标表中的过程。基于数据库复制技术的数据转移方案的数据分发模型是“拉回”模型，因为根据实际项目的特点，实施服务器及目标服务器对源数据只有只读权限。4.2.2设计思想本文提出的方案的设计思想是由用户根据需要创建任务，并设置执行周期,定期执行任务，以表的形式存放相关任务信息。任务创建包括取得复制源、取得目标、数据转换、任务保存等环节。任务执行则就是数据库复制过程。1. 取得复制源及取得目标取得复制源及取得目标要取得数据库连接信息及所有要复制的列。取得复制源及目标时要保证实施服务器正确连接到源服务器和目标服务器。这主要是由使用者提供连接数据库的信息，系统进行连接测试。如果可以正确连接，保存连接信息包括数据库类型、服务器名、用户名、密码及用户模式。取得所有要复制的列，由用户根据实际选择要复制的源列和目标列。系统保存源列集合和目标列集合。2. 数据转换数据转换是任务创建中的最主要的环节。各个数据库设计都有自己的相应规范，数据库与数据库间却存在的一定的规范性差异。各个数据库根据自己对应的字典表对表名、列名及字段内容进行一定的标准化。因此，这要求在进行数据转移过程中必须对数据进行有效的转化。源列的编码必须根据源数据库的字典表转化为真实数据，而当复制到目标数据库的时候，则需要把真实数据根据目标数据库的字典表转换成规范编码。在本文基于数据库复制技术的数据转移方案设计与实现所提到的方案中，采用列映射信息表存放列转化规则，映射信息表存于实施服务器上。在实际转化过程中，由取得的表字段信息，组成 SQL 语句对其进行数据转换。由于各个数据库的映射库，代码库设计不一致，本文提出的方案基于两个可能存在的情况，设置映射信息表。一种是必须根据映射表及代码表才能进行代码与真实数据间的转换，如图 4-1；另一种则是只需要代码表就能进行转换，如图 4-2。因此映射信息表字段包括列名、字典表名、字典表列字段名、代码编号、代码表名、代码列名、真实数据列名等。列名（column_name）：要进行转换的列的名称。字典表名（dic_tablename）：列对应的字典表名称。列字段名（dic_fieldname）：字典表中存放表字段的列的名称。代码编号（codeid）：字典表中对应的代码信息列。代码表名（dm_tablename）：列对应的代码表名。代码列名（dm_code_column）：代码表中代码所在列的列名称。真实数据列名（dm_description）：代码表中真实数据所在列的列名称。图 4-1 映射表-代码表联合型图 4-2 代码表型每个任务创建时应分别创建一张源列映射信息表及一张目标列映射信息表。源列映射信息表表名命名规则为 RULE+_源表名 1+_源表名 2+_源表 3+_.。目标列映射信息表表名命名规则则是 RULE+_目标表名。比如,从源表集合RSC.C001A001,RSC.C001A007复制到目标表 RSC.RSC_RYXX.对应的源列映射信息表表名是RULE_RSCC001A001_RSCC001A007，目标列映射信息表表名则为 RULE_RSCRSC_RYXX。3. 任务保存任务保存是以任务信息表的形式把相关信息保存于实施服务器上。任务信息表字段包括任务号、源表集合、源列集合、目标表、目标列集合、复制源数据库连接信息、目标数据库连接信息、源列映射信息表名、目标列映射信息表名、数据类型映射信息及执行周期。任务号（taskid）:应用程序在每个任务创建时，根据创建时间，给每个任务分配基于数据库复制技术的数据转移方案设计与实现一个任务号，用来表示任务。源表集合（srcSet）:记录所有复制源表名。源列集合（srcColSet）:记录所有要复制的列。目标表（dstTable）:记录目标表名。目标列集合（srcColSet）:记录相对应的目标列。复制源数据库信息（srcDBConnectInfo）:连接复制源数据库的所有信息，包括复制源数据库类型、服务器名、用户名、密码及数据库名。目标数据库信息（dstDBConnectInfo）:连接目标数据库的所有信息，包括目标数据库类型、服务器名、用户名、密码及数据库名。源列映射信息表名（srcMapInfo）:包括源实体表与源代码表之间的映射信息。目标列映射信息表名（dstMapInfo）:包括目标实体表与目标代码表之间的映射信息。数据类型映射信息（dataMapInfo）:记录两个数据库间数据类型的映射信息。执行周期(executrPeriod):记录运行周期。4. 数据库复制数据库复制思想就是从任务信息表读取相关任务信息，根据数据库连接信息、源表集合、源列集合、目标表集合、目标列集合等字段信息，根据 SQL 语句取得复制源，根据列映射信息表进行转换，然后又根据数据类型映射表进行数据类型映射，最后根据SQL 语句把源插入到目标数据库。4.3 技术特点4.3.1完全异构完全异构意味着复制能够在所有数据库至少是所有关系数据库兼容的数据库之间进行。基于SQL的数据库复制技术通过ODBC，OLE DB及PowerBuilder提供专用数据库可连接各种数据库。因此，此技术是完全异构的。4.3.2数据库系统无关目前的许多复制方案，特别是数据库产商提供的数据复制方案，都依赖于与产商自己的数据库系统核心关系紧密的实现技术，而基于 SQL 的数据库复制技术采用 PowerBuilder 技术开发，使用 PowerBuilder 提供的数据库专用接口及 ODBC、OLEDB 连接各种数据库,这样利用这些接口，就不用考虑太多底层的数据库系统的特性，可以透明地操作各种数据库系统。对不同类型的数据库的连接、访问、执行过程、查询等等，对于应用来说都是一样的，所以可以做到数据库系统无关。因此，此技术是与数据库系统无关的。4.3.3通用性基于 SQL 的数据库复制技术是以 SQL 语句形式出现的，可以给任何数据库做复制。此技术的实施程序从任务集里读取相关信息形成 SQL 语句对复制源数据库进行读取，在目标数据基于数据库复制技术的数据转移方案设计与实现库执行相对应 SQL 语句，进行复制。4.3.4可配置基于 SQL 的数据库复制数据转移方案是可以配置的，根据用户需要进行配置。4.4 可能存在问题4.4.1效率问题由于使用的变化捕获方法是完全捕获，而不是通过监视变化进行的增量复制，这使得复制效率稍低。采取完全捕获是由于作者根据实际实现项目的特殊性，对实时要求并不是特别高及数据源记录数并不大及对信息完整性的要求较高等因素。然而，这个仍然有待进一步改进。4.4.2数据弱一致性由于使用定时复制技术，所以在进行两次复制之间的这段时间内，不能保证多个数据副本之间的数据一致性，称这种一致性为弱一致性; 基于SQL的数据库复制技术，提供手动进行复制，在获知复制源数据已经发生改变，但复制周期还未到的时候，可以启动手动复制。4.4.3处理时间滞后由于是定时复制技术，所以在主数据库中新增加或修改的信息不能立即反映到从数据库中，数据传送的滞后就会造成事务处理时间的滞后。这种由定时进行数据复制引起的事务处理时间的滞后，在多大程度上可以让使用者接受，这是设置复制操作周期的重要依据。4.5 本章小结本章根据全面对数据库复制技术的分析与研究，提出了基于 SQL 数据库复制技术的数据转移方案，并分析其技术特点及可能存在问题。基于数据库复制技术的数据转移方案设计与实现第 5 章技术实现为了基于 SQL 复制技术的可行性及技术特点，作者与茅晓白同学共同开发了Transbuilder 数据移植工具，本章将进行详细介绍。5.1 实验环境实验环境如下:数据库系统: ORACLE9i, Microsoft SQL server 2000操作系统: Windows server 2000, Windows server 网络:局域网(TCP/IP 100Mbps)硬件:PC 机(Pentium4 2.4G, 1G RAM, 80GHD), PC 机(Pentium4 2.4G,512M RAM, 80GHD), PC 机(Pentium4 2.4G, 256M RAM, 80GHD)开发平台：Sybase PowerBuilder 9.05.2 应用背景在进行课程研究的过程中，作者参与厦门大学信息化建设中心的数据转移项目。根据各个部门学院的工作职能，各个部门学院共享基本数据，保留私有数据。共享数据存放于中央数据库，各个部门学院拥有自己的数据库，如图 5-1 所示。图 5-1 数据库系统结构基于数据库复制技术的数据转移方案设计与实现项目第一期工作是将各个部门学院的共享数据抽取出来放于中央数据库。第一阶段任务是将人事处的人员基本信息复制到校园中央数据库，供其他相关部门共享。因此复制源为人事处数据库的人员基本信息，目标数据库为中央数据库。人事处数据库是 Microsoft SQL server2000，中央数据库则是 Oracle9i，数据库间存在着异构。再者，由于现有的源数据库及目标数据库的设计不一样，其中表结构和字典表等的不一致性，给复制工作带来了更大的挑战。中央数据库含有映射代码库、实体表库、私有代码库及其他代码库，如框架图52 所示；人事处数据库经研究分析如图 53 所示拓扑图。因此，在复制过程要根据源数据库的字典表对源数据进行代码与真实数据间的转化，在复制到目标数据库时要根据目标数据库的字典表对数据进行真实数据与代码间的转化。研研究究生生院院现现存存数数据据库库教教务务处处现现存存数数据据库库人人事事处处现现存存数数据据库库财财务务处处现现存存数数据据库库_DESCRIPTIONPKRSC_TABLENAME RSC_DESC_RYXX JZ010001 JZ010004 JZ010008 JZ010009 JZ010010 JZ010029 JZ200003 JZ030002映映射射代代码码库库X部部门门实实体体表表库库共共享享代代码码库库X部部门门私私有有代代码码库库.表表名名 / / 字字段段名名 字字段段内内容容其其他他代代码码库库字字段段内内容容_DESCRIPTI