Oracle异构数据库评估改造智能迁移全链路解决方案

通过采集和评估提前发现定位问题 通过采集评估，梳理数据库对象关系，梳理应用和库的关系 提前对可以发生问题的对象进行识别和打标，如根据表特性进行十几种分类打标等。 提前发现迁移中可能发生的风险，如日志附加级别的查询等。 自动兼容性识别和转换 自动发现所有不兼容对象，进行分级别梳理，并完成自动转换或者给出修改建议 自动梳理数据库对象之间的关系，完成创建排序等动作 生成迁云计划，借助结构和订正能力，完成全部的结构创建定义和逻辑 高效低压力的增量同步和数据实时对比 通过支持高效低负载的Oracle增量同步，可以保证业务不停机的情况下，完成数据热迁移 同步过程中可以实时对比数据，保证数据在最终只需要很短时间完成对比校验 通过以上方法，可以有效缩短停机窗口，减少切换风险，保证业务迅速切换和上线。

Oracle数据库和应用异构迁移解决方案

全链路智能评估迁移平台

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

目录

1 概述 4

1.1 阿里ADAM迁移平台 4

1.2 DSG for ADAM数据库迁移 4

2 评估迁移平台产品功能 4

2.1 支持目标库类型 4

2.1.1 PolarDB 4

2.1.2 ADB for PG 5

2.1.3 PostgreSQL 5

2.1.4 GreenPlum 5

2.2 智能采集和智能画像（ADAM） 5

2.3 智能评估和智能改造（ADAM） 6

2.4 智能迁移计划生成（ADAM） 6

2.5 日志并发分析 6

2.6 按需复制 6

2.7 首次全同步 6

2.8 实时同步 6

2.9 数据一致性检查 7

2.10 统一管理平台 7

3 评估迁移平台整体评估迁移流程 7

3.1 智能采集与画像（ADAM） 8

3.2 智能评估和改造（ADAM） 9

3.3 结构迁移和订正，生成ADAM最终迁移计划 （ADAM） 10

3.4 完整表结构迁移 11

3.5 数据迁移 11

3.5.1 日志分析 11

3.5.2 交易合成 12

3.5.3 交易传输 13

3.5.4 数据装载 14

3.5.5 数据完整性保证 14

3.5.6 数据初始化装载 15

3.6 数据比对 16

3.6.1 全量比对 16

3.6.2 增量比对 17

3.6.3 数据修复 18

3.7 对象迁移 18

4 评估迁移平台feature list 18

5 评估迁移平台应用 19

5.1 评估迁移平台- Oracle To Greenplum智能迁移解决方案应用场景 19

5.2 评估迁移平台 - Oracle To Greenplum案例分析 20

 

 

1. 概述
   1. 阿里ADAM迁移平台

数据库和应用迁移服务（Advanced Database & Application Migration，简称 ADAM）是一款将 IT 系统轻松的从原有的运行环境迁移到阿里云的产品，尤其在把传统 IT 架构改造成互联网架构方面（比如从 Oracle数据库迁移到ADB for PG数据库）积累了阿里巴巴多年成功经验。

阿里ADAM推出Oracle数据库全链路智能迁移解决方案，覆盖Oracle迁移的全生命周期（包括：评估（兼容性、关联关系、性能、风险点）、转换（转换不兼容点、引擎特征优化转换）、结构迁移、数据迁移、一致性校验、SQL仿真回放、割接、优化。）。ADAM同时支持改造迁移方案，结合云端丰富的数据平台产品特性以及用户业务特性给出数据库和应用改造方案，助力企业Oracle数据库迁移上云。

1. 2. DSG for ADAM数据库迁移

结合阿里从传统 IT 架构向互联网和云架构改造升级方面的成功实践，及ADAM智能分析的迁移计划，DSG根据自身对Oracle数据库多年的同步迁移经验和高性能迁移产品for ADAM结合阿里云ADAM联合开发了DSG for ADAM智能迁移产品，可以为用户提供流程完整（包括结构迁移、数据迁移、数据比对、对象迁移）、操作简单（提供可视化UI管理界面）、安全可靠（提供数据回流）的数据库迁移。

