ERP 系统规划 - Baiduimages.china-pub.com/ebook3660001-3665000/3661050/ch02.pdf1 个JVM/Servlet...

第 2 章

ERP 系统规划

2.1　ERP 系统规划概述

2.2　资源配置估算

2.3　大型 ERP 系统架构涉及的内容

2.4　系统环境

2.5　本章小结

第 2 章　ERP 系统规划　　7

ERP 系统是大部分企业的核心系统之一，企业可能同时还会有很多套其他的系统，

分别支撑着不同的业务，但大部分系统都要与 ERP 系统进行集成。此类大型 ERP系统对公司的正常运营起着至关重要的作用，所以，在系统实施之前一定要有一个全局的规

划。规模较大的公司往往都会进行战略方面的咨询，ERP 系统的架构可以参考战略咨询的

报告来进行，但不能完全依赖战略报告，因为战略报告考虑问题的层面往往会比实际情况要

高，所以有些想法比较难落实，或者根本就无法在系统中落实。

国内有很多规模不大的咨询公司或外包公司也在做 ERP 的实施，但往往由于 ERP DBA经验不足，或者只注重功能和开发等方面，因此在具体实施时根本不进行任何技术架构的规

划。所以，一些企业的 ERP 系统上线后出现了不同程度的、因为规划不足而造成的性能问题

和管理问题。

2.1　ERP 系统规划概述

因为本书的重点是对 Oracle 电子商务套件的实践进行说明，所以，本章只是对 ERP 系

统的架构和集成进行简单地概述。

本章将从 ERP 系统架构的理论开始介绍，重点概述 Oracle 电子商务套件的技术架构，

其主要内容包括：

ERP 系统正常运行所需要的硬件和软件的资源配置估算，即基本的系统架构、存储架

构、网络架构、集成架构、客户端架构等。

介绍保证 ERP 系统正常运行所需要的辅助架构，如备份与恢复、灾难恢复方案、系

统管理与监控，以及安全策略等各个层面的内容。

这些内容在技术架构上没有统一的硬性规定，每个公司的业务特点不同，要求也不尽相

同，但大部分都是必须要做的。没有扎实的基础架构，再漂亮的大楼也是“危楼”。

2.1.1　ERP 系统规划的思路和步骤

规模较大的企业通常会在战略咨询的基础上对整个 IT 基础设施做一个规划，ERP 系统

规划可能只是整个 IT 基础设施中的一部分。对于一些规模较小的成长性企业而言，规划时

要考虑的因素可能没有大企业那么多，可以参考如下 9 个步骤进行自我规划。

1）前期调研。

2）企业战略分析。

3）行业成功案例参考。

4）把握最新的 IT 技术潮流。

5）IT 系统现状分析。

6）IT 战略方向分析。

8　　Oracle E-Business Suite：ERP DBA 实践指南

7）IT 人员能力分析。

8）IT 系统建设指导原则设计。

9）IT 应用架构蓝图设计。

有些企业据此做出来的规划可能超出了企业当前的实际需求，但可以将其作为以后的发

展目标。

2.1.2　ERP 系统架构的设计原则

在写作本书之前，笔者研究了包括四大咨询公司在内的很多 ERP 实施资料，同时，结

合自己多年的实战经验，总结出 ERP 系统架构设计的一般原则，供大家参考。

其实，每个 ERP 厂商都有自己的实施方法论，如果想详细了解这些理论知识，可以向

项目管理办公室（Project Management Office，PMO）、实施商或 ERP 厂商等索要相关的

资料。

一般而言，ERP 系统架构的设计遵循如下原则（其实这些原则和一般的 IT 系统架构的

原则类似）。

科学实用原则。该原则是系统架构的根本出发点，立足于科学技术，一切以满足公司

真实的业务需要为架构目的。

经济性原则。尽量利用现有资源，坚持在先进、高性能前提下合理投资，确保在成本

最低的情况下获得最大的经济效益和社会效益。

安全可靠性原则。最大可能地减少因系统架构故障而造成业务无法正常运行的情况，

同时，设计中还要规划安全体系的建设，提高系统的整体安全性。

先进成熟性原则。在 IT 技术飞速发展的今天，规划的产品和技术应具有一定的前瞻

性，能够适应未来一段时间内，企业业务需求和技术发展的趋势。同时，应该兼顾产

