云和恩墨（北京）信息技术有限公司

EBS 云迁移解决方案

目录

需求

CONTENS

解决方案 评估方法

迁移的需求

面临逐步被淘汰

建设策略复杂

维护周期越来越长

维护成本越来越高

VS

随着云技术的发展，在迈入云时代的今天，ERP正面临着从软件化到SaaS化的转变，一场关乎成本、效率与体验的云上革命已经全面到来。

华为云推出EBS上云解决方案，支持在华为云上部署EBS，助力企业数字化转型，为企业EBS业务的高性能、可靠性和安全性提供平台支撑。

越来越多的企业选择与现有成熟的云服务商合作，让现有成熟的云技术为企业所用。

消除搭建和运维复杂的IT基础设施的繁重任务，更好地专注企业自身业务的创新

EBS迁云通用需求

➢ X86-64环境下EBS系统架构设计和规划；

➢ 将EBS系统由传统的本地部署完整地迁移到X86-64的云平台上；

➢ 将数据库和EBS应用版本保持不变；

➢ 支持应用多节点和支持数据库RAC；

➢ 应用系统和数据库的云备份规划。

平台迁移需求

➢ 从方案上确保整个实施的零风险，而不仅仅是从操作方法上降低风险；

➢ 尽量缩短业务的停顿时间；➢ 确保数据迁移前后的完整

和一致性；➢ 操作过程中要保证现有系

统不受影响，一旦迁移出现任何异常，能够立即终止迁移动作，并将业务切换到原有状态，保证数据及业务的安全。

技术设计需求

➢ 分别考虑数据库和应用层迁移，首先执行数据库迁移；

➢ 通过将EBS迁移分解成数据库和应用层两项单独事件,是特别重要的潜在减少宕机时间的方式；

➢ 云平台上OS版本➢ EBS版本、使用的模块；➢ 数据库大小和系统业务复

杂度；➢ 业务需求➢ 选择正确的EBS迁移技术

路线

考虑因素

只在使用的时候才给基础设施付费，不需要事先固定投资

不需要再猜测容量，为未来买单

减少花在基础设施上的时间,专注于新的业务计划和创新

无须采购安装硬件,无须安装配置新软件,无须构建或升级数据中心

几分钟内完成系统的安装部署,统一的系统监控和报警

在华为云上

⚫ $0启动成本 随用随付费

⚫ 一键扩容 按需使用

⚫ 增加创新：更快的尝试并且低成本、低风险

⚫ 摆脱无差异化的、基础类的体力活

⚫ 摆脱耗时且成本高昂的任务

华为云涵盖所有的间接成本

操作系统虚拟化 机房

存储 电力空调

资源管理自动化

管理人员

服务器

7*24专业系统运维管理1小时内问题处理响应

目录

解决方案技术·方法·要点·特性

CONTENS

评估方法需求

EBS迁移实施总体原则

EBS由百种使用不同技术的子产品组成，其中许多子产品具有复杂的会话状态处理(一些在数据库中，一些在中间层),缓存需要保持同步;系统迁移后，需完整保留迁移前的功能和业务实现，通过调整或客户化开发等手段，定制个性化解决方案，解决系统存在的问题和满足客户的提升需求。

功能完整原则

系统迁移后，应该在不影响一线人员操作的情况下，尽量平滑的过渡到新的系统中，要求实施时间短、变化要小。

平滑过渡原则

通过掌控实施步骤，规避系统迁移的风险点，使得整个项目在可控范围内如期达到预定的实施要求和相关验收标准，同时要充分考虑新系统的系统安全，确定新系统在运行稳定。

最低风险原则

EBS系统是一套庞大和复杂的企业核心系统，部署的模块多、使用的机构多、客户化开发和第三方接口也较多，在系统实施时，牵一发而动全身，方案必须要通盘考虑，才能确保迁移后系统稳定。根据我们多年来的实施经验，通常有以下关键原则：

EBS数据库层迁移

EBS数据库层认证的平台字节次序

大字节次序平台 小字节次序平台

⚫ Oracle Solaris on SPARC ⚫ Linux x86 and x86-64

⚫ HP-UX Itanium and PA RISC ⚫ Oracle Solaris on x86-64

⚫ IBM AIX on POWER Systems ⚫ HP Tru64 and OpenVMS Alpha

⚫ IBM: Linux on System z ⚫ Linux Itanium

⚫ IBM: Linux on Power Systems ⚫ MS Windows Server x86/x64/Itanium

迁移

在相同平台上的操作系统升级或替代

一个新的操作系统作为目标(例如,迁移至华为云Linux上),用户可以简单地使用快速克隆技术复制应用层到一台新机器上。