2. 评估迁移平台产品功能

结合阿里云强大的ADAM迁移计划，DSG for ADAM依靠自身高性能、并发的Orale日志分析功能、首次全同步及数据增量同步功能、数据一致性检查和修复功能，将Oracle数据高效、安全的迁移到阿里云数据库中。

1. 1. 支持目标库类型
      1. PolarDB

 

POLARDB是阿里云自研的下一代关系型云数据库，兼容Oracle引擎，存储容量最高可达100TB，单库最多可扩展到16个节点，适用于企业多样化的数据库应用场景。

POLARDB采用存储和计算分离的架构，所有计算节点共享一份数据，提供分钟级的配置升降级、秒级的故障恢复、全局数据一致性和免费的数据备份容灾服务。POLARDB既融合了商业数据库稳定可靠、高性能、可扩展的特征，又具有开源云数据库简单开放、自我迭代的优势。

POLARDB高度兼容 Oracle，降低Oracle迁移风险、缩短迁移周期，助力企业快速替换Oracle。

1. 1. 2. ADB for PG

分析型数据库PostgreSQL版（原HybridDB for PostgreSQL）为您提供简单、快速、经济高效的 PB 级云端数据仓库解决方案。分析型数据库PostgreSQL版 兼容 Greenplum 开源数据仓库，为一种采用 MPP 全并行架构的数仓服务，其广泛兼容 PostgreSQL/Oracle 的语法生态，新一代向量引擎性能超越传统数据库引擎 10 倍以上，分布式SQL优化器实现复杂查询语句免调优。通过分析型数据库PostgreSQL版可以实现对海量数据的即席查询分析、ETL 处理及可视化探索，是各行业有竞争力的云上数据仓库解决方案。

1. 1. 3. PostgreSQL

PostgreSQL是一种特性非常齐全的自由软件的对象-关系型数据库管理系统（ORDBMS），是以加州大学计算机系开发的POSTGRES，4.2版本为基础的对象关系型数据库管理系统。POSTGRES的许多领先概念只是在比较迟的时候才出现在商业网站数据库中。PostgreSQL支持大部分的SQL标准并且提供了很多其他现代特性，如复杂查询、外键、触发器、视图、事务完整性、多版本并发控制等。同样，PostgreSQL也可以用许多方法扩展，例如通过增加新的数据类型、函数、操作符、聚集函数、索引方法、过程语言等。另外，因为许可证的灵活，任何人都可以以任何目的免费使用、修改和分发PostgreSQL

1. 1. 4. GreenPlum

Greenplum的架构采用了MPP(大规模并行处理)。在 MPP 系统中，每个 SMP节点也可以运行自己的操作系统、数据库等。换言之，每个节点内的 CPU 不能访问另一个节点的内存。节点之间的信息交互是通过节点互联网络实现的，这个过程一般称为数据重分配(Data Redistribution) 。与传统的SMP架构明显不同，通常情况下，MPP系统因为要在不同处理单元之间传送信息，所以它的效率要比SMP要差一点，但是这也不是绝对的，因为 MPP系统不共享资源，因此对它而言，资源比SMP要多，当需要处理的事务达到一定规模时，MPP的效率要比SMP好。这就是看通信时间占用计算时间的比例而定，如果通信时间比较多，那MPP系统就不占优势了，相反，如果通信时间比较少，那MPP系统可以充分发挥资源的优势，达到高效率。

 

1. 2. 智能采集和智能画像（ADAM）

自动采集客户的数据库基础信息，并智能构建完整的画像描述，让客户对自己的源库的使用特性和库表情况有一个完整的理解。

1. 3. 智能评估和智能改造（ADAM）

针对采集到的信息，以及选择的目标库，就可以完整的进行所有数据库对象的兼容性分析和评估，并进行智能转换和改造。

1. 4. 智能迁移计划生成（ADAM）