品和技术的成熟性，保证系统架构的整体安全性。

开放与可扩展性原则。系统的架构应尽可能地使用开放式的技术，并充分考虑可扩展

性，满足不断发展变化的企业业务和技术需求。

统一标准化原则。尽可能采用业界公认的行业或技术标准，降低实施和管理复杂度。

2.1.3　ERP 系统基本规划

由于 ERP 系统平台应做到可以支持任何硬件平台、操作系统甚至数据库的组合，并能

做到应用与硬件平台、操作系统和数据库无关，所以理论上对于应用的使用可以采用任何组

合方式。数据的安全、完整、可靠是整个系统构建的关键所在。在硬件系统设计、软件平台

设计及在两者基础之上的业务信息平台设计上，遵循开放性、先进性和标准性原则。在具有

强大的系统性能的基础之上，确保 ERP 系统的可用性和安全性，同时应该考虑后期 ERP 系

统的扩容和升级问题，并能够保证实现系统的平滑升级。


2.2　资源配置估算

资源配置估算（Sizing）的过程是科学的、严谨的，需要结合多种因素来综合考虑，而

不仅仅是计算，具体如图 2-1 所示。

客户信息输入

Oracle E-Business Suite Sizing

假设和缺省

值设定

伸缩性

基准测试

经验和

最佳实践

系统使用率

<=70%

伸缩性

测试

最佳实践

知识库

图 2-1　资源配置估算需考虑的因素

做资源配置估算主要包括以下关键内容：

通过对客户需求的调研，掌握 ERP 系统的应用需求规模。

掌握客户整个信息化系统阶段化发展的规划。

掌握客户不同阶段实施上线的应用模块和用户群体规模。

基于 ERP 实施的最佳实践知识库进行科学的规划。

与客户充分讨论，确认规划建议是否符合客户的 IT 规划的整体要求。

利用 ERP 厂商、实施商和硬件提供商提供的资源配置工具进行初步的估算。

参考行业内已经实施过的类似的 ERP 系统的使用情况。

听取原厂商、实施商和硬件提供商的建议，特别是经验丰富的 ERP 系统架构师的

建议。

初始阶段，可采用高档次、低配置的服务器来满足实施的要求，随着项目实施进程

的逐步推进，可以逐渐对服务器进行扩充和增加主机节点。在整个 IT 系统的规划阶段，

还需要进行详细的业务调研和估算，同时估算服务器、存储空间、网络资源等的具体

需求。

2.2.1　系统应用规模调研

ERP 系统规划首先要了解客户的实际需求，以及系统应用规模，并根据规划要求的因素

设计一份应用规模调查报告。表 2-1 是一个系统应用规模调查表样式，供读者参考。


表 2-1　系统应用规模调查表

序　号模　块操作人员数量高峰时最大并发数

财务信息系统

1 核心财务

2 财务智能分析

项目管理

1 项目会计

人力资源管理

1 人力资源管理

2 人力资源员工自助服务

3 人力资源分析

生产制造系统

1 生产制造管理

供应链管理系统

1 供应链系统

采购管理系统

1 采购管理

2 采购分析

设备管理

1 设备管理

订单管理

1 核心订单管理

销售管理

1 销售管理

2 销售分析

合计

在做调研的时候，ERP DBA 要向客户调研，并与功能顾问进行模块的确认，可以根据

以上的调研报告、ERP 技术架构的需求以及和功能顾问模块确认的结果等因素，绘制调研结

果分析报告。表 2-2 是调研结果分析报告表的样式。

表 2-2　调研结果分析报告表

内　容基于以上调研报告

用户并发度 50% ～ 80%

自助服务用户并发度 2% ～ 6%

用户工作强度工作强度适中 / 繁忙

在线业务处理与后台批处理的比例 4∶2

系统环境冗余度系统使用 70%

业务量（数据量）一年的数据量

其他假设假设仅仅针对电子商务套件标准功能


2.2.2　硬件配置的预估

ERP 系统的硬件资源配置的预估主要集中在 CPU 数量、内存大小以及数据存储空间的

预估上，同时还可能面临硬件设备类型的选择，下面就这三方面做详细的介绍。

1. 服务器的 CPU 数量

到底多少个 CPU 才能满足企业 ERP 持续、稳定发展的需求？针对这个问题，几乎所有