迁移到在不同平台上的应用层迁移技术

当考虑一个新的平台上部署EBS应用层(例如,从AIX迁移至华为云Linux上)，可以使用以下技术迁移应用节点到新机器上。

EBS应用层迁移

在相同平台上的操作系统升级或替代

当考虑一个新的操作系统作为目标(例如,迁移至华为云Linux上)，用户可以简单地使用快速克隆技术复制数据文件到一台新机器上。

迁移到相同字节格式的新平台

当数据库迁移的目标是相同的元字节格式,我们建议使用数据库迁移的过程称为便携式数据库(TDB)来迁移数据库。

迁移到一个不同字节格式的平台

当目的平台是不同字节格式的时候，有2种迁移技术:可根据项目的具体场景选择合适的迁移技术(如:迁移窗口时长,数据库版本,数据量的数据量,目标架构，硬件资源等)

• 使用数据泵的导出/导入一直传统地被用于执行数据库跨平台迁移，这是一个完整的数据库导出到dump文件，然后再导入并迁移到目标机器的逻辑。

• 使用新认证的TTS传输表空间迁移技术，它更合适作为减少停机时间的快速迁移过程，适合大型数据库,10g以后相同的RDBMS版本。

数据库层迁移

迁移

数据泵 XTTS

EBS迁移方法论

VS