自动将所有对象分析和转换结果、迁移建议、数据迁移辅助等信息生成智能迁移计划，指导和帮助后续的DSG for ADAM全流程迁移。

1. 5. 日志并发分析

DSG for ADAM进行日志分析时，可并发启动多个线程，对多个日志同时进行日志分析，加快日志分析性能。

1. 6. 按需复制

DSG for ADAM同时实现选择性复制。无需对所有的资料表信息进行复制，仅根据实际需要复制相应的表信息。

DSG for ADAM支持水平和垂直分割。在水平分割方面可以只复制那些满足预先定义的条件的记录，如DSG for ADAM可以指定需要复制的schema、指定不需要复制的schema、指定复制某些schema下的某些table、指定排除某些特定的table等预定义方式。在垂直分割方面允许设置对指定表的指定列进行复制。

1. 7. 首次全同步

for ADAM在不中断业务运行的情况下，将源端Oracle数据库数据通过DSG XEXP导出，目标端系统再通过YLOADER和YXAD模块批量导入到目标阿里云数据库上，实现初始数据的同步。

1. 8. 实时同步

DSG for ADAM对源端Oracle Redo log进行分析，实时获取变化数据，将数据转换为XDT格式输出，并实时通过网络传送到目标端阿里云数据库中，实现业务不中断的实时数据同步。

1. 9. 数据一致性检查

DSG for ADAM提供数据一致性检查工具，用来比较源端的记录和目标端的记录是否完全一致。如果出现数据不一致，for ADAM将对不一致的部分进行修复。

1. 10. 统一管理平台

DSG for ADAM提供可视化的UI管理平台，支持多用户并发访问。通过UI管理平台用户可以执行迁移操作、查看迁移统计信息（包括结构迁移、数据迁移、数据比对、对象迁移的统计信息）。用户通过统一管理平台，可以简单、直观的完成Oracle到阿里云数据库的迁移。

 

3. 评估迁移平台整体评估迁移流程

DSG针对阿里ADAM云迁移计划，按照用户实际需求，将Oracle数据库安全可靠的迁移到阿里云中，降低Oracle数据库的迁移成本和缩短迁移周期。

DSG for ADAM迁移流程包括：

图 1 DSG for ADAM完整使用流程和场景

 

图 2 ADAM转换能力图

 

图 3 DSG for ADAM迁移流程

1. 1. 智能采集与画像（ADAM）

DSG for ADAM 依赖阿里ADAM的评估结果和生成的迁移计划，首先需要下载ADAM的采集客户端进行智能采集生成数据包。

上传数据，ADAM for GP根据Oracle采集到的数据生成智能画像，全面描述客户源库使用情况和特征。

智能采集和画像的特点：

• Oracle数据库与应用架构发现
• 多维画像分析
•  Oracle使用特性(O特性)分析
•  Oracle性能分析
•  Oracle容量分析
• 外部依赖分析
• 特殊表类型分析
• 对象详情和搜索能力

1. 2. 智能评估和改造（ADAM）

ADAM for GP会自动分析Oracle to GP／ADB的兼容性，并自动进行改造和转换，给出所有的数据库对象的转换和处理建议。

          同时将所有的结果和标记生成ADAM智能迁移计划，用于ADAM Studio和DSG for ADAM的结构迁移、订正和改造，并指导数据迁移。

1. 3. 结构迁移和订正，生成ADAM最终迁移计划 （ADAM）

在仿真或者真实环境中，部署ADAM Studio（从官网下载），创建项目，并导入获取到的ADAM迁移计划，完成初步源库对比校验。

进行结构试迁移，并根据情况进行结构订正。

完成结构订正以后，生

1. 4. 完整表结构迁移

DSG for ADAM解析ADAM最终迁移计划，将迁移计划中Oracle数据库中的所有表结构（包括表结构关联的schema、索引、type和type body）同步到阿里云中，并在阿里云数据库中创建所有表结构。

1. 5. 数据迁移