的 ERP 厂商和硬件厂商都不能给出一个特别准确的答案，因为不同的业务特点、不同模块的

组合、不同的用户数量、不同的架构方式和不同的配置等因素都影响资源配置的估算，所以

很难预估出一个特别准确的数字。

在估算服务器需要的 CPU 数量时，除了要考虑以上列出的几个因素外，还可以参考针

对 Oracle 电子商务套件 R12 中影响性能最大的进程配置的推荐值：

1 个 JVM/OC4J 大约能支持 100 个活动用户。

1 个 JVM/Servlet 能支持 100 ～ 250 个 Forms 用户。

理想状态是 1 个 JVM 对应 2 个 CPU，但至少是 1 个 JVM 对应 1 个 CPU。为了达到良好的性能，每台服务器至少有 2 个 CPU。

从实践中得出一条经验：对于 ERP 系统而言，CPU 的数量比 CPU 的主频更重要。

2. 服务器的内存

Oracle 电子商务套件是 B/S 结构，支持多用户并发访问，通过应用服务器的 JVM 支

持用户的访问需求，而且对于每个 Forms 用户都有单独的服务进程进行一对一的服务支

持，以满足前端的瘦客户端访问，所以 Oracle 电子商务套件是内存消耗比较大的应用系统，

OACore 参数配置和 Oaforms Server 数量是影响应用服务器内存大小的主要因素；影响数据

库服务器大小的主要因素是 SGA/PGA 的内存开销。

以下是与 Oracle 电子商务套件 R12 内存相关的一些参考值：

一般来说，每个并发用户的数据库连接会耗用 5 ～ 10 MB 的内存。

应用服务器上每个 Forms 进程大概会占用 5 MB 内存。

根据评估的 ERP 系统规模，估算数据库 SGA、PGA 需要的内存值。

并发管理服务器（Concurrent Manager Server）本身的进程也会占用内存。另外，每

个并发程序的内存耗用情况不尽相同，保守估计为每个并发程序耗用 20 MB 内存。

操作系统至少需要 500 MB ～ 1 GB 的内存。

3. 数据存储空间

数据存储空间的预估是企业架构的重要部分，科学的、真实的空间预估不仅可以保证企

业的 IT 投资的合理性，而且也是保证 ERP 系统正常运转的一个重要环节。对磁盘空间进行


预估，如表 2-3 所示。

表 2-3　磁盘空间需求预估表

内　容数据库服务器应用系统服务器备　注

OS Kernel

Swap

应用产品软件

应用产品日志

应用产品产出物

应用产品补丁

应用产品临时文件

数据库软件

数据库临时空间

数据库 undo 空间

数据库 Redo Logs

数据库归档日志

用户数据日志 /dump

用户数据 DB 使用量

3 年的增加量

损失 10%

磁盘冗余 20%

需要的总容量

注意　以上要求的数据量是能实际使用的数据量，而不是物理磁盘的容量。

2.2.3　硬件资源的预估方法

在国内一些 ERP 实施公司刚刚起步时，由于当时的顾问资源不够丰富，或客户对 ERP的认识有限，导致在项目实施过程中人们往往只注重 ERP 功能或程序的开发，忽略了技术架

构的规划环节。随着中国 IT 业的快速发展，这种现象也在逐渐减少。

在预估硬件资源时，以下两种方法对 ERP 系统的架构的预估非常重要。

1. 利用预估工具

通过前面提到的系统应用规模调研报告，根据客户的模块需求、用户数量以及并发数量

等信息，使用预先制作好的预估工具，计算出硬件资源配置信息，再根据实施顾问的经验，

最后估算出硬件资源配置预估信息。这样的工具在 Oracle 电子商务套件 11i 时已比较完善，

暂时还没发现针对 Oracle 电子商务套件 R12 版本的工具。这些工具一般是由资深的顾问根

据自身经验使用 Excel 工具制作而成的。另外，每个 ERP 厂商都会提供一些 Benchmark，这


些 Benchmark 可以作为很重要的参考依据，并且 ERP 实施商或原厂商一般也都会有类似的

工具，如图 2-2 所示是其中一个资源预估工具的工作界面。

图 2-2　硬件资源预估工具工作界面

2. 计算 tpmC 值