迁移EBS系统是一项复杂的具有挑战性的工作，建议采用Oracle标准预定义流程和灵活的方法－EMM方法(即Easi Path Migration Method）

EMM的四个阶段

迁移的整个过程分为4个阶段，同时也包括质量控制检测点，确保项目的成功。在项目期间，实施人员在这4个阶段执行各自的工作，在每个阶段，对工作进行质量检查。

迁移评估 迁移与测试 系统移植 生产上线

评估阶段的目标是分析对应用

系统变更带来的影响，其结果

规划整个应用系统迁移的步骤。

迁移并测试应用系统的所有组

件，以确定系统的设计和应用

设置的正确性。

完整配置并迁移产品环境，并

最终把业务切换到新产品环境

中。

生产上线目标启用新产品环境

中，监控系统，保障产品环境

的性能和稳定。

• 现有EBS环境调研

• 业务对停机窗口要求

• 业务连续性要求…

• 迁移上云总体实施计划

• 迁移方案规划设计

• 订阅配置华为云

• 软件介质及环境准备

• 业务接口清单梳理

• 业务测试用例设计

• EBS开发系统迁移

• 迁移后单元测试

• EBS测试系统迁移

• 迁移后集成测试

• 生产系统迁移、切换

• 迁移后系统监控

• 上云后月结支持

• 系统持续优化

• 知识转移

• 项目总结报告

EMM的九个流程

需求评估

检查新应用系统适应用户业务的基本需求，确定这些需求在新的应用中是否受影响。

需求匹配更正

评估新旧版系统差异，通过调整系统架构等，满足客户的提升需求。

应用和技术架构更新

分析架构更新带来的影响，当系统移植到新架构后，适应客户新的提升需求。

客户化迁移

对现有客户化程序的修改，使之能运行在新的系统上。

数据移植

把当前系统的所有必须需要数据经测试移植到新系统中，通过使用Oracle数据迁移技术，

将数据移植完整地移植到新的环境中。

归档

在项目实施期间，参考文档模板，归档相关技术工作，便于日后的系统维护和调整。

业务系统测试

通过一套完整的方法，测试应用系统的所有功能，以确保系统迁移的工作质量和适应客

户需求。

培训

培训用户和系统管理员对新系统的掌握和使用。

产品移植

包括系统的移植，以及相关部门和人员的业务转移到新系统中操作。随着产品环境的切换，还应进行系统的监测、优化及规划，保障系统的良好使用。总之，产品环境移植包括:系统移植，环境就绪，切换，支持服务。

EBS迁移重点与难点

FormReportOAF等客户化开发，是否均存在最新源代码，需识别确定外围关联第三方系统接口，需确认支持新平台，迁移后接口能正常运行.

客户化识别与迁移

迁移后系统稳定和功能一致性验证

编号 重难点 应对措施

1 保障系统稳定性 多轮验证测试，确保迁移后系统运行稳定

2 确保功能一致性 搜集补丁完整清单，在Linux环境下，安装一致的或相应替代补丁。

3 标准程序修改提前识别，并在迁移后复制修改代码：核查执行文件的最后修改日期，是否与系统安装日期一致。技术顾

问在迁移后，参照原环境进行开发，功能顾问测试确认。

4 全面功能测试提供资深功能顾问，对标准功能测试范围和功能点进行确认。

对客户化功能，由甲方关键用户和资深功能顾问一起对测试范围进行确认。

风险与应对策略

当完成的进度与工作计划不相符时，发生工作进度风险；当硬软件发生问题或技术问题影响项目进度时，发生外部风险；当工作负荷过大或主要项目资源损失影响项目时，发生内部风险。

项目风险

应对策略

指针对常见主要风险点，采取降低风险的措施

指由于潜在的原因对项目的进一步实施会造成负面影响的因素

编号 风险点 应对措施

1 客户化源代码遗失 重新开发：功能顾问配合关键用户进行功能设计，技术顾问进行开发。

2 功能版本不一致 搜集补丁完整清单，在Linux环境安装一致的或相应替代补丁。

3 标准程序被修改提前识别并在迁移后复制修改代码：核查执行文件的最后修改日期，是否与系统安装日期一致。技术顾问在迁移

后，参照原环境进行开发，功能顾问测试确认。

4 功能测试不全面提供资深功能顾问，对标准功能测试范围和功能点进行确认。

对客户化功能，由甲方关键用户和资深功能顾问一起对测试范围进行确认。

5 硬件故障或性能不佳 华为云专家团队专业的现场支持，针对具体场景，提供云扩容，灾备等优化方案。

实施阶段和交付物

阶段 工作内容 交付物

启动阶段 召开项目启动会 项目章程、项目计划

评估阶段 第一次技术迁移及测试数据清理方案、客户化迁移方案、迁移测试方

案、第一次评估报告

迁移测试阶段 第二次技术迁移及测试数据清理方案更新、客户化迁移方案更新、迁

移测试方案更新、第二次评估报告

模拟迁移阶段 第三次技术迁移及测试数据清理方案、客户化迁移方案更新、迁移方

案的更新，正式升级前第三次评估报告

系统切换阶段 正式环境切换到新平台 上线切换计划，上线切换报告

上线试运行阶段 保证系统平稳、高效运行 系统试运行报告

项目验收阶段 准备验收材料，召开验收会议 项目总结、验收报告

理论

知识转移

在实施过程中，我们将采用有效的培训方法,完成技术技能的传递重大战略任务

将EBS迁移理论与原理生动的表

达出来，加深学员的理解和认知。

实践布置作业，实践结合理论，提高

动手和实战能力。

案例以实际案例为基础与学员讨论、

解析各个重要知识点。

反馈

通过答疑、作业回顾等手段，了

解学员对培训内容的掌握水平，

并针对性的予以指导和强化。

➢ 领导全力支持➢ 完整的客户化清单及客户化代码➢ 各项功能的测试充分➢ 详尽的生产迁移计划➢ 系统架构的设计合理及硬件平台的稳定

成功要点

知识转移

➢ UI功能：通过业务人员按人机交互的方式测试➢ 接口功能：对于优先级高的接口,通过请求发起端应用测试；对于优先级低的

接口,通过SOA平台，采用SOAP-UI测试➢ 典型功能性能测试：自动性能测试，采用成熟的自动化测试工具，测试预设

场景的性能；人海压力测试，由业务人员执行测试，测试实际操作的性能和体验；

➢ 回归测试：对于每一项开发,都要通过回归测试确认调整效果

全面测试

应对策略

步骤 内容 说明 参与人员（甲方）

1 确认应用实例 确认哪些应用系统、实例需要迁移，源系统的版本是多少，安装过哪些补丁或更新。 项目经理/技术顾问/DBA

2 确认业务场景与流程 穷举与迁移系统相关的业务场景，收集并整理操作流程和操作方式。 功能顾问/关键用户

3 准备测试用例 按原操作方式准备用于未来测试的脚本，包括步骤、数据。 功能顾问/关键用户

4 确认系统信息 确认最终的应用系统版本、更新和补丁、使用的模块、数据库版本 功能顾问/DBA

5 迁移后功能测试 按业务场景，根据测试脚本，对功能逐一进行测试。 功能顾问/关键用户

6 迁移后数据测试 选取核心主数据与业务数据，从源系统、目标系统分别导出数据。比较数据的差异。 功能顾问/关键用户

目录

评估方法

CONTENS

需求 解决方案

• FSG报表：• 随数据库迁移，工作量随功能验证

• ReportBuilder客户化报表（基于EBS标准报表）：• 需要根据目标EBS系统标准报表重新开发，工作量与原系统报表开发相同

• ReportBuilder客户化报表（不基于EBS标准报表）：• 如果EBS表结构无变化，工作量随功能验证。• 如表结构变化，需要基于原系统实施功能开发文档重新开发

• PL/SQL报表：• 如果EBS表结构无变化，工作量随功能验证• 如果EBS表结构变化，需要基于原系统实施功能开发文档重新开发

报表

OracleEBS系统迁移开发内容与工作量评估

• Form：需重新编译，工作量较少• JSP页面：需重新部署，工作量较少• 工作流Workflow：工作量随功能验证• 并发请求

• 如果EBS表结构无变化，工作量随功能验证• 如果EBS表结构变化，需要基于原系统实施功能开发文档重新开发，工作量与原

系统并发请求开发相同• 触发器DBTrigger

• 如果EBS表结构无变化，工作量随功能验证• 如果EBS表结构变化，需要基于原系统实施功能开发文档重新开发，工作量与原

系统触发器开发相同

客户化开发

• EBS系统内部接口：• 随数据库迁移，工作量随功能验证

• EBS系统与外部系统接口：• FTP/SFTP:需要更改源代码，工作量随功能验证增加1-5人天• Weblogic:需要更改源代码，工作量随功能验证增加1-2人天• DBLink:需要更改源代码，工作量随功能验证增加1-2人天

• Shell脚本：• 需要更改源代码，工作量随功能验证增加1-2人天

• SQL*Loader：• 工作量随功能验证

接口

• Form：需基于目标系统标准Form及原系统实施功能开发文档重新开发，工作量与原系统Form开发相同

• JSP页面：需基于目标系统标准JSP页面及原系统实施功能开发文档重新开发，工作量与原系统JSP页面开发相同

• 工作流Workflow：需基于目标系统标准工作流Workflow及原系统实施功能开发文档重新开发，工作量与原系统Workflow开发相同

• 并发请求：需基于目标系统标准并发请求及原系统实施功能开发文档重新开发，工作量与原系统并发请求开发相同

增强功能

硬件评估

硬件配置评估过程概览 硬件评估是一个过程，而并非仅仅是计算。

评估需要与用户、实施提供商进行多次交流，依据应用方案，评估结果才更加接近实际需要。

首先根据用户提供的信息进行初步评估，此评估结果是基于Oracle标准功能对硬件系统的需求。

在此结果上，再进行调整，比如加上对应用系统客户化、新增功能、操作系统和系统其他需求对硬件的需求。

最后，根据最终的硬件指标需求，匹配硬件的详细配置。最终配置还需与用户进行讨论，可能还需要进行调整，确定最终方案。

TPC-C

OracleEBS系统迁移开发内容与工作量评估

⚫ CPU

⚫ 内存

⚫ 磁盘I/O

⚫ 网络带宽

基于EBS使用场景

⚫ 系统吞度量

⚫ 响应时间

⚫ 并发用户数

基于企业业务发展

⚫ 系统的设计年

限

⚫ 业务年增长率

⚫ 增长事务类型

系统同时在线用户数为 1500人（U1）；

平均每个用户每分钟发出 2次业务请求（N1）；

系统发出的业务请求中 更新、查询、统计各占1/3；

平均每次更新业务产生 3个事务（T1）；

平均每次查询业务产生 8个事务（T2）；

平均每次统计业务产生 13个事务（T3）；

一天内忙时的处理量为 平均值的5倍；

经验系数为 1.6；(实际工程经验)

考虑服务器保留 30％的冗余；

需要的处理能力为：

TPC-C=U1*N1*（T1+T2+T3）/3*6*经验系数/冗余系数

TPC-C=1500*2*（3+8+13）/3*5*1.6/0.7=274,285tpmC

考虑到高可靠性和高可用性，并注重设备的可扩展性和性价比，系统将配置两台

TPC-C值不小于28万的数据库服务器

案例

硬件评估示例

10%操作系统及30%的冗余

64个CPU(core)

应用服务器CPU评估182core

应用CPU评估

2500FORMServer处理能力

支持在线FORM用户数2500

每个2CPU（core）支持250个用户

20个CPUCore需求

500OAF并发处理能力支持在线OAF用

户数500

每个2CPU（core）支持100个用户

10个CPUCore

并发管理器处理能力

支持在线500个并发管理器及请求

每个CPU（core）支持50个并发进

程

10个CPUCore

2500FormRuntimeCPU2500个

FORMRuntime

每25个Runtime使用一个CPUcore

100个CPUcore

应用服务器内存评估399G

FormsGroup内存评估

需要20个JVM

每个JVM512M大

小

10G

Runtime内存评估

5000个并发FORM

每个并发Runtime50

M

250G

OAF内存评估

5个JVM

每个JVM2G

10G

并发管理器内存评估

500个并发

每个30M

15G

10%操作系统及30%的冗余

94G

应用RAM评估

云和恩墨（北京）信息技术有限公司

谢谢观看