DSG for ADAM将Oracle数据首次全同步到阿里云数据库中，并实时分析Oracle redo log日志，将变化数据实时同步到阿里云数据库中，DSG for ADAM工作原理，如图 2所示。

图 2 DSG for ADAM数据同步原理

DSG for ADAM通过AOXD进程对源端Oracle日志进行监控和分析。当应用系统在源端向Oracle数据库进行任何操作时，这些信息都将在Redo Log中保存，AOXD通过对实时获取的Log日志进行分析，将Oracle日志以最快的速度转换为XDT格式输出，并通过Agent进程将XDT数据实时传送到目标端系统中。

目标端系统通过Xagentd进程接收源端数据库包，经过校验码检查，确认正确的数据库包后，调用阿里云数据库的函数按照交易的先后顺序，通过YLOADER装载进程在目标端系统中执行该交易。

1. 1. 1. 日志分析

Oracle的所有更改都记录在日志中，当我们需要了解数据库中所作的交易时，可以通过DSG for ADAM的AOXD分析Oracle Redo Log日志文件实现。

DSG for ADAM的AOXD包含AOX和AOXC模块，主要完成的功能是日志并发分析，将分析后的XDT数据排序加载等工作。

50. AOX为日志并发分析模块，只被动的做日志分析，输出XDT等简单管理工作。
50. AOXC为AOX客户端模块，完成XDT文件并发读、日志排序，以及与AOX一些交互工作。

当AOX接收到AOXC客户端请求日志分析的时候，将启动一个新的线程来完成日志分析，将Oracle日志以最快的速度转换为XDT格式输出。

如图 3所示，以源端Oracle两个RAC节点为例介绍for ADAM的日志分析功能。

图 3 DSG for ADAM AOXD日志分析

在进行日志分析前，Agentd启动后会做一个初始化连接到AOXC，得到XDT缓存目录以及其他配置信息等内容。

当Agentd决定从具体那个日志开始分析后，将调用AOXC模块，做开始读日志设置信息。

AOXC客户端连接到Agentd配置后将启动两个（即每个RAC节点一个独立的读XDT线程）独立的内部线程优先将分析过的日志XDT文件读到内存中。

AOXC优先查找AOX输出目录是否存在自己需要的XDT文件，如果存在将立刻读出对应XDT数据到缓存中，发现要读的XDT文件不存在的时候将自动给AOX发送分析请求命令，请求AOX尽快分析出对应日志的XDT输出，同时AOXC在给AOX发送请求的时候每次会多发送一些，这样AOX可以提前多分析一些日志。如果源端数据库库运行很慢的时候多发一些日志也是无效的，对应日志可能还没有产生，AOX将自动忽略不存在的日志；如果遇到源端数据库库运行很快的时候就会存在AOX同时多个日志在一起分析，这样就实现了分析并发。已经分析出来的日志在输出缓存目录中又可以为其他交易合成提供必要的数据，这样另外几套交易合成就不用再做日志分析了。

AOXC预读XDT到缓存后，当Agentd要读具体XDT数据的时候，AOXC将从缓存中立刻取出对应的XDT数据，每次只取SCN最小的一部分XDT数据给Agentd，Agentd有了对应XDT后就可以完成分组、转换等工作。

AOX输出XDT数据的缓存目录可以根据实际需要灵活配置，可以存放到本地，也可以存放到远程。输出后的XDT也可以按照目录总大小来删除，如：规定目录总大小为50G，超过50G部分AOX将优先按照最少使用的XDT数据优先删除；也可以按照AOXC请求的方式来删除，AOXC每次读完一个XDT文件后会给AOX发送一个小于该XDT删除命令，AOX将根据各个请求端的XDT需要，来决定是否需要立刻删除或者暂缓删除对应XDT数据。

AOXC对已经分析的日志将不会重复分析，输出到缓存目录中的日志也不会重复分析，减轻日志分析对源端生产库的影响。

1. 1. 2. 交易合成

通过Oracle Redo Log分析的交易指令存在以下两个特点：

