| 词条 | iStream DDS |
| 释义 | Istream DDS软件技术详解 [详细讲解Isteam DDS 软件的实现原理与技术细节解析] 九桥软件 2010/8/3 目录 前言... 3 一．DDS的应用领域... 3 1.1 生产系统的热容灾... 3 1.2 分担业务... 5 1.3 数据分发与集中... 6 1.4 数据迁移... 8 1.5 双向同步... 8 二．DDS支持的同步特性... 9 2.1 支持的同步对象... 9 2.2 支持的同步模式... 10 2.3 数据同步方式... 12 2.4 数据定位方式... 12 2.5 分区表特殊处理... 13 三．DDS的同步原理... 13 3.1 历史数据同步原理... 14 3.2 增量数据同步原理... 15 四．DDS同步的性能... 16 4.1 读取在线日志... 17 4.2 内存中完成交易解析... 17 4.3 只合成已经提交的交易... 17 4.4 实时压缩传输... 17 4.5 通过rowid寻址... 17 4.6 合成交易文件大小... 18 4.7 首次同步的性能... 18 4.8 增量同步的性能... 18 五．DDS的目标端数据库可复用... 18 5.1 目标端数据库始终处于打开状态... 19 5.2 交易数据准确... 19 5.3 新产生的数据对于同步无影响... 19 六．DDS的高可用性... 19 6.1 采用缓存机制... 19 6.2 跟踪日志... 20 七．DDS的特性... 20 7.1 在线部署简单、占用资源少... 20 7.2 异构跨平台的支持... 21 7.3 一对多和多对一... 21 7.4 对部分表重新进行单独全同步... 21 7.5 定时同步... 21 7.6 实时显示交易的统计... 22 7.7 字符操作和web操作模式... 22 7.8 数据验证... 22 7.9 支持oracle自带数据导入工具... 23 八．DDS的健壮性... 23 8.1 网络中断... 23 8.2 源端数据库重新启动... 23 8.3 源端DDS重新启动... 23 8.4 目标端DDS重新启动... 23 8.5 目标数据库重新启动... 24 九．DDS的软件体系架构... 24 9.1 源端体系架构... 24 9.2 目标端体系架构... 25 附录、DDS支持内容汇总... 26 前言 IStream DDS（以下简称DDS），是基于交易的逻辑级oracle数据同步软件。利用数据库日志在线跟踪、分析技术，将生产数据库的交易信息以事务为单位，通过异步的方式，实时的传递、装载到目标数据库中，以达到源端、目标端数据保持一致的目的。是一种准实时同步软件。 DDS 不依赖硬件的同步能力，支持多种系统平台，具有部署简单、同步速度快、交易延迟时间短的特点。 DDS能够支持跨多种Unix/Linux/windows操作系统平台、不同Oracle版本之间的交易同步。 DDS同步的目标数据库为在线打开状态，可以随时复用。 DDS 适用于（异构）热容灾、数据迁移、数据集中、数据分发、分担业务等应用领域。 一．DDS的应用领域 1.1 生产系统的热容灾对于大部分公司而言，容灾是一项巨大的工程，意味着高额的资金和人力投入。受到传统同步技术的限制，容灾必须拥有专用的硬件支持、专用的传输链路、容灾距离以及系统平台等诸多的限制。此外由于传统容灾系统的不能实时使用的特性，导致不但风险不能评估，而且巨大的投入也可能得不到任何回报。 DDS使用逻辑数据容灾技术，传递的是交易信息，因此传输数据量很小，保证了在低带宽环境下实现低延迟的Oracle交易异步同步，是一种高效且低成本的数据库容灾方式。DDS使用标准的TCP/IP协议进行通讯，容灾端的Oracle数据库可以部署在本地或远程容灾中心，距离没有限制。 此外，由于同步的目标端数据库始终处于打开状态，因此，当生产数据库遇到计划内或非计划停机时，DDS能够支持前端应用程序快速的切换到容灾数据库。与其它基于磁盘或文件系统的物理同步技术相比，不但省略了漫长的数据库recovery和启动时间，而且能够保证100%的切换成功率。 下图表示交易系统切换后，业务交易在容灾系统上继续执行的示例。 笔记本交易 电脑交易 手机交易 主交易业务系统 主交易数据库 热容灾数据库 DDS数据同步 当原生产系统数据库在恢复正常使用后，可以通过DDS将容灾端数据再次同步到源端数据库中，从而达到互为容灾的目的。 下图表示，原交易系统恢复正常后，容灾系统数据同步到原交易系统上的示例。 笔记本交易 电脑交易 手机交易 主交易业务系统 主交易数据库 热容灾数据库 DDS数据同步 1.2 分担业务DDS基于交易的逻辑级同步技术保证了目标端数据库始终处于可用状态，因此除了对于DDS所同步的schema不能进行修改以外，对于同步的schema做数据读操作、在同步数据基础上新创建的schema不会对同步本身产生任何影响，因此对于查询、报表、备份、分析以及与其它业务的接口等业务或应用都可以放在目标数据库上进行处理。 这些应用也不必在原交易数据库上争夺处理资源和时间窗口。生产系统运行和维护的压力得以释放，提高了稳定性，而不同的应用在分布的数据库上也可以进行有针对性的优化。 下图表示在容灾系统做业务查询、报表处理、数据备份、统计分析、与其它业务系统接口等应用的示例。 笔记本交易 电脑交易 手机交易 主交易业务系统 主交易数据库 热容灾数据库 DDS数据同步 业务查询 1.3 数据分发与集中DDS能够完成企业范围内的数据分发，将生产库的交易数据实时同步到一个或多个本地或异地的数据库中。也可以将业务数据分发到不同的目标端，实现专机专用。数据分发是一种典型的通过部署多服务器、多数据库来分担负载，提高响应速度的企业应用模式。 下图表示交易系统的业务数据同时分发到不同目标端的示例。 主交易业务系统数据库 DDS数据同步 本地容灾数据库库 本地查询数据库库 异地容灾数据库库 DDS能够完成企业范围内的数据集中，从多个交易数据生产库实时同步到一个本地或异地的数据库中。方便用户查询，报表打印，为BI提供基础数据。 下图表示交易系统的业务数据同时分发到不同目标端的示例。 DDS数据同步 目标端数据库 主交易数据库1 主交易数据库3 主交易数据库2 1.4 数据迁移数据库软件、硬件升级过程中涉及到的数据库迁移，是企业经常会遇到的情况，在传统数据迁移过程中，经常会面临三个方面的问题： 1.新系统和源系统os平台，oracle版本不同或数据库字符集不同。 2.迁移时间窗口有限，甚至在某些24X7的业务中无法停机。 3.由于人为因素影响，可能会导致新交易系统部分交易无法正常运行。 针对这三种常见情况，DDS分别对应如下处理机制： Ø DDS本身支持异构跨平台方式，对于源端和目标端操作系统和oracle数据库版本不同或者字符集不同的情况均能够支持。满足第一种情况 Ø 在迁移过程中业务无需中止，只需在业务切换时中止业务，可以使业务停止时间窗口变得很短，是以分钟来计算的。满足了第二种情况。 Ø 目标端数据库为实时打开，可以验证迁移是否成功，降低人为因素对迁移过程的影响。满足了第三种情况。 1.5 双向同步随着跨地域企业的不断发展，双业务中心逐渐会成为一种解决庞大业务数据和企业业务响应冲突的一种必要手段。 DDS解决方案如下图所示： 主交易数据库2 主交易数据库1 DDS数据反向同步 DDS数据同步 双方各自运行各自的业务。双方产生的业务数据实时的同步到对方数据库中。从而达到双业务中心，双业务数据备份中心的效果。 二． DDS支持的同步特性 2.1 支持的同步对象DDS支持两种级别数据库对象的同步：用户级同步、表级同步、多表同步 Ø 用户级同步： 源端数据库指定用户及其所包含的表、视图、索引、过程、函数、包、序列等数据对象全部同步到目标端数据库指定的用户下。 DDS支持源端用户名和目标端用户名不同的同步方式。 Ø 多表同步： 即group方式，针对多个用户，每个用户只同步指定部分表同步的情况。 Ø 表级同步： 表级同步分为单表同步和多表同步 单表同步指定源端数据库指定用户下单个表同步到目标端数据库指定用户下的单个表。 2.2 支持的同步模式同步模式主要指源端和目标端的架构模式，具体分为1:1模式、1:n模式、n:1模式、1:1:1模式四种。 1对1的同步模式 目标数据库 生产数据库 DDS DDS n对1同步模式 目标端数据库 主交易数据库1 主交易数据库3 主交易数据库2 DDS DDS DDS DDS 1对n同步模式 主交易业务系统数据库 目标数据库1 目标数据库2 目标数据库3 DDS DDS DDS DDS 级联同步 目标数据库 生产数据库 DDS DDS 目标数据库/生产数据库 使用者可以根据具体情况选择或组合以上同步模式到您所需要的应用架构中。 2.3 数据同步方式DDS支持历史数据同步、只同步变化数据同步两种方式。这两种方式和有效结合或单独使用。 历史数据的同步 历史数据指同步时刻已经存在的数据，历史数据同步方式分为两种： 1、快照方式 快照方式利用oracle的select的多版本特性，将历史数据抓取到目标端，同时可选择将变化数据实时同步，在历史数据装载完成后，再装载变化数据。历史数据的抓取与变化数据的抓取之间无缝结合，有业务运行也不影响数据同步的准确性。 相对而言，快照方式同步数据时间长，对于系统资源占有大。 2、读文件方式 读文件方式指DDS直接读取oracle数据文件中的表数据。 相对而言，快照方式同步数据时间端，对于系统资源占有小。但是这种方式抓取历史数据时，源端系统不能有业务，否则无法保证同步数据的准确性。 变化数据同步 变化数据同步有两种应用方式： 1、 与历史数据同步方式结合 DDS支持历史数据与变化数据无缝结合的同步模式，这种方式无需停止业务。 2、 单独同步变化数据。 这种方式是在两边数据已经一致的情况下，将某一边数据库现产生的交易同步到另外一边的数据库中。 2.4 数据定位方式目标端装载交易时，对于目标端对应数据（表的记录）的定位方式分为rowid和where两种方式。 rowid方式： Ø 使用rowid同步方式，由于在目标端装载时直接根据rowid方式定位表纪录的物理位置，不需oracle再度解析操作直接定位要修改的块。 Ø 使用rowid方式时，首先必须进行全同步+增量同步结合的模式，后续的增量数据依赖软件本身全同步操作。 Where方式： Ø Where方式在目标端装载数据时，对于目标端对应的数据查找依赖对应表的where条件，对于对应数据的查找速度完全依赖于数据库本身的查找速度。 主要满足两种应用需要： ² 一种跟rowid方式相同，差别在于表的数据不能出现重复纪录。 ² 另外一种方式是只同步变化数据部分。只依赖源端和目标端相关表的数据结构。这种方式采用DDS的只进行增量同步的方式进行。 2.5 分区表特殊处理DDS软件同步分区表时，可选择性的同步分区表的分区。并且DDS可按分区，并发复制分区表。此特性在数据库中有大分区表时，能极大提高数据同步的效率。 三． DDS的同步原理如图所示： DDS软件同步数据实现分为两个步骤 1. 历史数据同步。 2. 增量数据同步。 3.1 历史数据同步原理使用快照方式 首次同步时，对于同步map所涉及的每一个表的同步过程如下： 1、 锁该表； 2、 记录同步时刻的SCN(System Change Number)； 3、 释放锁； 4、 读取该表数据； 在表做开始同步的时刻，锁表是为了记录SCN，取这个SCN号时这个表的快照。 开始读取数据时，利用了oracle数据库自身提供的“多版本”特性，能够保证读取数据的一致性。同时对该表进行解锁，又使该表被锁的时间不会太长从而严重影响正常交易。 这种方式保证了源端在任何时刻下都可以进行首次数据的批量同步而不会影响同步数据的准确性。 读文件方式 首次同步时，对于同步map所涉及的每一个表的同步过程如下： 1、 记录同步时刻的SCN； 2、 读取该表数据； 首次同步时，直接从oracle数据文件中读取该表数据，同时记录同步时刻的SCN，由于这种方式要求在同步过程中，没有交易产生，因此会保证历史数据抓取的准确性。在同步完成后，将变化数据实时抓取。 注：首次同步是可以选择的，如果事先已经保证了两边数据一致，则可不选用DDS自带的全同步功能。直接进行交易变化部分的同步（同步方式只能选择where方式）。 3.2 增量数据同步原理如图所示增量数据同步分为下面四个步骤： 1．交易抓取 Ø DDS通过事先创建的视图来（sys.x$kccle与sys.x$kcccp的拷贝视图）捕获日志变化，由于每次捕获的日志的物理位置都会记录，因此可以得出日志变化量。 Ø 后续的抓取日志、分析交易、传输交易，完全由DDS独自完成，不使用oracle数据库任何资源。 Ø 在每次抓取的日志量处理完成后，记录在DDS的缓存目录中，因此对于日常运行过程中，DDS停止或其它原因需要读取归档日志时，根据记录的日志物理位置来定位需要抓取的归档日志。 Ø DDS抓取日志跟oracle数据库是写日志是并行操作而又互不影响。 Ø 正常情况下，DDS都是准实时的抓取变化日志量。 对于源端是rac环境来说： Ø rac环境中，在每一个实例所在的主机操作系统上可以读取另外主机的在线日志（包括归档日志）。通过每一个实例的日志和SCN（System Change Number）来保证交易顺序的准确性。 2．交易分析 严格按照源端Oracle数据库内部SCN执行顺序以及已经提交的交易来合成交易文件，该交易文件号是依次递增并且是唯一的，从0开始，交易文件号的算法跟oracle的SCN算法一样，可以保证在oracle数据库正常使用期间，保证DDS能够正常使用。 DDS只处理已经完成提交的交易，对于回滚操作，DDS不处理该操作。 3．交易传输 DDS只传输交易内容，不传输交易内容的数据结构，采用专有的合成交易文件格式，只有DDS提供的工具才可以解析交易内容，这样即证了在网络传输过程中数据的安全性又可以保证网络传输过程中数据的准确性。 满足下列三种情况，源端将删除该交易文件： 1) 接受的交易文件号跟源端传输的一样。 2) 接受的交易文件大小跟源端传输的一样。 3) 接受的交易文件校验码跟源端传输的一样。 4．交易装载 目标端接受交易合成文件后，首先存放在缓存目录中，然后严格按照从小到大顺序进行装载，装载的交易文件不能缺失。否则装载的进程将一直处于等待状态，因此无论目标端是rac环境还是单机环境都可以保证装载的准确性。 这样就可以保证在目标端装载过程中，保证按照源端合成的交易文件顺序来装载。 四． DDS同步的性能 4.1 读取在线日志DDS是直接通过读取Oracle日志来分析出交易内容，而不是通过数据库表来得到，这样将不依赖数据库本身的数据内容而直接得到交易信息。从而大大加快了合成交易文件的速度。 4.2 内存中完成交易解析源端在线日志的抓取的最新位置是通过查询数据库实例sga的动态视图得到的，这样不仅速度快而且不会直接影响源端数据库的物理I/O。 源端归档日志的抓取是直接抓取归档日志内容。也不会影响到源端数据库的物理I/O。 抓取后的数据，只分析同步用户或表相关的交易，对于跟同步用户或表无关的交易直接丢弃。 日志的抓取、分析、合成大部分情况下都是在内存中完成的，只有少数批量交易数据时才会使用缓存目录，这样就可以尽可能的提高抓取、分析、合成交易的速度。 4.3 只合成已经提交的交易DDS只合成跟同步用户或表有关的、已经提交的交易，并且每一个交易的大小不会超过10MB。这样将大大提高交易文件的合成速度。 4.4 实时压缩传输网络传输时，首先在源端将交易合成文件在内存中进行压缩，在目标端接收后在内存中完成解压缩，即：进行传输之前先压缩、目标端接受压缩交易文件解压缩后，存放到相应的缓存目录下。这样可以大大减少网络流量，从而加快交易合成文件传输的速度。 对于不含有lob类型的字段，交易合成文件何以压缩到10-15%左右。 4.5 通过rowid寻址数据库修改一条记录通常依赖索引或全表扫描，这样操作速度会因为数据量的差别而有明显的差异。DDS是直接通过rowid对该记录进行操作的，不会因为数据量的明显差异使合成的交易文件中的交易提交速度有明显的差异。这一点对于海量数据尤为明显。 4.6 合成交易文件大小DDS对每一个合成的交易文件最大上限为10MB，加上网络传输时的压缩功能，会使网络传输速度大大提高。 由于每一个合成的交易文件最大为10MB，在目标端装载时的读取、装载速度会很快、占用资源会比较少，从而大大加快了每一个交易合成文件的装载速度。 4.7 首次同步的性能对于首次同步而言，无论是快照方式还是读数据文件的方式，DDS在源端支持多达16个并行同步、目标端支持并行装载的模式，这样可以充分利用主机资源，加快首次同步的速度，减少首次同步对于源端、目标端主机性能的影响。 4.8 增量同步的性能对于某些情况下，目标节点装载增量合成交易文件慢的情况，DDS支持多达32个并行装载，可以将不同用户或表的数据放在不同的增量目录下，实行并行装载，不过对于表之间有关联关系的数据（比如外健），就需要将这些有关联关系的表放在同一个增量目录下，来保证装载数据正确性。 在一般交易系统中,软件正常安装后,在交易发生时(非清算时间)源端变化同步至目标端时间为2~4秒(交易量大小不超出网络与目标段机器装载性能所能承载的数值,这一数值与具体硬件与网络环境有关). 注：另外对于一个数据库，可采用多套DDS同时运行的模式，来对不同业务的不同用户或表进行有针对性的同步。从而在功能、需求、性能方面有针对性的解决方案。 五． DDS的目标端数据库可复用DDS通过三个方面来保证目标端数据库的可复用。 5.1 目标端数据库始终处于打开状态由于目标端装载是以数据库的交易方式来提交的，因此目标端数据库始终处于打开状态。即在任何情况下目标端数据库都是可用的。 5.2 交易数据准确DDS首先通过上述环节来保证交易数据的准确性，包括历史数据的同步和变化数据的同步。也包含同步过程中涉及到的权限，具体包括两个方面，一方面是同步时源端数据库中已经存在的权限，另外就是在日常使用过程中，源端数据库发生改变的权限。这两点DDS都能够支持。 5.3 新产生的数据对于同步无影响由于目标端始终属于open状态，对于下列情况： 1、对于同步业务数据基础上只读操作。 2、新产生的业务数据。 这样即不会对DDS同步产生影响，也可以衍生很多新的应用。 六． DDS的高可用性高可用性主要体现在RAC或HA环境下的DDS软件切换主机后能够继续运行的情况，在此主要描述源端切换后如何从机制上保证DDS软件继续运行。 6.1 采用缓存机制在源端： Ø DDS_PTRACK 跟踪到redo log增量信息，将其写入共享内存，并通知 DDS_PMERGE 进行处理，DDS_PTRACK同时将此数据包写入缓存目录 $DDS_DATA/track 中，以便后续进程没有成功处理或系统其它异常情况时，这些数据能够恢复并重新进行处理。 Ø DDS_PMERGE 收到 DDS_PTRACK和DDS_PCLEAN 的通知，将收到的数据包进行各种必要的处理，生成处理后的数据包，将新数据包写入共享内存，并通知 DDS_PCOMM 进行处理。 Ø DDS_PCOMM 收到 DDS_PMERGE和DDS_PCLEAN 的通知，将收到的数据包 发送到目标端系统，如果发送不成功（目标系统未启动、网络故障），将数据包写入缓存目录 $DDS_DATA/comm中。 注：DDS在源端通过抓取、分析合成、传输各个环境中的缓存机制来保证在软件因各种原因重新启动后，只要能够读取到相关的缓存目录就能够继续正常同步。 6.2 跟踪日志DDS_PTRACK进程的缓存文件中将记录数据库实例号、日志号、所分析到的地址。 无论DDS停止多长时间，只要有相关的数据库日志（个别情况下需要相关的归档日志），DDS就可以继续进行同步了。 对于HA或RAC环境，只要oracle数据库实例切换后，在切换后的主机上，DDS软件能够正常连接数据库实例、能读取归档日志、能够读写上一次停止运行时刻的缓存目录，就可以继续正常同步。因此说DDS满足了HA或RAC环境下高可用性的需求。 七． DDS的特性 7.1 在线部署简单、占用资源少Ø DDS部署非常简单。对于Unix/Linux以及Oracle熟悉的技术人员参照相关文档，在10-30分钟即可部署完毕。 Ø 在源端和目标端数据库上不创建任何表。 Ø DDS对于每一个同步的用户或表，只需4条指令完成，并且支持脚本操作，这样就可以避免多个用户同步时复杂的指令操作了。对于n个用户的同步，源端只需要n+3条指令即可完成同步操作。 Ø 增量同步过程中，DDS对于主机CPU资源的占用平均不会超过5%。 7.2 异构跨平台的支持Ø DDS是以数据库的交易为单位进行同步、装载，因此对于不同操作系统上的不同oracle平台环境，DDS均可以支持，。 Ø 对于源端和目标端操作系统，数据库版本不同的情况也可以支持，当然前提是不同oracle版本之间的schema使用方法要彼此支持。 7.3 一对多和多对一Ø DDS支持一个源端同时同步多达256个目的节点的同步模式。真正在软件上实现了一对多的同步模式。大大减少了源端主机资源的占有率。 Ø DDS支持256个目标端同时同步到一个目标端的同步模式，真正在软件上实现了多对一的同步模式。大大减少了源端主机资源的占有率。 7.4 对部分表重新进行单独全同步Ø 在增量使用过程中，有可能会因为某种误操作导致目标端数据更改，当源端再次对相关部分的数据进行更改时，结果导致DDS将停止这张表的同步。 Ø 对于这种情况，DDS的处理方式是对该表重新进行单独全同步，同时对于其它正在同步的表或shema不会有任何影响。这样就避免了因为某一张表的误操作而需要相关用户需要全同步的操作。 7.5 定时同步Ø DDS支持指定时间装载同步数据到指定时刻交易的功能。不仅可以满足某些特殊的应用需求而且在某些方面起到了备份的作用。 7.6 实时显示交易的统计DDS在目标端运行日志中： Ø 显示每一个合成交易文件的装载时间以及延迟时间。 Ø 显示每一个合成交易文件的dml数量，包括inert、update、delete数量上的统计。 Ø 显示每一个合成交易文件的ddl操作语句。 7.7 字符操作和web操作模式Ø DDS提供了不仅提供了字符操作模式而且也提供的web监控界面，通过两种方式都可以对DDS进行日常维护和监控。满足了不同用户的使用习惯 Ø 两种操作模式，DDS均提供了后台服务进程，无须第三方软件或服务协助。 7.8 数据验证静态数据校验 Ø DDS提供了静态数据校验功能，来确认同步数据的准确性，使用此功能时，会将源端数据全部取出，去目标端进行逐行对比，目标端软件装载也将停止，对比的时间与全同步时间相差不多，因此开启此功能时，源端数据库不能有数据变化， WEB对象校验 Ø DDS 提供了WEB对象对比功能，在源端WEB页面可随时发起对比命令（DDS日常监控）,该功能将对比源端和目标端复制的用户的所有对象存在与否一致的对比，如果不一致，将会把不一致的对象标红。 DDS Monitor对比软件 Ø DDS Monitor软件使用select count(*)原理对比源端和目标端表的记录数，不一致的表将会显示并顶置。此软件不会影响DDS软件的运行，不过由于select count(*)比较消耗oracle资源，并且源端有频繁交易时，源端与目标端记录数并不一致，因此只有在源端数据库停止变化时对比出来的结果才有意义。 7.9 支持oracle自带数据导入工具Ø DDS支持源端oracle自带的 imp和sqlldr数据导入工具的使用。对于10G中的impdp工具，DDS也提供支持。这样就不会影响使用oracle技术人员的操作习惯。 八．DDS的健壮性这里主要列举了增量同步期间，DDS对于常见的异常情况的支持。 8.1 网络中断对于同步期间网络中断的情况，由于DDS使用了缓存机制，因此在网络恢复后将继续进行同步、装载。 8.2 源端数据库重新启动对于同步期间源端数据库重新启动的情况，由于DDS使用了重试的机制，因此不会因为源端数据库的重新启动而重新启动DDS软件。 8.3 源端DDS重新启动对于同步期间网络中断的情况，由于DDS使用了缓存机制，因此在重新启动后，DDS将继续同步。 8.4 目标端DDS重新启动对于同步期间源端数据库重新启动的情况，由于DDS使用了缓存机制，因此在重新启动后，DDS将继续同步、装载合成的交易文件。 8.5 目标数据库重新启动对于同步期间源端数据库重新启动的情况，由于DDS使用了重试的机制，因此不会因为源端数据库的重新启动而重新启动DDS软件。 九． DDS的软件体系架构DDS无论在设计上还是实现上都采用了模块化的方式。进程体系跟oracle后台进程相似，分为三部分： Ø 第一部分是监控、管理进程。 Ø 第二部分是工作进程之间通讯管理。 Ø 第三部分是工作进程 9.1 源端体系架构DDS源端体系结构图 源端共享内存区主要记录源端共享内存、map参数、信号灯、进程等详细信息。 源端进程： Ø DDS_PMONS负责建立共享内存、信号灯、消息队列，监控系统其它进程的状态，重起异常退出进程并报告状态 Ø DDS_PMSGS负责收集其它所有进程报告的各种日志信息，将这些信息存放到文件 msg.log中。 Ø DDS_PRECVS负责接收界面发送来的管理命令并执行,同时也负责全同步时历史数据的同步。 Ø DDS_PTRACK负责跟踪数据库redo log动态增量信息，并抓取变化的redo log块。 Ø DDS_PMERGE负责将DDS_PTRACK 抓取量信息进行分析、过滤、合成交易文件。 Ø DDS_PCOMM负责将DDS_PMERGE 合成的交易文件发送到目标端。 Ø DDS_PCLEAN负责将 DDS_PMERGE和DDS_PCOMM成功处理的数据包进行清除。 9.2 目标端体系架构DDS目标端体系结构图 目标端共享内存区记录目标端共享内存、信号灯、进程等详细信息。 目标端进程： Ø DDS_PMONT负责建立共享内存、信号灯、消息队列，监控系统其它进程的状态，重起异常退出进程并报告状态。 Ø DDS_PMSGT负责收集其它所有进程报告的各种日志信息，将这些信息存放到文件 $DDS_DATA/msg.log中。 Ø DDS_PRECVT负责接收界面发送来的管理命令并执行，并接收交易文件到指定的目录中。 Ø DDS_PPUT负责将装载历史、增量信息到数据库中，并记录相关信息。也负责数据的比对。 附录、DDS支持内容汇总 支持总项目 支持项目 支持内容 备注 数据准确（DML部分） table Insert/update/delete Partition tables Insert/update/delete
columns Add/modify/drop constraints Add/modify/drop indexes Create/alter/drop views Create/alter/drop sequences Create/alter/drop functions Create/alter/drop Package( body) Create/alter/drop procedures Create/alter/drop Trigger Create/alter/drop Synonym Create/drop Role Create/drop Grant/revoke
Number/ TIME Char/varchar2/nvarchar2 用户定义类型 USER DEFINED TYPE
Oracle Oracle9i/10G/11G 归档/非归档 File/lv/ocfs/asm
双向同步 同步方式 只全同步or增量or组合 交易回退 表的dml/truncate/drop 单表同步 增量过程中，单表全同步 支持在线初始化 首次同步允许有交易。 同步对象 用户、表、组
目标端停止复制软件 断点续传 源端停止复制软件 断点续传 源端数据库异常 断点续传，无人工干预 目标端数据库异常 断点续传，无人工干预
多套/并行 增量同步 并行 目标端可用 交易完整性 Oracle的Exp/imp Oracle的sqlload
分担交易 一对多or多对一 双向 数据迁移 |
| 随便看 |
百科全书收录4421916条中文百科知识，基本涵盖了大多数领域的百科知识，是一部内容开放、自由的电子版百科全书。