首先，分解 Oracle 电子商务套件的几个关键进程，根据每类进程的特点和数量（如

JVM 和 CPU 数量的关系），以及 OAcore 占用的内存数量，分别计算出每类进程的 tpmC的值；然后结合客户应用的规模数量，计算出数据库和应用系统服务器各自所需要 tpmC的值。而后将计算出来的值和硬件厂商提供的某型号机器能提供的最大 tpmC 值进行比对，

最后确认哪个型号的服务器是满足需求的。具体的 tpmC 值计算方法，请参考官方网站

（http://www.tpc.org）提供的算法。表 2-4 为数据库和应用服务器关键进程的 tpmC 需求值

的样式表。

表 2-4　数据库和应用服务器关键进程的 tpmC 需求值表

内　容数据库服务器 tpmC 应用服务器 tpmC 备　注

操作系统

并发用户

活动用户

并发管理器

并发进程

UNIX/Linux 进程

Oracle 进程


内　容数据库服务器 tpmC 应用服务器 tpmC 备　注

DB SGA/PGA

Forms 服务器

Application 服务器

监控工具

实际使用

冗余率（30%）

需要的总量

注意　用这种方法估算出来的结果只是个理论值，还需要结合实际经验来综合考虑。在实际

操作中，项目实施经验比用公式计算更重要。

2.3　大型 ERP 系统架构涉及的内容

架构一般包括技术架构和业务架构等。对于 ERP DBA 来说，ERP 系统的架构和集成是

需要多方面的大量综合技术知识，同时，技术架构和集成的过程是复杂的系统工程，对实施

人员有很高的技术要求。

大型 ERP 系统架构涉及的领域很广泛，包括存储架构、高可用性架构、网络和客户端

架构、集成架构、系统容灾以及系统管理与监控等内容。本节有针对性地列举一些案例或架

构图，方便大家更进一步理解 Oracle 电子商务套件技术架构。

2.3.1　存储架构

存储设备是整个 ERP 系统架构中的关键部分之一，其中存储了大量的商业数据。存储

设备的选型和架构涉及的技术也比较多，每个配置环节都要尽量做到极致，对于大型的 ERP系统来说，很有可能会因为存储设备的配置不合适而造成严重的性能问题。

针对 ERP 系统，数据库应用是 I/O 密集型的应用，存储设备的速度直接影响应用的响应

速度和系统处理能力。应用服务器虽然对磁盘性能要求并不是特别高，但磁盘处理也可能成

为瓶颈，所以建议将应用程序也放到存储设备上，这样在程序文件的安全性、性能和管理等

方面都有保证。

当前情况下，很多客户已经真实感受到 I/O 是大型 ERP 系统的性能瓶颈，沿用了很久的

传统架构方式，虽然可以通过一些优化手段得到一定的改善，但很难在根本上解决 I/O 性能

问题。

（续）


Oracle 改变思路，颠覆传统的架构方式，早在 2008 年就生产出了世界上最快的数据库

和硬件服务器一体的“数据库云服务器”。相比传统架构，“数据库云服务器”可以至少提高

10% 的性能。Oracle 的“数据库云服务器”是唯一为数据仓库和在线事务处理（OLTP）应

用程序提供了超强性能的数据库服务器，并成为整合到网格或私有云上的理想平台。它是一

个高度可扩展、安全和可容错的功能齐全的软件包。借助 Oracle 的“数据库云服务器”，客

户能够通过整合降低 IT 成本，管理位于多个压缩层上的更多数据，提高所有应用程序的性

能和实时做出更好的业务决策。在全球，已经有大量企业的 Oracle 电子商务套件运行在了

Oracle Exadata 数据库云服务器上，这种架构方式不仅解决了传统架构面临的性能问题，也

符合企业“云计算”的 IT 需求。

2.3.2　高可用性架构

ERP 系统的高可用性是系统架构的一个重要部分，ERP 系统的可靠性和容错能力是保证

企业应用业务连续的基础。系统的高可用性包含如下几个方面：

网络高可用性

存储高可用性

数据库服务器高可用性

应用服务器高可用性

这里只介绍与 ERP 系统关系比较紧密的数据库服务器和应用服务器的高可用性。

1. 数据库服务器的高可用性

