注册 | 登录 忘记密码? 51cto首页 | 博客 | 论坛 | 招聘
热点文章 利用手机和电池实现反地心..
 帮助

Oracle数据库专家项目开发经验 之六(2006中国杰出数据库工程师评选)


2007-03-28 21:28:21
 标签:Oracle 项目   [推送到技术圈]

王作敬项目五:基金管理公司核心业务系统(登记过户、直销)1.0~2.0
项目简介(功能与用途):

基金管理公司核心业务系统(登记过户、直销)1.0~2.0: 该系统涵盖了基金管理公司从帐户申请、资金存款、交易申请受理到交易确认、资金清算及基金登记过户等所有的核心业务处理过程。

项目难点与解决方案:
系统采用领先的客户机+中间件与应用服务器+客户机技术架构,提高了系统的灵活性、扩展性与处理效率。。

该系统在采用IBM M85小型机,AIX操作系统, Oracle数据库,Bea Tuxedo, Bea Weblogic中间件与应用服务器,开发工具则采用 C, C++Builder(1.0版本用), Java, HTML,JavaScripts(2.0版本用)

项目成功与失败的经验归纳:
该项目先后在天同基金管理有限公司、海富通基金管理有限公司、中银国际基金管理有限公司与汇添富基金管理有限公司4家公司得到应用,并得到用户的肯定与认可。

你在项目中岗位与贡献:
本人作为该项目的技术经理完成了直销的需求分析、设计、全部后台程序开发与整个项目的管理与质量控制。

王作敬项目六:基金管理公司数据中心系统
项目简介(功能与用途):

基金管理公司数据中心系统: 包括TA系统、直销系统、CallCenter、网站、CRM等数据的整合与投资人、销售代理人、管理人3大主题分析

项目难点与解决方案:
该项目在基金公司属于首创没有相关的案例可以借鉴。

该系统在采用IBM M85, PC SERVER EtcAIXWindows操作系统, Oracle数据库,开发工具则采用Cognos系列BI工具+Power Designer

项目成功与失败的经验归纳:
株距中心建设是个负责的系统工程,无章可寻,我们采用统一规划分布实施的原则,截止2005年底完成了华夏的一期工作(投资人主题)并开始了二期(投资与管理)的开发。

你在项目中岗位与贡献:
本人作为该项目的高级专家完成了系统的需求分析、数据建模、ETL设计与规则制定。
王忠海 项目一:刑侦综合信息系统数据库规划
项目简介(功能与用途):

本项目是某省公安厅2001年度重要项目,整套系统业务要求十分复杂,用户要求12个月内拿出成型版本。

项目难点与解决方案:
难点:项目业务复杂,涉及的业务部门也很多,如刑侦、治安、户政等都有关联;有的用户有老的系统数据需要转换等,因此设计出合理的数据库结构就非常重要。

解决方案:为了解决各业务部门信息孤岛,采用中间件,建立中心平台,对各个业务进行数据抽取标准数据来进行信息共享,对于老的系统的数据,开发数据转换程序,提供一次性转换和定期自动转换功能,这样可以让新老系统在一定时期内并行使用,顺利交接;数据库结构设计要考虑各业务部门的实际需求,并要充分数据采集、查询、统计的性能。

项目成功与失败的经验归纳:
该项目在2001年底成功完成并且在适用期间收到良好反响,在2002年初举办的鉴定会上得到了鉴定组的充分肯定,并且获得科技厅科技进步一等奖。这个项目之所以这样顺利完成,是与项目组的团结合作分不开的。首先我们充分调研了用户业务需求,为成功奠定了坚实的基础,在数据库设计阶段,认真设计了数据库结构,为顺利开发提供了良好的数据库环境。在开发阶段,聘请用户来测试,不断调整程序,终于得以顺利完成。目前该系统已经成为公司主打产品之一,并在全国11个省级单位应用。

我在项目中岗位与贡献:

在本项目初期,参与了业务需求调研,为数据库结构规划做好了准备。在数据库规划阶段,充分考虑了业务上的需求,精心设计数据库结构,并向开发组成员详细讲解了数据库结构的设计。在开发阶段,负责写后台存储过程,审核程序员在程序中书写的SQL的合法性并经常与程序员进行沟通。

王忠海
项目二:铁道部案件系统数据库规划与开发
项目简介(功能与用途):

铁道部97年就有案件系统,但是用的是桌面数据库,近几年已经严重不能满足现实要求。用户要求改造成网络版的系统,并且提出了新的业务需求。

项目难点与解决方法:
难点:铁路线路很长,有的铁路局下属单位距离可能有几千公里,网络不是很好,甚至有的用户使用拨号上网,因此需要尽量减轻网络传输负担,因此库结构的设计十分重要。

解决方法:将主要查询、统计、分析功能封装在存储过程里,尽量减少应用程序上发出的SQL语句,严格控制返回记录数量,尽量减少网络负担。

项目成功与失败的经验归纳:
经过近一年的开发与试运行,该系统在整个铁道部及各路局运行平稳正常,成功解决了网络问题。个人感觉将统计、分析功能封装在存储过程中是一个不错的方法,得到了实践的检验。另外,规划数据库结构的时候,根据实际情况添加了一些冗余字段,提高了查询、统计、分析性能,减少了服务器负担。

我在项目中岗位与贡献:

数据库结构的规划,参与开发组的数据库指导。

王忠海
项目三:广西省厅异构数据转换
项目简介(功能与用途):

2004
年初,公司派我到广西负责将省厅某业务系统的旧数据转换到我公司开发的系统中。旧系统的数据库是SQLSERVER6.5,新系统采用的数据库是Oracle9i,数据量总共有700多万,容量大约120GB

项目难点与解决方法:
新旧系统库结构相差很大是该项目的主要问题。数据上的一个字段对应多个字段、一表对应多表,字段内容含义不同的情况很多。针对这种情况,认真设计了转换用的对照表,并设计了多个转换用的存储过程。

项目成功与失败的经验归纳:

本项目从开始到完成用了4个星期,是由我一个人独立完成的。由于自己经过大量的测试,为期两天的验收一次性通过。这次转换一次完成就可以,所以不用在性能问题上过多考虑,重要的是转换后的数据不能丢失,而且要准确,以及要考虑新系统中没有地方放的数据的处理方法。

我在项目中岗位与贡献:
包括对旧的数据结构、业务系统的熟悉,转换方案确定,具体实施、测试。

王忠海
项目四:某省厅通讯处Oracle数据库优化
项目简介(功能与用途):

这是用于治安的一套系统,数据库服务器操作系统是AIX5.2L Oracle 版本是9.2.0.4。主表有300万的数据。

项目难点与解决方法:

用户反映通过网页查询速度很慢。由于该系统属于比较关键的业务应用,因此要求尽快将性能提升上去,并且用户明确指出硬件无法更换。

经过对数据库初始化参数的检查,在业务高峰做的STATSPACK分析,认为该数据库安装后没有进行过优化,而且应用程序查询的时候没有使用绑定变量。针对业务需求进行了优化,修改了一些初始化参数,将表和索引了行了分析后性能就明显改进了。经过测试,发现OPTIMIZER_MODE设置成FIRST_ROWS性能更好。另外将CURSOR_SHARING设成SIMILAR,明显减轻了库缓存的负担。根据经常运行的不合法的全表扫描SQL语句添加了几个索引。最后再次进行了STATSPACK,查找出一些不友好的语句,但是通过与用户沟通,用户表示优化到此已经可以接受,因此没有进一步优化。

项目成功与失败的经验归纳:

这次优化很快就完成了,完成后经测试主要查询速度提高了15倍以上,STATSPACK结果也比较正常了。但是也有一个应该改进的地方:因为想为用户优化的更好,所以在初次优化之后,跟用户还专门为是否需要进行比较费时的优化进行了讨论(如重新组织表、使用执行计划稳定性)。我建议进一步优化,但用户认为优化已经达到了要求,所以没有进一步优化。看来最优不是目的,让用户满意才是根本目的。

