Oracle数据库专家项目开发经验 之七(2006中国杰出数据库工程师评选)
王颐项目二：某大型制造业生产系统数据库系统I/O过重架构整改方案
项目简介（功能与用途）： 生产流程导致shop floor系统的数据库I/O 过重，导致性能较差 原为单机运行的数据库，要求重新规划DB 架构 项目难点与解决方法： 建议通过应用的分开来实现I/O的减轻 建议将原数据库的report查询移到另一数据库进行 采用logical standby 架构同步数据，并在logical standby DB内作实时查询达到I/O的降低提高性能 1. 因裸设备的管理维护麻烦故不建议使用 2. 如采用高级复制将数据实施同步会导致主数据库loading增加，则违背应用的分开来实现I/O的减轻的初衷 3. 建议配置logical data guard实现数据库的同步并将report应用在standby db运行达到loading的减轻 4. 因9i后几个数据库版本主要是修正一些logical data guard的bug故建议升级数据库至9208 5. 制定合理的failover及重建logical data guard的文档及处理机制弥补logical data guard的不稳定。 项目成功与失败的经验归纳： 此为苏州地区生产库使用logical data guard的第一例，故很有代表性，成功的实施对以后的我们在苏州地区对logical data guard技术的推广很有积极意义。 规范化的管理以及无特殊运用使得该数据库系统运行良好，相对稳定。 你在项目中岗位与贡献： 1.协调客户与公司之间的供需关系 2. 几种方案的提出及优缺点对比分析及最终选型确定 王颐项目三：某大型500强企业100个数据库的集中管理及 监控系统的实施 项目简介（功能与用途）： 大型制造业100个生产数据库，主要数据库40个左右 要求集中管理监控性能，减轻企业DBA日常管理负担 要求监控系统对资料增长，性能及硬件采购做提前预判 报错能发message到email及手机 项目难点与解决方法： 每日的daily check自动化可以减轻DBA的监控的负担，但无法保存每日session数，交易量等指标作历史对比及预估。 所有db单独监控发email至DBA邮箱会导致email过多。 1． 建制单独的db通过dblink每日收集各数据库的主要信息(DB的连接状况，用户状态，日志切换每日次数，datafile状态，各种命中率，失效的物件，DB size，session状态，tablspace使用状态，top10 index,top10 table的状态等等)并保存到数据库的table中，通过定义的view每周，每月自动产生报表并图形化供分析及主管审阅。DBA连接该数据库便可了解所有数据库的状况。 2．对所有DB建制监控，做到报错会自动发email及短信提醒相关人员 3. 对重要的5个DB按客户需求每日上班前发html检查内容至相关人员邮箱监控内容如下: Sorting效率, Tablespace目前状况, Datafile目前状况, Redo Log目前状况, Control File目前状况, 数据库对象目前状况, Index目前状况, Table目前状况, User管理, User权限控管 项目成功与失败的经验归纳： 以日报，周报，月报，季报，年报的形式让客户不同阶层的人员了解数据库的状况，专业技术人员可以根据数据报表分析数据库，主管通过图形化的形式轻易了解数据库的运行状况。 紧急情况短信提醒，避免重复收取信息。 连入单独建制的DB可以得知任何数据库的任何时间状况，历史资料供可预估分析使用 你在项目中岗位与贡献： 1．客户需求分析 2．项目规划 钱彦云项目一：电信业务档案管理系统 本文出自 51CTO.COM技术博客项目简介（功能与用途）： 电信在与客户的业务交互过程中，产生了大量的纸质媒介信息，如合同，协议，装(移、拆)机工单等。而随着电信业务的不断发展，这些纸质媒介信息的数量还在日益增多。日积月累，数量已经非常庞大，其查询、保存、流通十分困难。本系统以此为出发点，将纸质媒介信息通过高速扫描仪进行数字化处理后，再根据用户需求进一步加工，从根本上解决纸质媒介信息难以查阅、保存和流通的问题。 本系统的功能就是将电信每天受理产生的纸质量合同通过扫描、压缩、加密后存储在文件服务器上，同时以日接口方式获得电信业务支撑系统的客户、用户信息及其修改信息。实现电子化档案管理，相关人员可以在网页中随时按照条件组合查询业务档案信息。如下图。 系统的开发和部署环境： 软件环境： web容器是IIS6.0；数据库选型号oracle10g；操作系统选择win2003 硬件环境： IBM X366 开发工具： vs2005 项目难点与解决方案： 难点1： 数据库中的用户信息客户虽然有500万条以上，但是通过分区和分区索引的使用技巧，性能还是比较好。但是文件服务器的负荷非常高。以每天发生2000到3000笔业务估计，每天会产生20000张纸质信息，每张纸质信息的数据最大存储量约32k，这样，每天会产生640M的图片信息，5年时间就有1T的数据在文件服务器上。有很高的性能需求。 解决方案1：在不影响清晰度的情况下尽量压缩，运用DIBB等各种图像无损压缩算法，在保持原样的基础上，对数字化文档进行压缩后存储 解决方案2：清晰化处理，仅对纸质文档的文字信息进行原始留样，运用锐化，去污等多种图像滤镜算法，对数字化后的文档进行清晰化处理。可以更好的减少图片占有空间 解决方案3:合理组织目录名、文件名，以组织机构 ＋ 日期组织目录名，以业务工单号 ＋ 序号组织文件名。将全路径存储在数据库中，在文件服务器的查询使用全路径，直接定位文件。 难点2： 扫描和刻录要求在浏览器中完成，需要突破IE安全限制 解决方案：自己写了ACTIVX控件完成此功能 项目成功与失败的经验归纳： 本项目属于成功的项目经历，主要有以下体会： 仿照PetShop框架，我们设计了自己的一个简单web框架，数据访问层和业务逻辑层使用了Factory模式解偶。对这个项目和将来的项目都是很好的积累。先做框架，在快速原型的方法在这种数据密集型的应用中很有价值。 加密算法使用.NET框架自带的类库完成，又一次证明了不要自己造轮子的意义。 你在项目中岗位与贡献： 项目的需求分析，项目的主要设计人员。接口数据的来源来自省公司的数据仓库，接口部分所有的设计和实现。同时在本项目中承担质量控制员的角色。 钱彦云项目二：电信业务支撑系统二期改造－欠费管理模块 项目简介（功能与用途）： 本系统的主要功能有 1. 在电信业务支撑系统中建立并完善欠费管理功能，向管理催缴的业务部门提供催缴数据，催缴是通过10000号语音系统完成的，本系统通过接口形式将需要播放缴费通知音的客户数据提供给10000号，有10000号平台完成相应呼出，达到缴费通知的目的。对于存在担保电话的设备、连带担保电话一并催交。 2. 对于经催费后仍未交费的用户，系统能自动停机，停机的数据采集应支持按欠费金额大小，按区局，按地理区域，按局码组合数据，同时应剔除重要用户，用户交清欠费后，系统能自动生成复机数据，并确保复机数据传给程控机房，程控机房处理完毕后应及时回送处理信息，在一定时限内若没有处理成功，系统能自动重传数据。欠费停机，缴费开机是本系统最主要功能。 3. 系统会自动生成停机、复机、拆机处理详细日志，对欠费催缴、缴费、停话、复机、拆机、复装等处理全过程就可以提供统计、查询、打印。 4. 提供人工派单接口，可以人工强行停、复机 5. 对调帐业务的支持 6. 对预付费设备停、复机工单的支持，预付费设备的停复机逻辑由朗讯另外负责，不在本系统内。 7. 高额、限额业务支持 8. 对欠费用户的信息处理，一方面将欠费信息提供给营业系统（限制该用户办理业务）；另一方面将欠费信息提 供给网管系统（限制该用户使用现有的业务功能）。 9. 对无法收回的坏帐进行分类归整，将其费用转入坏帐处理系统中，并纳入黑名单管理。 系统简单流程描述：对后付费设备，在每月交费周期过后，电信计费系统会将没有交费的数据生成欠费。本系统采用月接口以ftp方式接受计费全量账单。用户销帐后，销帐信息使用unix的SOCKET包发过来，解析后调用存储过程更新用户账单，对已经停机的设备会做开机处理。预付费这里只是提供了工单接口。 系统的开发和部署环境： 软件环境： ORACLE RAC 硬件环境： IBM AIX 开发工具： C/PRO*C 项目难点与解决方法： 难点1: 数据量大，全省的电信账目，用户信息和客户信信息量都非常大，最大的表有上千万条记录，但是缴费开机对性能的要求非常高，否则就有可能被投诉。 解决方案： 对大表按照地区分区，创建充分索引，并且索引都创建为分区索引。这样销账开机时对表中数据的查询可以迅速返回。但是这里同时又引入了新的风险，数据不断更新后oracle的统计值可能会不准备，不能采用正确的执行计划。曾经发生过突然销账非常缓慢的情况，应该写代码定时分析表，避免此类错误。索引增加会增加insert和update操作的开销，这里需要注意这两方面的平衡。 难点2: 系统的稳定性要求很高，任何故障都有可能被投诉 调度逻辑采用标准C编写，部署在AIX上，后台数据库IBM小型机上，并且是ORACLE RAC，为了保证不发生存储过程失效，写了个proc程序定时监测存储过程状态，保证7*24的运行。数据库定时热备份。备份的方案很复杂，由IBM来做。 项目成功与失败的经验归纳： 成功经验1： 数据密集型程序设计阶段要充分重视数据流程图，这点和应用密集型程序有所区别。建模上要有侧重点。一定要先有E-R图，再向数据库详细设计走，这样很容易的迭带开发，数据库设计也更容易被理解。 成功经验2: 接口非常多的项目，例如本项目，要搞好接口谈判并且明确定义接口，写出清晰的接口文档。尽量早的开发出接口并测试 你在项目中岗位与贡献： 主要设计人员，所有的C/PRO*C代码的编写，和计费接口所有ORACLE数据库包编写。系统性能的主要优化人员。 钱彦云项目三：电信网上营业厅 项目简介（功能与用途）： 网上营业厅是电信推出的，通过网络办理电信业务的新运营模式，以网上营业厅的形式为客户提供服务，客户、代理商或合作伙伴等用户都可以完成的电信的全业务受理。 主要包括三部分功能： 面向客户的功能² 面向后台用户的功能² 面向系统管理员的功能² 软件环境： EJB容器：weblogic；语言：java；数据库调用逻辑和连接：tuxedo 硬件环境： IBM AIX 开发工具： JAVA 项目难点与解决方法： 难点1: 负载均衡，由于是全省电信的应用，用户的数据分布在全省14个地州，web服务器采用省集中方式部署，业务受理时要自动选择负载最小，并且是存放用户信息的数据库服务器。由于系统的稳定要求很高，当因网络等原因数据库链路中断后，要有完整的事务处理机制。 解决方案： 采用BEA TUXEDO中间件，由中间件自动转发数据请求做到负载均衡。Weblogic上只是实现了应用界面层。数据的操作逻辑全部在TUXEDO上实现。本系统充分利用了以前的程序，用java把delphi的界面逻辑重新翻写。大大减少了代码量。 项目成功与失败的经验归纳： 1. 复用以前的代码和数据库 2. 使用了中间件实现后台很重要的管理和企业级别特性，降低了开发复杂度 3. 使用了Spring框架 你在项目中岗位与贡献： 受理缴费部分代码 项目四： 铁路客运审核系统 项目简介（功能与用途）： 当时是铁道部的一个项目，功能主要有 1. 审核是否有票价错误的票根 2. 审核各类客运票据，并产生铁道部统一规定的财务报表 3. 生成其他统计报表 项目难点与解决方法： 全国各地的票价制定规则是有区别的，而且票据也五花八门各不相同，报表的需求差别非常大。 解决方案： 1. 制作了自定制报表，有点类似于OLAP报表工具的自定制功能 2. 各功能点安装时定制 项目成功与失败的经验归纳： 这个系统做完都过去好几年了，之所以这里提到因为这是个很惨痛的失败项目。项目首先性能太低，不论是票据的录入速度，电子票的导入，报表的生成，时间都无法让人忍受，导入1次电子票要等2个甚至3个小时，汇总统计报表也是这样。 根源在数据库设计上，虽然花很大功夫优化了数据库环境，但是收效不能令人满意。查询中到处用到多表关联，并且这些表都很大。票据审核的算法有问题，影响了导入性能。 其次开发的时间太长，开发完毕后大量新的需求出现。数据密集型的应用最好在三个月内完成。 你在项目中岗位与贡献： 数据库优化工作 |
gulibin
博客统计信息
热门文章
最新评论
友情链接
