【信息化-精编】公司数据中心ERP和EHR升级改造项目技术文件

公司数据中心ERP和EHR升级改造项目技

术文件

上海保利协鑫电力运行管理有限公司太仓数据中心ERP和E-HR升级改造项目

技

术

文

件

（正本）

南京科技有限公司

2014年9月

目录

第一章项目概述7

1.1.建设目的7

1.2.系统现状7

1.2.1.ERP、E-HR数据库服务器现状7

1.3.存在问题7

1.3.1.性能不足7

1.3.

2.安全风险8

1.3.3.存储空间不足8

第二章方案设计8

2.1.设计目标8

2.1.1.建立稳定的冗余负载均衡数据库服务环境，减少全年业务中断时间。8

2.1.2.提高数据库的服务性能，满足业务部门不断提高的性能要求。9

2.1.

3.部署全面覆盖、自动执行的备份体系，同时消减历年累计的各类安全问题。9 2.2.规范标准9

2.3.设计原则9

2.3.1.技术先进性9

2.3.2.标准化10

2.3.3.可扩展性10

2.3.4.可用性10

2.3.5.兼容性10

2.3.6.可靠性10

2.3.7.冗余性10

2.3.8.容错性10

2.4.解决问题11

2.4.1.安全风险解决11

2.4.2.性能不足解决11

2.4.

3.存储空间解决12

2.5.设备环境12

2.5.1.目前拓扑环境12

2.5.2.改造后拓扑环境12

2.5.

3.目前已有设备12

2.5.4.改造需增加设备及服务14

2.6.改造升级15

2.6.1.在新设备安装AIX7.1并搭建数据库11G rac的测试环境，协同ERP、E-HR开发人员和业务使用人员，对11G环境下的ERP和E-HR业务应用进行业务稳定性测试（测试内容由业务部门定制），并将测试结果反馈本项目人员。如长时间测试无法解决问题，则继续使用原有10G。15

2.6.2.搭建数据库服务器和存储系统新环境，aix系统采用7.1，数据库为oracle11G，搭建数据库rac结构，导入正式库数据库数据，并建立备份环境，进行业务稳定性测试。15

2.6.

3.测试正常后，暂停ERP和E-HR服务，将ERP和E-HR最新数据库在线迁移至新环境，测试无误后，正式上线并对外提供服务。15

2.6.4.将原有系统和存储重新配置，安装Aix7.1系统和oracle 11g rac，导入正式库数据库数据进行测试，测试新环境对E-HR和ERP的运行支持的稳定性。15

2.6.5.测试正常后，暂停新系统中的E-HR服务，导入E-HR最新数据库至旧环境，测试无误后，正式上线并对外提供服务。15

2.6.6.完善现有的备份体系，移植和完善集团和电力现有虚拟化平台。15

2.6.7.从方案上要保证整个实施的零风险，而不仅仅是从操作方法上降低风险。尽量缩短业务的停顿时间。迁移过程中要保证现有系统状态不受影响，一旦迁移出现任何异常，都能够立即终止迁移动作，并将业务切换到原有状态，保证数据及业务的安全。将整个实施流程分割成多个操作单元，操作单元之间的关联性很小，一个操作单元的实施结果不会对另一个实施单元造成影响。操作单元内的操作要做到简单可控。15

2.7.数据库在线迁移和升级16

2.7.1.任务16

2.7.2.现状17

2.7.

3.前期准备18

2.7.4.迁移演练19

2.7.5.迁移步骤20

2.7.6.数据验证21

2.7.7.迁移回退22

2.8.配套的升级改造23

2.8.1.小机AIX23

2.8.2.存储25

2.8.

3.备份25

2.8.4.虚拟化26

第三章项目管理26 3.1.文档管理26

3.1.1.项目资料文档：26 3.1.2.实施安装文档：27 3.2.组织管理28

3.2.1.项目领导小组28 3.2.2.项目实施小组28 3.2.3.测试验收小组28 3.2.

4.质量管理小组28 3.3.过程管理29

3.3.1.设备采购29

3.3.2.安装准备29

3.3.3.安装调试29

3.4.进度管理29

3.4.1.到货进度29

3.4.2.实施进度30

3.5.质量管理30

3.6.安全管理31

3.6.1.思想保证体系31 3.6.2.组织保证体系31 3.6.3.工作保证体系31 3.7.阶段管理31

3.7.1.准备阶段31

3.7.2.实施阶段31

3.7.3.验收阶段31

3.8.联络管理32

3.9.实施管理32

3.9.1.实施步骤32

3.9.2.实施周期33

3.9.3.实施人员34

3.10.流程管理38

3.10.1.安装流程38

3.10.2.测试流程44

3.10.3.验收流程46

第四章客户培训49

4.1.培训体系49

4.1.1.培训安排49