50. 这些指令是交叉出现的。一个交易（Transaction）中的多条SQL 指令是非连续存储的；而多个交易中的SQL 指令之间是相互穿插的。
50. Redo log中记录了所有交易，包括已经Commit的交易和未Commit的交易。

为了提高系统的可控制性、保证逻辑完整性及避免数据丢失，最好将复制的最小单位作为一个交易（Transaction），这样在目标端的交易装载更加容易控制。

同时对于复制的数据而言，在目标系统中只有那些已经Commit的数据是有意义的，Rollback的数据无需复制到目标系统上。

因此DSG for ADAM不是复制每个SQL 语句，而是对抓取的数据进行交易整合后以交易为单位进行复制，并且只复制Commit的交易。

图 4 交易合成

如图 4所示，Online Log Cache 文件包含Commit的交易、没有Commit的交易和Rollback的交易。交易合成模块首先按照交易序号对SOL 语句进行划分，然后以交易为单位将已经Commit的交易，传递到传输处理模块，将未Commit的交易保存在本地，将Rollback 的交易作丢弃处理。当交易合成模块通过日志得知保存的未Commit的交易已经提交，则该交易将会被立即发送到传输处理模块中。

1. 1. 3. 交易传输

DSG for ADAM为了保证数据传输的安全性和可靠性，在传输处理上进行改进：

1. 数据在传输之前首先存入源数据端的Cache，传输进程（Export Process）从Cache中读取交易数据并将其封装为TCP/IP 数据包，传送给目标端的xagent进程。
2. 在目标端，xagent进程在收到传输的交易数据包后，首先将数据包存入Queue中，然后由yloader进程从Queue中严格按照交易的顺序装载交易信息到阿里云数据库中。

图 5 交易传输

如图 5所示，负责传输的进程（Export Process）从本地队列中按照先进先出的原则抓取需要传输的交易，然后将交易数据封装成一个数据包后，通过TCP/IP 协议传递给目标端系统。目标端系统在接受到传来的数据包后，首先根据包头描述的包大小进行传输的合法性检查，判断是否传输完整。

1. 1. 4. 数据装载

DSG for ADAM采用XDT数据格式进行装载，在装载性能上进行了大幅度的改善，使得装载端的性能和处理能力需求降至最低。

XDT格式是DSG公司的专有技术，用来表达SQL 指令。该数据格式能够通过DSG的专有转换算法直接转换为阿里云数据库的内部数据表达格式，在分析和转载时仅需要进行最小的格式转化即可，提高分析和装载速度并减少资源占用。

关系型数据库系统在设计上提供4个层次的接口，其中包括User层、SQL层、Transformation层和I/O层。DSG for ADAM通过XDT数据格式装载时，调用I/O层直接将数据通过阿里云数据库的最底层函数写入系统中，如图 6所示。

图 6 数据装载

1. 1. 5. 数据完整性保证

DSG for ADAM复制软件主要通过以下几个方面保证数据的一致性和完整性：

50. 保证交易先后顺序

DSG for ADAM严格按照源端Transaction执行顺序在目标端加载，严格的I/O顺序是保证系统逻辑正确的关键因素。

DSG for ADAM通过对Transaction的SCN号进行判断，并严格保证源系统上先Commit 的交易在目标端也是先装载。

50. 检查日志跟踪的连续性

DSG for ADAM在每次log读取结束时，都将记录当前读取的日志的Sequence No、Block No和最后读取的Offset。当下次读取文件时，先检查是否和上次读取的位置严格连续，从而保证对日志分析的完整性。

50. 数据一致性检查

DSG for ADAM提供数据一致性检查工具，用来比较源端的记录和目标端的记录是否完全一致。如果出现数据不一致，DSG for ADAM将对不一致的部分进行修复。

1. 1. 6. 数据初始化装载

当系统进行初始化或需要重新完成批量数据复制时，DSG for ADAM提供海量数据的高速复制功能。

DSG for ADAM复制功能是通过对数据实行导入、导出的方式实现的，该功能不是对Oracle数据库底层的存储数据块进行复制，而是将源系统上的已有数据记录从datafile中直接读取并解析成为XDT 数据格式，再利用YLOADER将XDT数据批量快速装载到目标端系统上。