一般有两种方案用于保证数据库服务器的高可用性：一种是采用真正的应用集群（Real Application Clusters，RAC），另一种是采用物理服务器的双机热备。后一种架构方式在早些

年有使用，但在现实业务中，采用最多的是 Oracle 相当成熟的真正的应用集群方式。图 2-3所示是针对 Oracle 电子商务套件数据库服务器高可用性的常用架构方式，这种架构方式主要

采用了如下技术：

存储级别采用自动存储管理（Automatic Storage Management，ASM），提供了在

所有磁盘之上的自动负载均衡，从而减少文件系统中的热点，同时大大减少维护

的要求。

使用数据库最新技术—Flashback（闪回），这种不完全的恢复策略可以用于恢复由

于人为错误导致逻辑损坏的数据库。

RAC 的使用做到了系统压力的负载均衡和进程级别的自动故障转移，保证了系统真正

的 7*24 小时高可用需求。

数据卫士（Data Guard，DG）是相当成熟的 ERP 数据库的容灾技术，它的使用进一

步加强了数据库系统的高可用性。


2. 应用服务器的高可用性

在应用服务器层，可以根据需要处理的用户负载的需求安装多台应用服务器，组成应

用层集群，并采用配置平行并行处理（Parallel Concurrent Processing，PCP）来保证并发

管理器的高可用性。当任何一个应用服务器出现突发性硬 / 软件故障时，也可以使用负载

均衡交换机提供的故障转移的能力来屏蔽掉这个服务器而不影响整个系统的运行。图 2-4是 Oracle 电子商务套件应用服务器高可用性的常用架构方式。这种架构方式需要注意以下

几点。

图 2-3　数据库服务器高可用性架构

根据 Oracle 技术支持的相关 Notes，如果 ERP 数据库层采用了 RAC，ERP 应用层也

必须使用多应用的架构方式，并且必须配置 PCP。应用层的高可用性，可以采用硬件设备的负载均衡、多个 Web 服务器的负载均衡、

多个 Forms 服务器的负载均衡以及配置 PCP，根据不同的业务需求，可以单独做某个

层面的负载均衡，也可以做到以上 4 个层面的同时负载均衡。

2.3.3　网络架构

对于大型 ERP 系统而言，需要对网络带宽、防火墙端口、协议等做出具体的规划，不

同的架构方式对网络的需求也不尽相同。因此，具体的需求可以根据访问用户数量、ERP 模

块以及数据量等因素来估算。

特别注意，网络质量是要重点考虑的内容，丢包现象对系统性能的影响是巨大的。


图 2-4　应用服务器高可用性架构

根据公司的应用业务类型、应用模式和使用用户（最终用户）的分布情况，可以有不同

的架构方式。下面介绍三种常见的网络架构方式，具体采用哪种架构要根据每个公司的实际

情况进行规划。

1. 集中式架构

集中式架构是指应用服务器与数据库服务器都部署在公司总部，分公司和下属单位不

安装应用服务器和数据库服务器，而是通过网络与总部的应用服务器连接，从而实现对应

用系统的访问。这种架构方式也符合近几年来很多大系统进行大集中的形势。图 2-5 所示是

Oracle 电子商务套件常见的集中式架构。

机器放在集中机房中所有用户通过浏览器访问

集团公司内部网络

EBS数据库

其他分公司局域网

其他分公司局域网

公司用户

外网用户VPN

http/httpshttp/https

http/https

http/https

VPN/DDN

用户

用户http/https

总公司

图 2-5　Oracle 电子商务套件集中式架构


2. 分布式架构

分布式架构是指公司总部和下属分公司各自采用一套独立的应用系统，分公司应用系

统通过独享网络或 VPN 等方式与公司总部的应用服务器相连接，总部可采用一些技术对各

分公司的数据进行必要的采集，或通过 Oracle Application 各模块的接口，定期将各分公司

的管理信息输出并保存到总部的数据库中。图 2-6 所示是 Oracle 电子商务套件常见的分布

式架构。

外部用户

地区系统局域网局域网

分公司层面分公司层面

地区系统

总部局域网

广域网 / 企业专线

总部系统

总公司

VPN

图 2-6　Oracle 电子商务套件分布式架构

3. 混合式架构

混合式架构是集中式架构与分布式架构的结合，各分公司有各自的应用服务器，而