4.1.2.培训计划50

4.2.现场培训51

4.3.课程培训51

4.3.1.AIX培训51

4.3.2.ORACLE培训52

4.3.3.培训计划和内容52

第五章支持服务53

5.1.售后支持53

5.1.1.科技客户服务优势53

5.1.2.科技客户服务简介53

5.1.3.售后服务体系综述54

5.2.服务承诺56

5.2.1.产品保修56

5.2.2.维护和咨询58

5.2.3.设备统计和巡检服务58 5.2.4.支持服务61

5.3.服务响应61

5.3.1.电话响应61

5.3.2.Internet与电子邮件响应61 5.3.3.远程维护响应61

5.3.4.现场服务响应61

第六章产品清单62

第一章项目概述

1.1.建设目的

本次信息化改造项目招标为已有的ERP及E-HR的基础上，对当前系统应用进行相应的冗余负载均衡升级改造，并完成相关配套调整，以保障协鑫ERP 和E-HR系统健康运行。

通过在太仓数据中心对ERP和E-HR系统进行升级，调整相关配套设备和服务，将在太仓建立高效稳定的ERP和E-HR应用。

1.2.系统现状

1.2.1.ERP、E-HR数据库服务器现状

1.2.1.1.ERP和E-HR数据库肩负着协鑫电力ERP应用和全集团E-HR应用的后台数据库服务任务，属于最关键的核心业务之一，但目前设备陈旧、版本过低，面临越来越高的风险。

1.2.1.2.ERP和E-HR应用服务器去年已完成更新换代和升级，改善了ERP和E-HR的访问性能，但随着ERP和E-HR业务的快速扩充，特别是E-HR档案模块上线和后续各类开发，引发了数据库的各类故障和bug，数据库低版本和硬件性能不足越来越成为一块短板，拉低了整体性能和稳定性。

1.2.1.3.鉴于数据库服务器已成为故障的根源，经集团信息部、协鑫电力信息部、厂商联合调查讨论后，认为升级改造数据库硬件和软件是解决问题的根本办法。

1.3.存在问题

1.3.1.性能不足

如上图所示：集团ERP和E-HR数据库为同一数据库，负载不大的情况下可正常运行，但月末和月初集中核算期间，ERP和E-HR处于高负载运行，互相抢占数据库和存储带宽，会造成ERP和E-HR访问性能急剧下降；此外，这种

模式也会对权限划分、后期维护造成负面影响，其故障判断和恢复也造成很大延误。

1.3.

2.安全风险

1.3.

2.1.两台数据库服务器迄今已服役八年，其宕机风险也越来越大。

1.3.

2.2.目前oracle厂商最新版本为oracle12C，而当前的10G版本近期将停止技术支持；操作系统的AIX系统版本为低版本的5.3，其安全性和版本支持性问题也在逐渐凸显。

1.3.

2.

3.目前Oracle数据库无有效维保，所有维护和故障处理全靠内部IT人员自行查找和解决，无厂商的技术支持。

1.3.

2.4.Symantec备份体系只包含现有ERP和E-HR数据库环境，应用环境和其他关键服务采用第三方软件组合，可靠性差。

1.3.3.存储空间不足

1.3.3.1.现有数据量呈爆发性增长，剩余空间已远远无法满足后续使用需求，以ERP和E-HR生产数据库为例，2013年初数据库的占用空间为250G，但截至2014年5月，数据量达到600G，其中，主要的增长是由于E-HR的扫描件上传引起，按照每年近400G增长量，考虑到后续3-5年，须预备2T空间，而对应的备份空间需要8T。另外，考虑到业内虚拟化主流趋势和协鑫数据中心规划，未来服务器将尽量不再采购，但存储空间要求相应提高，仅参考目前要建立数据库测试环境、PM环境、SIS环境、虚拟化平台和其他关键应用，须预备10T空间；最后，考虑到徐州数据中心灾备，预留10T空间，合计30T空间的使用需求。

第二章方案设计

2.1.设计目标

2.1.1.建立稳定的冗余负载均衡数据库服务环境，减少全年业务中断时间。

2.1.2.提高数据库的服务性能，满足业务部门不断提高的性能要求。

2.1.

3.部署全面覆盖、自动执行的备份体系，同时消减历年累计的各类安全问题。

2.2.规范标准

本技术方案中涉及的所有规范、标准或材料规格（包括一切有效的补充或附录）均为最新版本，即以招标人发出本信息系统定单之日作为采用最新版本的截止日期。系统中所有设备的设计，检查，试验及特性除本规范中规定的特别标准外，都遵照适用的最新版中国国家标准（GB）及电力行业（DL）标准，以及国际单位制（SI）。我方提出的等同标准应不低于招标人要求的标准并征得招标人的认可，本方案遵循的标准包括：

?IEC国际电工学会