1. 1. 1. 1. 首次批量数据装载

DSG for ADAM调用Oracle的I/O层的API接口批量读取一张表（Table）的记录，然后将读取的记录转化为XDT格式，再将XDT格式表示的一批记录传送到目标端的Xagent进程，目标端再调用YLOADER和YXAD进程将数据批量写入阿里云数据库中，如图 7所示。

对于Oracle而言，其中有许多张表（Table），DSG for ADAM依次将每张表的所有数据按照上述原理复制到目标端数据库中。

XEXP导出过程不是通过Oracle的标准select接口，所以其导出速度非常快。同时，在采用YLOADER实现批量数据装载时，还无需停止源系统上的业务流程。

图 7 数据首次复制

1. 1. 1. 2. 增量数据装载

那么for ADAM是如何处理在导出过程中新改变的数据的复制呢？DSG for ADAM还提供第二阶段的增量数据复制：当上个步骤的大批量数据完成后，DSG for ADAM再将上步骤过程中新增加的交易重新复制到目标系统。

增量数据复制的工作原理是通过跟踪和分析从上个步骤开始时的所有redo log信息，从log文件中分析和翻译出这段时间内新增加的记录，然后再将记录通过语法转换在目标数据库上插入，如图 8所示。

图 8 增量数据复制

在这两个执行过程中，生产系统的业务可以保持运行状态，无需中断业务。

1. 6. 数据比对

DSG for ADAM提供数据一致性比对工具，用来比较源端的记录和目标端的记录是否完全一致。如果出现数据不一致，for ADAM将对不一致的部分进行修复。

DSG for ADAM支持对数据进行全量比对、增量比对及数据修复。

1. 1. 1. 全量比对

DSG for ADAM支持对同步的所有数据进行全量比对，全量比对的工作原理如图 9所示。

图 9 DSG for ADAM全量比对

1. DSG for ADAM对源端和目标端数据库按顺序导出表数据，导出后立刻计算每行数据CRC，然后将CRC和ROWID数据传给DSG for ADAM比对工具。具体表数据不会在网络上传输，不影响业务性能。
2. DSG for ADAM比对工具按照CRC排序，比较排序后的CRC数据，如果出现不一致信息，根据具体的CRC数据查找对应的ROWID值，可以对不一致数据进行修复。
   1. 2. 增量比对

增量比对，即在上次不一致数据的基础上再做一次比对，不会对原来已经确认为一致的数据再进行比对。

图 10 DSG for ADAM增量比对

 

1. 查询比对记录表，得到哪些数据需要做增量比对。对需要比对的表查询出具体每行数据，并计算出CRC。
2. 比对新导出数据的CRC。如果不一致，则表结果写入到比对记录表中。
3. 和全量比对一样，根据具体的CRC数据查找对应的ROWID值，可以对不一致数据进行修复。
   1. 3. 数据修复

DSG for ADAM会把源端和目标端不一致的记录导出成xdt数据，然后自动调用yloader先删除目标端不一致数据，然后再加载源端导出的xdt来完成修复。

1. 7. 对象迁移

表结构和数据迁移完成后，且数据比对完全一致，DSG for ADAM根据ADAM迁移计划，将Oracle的所有对象迁移到阿里云中，并在阿里云数据库中创建所有对象。

4. 评估迁移平台feature list

50. 全面的数据库迁移方案：

依托阿里云ADAM智能分析的迁移计划，结合DSG在Oracle到异构数据库的迁移产品及经验，为用户提供流程完整、操作简便、数据安全准确的Oracle数据库迁移方案。

50. 数据对象自动转换和改造：

DSG for ADAM依赖ADAM的智能采集、智能评估、智能转换和智能改造，对于所有数据库特性都提供智能转换或者改造建议。

50. 数据库日志高效分析：

