下面是小编为大家整理的银行卡统计分析系统试运行情况汇报【精选推荐】,供大家参考。
银行卡统计分析系统试运行 情况汇报
1． ． 试运行 基本情况 按照项目整体进度的安排，在各级领导的支持下，在项目组全体成员的共同努力下，项目组如期完成了银行卡统计分析系统各项功能的开发、测试工作，以及 ASE 到 IQ 的移植。
为了确保系统正常上线，在总行卡部、科技部的组织下，项目组到山东分行进行试运行。项目组全体成员于 6 月 11 日抵达济南，从11 日至 22 日进行了为期 12 天的紧张工作，完成了试运行的所有工作，试运行也达到了预期的目标。全体成员中业务人员共 3 人，包括总行卡部 2 人，山东分行 1 人；技术人员共 12 人，包括总行开发中心 3 人，广州分中心 4 人，山东分行 3 人，外协 2 人。
2． ． 试运行 环境 按照项目组下发的软硬件配置清单，山东分行提前搭建了试运行环境并且准备了 2007 年 3、4、5 月份的数据，详细情况如下: 1）硬件环境 数据库服务器：RP8420 小型机、32 个 CPU、96G 内存，500G可用磁盘空间； 应用服务器：
PC Server，内置 16 个 CPU、3G 内存、70G磁盘空间
多维服务器：
PC Server，内置 16 个 CPU、3G 内存、70G磁盘空间 2）软件环境 数据库服务器：
操作系统 HP-UX B.11.11；数据库 Sybase ASE 12.5.3，初始化建立名为 yhktj 的数据库，大小 600M，日志200M；数据库 Sybase IQ 12.6 数据库，数据段空间 200G，server 名与数据库名均为 yhktj。
应用服务器：操作系统 SuSe Linux 9.0；应用服务器为 IBM WebSphere Application Server for Network Deployment 5.1.1.10
多维服务器：操作系统 Windows Server 2003 Standard Edition；多维服务器为Cognos 8.2.43；Web服务器为Windows下的 Internet 信息服务(IIS)；Cognos 数据库 Sybase ASE 12.52；IQ 客户端 Sybase IQ Network Client Windows 12.6 3）数据环境：
试运行的数据与将来实际生产的数据完全一致，分行准备了2007年 3、4、5 月份的生产数据，其中 32 张 ABIS 源数据, 3 张 AIPS 源数据，总共 35 张表，数据文件每日增量 0.9G，月底全量 29G。
3． ． 试运行 过程 此次试运行工作是对整个系统的全面检验，在试运行过程中项目组与山东分行的科技和业务人员一起，从环境搭建、数据准备、应用
部署、系统运行、系统测试几个方面进行，达到了非常好的效果。
1）环境搭建 山东分行系统人员按照项目组试运行方案中的要求，安装了HP-UX、ASE12.5 并按要求完成了相关参数的配置，安装了 Suse Linux 9 和 Websphere5.1，总行项目组成员完成了 IQ12.6，多维服务器的安装和配置。
项目组根据以上安装情况，完善形成了《银行卡统计分析系统后台安装手册》、《银行卡统计分析系统 WebSphere 安装手册》、《银行卡统计分析系统 Cognos 安装手册》。
2）数据准备 山东分行按照试运行方案的要求完成了 2007 年 3、4、5 月份 ABIS和 AIPS 数据的准备，随后又准备了 2006 年 12 月底和 2007 年 1 月、2 月份的数据。在试运行的过程中发现分行准备的有些数据有问题，比如 4 月 1 日的 CSD 表有些记录被截断，分行人员从 AIPS 系统中重新抽取一次就没有问题了。
根据数据准确情况，形成了《银行卡统计分析系统数据处理策略》。
3）应用部署 项目组在环境搭建完成后，执行安装程序完成后台所有应用程序的部署，初始化前、后台用到的所有参数表，根据系统环境修改环境变量；完成应用程序在 WebSphere 上的发布，Cognos 应用程序的部署，完成监控系统的发布。
项目组根据应用部署情况，完善了《银行卡统计分析系统部署手册》。
4）系统运行 在试运行的前期，系统运行的工作主要由项目组承担，系统运行比较稳定后，项目组逐渐把运行工作移交给分行人员进行。目前除了Cognos 的一个问题导致系统不太稳定外，分行人员已经基本掌握系统的运行情况。其中从 2006 年 12 月底到 2007 年 2 月的数据由分行独立完成。
5）系统测试 项目组配合业务人员一起完成了系统测试，在测试的过程中，主要针对数据准确性、功能、性能、数据处理情况等几个方面。
4． ． 试运行 效果 经过项目组全体成员的共同努力，目前系统的数据准确性、功能、性能、数据处理都达到了预定的效果，系统基本满足上线的条件。具体为：
1）系统运行情况 在以上所示机器资源配置和数据量的情况下，在 7 个并发的情况下，每日后台批量处理时间为 30 分钟，月底为 5 小时。运行过程中发现 Cognos 关于刷新 Cube 的程序不是太稳定，有时会中断，导致整个作业挂起。
2）数据准确性
业务部门对卡量、余额类，交易类，风险类，辅助采集类等数据与山东分行的数据广场和经营管理系统的数据进行核对，经过核对考虑统计口径上的差别，数据是准确的。项目组根据核对结果形成了《数据准确性核对分析报告》（附件一）。
核对的大概情况为：
借记卡卡量：总行统计口径为不包含注销卡、睡眠卡且人民币主账户状态为正常的卡，山东分行统计口径为卡状态为正常、未启用、睡眠卡，考虑统计口径上的差异，数据是完全能够对上的。
借记卡余额：总行统计口径为不包含注销卡、睡眠卡，主卡下的账户状态为正常的人民币主账户余额，山东分行统计口径为卡状态为正常、未启用、睡眠卡，主卡下的账户状态为正常的账户余额，考虑统计口径上的差异，数据是完全能够对上的。
准贷记卡卡量：总行统计口径为不包含注销卡、睡眠卡，人民币账户状态为正常的卡，山东分行统计口径为卡状态为正常的卡，考虑统计口径上的差异，数据是完全能够对上的。
准贷记卡余额：总行统计口径为不包含注销卡、睡眠卡，主卡下的账户状态为正常的人民币账户余额，山东分行统计口径为卡状态为正常(包含睡眠卡)，主卡下的账户状态为正常的账户余额，考虑统计口径上的差异，数据是完全能够对上的。
信用额度：总行统计是按照消费的信用额度进行的，分行是按照取现的信用额度进行的，这个问题还需要与相关人员确认。
交易类数据：此类数据与山东分行数据广场差别较大，统计口径
上存在较大的差别，如：
存现交易：总行统计口径是银行卡交易明细（PPTJ）表中PPTJTRCODE=1 的交易，山东分行数据广场除了统计 PPTJ 表中PPTJTRCODE=1 的交易，还包括 APSH 表中符合 APSHTRCOD in (1051,4212,2301,2309) and APSHDBKNO=0 and APSHACTNO in(PDCR or PCCI)的交易。其中 1051 为活期存现交易；2301、2309 为还款交易，目前总行没有要求把这三种交易统计到卡存现交易中，4212 为银行卡现金存现交易，但每笔 4212 交易在 PPTJ 中都已经有一笔PPTJTRCODE=1 的交易与之相对应。
取现交易：总行统计口径是银行卡交易明细（PPTJ）表中PPTJTRCODE=2 的交易，山东分行数据广场除了统计 PPTJ 表中PPTJTRCODE=2 的交易，还包括 APSH 表中符合 APSHTRCOD in (2122,4213,4214) and APSHDBKNO=0 and APSHACTNO in(PDCR or PCCI)的交易。其中 2122 交易为准贷记卡密码重置交易，4213 为银行卡活期账户取款交易，4214 为银行卡现金取款交易，但这两个交易在 PPTJ中都已经有一笔 PPTJTRCODE=2 的交易与之相对应。
消费交易：总行统计口径是银行卡交易明细（PPTJ）表中PPTJTRCODE in (4,5,9,13,19,33)的交易，山东分行数据广场除了统计 PPTJ 表中 PPTJTRCODE in (4,9)的交易，还包括 APSH 表中符合APSHTRCOD in (3961,2118,4254) and APSHDBKNO=0 and APSHVCHNO like ‘P__Z%’ and APSHACTNO in(PDCR or PCCI)的交易。该部分交易包括转账电话交易；且山东分行数据广场中没有将 PPTJTRCODE=19
（网上消费）的交易统计在内，也没有剔除 PPTJTRCODE in (5,13,33)的消费撤消交易。
转入交易：总行统计口径是银行卡交易明细（PPTJ）表中PPTJTRCODE in (10,27)的交易，山东分行数据广场除了统计 PPTJ 表中 PPTJTRCODE=10 的交易，还包括 APSH 表中符合 APSHTRCOD in (3958,3959,3960,3961,4210,3034,3042,2310,2368,3003,1045) and APSHDBKNO=0 and APSHACTNO in(PDCR 或 PCCI)的交易。其中 3958位批量代付,3959 为转 94，3960 为转 94，3961 为个人折、卡互转，4210 为过渡转入，3034 为活期主账户转开子账户，3042 为主账户转零整续存，2310 为 放款转支票户/银行卡户/活期储蓄户，2368 为放款转银行卡户/活期储蓄户，3003 为 活期子账户过渡转入，1045为转账存款，这些都与总行卡部定义的转入交易概念不一致。
转出交易：总行统计口径是银行卡交易明细（PPTJ）表中PPTJTRCODE in (11,27)的交易，山东分行数据广场除了统计 PPTJ 表中 PPTJTRCODE=11 的交易，还包括 APSH 表中符合 APSHTRCOD in (2113,3957,4211,3004,3961,1046) and APSHDBKNO=0 and APSHACTNO in(PDCR 或 PCCI)的交易。其中 2113 为准贷记卡转账销户，3957 为代收，4211 为过渡转出，3004 为活期子账户过渡转出，3961 为个人折、卡互转，1046 为转账取款，这些都与总行卡部定义的转出交易概念不一致。
2）功能 业务部门对电子报表、数据查询、辅助采集、多维分析、系统管
理和帮助等功能的测试，在测试的过程中提出了一些需求变更和新增了一些需求。针对这些情况，项目组进行初步分析整理，形成了《试运行功能分析报告》 （附件二）。
3）性能 项目组与分行系统人员一起对机器的性能进行分析，统计出运行过程中 CPU、内存等的使用情况，并参照 TPC－C 值衡量出系统配置情况。
TPC-C = M × M0 ×（1＋M2）×（1＋M3）
/（M1）
其中 M：为需要处理的原数据记录数。经分析，山东分行 2007 年 4 月处理的月底全量源数据记录数约为 11409 万条记录(27.2GB 的数据量,一条记录按平均 0.25K 计算)；
M0：为处理一条记录所需的事务数，由于数据在进入中央数据库的过程中为批量处理，这里 M0 可取为 0.1，即 1 个事务内平均可处理 10 条记录。
M2：为主机 CPU 处理余量。实际应用表明，一台主机服务器的CPU 利用率高于 80%则表明系统会产生瓶颈，而利用率处于 70%时，是处于利用率最佳状态。因此，这里设定 M2=30%。
M3：为从原始数据加工到最终数据的过程中，处理的记录数与原始数据记录数的比，实际应用表明：
M3=8 比较适当。
M1：数据处理完成时间，这里 M1=240。即数据处理完成时间不超过 240 分钟(4 小时)。
所以：TPC-C = M × M0 ×（1＋M2）×M3 /（M1）
＝ 114090000×0.1×(1+30%)×(1+8)/240
＝556,188.8 CPU 个数＝556,188.8/50000≈12 个 综上，山东分行的数据量在全行属于大行，结合全国其余几家大行的情况，因此将数据库服务器的 CPU 设置为：12 个＋4 个＝16 个；内存设置为：16(CPU)×4＝64G；并发作业数等于数据库可用 CPU 个数减 1，即：16(CPU)－2(系统使用)-4(解压缩等操作使用)-1＝9 个。
根据大型分行的性能要求，中型分行的数据库服务器配置建议为：12 个 CPU，48G 内存，7 个并发作业；小型分行的数据库服务器配置建议为：8 个 CPU，32G 内存，5 个并发作业。
4）数据处理 项目组在试运行的过程中，对数据处理的每一个环节进行统计和整理，汇总为：
类型 增/全量 文件系统增量 报表 xml 文件
数据库增量 备注 第一次加载 全量 29G 1.5G 37.5G 数据库包括加载区、平台区、应用区和报表区的数据 每 日 （ 除 月底）
增量 0.9G 0G 0.4G 数据库只包含平台区、应用区的数据 月底 全量 29G 1.5G 11.5G 数据库包括平台区、应用区和报表区的数据 根据业务的要求，源数据文件的数据保留三个月；数据库中的数据保留两年。这样两年后的数据空间使用为：
文件系统 29.0G+1.5G+(0.9G×30.5 天+29.0G)×3 个月 +(1.5G×12 个月×2 年)
=235.9G
数据库 37.5G+(0.4G×30 天+11.5G) ×12 个月×2 年
=601.5G 临时库 37.5G+(0.4G×30 天+11.5G)×(3/7)×12 个月×2 年=279.2G 系统空间 500G 合计 1 16 6 16.6G
综上，山东分行的数据量在全行属于大行，结合全国其余几家大行的情况，因此将数据库服务器的存储空间建议为 3T 可用空间。
根据大型分行的空间配置要求，中型分行的数据库服务器的空间建议为：2T 可用空间；小型分行的数据库服务器的空间建议为：1T可用空间。
5． ． 试运行 中发现的问题
试运行过程中，业务人员在统一安排下对每个数据项、功能点进行了全面认真的测试，每天每人提交测试报告汇总后统一交给开发人员，大部分问题开发人员现场及时做了修改，遗留部分也已经整理完成，大部分问题也已经达成了一致的修改意见，个别问题需要进一步讨论确定。
对于测试中的问题分为几类：
1)程序错误：该类错误在本次测试的所有问题中所占比例较小，开发人员利用试运行的时间对部分问题已及时进行了修改； 2）需求变更：此类问题占了绝大多数，这些问题主要包括模块和报表名称修改，报表输入输出选项格式的调整，增加其余数据项的查询，报表调整等对一些功能上的调整。
3）新增需求：此次新增 7 类需求，部分新增的已经实现，对于有些新增需求，比如旬报，对系统的性能影响比较大，而业务部门又
不是很迫切的，目前暂不考虑。
4）程序优化：这些问题主要是为了提高程序的运行效率，减少程序的复杂性，增加系统的友好性，比如：索引、页面风格、操作习惯等。
5）多维分析。
目前项目组没有对多维分析比较熟悉的人员，很有可能对这部分的测试和分析还有一定的不足，需要对这一部分进行更加深入的分析，并根据情况对问题进行修改。
6 ．下一阶段的工作安排 及问题
试运行结束后，项目组将回北京利用一周的时间解决遗留的问题，然后到广东分行进行试运行。
在试运行的过程中发现多维分析部分需要修改的地方比较多，而目前项目组没有对 Cognos 比较熟悉的人员，需要领导协调解决。
目前，总行的设备还没有到位，无法搭建总行的测试环境，也就没有办法对系统...
推荐访问:银行卡统计分析系统试运行情况汇报 试运行 统计分析 银行卡