?AIEE美国电气电子工程师协会

?ANSI美国国家标准化协会

?NEC美国国家电气标准

?ISO国际标准化组织

?TCP/IP系统传输控制协议和接口程序

?IEEE802局域网协议标准

?电磁学规范：FCCClass.A、FCCClass.B或CISPR22Class.B

?安全规范：ULListed（美国）或EN60950(国际)

?质量标准：ISO9000认证

?智能终端、显示器等设备应符合能源之星(EPA)标准

2.3.设计原则

建设原则按照“统一设计，分步实施”。

2.3.1.技术先进性

当今世界，通信和计算机技术的发展日新月异，我们的方案应该适应新技术发展的潮流，既要保证系统的先进性，同时又要确保各项技术的成熟性。

2.3.2.标准化

计算机管理信息系统就是要实现系统及设备资源的共享，把不同厂商的设备和计算机软件进行互连。在一个复杂的大型系统系统里，必然有多个厂商的硬件及软件，为了保证用户的计算机系统系统具有互操作性、可用性、可靠性、可扩充性、可管理性，需要建立一个开放式、遵循国际标准的系统系统。

2.3.3.可扩展性

由于用户业务的不断发展，系统系统必然随之不断扩大，为此，目前的系统设计必然为今后的扩充留有足够的余地，以保护用户的投资，并且不影响原有用户的工作。

2.3.4.可用性

由于本系统对于数据的时效性、可靠性要求较高，因此在设计时应重点考虑系统及设备的可用性。我们的方案要充分考虑用户的费用情况，不但理论上可行，更重要的是实际上可用，最好地适应用户的需要。

2.3.5.兼容性

系统结构有良好的兼容性，能够实现与不同类型的子网的无缝连接。

2.3.6.可靠性

为使系统可靠地运行，我们方案中要选用高品质的产品，把故障率降到最小。

2.3.7.冗余性

在设计时应考虑为系统留有适当的冗余度，硬件设备应具备一定的冗余模块，以提高系统容错能力。

2.3.8.容错性

设备容错性：所选用设备必须具有全容错结构，一台设备中单个电源、单个风扇的故障不影响设备工作，单个模块的故障不影响其它模块的正常工作；设备应具有热修复能力，即当设备的某些部件发生故障时，可以带电更换而不影响设备其它部件工作，新更换部件可直接投入工作而不必重新引导整个设备。2.4.解决问题

2.4.1.安全风险解决

2.4.1.1.新购2台IBMP740小型机服务器，将数据库实例从现有超期服役数据库服务器中分离出来，并使用双实例进行交叉负载均衡

2.4.1.2.数据库升级：测试并升级至11G版本

2.4.1.

3.AIX系统升级：测试并升级至7.1版本

2.4.1.4.数据迁移：重新安装和部署数据库系统，并将现有ERP数据迁移至新系统。

2.4.1.5.原有环境：原有数据库体系也升级至11G，重新分配存储空间和备份空间后搭建冗余负载均衡体系，导入E-HR生产数据。

2.4.1.6.维保支持：远程技术支持、版本升级、现场灾难恢复等服务。

2.4.1.7.数据备份:现有SymantecNBU存储备份软件已过期，升级费用很高，为节省成本，计划不再购买新License，而通过第三方重新建立数据库系统和其他系统的硬盘和磁带库备份体系。

2.4.1.8.灾难恢复：实际测试并履行一次灾难恢复演练，形成评估报告。

2.4.2.性能不足解决

2.4.2.1.针对资源占用性能不足的问题，本次项目对ERP和E-HR数据库进行分离，ERP系统数据库从原来的数据库中迁移到新的数据库环境，E-HR继续使用现有数据库环境，并且通过对数据库和操作系统的升级改造提高两套系统的性能和稳定性，拓扑图如下：

2.4.

3.存储空间解决

2.4.

3.1.为满足存储需要，存储设备须可用容量30T，考虑到性价比原则，将ERP、SIS、PM等高等级数据存储在快盘柜，使用900G10KSAS盘，可用存储空间达到9T；低等级慢盘柜使用4T7200SAS硬盘，存储空间20T，规划存储各类关键系统的虚拟化平台、本地和远程灾备等内容。

2.5.设备环境

2.5.1.目前拓扑环境

2.5.2.改造后拓扑环境

2.5.

3.目前已有设备

2.5.4.改造需增加设备及服务

2.6.改造升级

2.6.1.在新设备安装AIX7.1并搭建数据库11Grac的测试环境，协同ERP、E-HR开发人员和业务使用人员，对11G环境下的ERP和E-HR业务应用进行业务稳定性测试（测试内容由业务部门定制），并将测试结果反馈本项目人员。如长时间测试无法解决问题，则继续使用原有10G。