数据库都集中存放在总部。可以根据实际情况，把一部分应用服务器架构在防火墙内，

把另一部分服务器架构在防火墙外，以满足不同的业务需求。这种架构方式适合云计算

技术。

三种架构方式的优缺点以及应用场景对比如表 2-5 所示。

表 2-5　三种架构方式的优缺点以及应用场景对比表

架构方式优　点缺　点应用场景

集中式

系统配置简单网络配置要求较高　适用于大部分企业，并且只是在

内部网络内访问实施简易及维护成本低廉实施成本和维护成本高

总部可以集中管理需较大数据库及硬件设备

分布式网络配置要求低系统须多次安装

　用这个架构不多系统响应速度快成本及硬件维护成本高

混合式介于前两者之间介于前两者之间　适用于大部分企业


2.3.4　客户端架构

客户端架构主要考虑 ERP 最终用户访问 ERP 系统的 PC 的硬件资源配置、浏览器的版

本是否符合 ERP 版本要求，以及是否有防火墙的限制。

2.3.5　集成架构

集成架构是指为实现系统集成所需要的组件、组件的作用以及组件之间的相互关系。可

以通过各种集成架构组成以 ERP 系统为主线，贯通关键业务流程和业务数据的整个企业的管

理系统。

针对 Oracle 电子商务套件产品，Oracle 有很完善的集成架构和大量的最佳实践。除了

可以采用 Oracle 的 AIA、BEPL、SOA 等解决方案，还可以采用其他的解决方案（如 IBM Tivoli、IBM WebSphere 等）与 Oracle 电子商务套件集成。下面介绍几种比较常用的集成

方式。

1. 应用集成架构

针对客户的企业应用集成需求，Oracle 应用集成架构（Applications Integration Architecture，AIA）解决方案预制业务流程包，由于无需再进行大量的开发工作，客户在应用集成类项目中可

以减少实施成本、缩短实施时间、降低实施风险。

Oracle 应用集成架构充分利用业界最好的基于标准的 SOA 中间件平台，是通过大量的

最佳实践过程而形成的解决方案，其主要产品包括：

最佳业务实践、验证的业务流程、企业业务服务和业务对象。

SOA 参考架构、SOA 编程模型、SOA 管控、SOA 服务资产库等。

预制的业务流程集成包、集成基础架构包。

对于大部分顾问而言，在做系统集成时，最常用到的有 BPEL（流程管理器）、ESB（企

业服务总线）。其实，这些产品是 Oracle 融合中间件产品中的一部分，Oracle 应用集成架构

构建在 Oracle 融合中间件之上，是集成技术的进一步延伸和完善。图 2-7 所示是应用集成架

构和融合中间件的关系以及其中的关键产品。

Oracle 应用集成架构具有如下特点：

直接集成 (DI)：在两个应用之间预置的紧耦合集成解决方案。

流程集成包 (PIP) ：跨多个应用产品，基于预置的复杂业务流程集成，具有很高的可

配置性和扩展性。

基础包 (FP)：预置的一套企业业务服务 EBS 和企业业务对象 EBO，通过 SOA 的编程

建模创建复杂的业务流程。


“可控告的”用户和 EBS 职责的定期审查。

用纠正来预防和侦测 SoD（IDM 和 GRC）。

针对 EBS 形式 / 域级的严密的访问控制。

图 2-10 所示是 Oracle 电子商务套件与 Oracle IDM 产品家族中的 Oracle Access Manager集成。

登录界面

外网＆内网 SSO

自助服务注册

审计用户访问

可选的、“紧固的”、更强大的认证

员工

“ ”

图 2-10　Oracle 电子商务套件与 Oracle IDM 产品家族中的 Oracle Access Manager 集成

5. 与 Oracle BI Publisher 集成

Oracle BI Publisher 以前称为 XML Publisher，是一个企业报表解决方案，可创建、管理

和提供各种类型的高度格式化的文档，已在 Oracle 电子商务套件中广泛使用。自 Oracle 电

子商务套件 R12.1 版本开始，标准的报表都已经转换成了 BI Publisher 的报表，无疑大大

减少了客户化开发的数量，同时可以提供高质量的报表输出。BI Publisher 主要具有如下的

特点：

报表可灵活输出所需要的文档格式，例如 Excel、PDF、HTML、rft。业务人员可随时修改报表布局。

降低报表维护和重开发成本。

可以利用任何数据源，并发布到任何目的地输出。

图 2-11 所示是 Oracle 电子商务套件与 Oracle BI Publisher 的集成。

注意　 Oracle 电子商务套件也可以与其他非 Oracle 的产品集成。实际业务中，集成比较多的

有 IBM WebSphere 、IBM Tivoli 安全管理等。


2.3.7　备份与恢复规划

如果出现类似于系统崩溃的灾难，就必须对数据库和应用进行恢复，恢复是否成功取决

于两个因素：精确性和及时性。能够进行什么样的恢复依赖于有什么样的备份。应用出现问

题的可能性并不大，基本上都是以文件的形式进行备份的。

1. 备份的重要性和目的

备份是系统管理中需要考虑的最重要的事项之一。备份的工作量在系统的整个规划、开

发和测试过程中虽然还占不到 1%，看似不太重要，但只有到需要恢复数据时才能真正体现

出它的重要性。任何数据的丢失和长时间的宕机都是不允许的。如果备份不能提供恢复时必

需的信息，使得恢复过程不能进行或需要很长的时间来进行，这样的备份（如一个没有经过

严格测试的备份方案）都不能算是一个好的备份。

备份的目的如下：

防止数据灾难。

缩短停机时间。

保证数据安全。

方便服务器硬件升级。

方便应用系统升级。

方便应用系统打补丁。

备份的最终目的是能够恢复，备份大于一切。备份不仅是企业 IT 的管理制度，更是每

个 ERP DBA 要养成的良好习惯。

2. 备份策略

我们应该制定日常备份制度，综合考虑备份时间和数据恢复的时间，正确选择适合企业

需求的备份内容、频率和方法。最好将备份磁带存放在企业的主要办公地点以外的地方，这

样，当主要办公地点遭受自然灾难时，数据备份仍然是安全的。此外，还需要针对所有备份

演练数据恢复，确保备份的有效性。

大型的 ERP 系统都会根据自身的业务需求制定备份策略。如下的备份策略供大家参考：

日与周的备份：这是为了确保在系统出现物理和逻辑上的故障后，可以快速地恢复到

故障时间点之前的状态，为生产系统数据提供有效的数据备份。即在每周一到周六的

晚上对每套生产系统进行数据库的增量备份，每周日进行数据库的全备份。

月的备份：这是在月结完成后，进行一次数据库的全备份。

年的备份：一般是在每年的财年结束后，找一个合适的时间，对系统进行全备份，以

备以后查找历史数据时使用。


注意　对于所用的第三方备份软件自身的数据库，也要定时备份并保存到异地。

3. 备份和恢复管理

对于每套生产系统，为了保障备份到磁带库中的数据库备份可以正确恢复，应每月进行

一次恢复测试，一方面可以确认磁带库中的数据是否有效，另一方面可以模拟数据库故障，

熟悉恢复的流程，以便当生产系统真正出现问题的时候可以快速恢复，所以建议建立定期恢

复测试流程。

备份和恢复测试管理是我们日常工作中必不可少的环节。有效的管理是系统正常运转的

保证和基础。表 2-6 ～表 2-9 是备份和恢复管理相关的样式表格。

表 2-6　备份时间调度（周，日）

系统名全备份时间增量备份时间归档日志备份时间保留周期数据总量

表 2-7　备份时间调度（月）

系统名备份时间保留周期备份数据总量估计

表 2-8　备份时间调度（年）

系统名月备份时间（全备份）保留周期（保留版本数）备份数据总量估计

表 2-9　恢复记录（包括恢复测试）

系统名恢复测试时间

2.3.8　容灾架构

对于 ERP 系统，建立有效的容灾机制是必要的。根据不同的 ERP 规模以及业务的重要

性等因素，可以采用不同的方法进行容灾，例如，最简单的容灾是每天或定期把备份磁带存

放到异地，对于复杂的容灾体系的建立需要作为一个大的项目规划来进行。

针对 Oracle 电子商务套件，实际业务中用的最多的容灾方案是通过数据卫士（Data Guard）的架构方式。而业界常用的容灾软件 Oracle GoldenGate，暂时还没被 Oracle 电子

商务套件认证为容灾工具，但可以使用 GoldenGate 的复制功能在第二个独立的 EBS 系统