我在项目中岗位与贡献:
数据库优化

王忠海
项目五:山东某市公安局刑事信息库灾难回复
项目简介(功能与用途):

2005
5月,接一个朋友的电话,称该数据库出现了问题。朋友对数据库不是很熟悉,出现问题后在网上找了不少解决方法,但是都无效。通过专网远程检查,数据库版本是Oracle 8.1.6,操作系统是Solaris 8,数据库运行在非归档的环境下,没有备份,检查alert日志发现ORA-01189错误(File is from a different RESETLOGS than previous files)。

项目难点与解决方法:

本来数据库只是经历了一次突然断电,应该很简单就能够恢复的;但是朋友却由于在没有备份现场数据库的情况下就进行了很多危险的操作,然后才想起备份了一下,并且随后又作了很多操作,导致问题复杂了起来。

项目成功与失败的经验归纳:
这个ORA-01189的问题以前我也没有遇到过,通过查GOOGLEOracle官方技术支持网站metalink也没有得到合适的解决方法。最后根据alert日志的各种信息,通过重建只包含系统表空间的控制文件能够将数据库启动起来,接下来手动添加其它表空间,最终得以恢复。其间主要遇到的错误有ORA-01189ORA-01190ORA-00600[25012]ORA-01192,主要的解决方法是通过重建控制文件并手动添加其它表空间,使用_allow_resetlogs_corruption_offline_rollback_segments隐含参数来强制打开数据库。这个库恢复起来很费周折,整整折腾了将近20个小时。从这个恢复的案例上可以充分体会到备份数据的重要性。

我在项目中岗位与贡献:
从灾难中恢复数据,并进一步提高了恢复数据的能力。
王颐项目一:台湾某大型液晶面板厂大中华区5个厂MES 系统Oracle数据库(24x7)统一规划
项目简介(功能与用途):
24*7
的生产系统用数据库
DB
高可用,低
downtime
制定全国5个厂的数据库统一管理备份灾难应急处理机制

项目难点与解决方案:
1.5
个厂分处华南及华东地区为管理方便要求统一规划
2.
生产系统的数据库要求DB 高可用,低downtime,资料最大允许丢失10分钟

3.
要求做到DBSERVER级别的双重保护

4.
要求最大可能的保护DB的性能

1
Server: IBM P570 OS:AIX5.3L Oracle: 9207
2
统一配置OS Cluster+ share storage的双机热备及physical Data guardHA架构

3
DB配置两个nodephysical Data guard,一个处于recover mode保障与主库同步并保障随时可failover代替主库,另一个delay24小时,避免人为错误导致的资料损毁即可作前一天的资料备份

4
增对standby DB进行每日的备份以减轻primary数据库的
loading
5
因为要求数据库最大丢失10分,故强制主库10分钟archived
current redo log
5.
协助企业将DB的维护,备份及何时切换data guard机制化,统一化

6.
各厂之间因为专线建议Data Guard Server 相互错位放置达到最佳容灾

7.
设置相关自动监控的机制方便及时掌握客户系统运行状况

8.
定期主动式的到厂维护检查相关系统运行状况

项目成功与失败的经验归纳:
制造行业因生产要求故对数据库的高可用,低downtime 要求较高,且企业期望资讯管理
简单化,制度化。本项目利用os的双机热备保障了server维护及故障过程中系统的高可用,利用

physical Data guard
保障了数据库损毁及如server硬件升级的高可用
.
另制造业的硬件采购流程要求对DB的资料增长及数据库使用状况预估要求较高故我们采用自动监控机制作预估做到有历史资料可查,并尽量提前预估。

你在项目中岗位与贡献:
1.
协调客户与公司之间的供需关系
2.
召集客户相关部门收集客户系统需求,协助IT 相关人员协调各部门需求差异

3.
负责规划且具体的实施




    文章评论
 
 

发表评论

昵   称:
验证码:  点击图片可刷新验证码  博客过2级,无需填写验证码
内   容: