Sybase复制服务器
一个经过实践证明的信息分布和共享体系结构
目录
?摘要 (1)
?简介 (2)
?什么是数据复制？ (3)
o早期的数据复制: Dump 和 Reload (3)
o同步复制：两阶段提交 (3)
o不保证交易完整性的复制技术: 快照 (4)
o不保证交易完整性的复制技术：数据库触发器 (5)
o基于日志的复制技术：利用触发器或规则 (5)
o最先进的复制技术: Sybase复制服务器 (6)
?在什么环境使用复制服务器 (8)
o例1：一个主站点对多个辅站点（决策支持复制） (8)
o例2：多个主站点对一个辅站点（多个数据源合并） (9)
o例3：没有更新冲突的对等配置（共享公司数据） (10)
o例4：具有更新冲突的对等配置（公司数据的集成） (11)
o例5：一主一辅（热备份数据库） (12)
?复制服务器如何工作 (14)
o交易（数据变化）检测------LTM (15)
o交易在LAN和WAN上的传播和路由 (16)
o复制系统的配置和管理 (17)
o如果系统和连接出故障怎么办：稳定队列(Stable Queue) (18)
o修改复制数据：分布式更新 (19)
?为什么使用Sybase复制服务器？ (22)
o复制服务器优势：高性能 (22)
o高性能数据获取：不使用触发器或规则 (22)
o高性能数据传输 (23)
o高性能数据存取 (23)
o复制服务器优点：一致的数据传送 (23)
o复制服务器优点：简单的集中管理 (23)
o复制服务器优点：数据的高可用性 (24)
o复制服务器优点：异构系统集成 (24)
o复制服务器优点：本地管理 (25)
?总结 (26)
?附录∶怎样建立复制服务器环境？ (27)
o例1：决策支持复制 (28)
o例2：数据合并 (29)
o例3：企业数据共享 (30)
o例4：数据集成 (31)
摘要
本文重点介绍Sybase的复制服务器（Replication Server）。复制服务器是Sybase 数据库应用产品集的重要组成部分，该产品集是为了满足企业范围内的Client/Server计算的需求而专门设计的。复制服务器提供的异构硬件和数据源之间复制信息的功能，可以在保证数据交易完整性的前提下，实现企业间信息方便的共享。
复制服务器提供了一个可靠的存储转发（store and forward）功能，以适应现实世界中网络连接或网络设备可能出现故障的情况。如果远程站点可以连通，则信息直接发送到该远程站点，如果一个或多个远程站点网络连接出现故障，则信息一直被保存，直到重新建立连接，此后信息会自动重新进行同步。即使在网络出现故障，不能存取远端站点信息的情况下，本地系统仍可不受影响地继续工作。
Replication Server Manager是一个功能强大的、易于使用的图形化系统管理工具，可大大简化分布式系统的管理工作。系统管理员可通过一台机器对整个企业复制环境中的所有分布式组件进行统一管理和监测。
经过三年周密设计和客户的积极参与，Sybase于1993年11月正式发布了复制服务器，目前复制服务器已在数百家全球企业级Client/Server应用的数据分布系统中得到成功应用。复制服务器为业务单位的数据管理提供了最经济可靠的途径。
本文首先通过举例介绍了分布式系统中数据复制的概念，以及数据复制可解决的业务和技术问题。其后详细描述了复制服务器的工作原理，并重点介绍了Sybase体系结构的优点。附录详细介绍了构建复制系统的具体操作。
简介
Sybase复制服务器是Sybase数据库应用产品集的重要组成部分，该产品集是为满足用户企业范围内的Client/Server计算的需求而专门设计的。复制服务器正式发布于1993年11月，目前已成为全球企业级Client/Server应用中数据分布的基础。本文描述了使用复制服务器进行信息分布和共享的特有优势。
与简单地将一部分数据从一台机器拷贝到另一台机器相比，企业内业务数据的复制要复杂的多。复制系统必须满足以下所有业务需求：
1.数据的高可用性：复制系统应具有可靠性，同时复制系统的计算机系统故障不应影响
业务的正常操作。
2.信息传送的一致性：分布式系统必须保证数据完整性。
3.高性能：复制系统不应影响数据源系统的正常运行，应当高效地利用网络，并允许各
点采用最优化的方法存取本地数据。
4.简单的集中化管理：系统管理员可简单的通过单个终端对复制系统中的所有分布式组
件进行统一管理。
5.支持异构数据源：复制系统应支持异构数据源之间的数据传输。
6.本地自治：每个复制点可自行设定要接收的信息集，以及如何查看，存取和修改数
据。
如下文所述， Sybase的复制服务器对于信息分布和共享是一个理想的、并已经过实践证明了的体系结构。本文首先介绍了分布式应用中数据复制的概念，并介绍一个使用复制服务器构建的复制系统例子，以及该例子解决的应用和技术问题。其后详细描述了复制服务器的工作原理，并重点介绍了Sybase体系结构的优点。附录详细介绍了构建复制系统的具体操作。
什么是数据复制？
仅仅在几年前，所有数据还都存放在数据中心，远地部门要获得信息，必须与中心建立直接连接，或者从中心MIS系统申请打印好的报表。但是这两种方式都有一定的缺点，直接连接开销较大，稳定性不好，并且还有连接用户数的限制。而报表灵活性较差，并且也不能及时反映最新状况。
开放系统为企业的各个部门提供了便宜而且强大的计算资源。充分利用这些新的资源实现信息共享的能力成为企业最重要的竞争优势。企业今天面对的问题已经不是“为什么要分布和共享信息”，而是本文下面要讲述的“如何有效地分布信息”。复制正在成为大多数分布式应用体系结构的选择。
图 1: 数据分布方案
早期的数据复制: Dump 和 Reload
复制数据的概念并不是新近才提出的，早在几年前，企业就采用先“卸载”数据（可能通过磁带方式）然后在另一个节点“重新加载”数据的方式来进行数据分布。在那个时候，各机构之间通过邮寄数据磁带进行数据复制的情景很常见，而业务部门决策时所使用的数据可能是几天甚至几周前的数据。
采用“卸载和重新加载”进行数据分发，使企业不同地区之间共享数据成为可能，但是每个地方的数据都不是实时的，并且整个过程通常采用的是手工方式，没有实现自动化。
同步复制：两阶段提交
八十年代后期，两阶段提交技术的概念（Sybase是其倡导者之一）为分布和共享数据提供了更实时的途径。两阶段提交可以实现分布式数据间的同步。在这种技术下，只有当与交易相关的各个点全都认可时，交易才被接受并执行。各分布节点可通过精心制作的“握手”机制进行协同。
图 2:在两阶段提交中，直到所有相关站点都同意进行交易，交易才
被接受并执行。因此，业务运作容易受到单个系统组件失败的影响。
当企业的确需要对分布式数据进行同步时，采用两阶段提交可能比较合适。但这是有代价的。由于在交易被认可之前，所有分布节点都需要同步认可，信息系统容易受到单个组件故障的影响。如果任何一个组件失效，则交易必须等待。操作就受制于单个组件的失败。此外，握手机制是通过节点间信息的传送来实现协调的，这为网络带来了很大的负担。
由于分布式系统中网络连接和单个组件都可能发生故障，很多组织开始寻找更经济实用的方式来实现协同数据共享，同时希望将对操作的影响降到最小。显然，实时分发当前数据拷贝可解决这个问题。由于有了有效的数据备份，各独立节点不再需要考虑网络或远程节点的可用性。它们可使用本地数据备份继续进行操作。不过，分布节点所操作的数据并不是同步和实时的。
不保证交易完整性的复制技术: 快照
最早，人们采用表快照的方法来解决分布式数据拷贝的问题。表快照实现了对单个表、表子集、甚至基于预定义的表集合的变更的异步发送。
虽然与“卸载和重新加载”过程相比，表快照先进的多，但其还存在一些明显的不足，这些缺陷限制了它的适用性。首先，快照不能保证交易完整性，其次，快照只是一个“只读“拷贝，其它节点只能获取但不能进行修改。
快照在拷贝单个的数据表或数据项时，并不保持交易的原子性。当交易中断时，分布式数据之间的完整性就可能得不到保证。例如：如果银行使用快照方式来分发你的银行帐号信息，存款帐号信息和支票帐户信息的复制是独立的，如果你将钱从存款帐户转到支票帐户，存款帐户的改变可能没有在支票帐号改变时同时进行拷贝。黑客可能利用这些缺陷攻击这类不可靠的银行支付系统。很显然，对于任何一个重视数据完整性和一致性的企业来说，这种方法是不被接受的。
此外，采用表快照方式只能实现数据的单向传输，虽然数据可以备份到多个节点，但备份是只读的，各节点不能对分布式数据进行任何修改。
不保证交易完整性的复制技术：数据库触发器
除了快照，一些数据库厂家还提供了另外一种异步机制来进行单向数据复制——触发器。在早期的基于触发器的复制系统中，客户希望通过使用触发器来达到整和复制应用的目的。
你可以将触发器想象成数据库中一个警报器，该警报器与某一段特定的数据相关联。当标记的数据项发生改变时，就会触发源数据库中的相关警报器，该警报器接着激活源数据中特定的复制代码，开始进行复制。
最初，数据库厂家引入数据库触发器是为了保证数据间的参照完整性，同时将业务规则放在中心处理。其观点是数据库本身应包含一种对非法数据实体的检测机制。在引入触发器之前，必须在所有存取数据库的应用中考虑数据过滤，对于提供触发器的数据库厂家来说，基于触发器的复制似乎为产品提供了一种直接简单的扩展。
与快照相比，触发器为用户提供了更大的灵活性，但早期的基于触发器的复制系统并没有克服快照技术的内在缺点：缺少对客户数据的交易完整性的支持。基于触发器的复制存在以下限制：
?当数据项改变时，触发器只是进行简单数据传送，而不保证交易完整性
?触发器只允许单向复制，复制点的数据是只读的，不能进行修改
?在数据库中执行触发器会影响数据库的性能
?触发器需要数据库管理员的细心管理，需要专人对数据改变时所有“警报器”的执行情况进行跟踪。
?数据库中触发器的激活的过程不能简单的“回滚”或重做。
总之，在早期的基于触发器的复制系统中，需要用户自己构建系统来跟踪并保证交易的完整性。
基于日志的复制技术：利用触发器或规则
如上所述，为数据复制目的而提出的扩展数据库触发器技术（或者规则—触发器的一种表示形式）为数据库厂家提供了一种简单的扩充其支持特性列表的方法。
然而，提供基于触发器或规则的复制技术的厂家很快就意识到，他们必须面对如下事实，即简单的触发器或规则并不能保证复制数据的交易完整性，并且对复制点数据不能进行修改,而用户需要的是一个灵活的可保证交易完整性的复制系统。
对于已经采用基于触发器或规则进行复制的厂家来说，其解决方法是显而易见的：与其让用户用触发器或规则作为他们整和系统的工具构建他们的复制系统，为什么不在内部使用触发器来创建一个复制产品，这样厂家就可以将用户从最低层的触发器和规则隔离开。
这些厂家引入了一种新的机制，可以将源数据库内触发的数据变化组成一个交易，以此解决了基于触发器或规则的复制系统的数据交易完整性的问题。虽然这个过程不可避免的增加了性能负担。
对触发器和规则进行约束限制解决了完整性等部分问题，但没有解决其它问题，如触发器给数据源造成的性能负担，给系统管理员增加的管理负担等。这些问题包括：
?在数据库内部执行触发器增加了数据库性能负担。
?触发器需要数据库管理员的细心管理，需要专人对数据改变时所有“警报器”的执行情况进行跟踪。
?数据库中触发器的激活的过程不能简单的“回滚”或重做。
触发器的使用增加了源数据的性能和管理负担。当触发器是用于保护数据完整性或加强业务规则时，这种额外支出是必要的，但是对于复制系统这种支出是没有必要的，并且在事实上，其也不适用于复制系统。
基于触发器的复制系统与源数据库捆绑过于紧密，要执行一个复制进程，必须在源数据库内执行复制代码，从而，为数据源增加了额外的性能负担。
Sybase很早就意识到基于触发器的复制的局限性，并决定实现一个灵活的复制体系结构，该复制体系结构不应增加数据库管理员的负担，并且不会影响系统性能。
最先进的复制技术: Sybase复制服务器
在了解了前面所讲的一些早期复制实现方法之后，我们很快发现：一个可靠的复制系统比简单的数据备份要复杂的多，其还必须满足以下要求：
?在事物层保证数据的完整性
?通过网络快速有效地分发数据
?允许分布的节点分别更改数据
?易于监控和管理（这也许是最重要的功能）
?在异构数据源之间实现双向数据传输
1993年秋天，复制服务器的产生将第一个也是迄今为止最优秀的复制产品引入了市场，通过与客户的紧密合作，Sybase 为协同信息的分布提供了一个全新的，实用的、可靠的解决方案。
复制服务器为数据复制概念增加了很多新的内涵。复制服务器的异步操作可分成以下六个组成部分：
1.首先，复制系统对一个或多个源数据库中发生的交易进行监测并捕获。这个过程不使用触
发器或规则，以保证对系统的性能影响最小。
2.其后交易信息通过局域或者广域网络向外进行分发，在此过程中系统管理员可以选择一种
最优的方式来使用网络资源。
3.交易被发送到目的节点，目的点用户可以不受限制地裁剪和修改复制来的数据。
4.强有力的图形管理工具使管理员通过单一中心节点就可监测和管理分布式系统中的所有组
件或组件集。
5.如果网络或系统组件出现问题，正在传送的数据被临时保存在磁盘缓冲队列中；当失败的
组件恢复正常时，复制重新启动并将缓存的数据重新发送到目的节点。
6.使用 Sybase产品，用户可实现异构硬件和数据源之间的双向数据传输。
在什么环境使用复制服务器
在详细介绍复制服务器工作原理之前，我们先向大家介绍一些复制服务器在Client/Server环境下的应用实例。下面的例子虽然不是面面俱到，但它能够说明在分布式的环境中灵活的复制结构所带来的益处。根据使用复制服务器的分布式系统的设计，我们可以在分布式系统中区分三种类型的站点：
?主站点（只包含原始数据的站点）：将数据从本地向其他系统复制的场所，主站点的数据可以被修改和更新。
?辅站点（只包含复制数据的站点）：此站点从一个或多个主站点接收数据。辅站点数据只能读取，不能更改。
?对等站点（既包含源数据又包含复制数据的混合站点）：既可以将本地数据复制到到其它系统，又可以从一个或多个主站点接收数据。对等站点的复制方法适用于没有更新冲突的应用。
下面我们将举例说明，Sybase复制服务器可以用于包含上述站点的任意组合的应用环境。并且信息可以在SYBASE数据源和非SYBASE数据源之间复制。
例1：一个主站点对多个辅站点（决策支持复制）
在简单的应用中，复制服务器提供了一种经济的、从单一中央站点向多个复制站点分发信息的方式。在复制站点中，信息只能被读取，不能被修改。不象快照方式，分布式机制维持了数据的交易完整性。
图3显示了如下情形：一个公司在旧金山使用中央OLTP数据库（这个数据库也可能建立在历史数据源之上）处理定单。定单录入程序（作为终端或客户端）直接与中央OLTP系统相连，中央OLTP 系统直接由公司的MIS人员控制。公司其他地区的大量决策者（如旧金山的财务部，达拉斯的制造部，纽约的销售部）希望能够查阅订单的信息，以及时地在本部门做出决策。然而，由于这些查询请求经常需要大量耗费系统的资源，并且这类用户的量比较大，OLTP系统无法直接支持这类请求。决策者常常不得不从MIS人员提供的标准报告中寻找所需信息。
如果使用复制服务器，单独的区域就能够“订阅”中央站点数据的子集，并在本地查看信息。财务，销售和制造部门不必登录到旧金山的中央MIS系统，而是直接访问本地从中央数据库复制下来的本地需要的数据。更好的是，可以将网络和远程系统的故障与各地的用户隔离开来。此外，由于本地使用者访问的是本地的数据，从而加快了查询的结果。
图三：决策支持复制
复制通过向更多的部门提供决策支持的数据使整个系统的扩展能力大大地加强。正如我们在本文后面要讨论的，复制服务器在复制过程中不增加源数据库负担。只要在复制站点的“订阅“内容足够少，使得复制系统能够与OLTP系统的活动保持同步，复制服务器就可以作为扩大现有OLTP 系统的应用范围的一个非常好的方法。采用复制服务器这种灵活方式，数据可以存在于任何SYBASE或非SYBASE的数据源中，包括历史数据源。有关复制服务器对异构数据源的支持能力将在下文介绍。（参见“复制服务器如何工作”部分）。
例2：多个主站点对一个辅站点（多个数据源合并）
除了从一个中央节点分发信息这种方式，复制服务器还提供了一个简单的机制将不同地点的信息合并发向一个节点。
这种应用的一个情形是某公司从各个远地生产站点收集信息，汇总到总部后进行集中分析。图4给出了一个可能的例子：一个跨国公司拥有多个分支机构分布在世界各地，生产地点分别在汉城，法兰克福和墨西哥城，公司总部在波士顿。波士顿总部需要查看全球各地最新的生产状态，这三个生产地点的信息汇总到波士顿，波士顿总部的数据将有几秒钟或几分钟的延迟，因此系统获得的数据是准实时的数据，但不会影响公司在纽约的应用系统。复制服务器提供了一个整合公司分布式数据的有效方法。值得注意的是，汉城、法兰克福、墨西哥城和波士顿的数据库框架是可以不同的。
图4：公司的数据整合
我们有必要将这种配置与现有应用系统常用的‘备份和转储’应用进行比较。这种方式不象‘备份与转储’方式那样从每个站点得到的是几天前或几个星期前的数据磁带或报告，波士顿使用这种方法得到的是几秒钟前的数据。
例3：没有更新冲突的对等配置（共享公司数据）
以上两个例子描述的是复制发生在一个方向，第一个例子是从一个站点发向多个站点，第二个例子是从多个站点发向一个站点。但是数据复制往往并不一定只是单方向的，大企业的数据共享就是其中一个例子。如图5所示，在这种应用情境中，多个分布式系统既包含主点数据同样包含备份数据。
比如，一家公司在美国的多个州都有自己的分公司（亚特兰大、芝加哥、西雅图），现需要合并员工数据。每个办事处分别管理本地区的雇员信息。复制服务器为公司提供一种机制能够共享这些分布式的雇员数据。
图5：企业数据共享
由于每个雇员只隶属于一个地区，在本例中，不同的数据从各个地区结合到一起，同时各地区间不会发生数据更新冲突的问题。当每个地点既包含主数据又包含备份数据时，不允许两个地点同时更新同一个雇员的的信息。因此，亚特兰大办事处仅能更新亚特兰大的雇员信息，芝加哥办事处仅能编辑芝加哥雇员的信息，整个系统所有的员工都能够查阅全公司近实时的雇员信息。
例4：具有更新冲突的对等配置（公司数据的集成）
前面的实例集中阐述了不同地点数据项的合并和不同地点如何避免更新同一块数据。设计和管理一个完全避免更新冲突的应用当然使得整个系统比较简单，但实际上完全避免冲突有时是不大可能的。很多商业应用都要求多个地点更新同一个数据项。图六说明了这样的分布式更新的情形。
图6：公司数据综合
某跨国软件公司在三个地点有技术支持分析员：一个在亚洲，一个在欧洲，另一个在北美。每个地区的支持分析员进行用户电话支持和支持地区客户。所有分析家共享一个通用的故障数据库，客户出现的问题被记入日志中。这个故障数据库要被三个地点访问，同时，三个地点的分析家需要能够访问并更新故障数据库中的信息。这是一个数据项可以被任意一个支持中心更新的事例。由于多个地点能够同时更新数据库的数据，故障跟踪应用中需要包括一个更新冲突解决机制。
关于SYBASE在此环境下如何解决更新冲突的方案建议在本文的“复制服务器是如何工作的”部分有详细讨论。SYBASE推荐了一种使这种复杂的分布式环境变得易于管理的方法。
例5：一主一辅（热备份数据库）
在另一种可能的应用情形中，复制可以提供了一种经济有效的方法，以建立业务系统数据库的准实时备份。这个备份系统可以在主点失败时接管工作，为应用系统提供数据服务。
图7 提供了一个例子。一个大型电力公司在中央电厂有一个数据库系统。这个电厂控制电力的生产并将电从电厂传送至用户家中。在这个系统中，控制电力输送的应用显然是一个十分关键的部分，它需要一个冗余的结构：数据应被镜像（mirror）到系统中的多个磁盘，网络连接也应该是冗余的等等。即使如此，仍然还有一个问题存在：如果发生大的灾难，如地震，洪水，或工厂内的火灾，控制电力转接和电力传输的系统将可能完全失效。公司的冗余体系还需要一个在外地的备用系统，这样在在主站点（电厂）发生灾难性的事故时，系统管理员能够将应用切换至其它地区的备用地点。
图7 热备用数据库
当我们建立一个主站点的冗余系统时将面临一个重要的折中的选择。由于在正常情况下复制将滞后主点系统几秒钟，前端应用系统需要能够容忍这个滞后或延迟时间。在上述例子中，在主系统发生故障前一两秒内的数据变化可能在系统切换后不能反映到备份系统中。但不管怎样，电力公司在上述情形下得到了从远距离控制电厂的电力传输的益处。
还应该指出，如果被复制的整个数据库的交易速度如果很快的话，备用点的复制将不可避免的落后于主站点。系统管理员在建立一个备用系统时，应考虑复制系统的吞吐量。
正如这些例子所说明的，复制系统的使用需要在数据可用性和数据同步性之间寻找一个折中的方案。复制系统提供了一种能够减小错误的经济有效的方法，这种方法的损失是以准实时的工作方式代替同步获得信息。正如我们在下面几章中证明的，SYBASE的复制服务器为实施类似上述的应用环境提供了最有效和最安全的体系结构。
在上述的所有例子中，所复制的数据可以包括整个表，一个表的若干行的子集，列的子集，或者两个都包含，如图8中所示：
图8：复制服务器允许复制若干表格的选择性的子集,每一个站点都自行决定复制哪些数据，以及
如何查看复制的数据。
以上已概要描述了复制服务器所能做的工作，下面将简要讨论它如何工作。
复制服务器如何工作
以下介绍Sybase复制服务器产品的部件并说明各部件之间是如何工作的，整个复制系统由以下四部分组成：
?交易（数据变化）检测------单数据源或多数据源
?交易在网络上的路由
?交易到达目标数据库，以及
?复制系统的管理
图9：Sybase复制系统部件(单向复制的建立)，
可从一个工作站的复制服务器管理器上管理这些部件
在Sybase复制环境中，通过使用LTM这一轻负载进程，源数据库的数据的变化会被检测到，LTM通常与源数据库在同一系统中。LTM把检测到的变化传递给一个复制服务器，该复制服务器可以在另外一个系统中。一组在独立的局域网上的复制服务器通过协同工作把数据的变化用已经配置好的路由直接传递到目的地。在复制进程的最后一步，一个复制服务器把数据的变化传给目标数据库。
整个工作过程都可以从复制服务器管理器的具有友好的用户界面的单台工作站上进行管理和监控。数据从源数据库向目标数据库的传输可通过稳定队列来容错，稳定队列是一种安全机制，它给复制系统提供了对单独部件失败的可配置的容错级别。
交易（数据变化）检测------LTM
Sybase复制服务器产品包括LTM部件，LTM是一个轻负载线程，通常与源数据库在同一系统中。如果复制系统有一个以上地方的数据发生了变化，那么每一个地方对应一个LTM进程。
LTM的作用是检测和捕获它所在数据库系统中发生的交易，然后把这些变化传给复制服务器并最终到达复制目的地。
LTM读取主数据库的事务日志（transaction log）来检测源数据的变化。事务日志是反映源数据库变化的最佳信息源，因为它包含了已提交的、可恢复的事务。在图9中，当一个应用改变源数据库时，该事务被记录在事务日志中，为了保持数据的完整性，所有改变在事务提交时才写入磁盘。复制进程并不干扰数据库系统的日志功能。LTM监控数据库系统的常规活动，一旦检测到一个事务，就把它传递给复制服务器。
LTM线程是一个内置于对应的源数据库管理系统中的一个线程。该线程与数据库系统采用进程内通信来处理已提交事务，可以保证其对源数据库带来的影响为最小。
LTM线程把数据库的事务转化为与数据源无关的可被复制服务器识别的命令。例如，如果一个更新操作在一个事务中发生了，LTM会把该更新命令转化为“复制该更新”类型的命令
（rs_update）并把该命令传给复制服务器进程。LTM自动地转换数据库的命令成为复制服务器命令。
把源数据库的事务活动转换或映射成复制服务器可识别的命令这个过程是Sybase复制体系的一个重要方面：LTM和复制服务器之间的接口对用户是可见的。日志转换语言LTL是复制命令语言RCL的一个组成部分。因此，用Sybase的Open Server/Open Client技术可以为那些没有现成的LTMs的数据源构造LTMs。
如果你可以从数据源捕获一个事务，你就可以把该事务映射到复制服务器环境并复制该事务。这样，和其他主要竞争产品不同的是Sybase复制服务器允许你构造从异构数据源复制数据的应用程序。对于有遗留系统（Legacy System）的公司来说，这允许他们从遗留系统到开放系统复制数据而不需要改变现有的数据和应用。
有必要注意，LTM和复制服务器对源数据的交互和负载是最小的。后面我们会展示，这个特性是Sybase体系结构和其它复制模式之间的重要的差别。与基于触发器或者快照模式的复制体系结构不同，基于LTM的Sybase模式不会妨碍源数据库的正常操作。
交易在LAN和WAN上的传播和路由
现在让我们看看当信息从LTM传送到相应的复制服务器后会发生什么。如果源数据库和目标数据库在不同的局域网上，复制过程的下一步是从与源数据库关联的复制服务器到与目标数据库连接的复制服务器传送数据。
注意如果源数据库和目标数据库在同一局域网上，就不需要第二台复制服务器。在同一局域网上，一个复制服务器就可以进行数据的传递。附录中的图15图解了这一点。
在多个局域网的情况下，不同复制服务器之间的路线可以是直接的（如图10a），即在源数据库和复制端没有中间站点；该路线也可以是间接的（如图10b），即在源数据库和复制端有一个或多个中间站点。
图10a：LA和Athens的复制服务器的直接路线
图10b：复制服务器之间的间接路线
复制数据的直接路由或间接路由可由系统管理员预先设置。路由的选择使管理员可以通过协调网络的限制因素和应用数据传输需求从而发挥出整个网络的最佳效率。可以从配有复制服务器管理器的管理中心监控直接或间接路由的配置和状态信息。
在前面两部分我们研究了复制数据在站点之间的传输，LTM进程和复制服务器进程是如何共同工作来检测和抽取源数据库的数据变化并通过网络传递这种变化到目的地的。我们现在研究复制过程的最后环节：复制数据到一个或多个站点。
象我们开始提到的那样，复制服务器进程本身是一个Sybase Open Server/Open Client应用。在数据变化从源数据库到复制点的最后传输过程中，一个复制服务器建立了和目标数据库的连接。这个目标数据库可以是Sybase系统也可以是非Sybase系统。
复制服务器作为一个有特权的客户端用户使用标准的客户/服务器连接可目标数据库相连。然后，该复制服务器传递复制数据到目的地。在下一部分，我们将描述复制服务器如何“知道”传递哪些数据以及传递到哪里。象我们将要展示的那样，复制点“定阅”它们所要的信息。所有定阅的信息将保存在与复制服务器关联的数据源。每一个复制服务器都有一个保存订阅信息的相应的数据源（RSSD）。
既然复制服务器可简单地象其他数据库客户那样传递数据到目标数据源，那么复制数据到非Sybase数据源也是直接的。用户能够简单地使用Sybase的Omni网关使复制服务器客户端可以连接到第三方的数据源。从概念上讲，可以认为这些网关提供了这样的机制：它使非Sybase数据源（对于应用客户来说）看起来和Sybase数据源一样。不需要复制服务器的任何变化就可以复制非Sybase数据源。
既然最终的复制数据的目标是Sybase或非Sybase数据库，本地用户可以自由定制他们的数据访问方法以获得最大的性能，就象对本地的非复制数据的访问一样。为了优化数据访问性能，复制系统没有限制本地站点的定制索引，磁盘上的数据分布等。
复制系统的配置和管理
显然，拥有一个功能强大的系统管理工具对于成功地实现和管理大型分布式复制环境是必须的。Sybase在它的复制服务器产品的设计时期就认识到这个事实并构造了复制服务器管理器（RSM）。
RSM提供了一个功能强大的图形用户接口，通过它系统管理员可以从一个工作站监控和管理Sybase复制服务器环境的所有方面的功能。RSM是Sybase企业级客户/服务器管理系列产品的一部分，它由公司的系统管理产品部开发。它第一次在数据库行业引入了区别于单一的部件的管理对象集合的概念。
复制服务器部件如LTM，复制服务器，数据源在RSM屏幕上以图标来表示。RSM工作台，如图11所示，允许管理员不仅可以监控和管理单独的部件，更重要的是可以管理大型分布式环境和部件的集合。在图解的例子中，东方海岸的图标被系统管理员定义为复制系统的一组部件。如果其中有一个部件发生了问题，该图标就改变颜色以向系统管理员报警。当问题发生时收集事件和定义自动行为的能力是RSM重要的实力，它可以增强管理员的生产力和推动系统管理。
图11：复制服务器管理器屏幕
其他的RSM屏幕允许管理员监控网络连接和复制路线的状态。数据源之间的等待时间和数据传送时间可以被检测到：一个RSM的“心跳”应用允许管理员检测一段时间内信息传送性能的图表（注意这个传送时间也可以表示复制数据落后源数据的时间有多少）。
队列，即在复制部件之间的临时存储区域也可以从一个有RSM的地方被检测到。管理员能够看到给每个队列分配的空间的百分比而且也可以看到每个队列的内容。
复制服务器管理器帮助管理员建立复制数据的订阅。为了接收复制数据，一个特定的站点需要订阅需要的数据。一个订阅是从一个主表中接受所选择的行的一览表式的请求。复制服务器管理器提供了方便的方法使用填空的模板建立这种订阅，一个订阅的命令行接口很象SQL。
复制服务器管理器给数据库带来了复杂的面向对象的分布式系统管理技术。如果没有象RSM这样强大的工具，一个复制环境是很难管理的。
如果系统和连接出故障怎么办：稳定队列(Stable Queue)
Sybase的模块化的复制系统设计允许复制系统在短暂的网络或系统失败的情况下快速方便地恢复操作。这种复制系统的组件失败的可配置保护是通过磁盘队列来实现的。