实现某些业务需求，如实现业务报表的展示功能。Oracle 电子商务套件容灾架构如图 2-13所示。

图 2-13　Oracle 电子商务套件容灾架构

2.3.9　系统管理与监控

系统管理和监控是保证 ERP 系统正常运行的重要组成部分，主要完成如下几个方面的

工作：

整体监控

系统管理

数据库管理

应用管理

网络管理

备份与恢复

Oracle 电子商务套件除了自带多种管理工具外，还可以无缝集成 Oracle 企业管理器

（Enterprise Manager）和针对 Oracle 电子商务套件的两个管理包—ACM（Application Change Management Pack）和 AMP（Application Management Pack），全面管理 ERP 系统。

有关 Oracle 电子商务套件自带工具的作用和配置，将在第 5 章进行详细介绍。

通过 Oracle 企业管理器以及集成的 ACM、AMP 管理包，进一步扩展了 Oracle 电子商

务套件的管理功能，关键的功能包括：

自动化的系统查看及管理。

服务级别监控。


为常识了解：

核心环境（Master environment）。这个环境主要用作管理和配置工作，其中并没有任

何的交易数据。

开发环境（Development environment）。这个环境主要用于开发人员的开发、设计以

及客户化程序的定制。在这个环境中开发人员往往具有类似系统管理员的权限。

测试环境（Testing environment）。这个环境也叫做 UAT 环境，开发人员一般没有

APPS 的密码权限，主要测试用户定制和配置的变化。

部署环境（Deployment environment）。一旦完成 UAT 的测试，就可以把这个环境定

为部署环境，它是上线前的系统，主要用于有效地应用补丁、部署实例。

补丁测试环境（Patching environment）。这个环境专门用作测试补丁的修改，以及系

统的升级等。补丁文件可以在 Oracle 支持网站上下载，并由 Apps DBA 去执行。

支持环境（Support environment）。如果一个生产系统存在一些问题，需要 Oracle 的

技术支持，则支持环境可以用做这个用途。

CRP 环境（CRP environment）。CRP 是 Conference Room Pilot 的缩写，可以直

接翻译为：会议室模拟。在基本掌握软件功能的基础上，选择对应的模块，将各

种必要的数据录入系统，带着企业日常工作中经常遇到的问题，组织项目小组进

行实战性模拟，提出解决方案。CRP 就是在会议室里进行一项“试验”，采用真正

的流程、模拟的数据来验证系统是否符合企业的流程；记录出现的问题，研究解

决方案。

移植环境（Migration environment）。这个环境只有在特殊情况下才会出现，例如

Oracle E-Business Suite 11i 到 R12 这样大版本的升级；不同的硬件平台的迁移（从

IBM AIX 迁移到 Linux 系统）；也可用作开发人员从原始的系统向 Oracle E-Business Suite 数据迁移。

生产环境（Production environment）。生产环境在所有环境中扮演着最重要的角色，

企业的日常业务都会运行在这个环境中。

2.5　本章小结

本章主要概述 ERP 系统的规划思路、架构设计的原则以及硬件资源配置估算的方法。

通过对存储架构、网络、客户端架构、集成架构、系统容灾以及系统管理与监控的概述，让

大家了解大型 ERP 系统架构涉及的领域和内容，并有针对性地列举一些案例或架构图，方便

读者更进一步理解 Oracle 电子商务套件的技术架构。

作为 ERP DBA，不仅要掌握 ERP 紧密相关的数据库、应用等技能，还要对 ERP 系统涉

及的技术有一定的理解；平时也要经常和业务关联的顾问及时沟通和联络，只有这样才能做


到游刃有余。

系统架构需要大量的经验，而经验要在大量实践的基础上积累。经验的积累需要我们付

出努力，还要注重方法。思路和技能同样重要。笔者总结出一句话，和大家一起共勉：

“以销售的思维思考技术，以客户的需求操作技术，以非专业的角度讲解技术，以批判

的眼光研究技术。”

ERP 系统规划 - Baiduimages.china-pub.com/ebook3660001-3665000/3661050/ch02.pdf1 个JVM/Servlet...

Documents

Transcript of ERP 系统规划 - Baiduimages.china-pub.com/ebook3660001-3665000/3661050/ch02.pdf1 个JVM/Servlet...