DSG for ADAM支持对Oracle数据库日志并发分析，加快日志分析性能。通过AOXD模块对日志进行一次分析，分析输出的XDT文件可供多进程、多任务使用，同时XDT文件可存放在本地或远程，以减轻数据库日志重复分析对源端系统带来的压力。

50. 无需中断业务

DSG for ADAM在不中断业务的情况下可以实现数据同步和不一致数据修复，无需人工干预，简化软件操作，减少用户工作量。

50. 支持Oracle迁移到阿里云多种数据库：

DSG for ADAM支持对Oracle数据库到阿里云POLARDB、RDS、ADB、PPAS等各种异构数据库的同步迁移。

50. 支持数据回流：

DSG for ADAM支持数据回流功能。可以将迁移后的阿里云数据反向同步到Oracle数据库中，保障数据安全。

50. 统一监控管理：

提供的UI管理平台，方便用户通过简单操作，就可以完成Oracle数据库迁移操作，同时，对迁移中的没有流程都显示详细的同步信息。

5. 评估迁移平台应用

根据ADAM迁移计划，再结合DSG for ADAM自身的同步迁移功能，在不中断业务的情况下安全可靠的实现Oracle数据库到阿里云的数据迁移。

图 11 Oracle数据库零停机迁移

1. 1. 评估迁移平台- Oracle To Greenplum智能迁移解决方案应用场景

ORACLE数仓迁移场景介绍

1. 大量CLOB/BLOB表里面存储的大量的文本或图片，要快速的迁移到数仓
2. 不同源端系统不同字符集，到数仓需要统一的字符集应用
3. 源端业务系统不含主键的表，到数仓保证更新和删除快速完成
4. 源端的建表语句和到数仓的建表语句不同，保证分区字段的更新不影响数仓表的更新
5. 源端业务的升级有大量的DDL变更，保证正确的DDL语法转换后无感知无故障的应用
6. 源端业务表为了快速在线业务建立的索引，需要在数仓里的快速分析业务里变化成合适的索引
   2. 评估迁移平台 - Oracle To Greenplum案例分析

50. 客户案例背景介绍

随着大数据时代的到来，xx省公安厅下辖各级公安机关警综系统采集汇聚的数据量日益巨大、数据结构更加复杂，增长迅速。目前，xx省公安厅还未建立有效的警综系统数据汇聚手段，原有的数据抽取整合工具在传输海量结构化数据时效率低下，且无法满足各类数据抽取整合的需要。为解决因数据分散导致的资源共享不及时、利用率不高等问题，xx省公安厅急需开展警综系统数据汇聚整合工具建设，实现对下辖各级公安机关警综系统的高效抽取汇聚和关联整合，进一步丰富全警实战应用需要。

50. 客户需求：完成xx省公安厅下辖十三个地市警综系统（Oracle）数据实时汇聚到xx省公安厅警综系统集中库（GP）
50. 客户需求特点：

1. 数据量大

省内下辖十三个地市的警综系统进行数据汇聚，数据量目前估算约为20-24TB左右

2. 准确性高

省内下辖十三个地市的警综系统进行数据汇聚，常发生丢或漏数据的情况，需要保证数据的准确性、一致性为了后续业务的正确性使用

3. 差异化

省内下辖十三个地市的警综系统进行数据汇聚，部分地市有个性化开发，导致有的地市表结构不完全相同（关键字段是有的），考虑汇聚共性字段

4. 标准性

省内下辖十三个地市的警综系统进行数据汇聚，从地市警综系统生产端压力考虑，目前采用从警综前置机或备份库上进行数据汇聚，地市前置库或备份库具体建立技术标准，由省厅统一下发

5. 整合性

省内下辖十三个地市的警综系统进行数据汇聚，为了便于对汇聚库资源进行整合，地市相同表名的数据同步省厅，需要整合到同一个表内

6. 实时性

省内下辖十三个地市的警综系统进行数据汇聚，要求数据为实时或准实时复制，原有数据汇聚整合工具，无法做到实时或准实时的数据汇聚。