2.6.2.搭建数据库服务器和存储系统新环境，aix系统采用7.1，数据库为oracle11G，搭建数据库rac结构，导入正式库数据库数据，并建立备份环境，进行业务稳定性测试。

2.6.

3.测试正常后，暂停ERP和E-HR服务，将ERP和E-HR最新数据库在线迁移至新环境，测试无误后，正式上线并对外提供服务。

2.6.4.将原有系统和存储重新配置，安装Aix7.1系统和oracle11grac，导入正式库数据库数据进行测试，测试新环境对E-HR和ERP的运行支持的稳定性。

2.6.5.测试正常后，暂停新系统中的E-HR服务，导入E-HR最新数据库至旧环境，测试无误后，正式上线并对外提供服务。

2.6.6.完善现有的备份体系，移植和完善集团和电力现有虚拟化平台。

2.6.7.从方案上要保证整个实施的零风险，而不仅仅是从操作方法上降低风险。尽量缩短业务的停顿时间。迁移过程中要保证现有系统状态不受影响，一旦迁移出现任何异常，都能够立即终止迁移动作，并将业务切换到原有状态，保证数据及业务的安全。将整个实施流程分割成多个操作单元，操作单元之间的关联性很小，一个操作单元的实施结果不会对另一个实施单元造成影响。操作单元内的操作要做到简单可控。

2.7.数据库在线迁移和升级

2.7.1.任务

需要将数据库从当前现有平台迁移到新系统平台。相应的流程规划如下：

2.7.2.现状

2.7.2.1.数据量大

数据库table比较多，数据量比较大，索引、Lob数据也比较大。

2.7.2.2.跨平台

此次迁移即是将数据库从AIX5.3主机迁移至AIX7.1主机。

2.7.2.

3.跨数据库版本

从oracle10gRAC迁移到oracle11gRAC。

2.7.2.4.停机时间有限

有数目前数据库是核心系统，迁移时间有限。

2.7.2.5.数据准确性要求高

由于是数据库记录的都是重要信息。如果出现数据准确性问题，将导致整个数据库系统的紊乱。

因此，此次迁移工作具有“跨平台，跨数据库版本，大数据量，停机时间短，数据准确性要求高”

2.7.

3.前期准备

根据前期的调研工作,提供数据迁移步骤。

2.7.

3.1.数据库层面

2.7.

3.1.1.原库准备

?清理/区分无用的表

?整理出可以不停应用，预先迁移的历史、静态表（以下称第一阶段迁移的表）的列表

?整理出需要停应用才能迁移的其它表（以下称第二阶段迁移的表）的列表

?整理出第二阶段迁移的表的索引以及约束的ddl，并修改nologging以及并行属性

2.7.

3.1.2.新库准备

?为导入及建索引优化调整新库的参数：

?加大pga到8～12GB

?加大undo到100GB/实例

?加大db_

?加大sort_area_size参数

?设置非归档模式

?新库的表空间名与大小要与原库完全一致

?导入生产库的所有用户schema的空结构（不导入数据），完成表、索引、约束、sequence、trigger、procedure、package、databaselink等的创建，注意进行第二阶迁移前需先drop第二阶段迁移的表的索引和约束，另外所有的用户sequence在第二阶段迁移完成后需要重建。

?修改所有表的属性为nologging

?禁用所有约束

?建立到原库的databaselink

2.7.

3.2.应用层面

搭建基于新库的应用环境，在新库上测试应用

2.7.4.迁移演练

迁移前的充分演练非常重要：

?最大限度的优化迁移步骤

?比较真实的评估各迁移步骤的消耗时间

?了解基于新库的应用是否能正常运行

2.7.4.1.从生产库导出空结构到新库

用于在新库创建所有用户、表及附属对象的定义。

2.7.4.2.测试基于新库的应用是否正常

经确定迁移演练已经完成后，并且数据已经全部迁移到新的平台数据库中，在应用层面的功能性测试，目前没有发现异常情况。（全业务测试覆盖表）底层的数据验证工作：首先对表的数据进行count，如果两边count一致，再做minus比对。如果count不一致，默认为失败。在比对过程中，处理出错的表。

2.7.5.迁移步骤

根据前期迁移演练的结果，迁移步骤如下：

2.7.5.1.数据初始化同步：

在原系统业务不中断的情况下，依次将原系统中的所有表（Table）中的记录复制到新系统的对应表（Table）中去。该过程需要时间较长，根据前期测试的情况，迁移顺利和所需时间估计如下；

根据当前系统估算同步的时间：

中出现的问题进行处理。以上总需要多少时间。

2.7.5.2.增量数据同步：

将在大数据量同步过程中新增加的记录复制到新系统上，并且在割接前保持新系统与原系统的记录实时同步；

根据业务的需求，分成3套以上分别复制，防止增量日志太大，分析跟不上： 静态数据、