上海电信ODS系统数据库升级项目测试方案V.docx
《上海电信ODS系统数据库升级项目测试方案V.docx》由会员分享，可在线阅读，更多相关《上海电信ODS系统数据库升级项目测试方案V.docx（19页珍藏版）》请在冰豆网上搜索。
上海电信ODS系统数据库升级项目测试方案V
*******************************上海电信ODS系统
数据库升级测试方案
*******************************
2010-12-16
第1章项目概述
上海电信ODS系统作为上海电信MBOSS信息整合项目的一个重要组成部分，存储上海电信的运营数据，包含客户、产品、计费和资源（业务资源）主题域，支撑上海电信的客户经理和管理层所需的经营和客户数据的分析和统计工作。
自2004年上线运行以来，新业务的涌现以及电信需求的不断增加要求ODS系统不断向前发展。
而现有的系统从硬件环境和数据库环境等各方面，都已经不能满足用户对于该系统的需要，主要存在的问题包括：
❑数据库版本过低，ORACLE原厂商将停止保修
❑服务器老化，维保费用高昂
目前上海电信ODS系统数据库服务器使用的是IBMP5-590和P5-690小型机，590和690耗电量巨大，原厂商的设备维保费用高昂，如果继续使用上述服务器用于生产环境，从成本角度，是不经济的，从节能角度，是不环保的，从性能角度看，IBMP5的性能远不如P6。
基于以上因素，上海电信购买了两台满配的P6-570，计划用于替换先前的ODS数据库服务器，通过硬件的升级，从而进一步提高系统的稳定性和用户响应速度。
1.1本文目的
本文主要是对上海电信ODS系统数据库升级项目的实施方案描述，对项目实施中的涉及系统的迁移及扩容等提供依据。
1.2本文读者
上海电信ODS系统数据库升级项目相关人员，包括上海电信IT部和理想公司相关人员。
1.3参考资料
《上海电信ODS系统数据库升级项目实施方案V6.0.rar》
1.4Oracle升级对周围IT系统的要求
ODS数据库软件Oracle从原先9i升级到11g后，ODS其它软件也需要进行相应版本升级，才能支持Oracle11g。
目前ODS的生产软件对Oracle的支持与否已经得到厂商的正式回复，简述如下：
●报表展现工具：
Businessobjects（BO）
目前版本不支持Oracle11g
目前使用版本：
enterprise11.0 ReleaseI和ReleaseII
需要升级到的版本：
BusinessObjectsXIR3（servicePacket3.1）
QLinkView（QV）
目前版本支持Oracle11g。
但仍需测试。
●ETL开发工具：
Informaitca
目前版本不支持Oracle11g
目前使用版本：
InformaitcaPowerCenter851
需要升级到的版本：
InformaitcaPowerCenter861
BO、QV和Informaitca是ODS部门IT开发的主要工具，是维持ODS生产经营的重要基础。
这些工具的升级，需要谨慎和细致的测试工作。
由于这三个工具紧密结合数据库，所以测试工作必须在Oracle升级完成后展开，测试步骤见第2章。
BO和Informaitca升级后的新版本软件需要有硬件服务器来运行。
建议配置两台服务器，一台给BO，一台给Informaitca。
新版本Informaitca服务器的配置建议参考现有ETL服务器配置，如下：
IBMpSeries67016CPU/64GB
新版本BO服务器的配置建议参考现有ETL服务器配置，如下：
IBMx4458CPU/32GB
第2章上海电信ODS数据库升级测试方案
2.1测试方案流程
★测试前准备工作：
（1）各类迁移或受升级影响的程序的统计整理，整改。
统计采用自主申报和无主认领相结合的方式展开。
首先让ODS各个小组将各自负责的程序按照模板上报，由DBA审核。
第二步是对无主程序的认领。
具体见”SP/function/Package程序的迁移”小节的描述信息。
（2）搭建Oracle11g的测试环境。
具体步骤见《上海电信ODS系统数据库升级项目实施方案V6.0.rar》
（3）新建ETL测试环境（版本：
InformaitcaPowerCenter861）、新建BO测试环境（版本：
BusinessObjectsXIR3），准备QV测试环境。
（4）把ODSPD上的程序迁移部署到该测试环境中，然后复制原数据库的生产数据的一部分到测试数据库环境中
（5）在ETL测试环境部署受升级影响的ETL进程
（6）在BO，QV测试环境部署相关程序
★测试步骤：
●Oracle11G数据库升级测试
（1）在新环境测试迁移的Oracle程序。
（2）运行测试完后，数据比对。
若数据比对未通过，查找原因并予以解决。
（3）在新环境对Oracle程序进行大数据量加载的性能测试，若性能测试不合格，查找原因并予以解决。
（4）在ETL测试环境测试受升级影响的ETL进程。
（5）运行测试完后，数据比对。
若数据比对未通过，查找原因并予以解决。
（6）大数据量性能测试，若性能测试不合格，查找原因并予以解决。
（7）在BO，QV测试环境运行测试程序。
（8）在BO，QV测试环境，IT或业务部门查看报表是否正常。
若不正常，则查找原因并予以解决。
（9）Oracle11G数据库升级测试完毕
Oracle11G数据库升级完毕后：
●InformaitcaPowerCenter861升级测试
（1）在ETL新环境测试和部署在Oracle11G数据库升级阶段未测试过的ETL进程。
（2）运行测试完后，数据比对。
若数据比对未通过，查找原因并予以解决。
（3）InformaitcaPowerCenter861升级测试完成。
●BusinessObjectsXIR3（ServicePack3.1）升级测试
（1）在BO新环境测试和部署在Oracle11G数据库升级阶段未测试过的BO进程。
（2）运行测试完后，数据比对。
若数据比对未通过，查找原因并予以解决。
（3）BusinessObjectsXIR3（ServicePack3.1）升级测试完成。
●测试方案流程示意图：
2.2SP/function/Package程序的迁移、修改和验证
●SP/function/Package程序的迁移
◆所有的SP/function/Package程序由程序员填写迁移申请表
申请表记录下列信息：
申请人、申请日期、SP/function/Package的名称、环境（用户名）、项目组、程序用途（业务背景、逻辑等）、程序源表、程序目标表、程序上线日期、程序运行时间点、程序运行周期。
◆EDA架构师团队对所有申请的SP/function/Package进行审核
审核的内容包括：
该SP/function/Package是否还有效，无效的SP/function/Package将不迁移，但由DBA做好备份；
该SP/function/Package是否符合EDA的代码规范；
该SP/function/Package是否需要变更运行环境；
该SP/function/Package是否需要做其他修改。
◆审核通过的该SP/function/Package由DBA发布到新的服务器上
◆审核不通过的该SP/function/Package，给出整改意见，整改通过后发布
◆无人认领SP/function/Package的处理
DBA整理出所有没有人提出迁移申请的SP/function/Package，提交EDA架构师团队做第1步分析，是否该SP/function/Package是否有效；
如果认定有效，则由DBA发布，并指定程序负责人；
如果认定无效，群发给EDA所有人员公示1周，若还无人认领，则作为无效SP/function/Package处理；
如果认定有效但需要做修改，则指定程序负责人，给出整改意见，整改通过后发布。
●SP/function/Package程序的修改
EDA架构师团队审核不通过的SP/function/Package，给出整改意见，提交程序负责人进行整改；
整改过程需要按照EDA的代码规范执行；
程序负责人在接到整改通知后1天内提交整改计划给EDA架构师团队审核，审核通过后，按计划进行整改；
整改后并通过验证后，由DBA提交。
●SP/function/Package程序的验证
●如果有必要，程序需要编写测试稽核脚本。
用以比对程序迁移后是否正常和准确的运行。
◆功能验证
功能验证验证3点：
程序是否能正常运行；
程序执行结果是否与预期的一致。
如通过稽核脚本的测试。
报表数据是否得到业务部门的确认。
◆能力验证
验证应用程序是否能够达到预期的执行效率；
验证应用程序是否会耗费大量的资源；
◆验证方式
验证工作由EDA基础维护组和业务单位共同完成；
验证工作同时兼顾功能验证和能力验证；
拟态验证，在同一计划时间内运行的程序，也在同一时间内验证；
程序负责人提供理论结果，验证人验证结果是否正确；
2.3ETL程序的修改和验证
●ETL程序的的迁移
同SP/function/Package程序的迁移。
●ETL程序的修改
在测试环境，所有链接原ODS服务器ETL程序都应更改为新的服务器链接；
●ETL程序的验证
◆功能验证
如果有必要，程序需要编写测试稽核脚本。
用以比对程序迁移后是否正常和准确的运行。
功能验证验证3点
程序是否能正常运行；
程序执行结果是否与预期的一致。
如通过稽核脚本的测试。
业务部门确认报表数据正确。
◆能力验证
验证应用程序是否能够达到预期的执行效率；
验证应用程序是否会耗费大量的资源；
◆验证方式
验证工作由EDA基础维护组和业务单位共同完成；
验证工作同时兼顾功能验证和能力验证；
拟态验证，在同一计划时间内运行的程序，也在同一时间内验证；
程序负责人提供理论结果，验证人验证结果是否正确；
2.4BO报表语义层的修改和验证
●BO程序的迁移
同SP/function/Package程序的迁移。
●BO报表语义层的修改
在测试环境，链接到原ODS数据库的BO语义层的数据库链接做修改
●BO报表语义层的验证
验证工作同ETL程序，由EDA基础维护组和业务单位共同完成；
验证工作同时兼顾功能验证和能力验证；
程序负责人提供理论结果，验证人验证结果是否正确；
2.5QV报表程序修改和验证
●QV报表程序的迁移
同SP/function/Package程序的迁移。
●QV报表程序修改
从原ODS服务器上抽取数据到QV服务器上的程序将链接改为新服务器
●QV报表程序验证
验证工作同ETL程序，由EDA基础维护组和业务单位共同完成；
验证工作同时兼顾功能验证和能力验证；
程序负责人提供理论结果，验证人验证结果是否正确；
2.6测试计划（草案）
任务名
子任务名
开始时间
天数
结束时间
参与单位
数据库升级功能测试与验证
新建ETL测试服务器（InformaitcaPowerCenter861）
2011-1-3
3
2011-1-5
IT部、理想
新建BO测试服务器（BusinessObjectsXIR3）
2011-1-3
3
2011-1-5
IT部、理想
在ETL测试服务器部署测试ETL程序。
如将程序数据源连新环境。
（共800多个）
2011-1-6
3
2011-1-8
IT部、理想
在BO测试服务器部署测试程序。
如将程序数据源连新环境。
2011-1-6
2
2011-1-7
IT部、理想
在QV测试服务器部署测试程序，如将程序数据源连新环境。
2011-1-6
2
2011-1-7
IT部、理想
在oracle11g测试环境部署原ODSPD的oracle存储过程、函数（共3000多个）
2011-1-6
3
2011-1-8
IT部、理想
oracle存储过程、函数的测试运行
2011-1-8
6
2011-1-13
IT部、理想
oracle进程数据稽核。
（数据比对脚本的运行和比对结果分析）
2011-1-8
10
2011-1-17
IT部、理想
原ODSPD的oracle存储过程、函数的修改和再测试
2011-1-18
2
2011-1-19
IT部、理想
ETL测试程序运行
2011-1-20
5
2011-1-26
IT部、理想
ETL测试程序的数据比对脚本的运行和结果分析
2011-1-21
10
2011-1-30
IT部、理想
ETL测试程序的修改和再测试
2011-2-10
3
2011-2-12
IT部、理想
BO测试程序运行
2011-2-13
3
2011-2-15
IT部、理想
BO报表查看和业务单位确认
2011-2-14
3
2011-2-16
IT部、理想、业务单位
BO程序的修改和再测试,确认
2011-2-18
3
2011-2-20
IT部、理想、业务单位
QV测试程序运行
2011-2-22
3
2011-2-24
IT部、理想
QV报表查看和业务单位确认
2011-2-26
3
2011-2-28
IT部、理想、业务单位
QV程序的修改和再测试,确认
2011-3-1
3
2011-3-3
IT部、理想、业务单位
数据库升级性能测试与验证
oracle存储过程、函数的在大数据量下的测试
2011-3-4
2
2011-3-5
IT部、理想
ETL程序在大数据量下的测试
2011-3-6
2
2011-3-7
IT部、理想
ORACLE性能调优
2011-3-8
3
2011-3-11
IT部、理想
ETL版本升级测试与验证
部署老环境程序
2011-6-8
5
2011-6-22
IT部、理想
运行
2011-6-23
3
2011-6-25
IT部、理想
测试和验证和修改。
2011-6-26
7
2011-7-2
IT部、理想
BO版本升级测试与验证
部署老环境程序
2011-7-3
5
2011-7-7
IT部、理想
运行
2011-7-8
3
2011-7-10
IT部、理想
测试和验证和修改。
2011-7-11
7
2011-7-17
IT部、理想、业务单位
第3章Oracle\ETL\BO\QV程序统计模板
3.1SP/function/Package程序
3.1.1程序列表模板
用户
对象名字
类型
3.1.2数据实例
见《oracle进程统计.xls》
3.2ETL程序
3.2.1程序列表模板
服务器名字
workflow名称
3.2.2数据实例
见《ETL进程统计.xls》
3.3BO\QV程序
3.3.1程序列表模板
主题
报表名称
报表类型
需求提出部门'
业务部门联系人'
业务部门联系电话'
报表计划启用日期'
报表停用日期'
报表展现系统'
备注
统计口径补充说明'
STATE
频率
追溯期限'
IT部门联系人（开发部门）
需求提出部门联系人'
需求审核部门联系人'
需求提出单位'
'IT部门联系电话（开发部门联系电话）
需求提出部门联系电话'
需求审核部门联系电话'
报表实际启用日期'
操作状态
开发部门'
需求审核部门'
访问路径
BSS工单编号
日报表刷新时间'
权限
3.3.2数据实例
见《BO、QV进程统计.xls》
第4章系统恢复预案
为避免因系统迁移失败给上海电信业务所造成的影响，确保业务的正常开展，我们必须做好两手准备，一方面要对系统迁移方案进行严密的分析、论证，并严格进行测试、模拟，加大各级人员的培训力度，而且只有在所有准备工作就绪，对于数据库迁移日期选定在连续1-2天节假日前的凌晨进行，一切准备完备的基础上进行数据迁移，确保平滑成功地移植。
另一方面必须做好迁移不成功时的恢复方案，使业务生产能平滑恢复到原系统进行，保障业务的正常开展。
数据库迁移失败的恢复预案
如在数据库迁移过冲中出现数据库迁移失败的情况，直接将旧的数据库系统投产即可，没有需要恢复的数据。
由于旧的数据库系统启用，等到故障排除后，又须做一次数据库迁移，这时相当于前次的系统迁移。
第5章项目难点及风险
Oracle数据库系统升级是一项机遇和风险并存的系统工程,对现有系统的全面了解和评估，升级需求的分析，合理的升级技术方案设计是升级项目的基础。
由于ODS系统为在用的生产系统，因此整个升级过程必须十分慎重，科学的升级方法论指导和项目有计划的实施是升级的重要保障。
并可能出现的问题，需采取预防措施，尽可能减少风险的发生。
下表列举了升级过程中可能存在的风险以及应对和监控措施。
序号
可能遇到的风险
风险等级
可能造成的后果
风险规避方法
1
升级中遇到无法解决的错误，如升级程序遇到Bug。
高
升级失败
1）尽早搭建和生产环境一致的测试环境,预先在测试环境演练升级全过程,对于升级中发生的每一种错误找到解决办法；
2）预先制定可靠的系统回退方案，一旦升级失败，可采取快速回退，保障生产业务系统不受影响。
2
升级耗用的时间超过计划停机时间
高
业务系统运营延误
1）在测试环境升级演练中估算生产环境所需的升级时间,适当调整升级方案和计划。
2）升级前进行预演，保障升级最终方案的可行性。
3
数据库新老特性不一致，导致应用运行不正常
高
升级失败
确定需要使用的新特性和要废弃的老特性，以及用户的权限变化，在详细的测试中定下方案
4
客户端应用与服务器端不兼容
高
应用不稳定或不可用
1）尽管Oracle11g数据库对9i的应用是兼容的，为保证应用系统在升级后运行的稳定性和高效性，建议数据库升级前，应用开发商做较全面的应用功能测试，以验证客户端应用与11g数据库的兼容性。
2）如环境或资源的限制，不能作到应用的全面测试，但也要保证重点业务应用的测试。
3）与应用密切相关的数据库重点测试内容，例如设置新的11g数据库参数、数据库分区、数据库并行处理操作、物化视图等测试。
4）建议将客户端也升级到11g，并重新对原有应用进行link操作。
5
部分应用的性能降低
中
部分业务处理无法正常进行
同上，另外使用预演功能
6
数据库运行不稳定
中
生产运营受到影响
1）在测试环境进行充分的压力测试，提早发现潜在问题，通过Oracle的支持找到解决办法；
2）升级后如数据库出现问题，可通过Oracle内部关键支持力量（包括产品研发部门）对系统问题提供及时响应和解决
7
项目组成员不能
到位
中
项目计划无法正常
执行
尽早提出和确定项目实施计划，以便客户方
及时安排主要人员的工作
8
需要连带升级INFORMATICA和BO系统
中
测试工作量大
严格按照测试计划分步骤实施测试。
如果使用DBUA方式升级数据库，在DBUA过程中，可能遇到诸多ORA-报错，数据库的可用性存在问题。
第6章项目进度
查看附件一:
升级会员 