50. 客户案例实施过程 - Oracle To Greenplum主流程(ADAM+DSG)

1. 画像 - ADAM
2. 评估 - ADAM
3. 改造 - ADAM
4. 迁移 - DSG 
5. 同步 - DSG 

50. 客户案例实施效果总结 (DSG)

• 最小风险
• 最少改动
• 最优成本
• 最大扩展

50. 省厅下辖十三个地市警综系统（Oracle）数据实时汇聚到省厅警综系统集中库（GP）系统架构如下：

 

xx省公安厅数据汇聚平台，涉及xx省13个地市的警综数据，各地市的系统、平台等环境都存在一定差异，因此，如果要如此大规模的数据汇聚，存在诸多方面的挑战。DSG给出的方案中，基本上解决了各种难题，主要体现如下：

参与复制的系统多，并且生产端都是生产系统，这就要求数据复制产品的复制效率要足够高，否则影响查询结果。

多种平台混合复制。由于源端有13个生产库或者生产库的备库，其中存在hp，aix等知名厂商的各种平台系统，这就要求复制产品支持各种异构平台。

基于表复制。每个系统抽取的数据均是部分表的数据。

索引异构。由于源端和生产系统，目标端是查询系统，系统的功能不同导致相应的索引也有所不同。

分区异构。同样由于系统功能不同，导致某些表的分区结构也不同，要求复制软件能够在分区异构的情况下也能正常复制。

多表合一。在多个系统中，有可能存在用户名和表名均相同的情况，在复制过程中，需要解决多表合一的问题。

数据转换分析

根据现场的实际情况，把数据从oracle到greenplum的数据复制，存在以下方面的一些转换：

序号	需求内容	解决方案	实现结果
1	字符集转换	GBK转换为UTF-8	实现
2	Blob 表处理	Blob 表源端导出过滤、目标端加载过滤	实现
3	Delete+insert	Update 操作先delete后insert	实现
4	关键字特殊处理	表结构有特殊字段#或者是count(*) 进行转换	实现
5	字段长度处理	字段长度太长，进行转换处理	实现
6	Index 处理	根据需求制定特殊列的索引为btree	实现
7	增加loadtime列	增加gp入库的时间标记	实现
8	增加rowid	增加rowid对no pk/uk提升update加载速度	实现
9	数据引号处理	入库数据不需要‘’处理	实现
10	Delete 删除优化	优化delete 操作	实现
11	Update更新优化	优化update 操作	实现

13个地市相同表名的数据同步省厅，业务整合的涉及内容及数据比较：

测试项目	业务表不整合		业务表整合
安装和部署	比较简单		需要针对每个地市的每张表都需要进行详细配置
数据初始化同步效率及资源占用	效率较高，资源占用较低		对生产端资源占用没有影响 对省厅GP目标端资源占用较高，特别是磁盘IO和内存资源消耗较高
单表数据修复	支持单表数据修复，1千万数据需要600s		支持单表数据修复，1千万数据需要1200s
表结构更改	无需干预		需要重新配置配置文件并使其生效，有些情况可能需要重新初始化
前端应用配合	应用层面需要进行调整		应用层面调整较小
后期运维服务	为保证稳定性，均需要驻场服务，业务表整合增加了单表数据修复功能，维护量和业务表不整合未有差别
查询效率 分别列举了10条常用的sql进行对比	未整合效率比较整合后低，整合后查询快，资源消耗小
	SQL1：	65s	SQL1：	74s
	SQL2：	66s	SQL2：	29.27s
	SQL3：	22.73s	SQL3：	9.59s
	SQL4：	66s	SQL4：	15.43s
	SQL5：	11.7s	SQL5：	7.27s
	SQL6：	5.49s	SQL6：	3.6s
	SQL7：	5.99s	SQL7：	3.24s
	SQL8:	19.81s	SQL8：	3.65s
	SQL9：	7.58s	SQL9：	4.49s
	SQL10：	6.9s	SQL10：	20.86

 

售后服务范围为产品使用方面的技术支持，售后支持时间范围为合同期范围内