项目经验-黄卫

项目一：项目名称
项目简介（功能与用途）：
用友新一代ERP产品U9。替代U8的下一代ERP产品。
后台数据库：SQL Server 2005/Oracle

项目难点与解决方案：
难点：开发产品软件，要求在产品上市之前必须保证产品的性能和健壮性。而作为综合性的大型ERP软件，其中表、存储过程等数据库对象众多，同时具有OLTP和DSS特性。要求数据库设计、优化人员在评审业务设计人员设计书时，要根据应用场景和今后可能发生的大数据量，应用数据库的特性进行优化设计，并且考虑今后业务的功能扩展和多数据库平台的支持。

解决方案：根据数据库设计理论和应用场景，对表进行优化设计。制定优化目标，通过不同数据量的迭代测试过程，观察数据库响应时间，做出相应调整。对OLTP和DSS应用部分分别设计。对数据量庞大的表采取历史、实时数据分别处理策略等。

项目成功与失败的经验归纳：
制定优化目标，通过不同数量级的应用Demo检验产品的健壮性和性能是最根本的方法。制定严格的规范，保证产品的规范性。优化工作最忌无目标的盲目优化。在保证性能的前提下，为了管理和开发工作提供最优雅的实现。

你在项目中岗位与贡献：
岗位：数据库专家
贡献：负责整个U9产品的数据库设计优化工作。制定数据库设计、开发规范。评审设计人员的数据库物理设计，并做出优化建议。为200人的专职开发团队提供数据库技术解决方案和数据库技术培训。管理核心开发数据库。

项目二：项目名称
项目简介（功能与用途）：
江西省发电监控系统。监控发电设备的实时运转情况。
后台数据库：Oracle9i

项目难点与解决方案：
难点：24*7不间断工作系统。数据量大，每天要入库1000万条以上的记录。并且要求较高的实时性统计汇总。

解决方案：采用Oracle Guard，将归档的重做日志从primary database数据库异步写到standby database数据库来使primary database数据库在极少损失性能的前提下，最小化地减少数据的丢失。在primary database数据库发生异常的时候，自动切换到standby database上。在standby database上进行统计汇总，减少primary database数据库的压力。


项目成功与失败的经验归纳：
由于项目初期对数据量估计不足，硬件环境较差。在用户要求扩展业务而数据量激增的时候，原有环境无法满足运营需求，再次增加硬件设备才使系统正常运转。

你在项目中岗位与贡献：
岗位：数据库优化人员
贡献：在无法从优化数据库设计角度改善性能的前提下，建议增加硬件设备。选择Oracle Guard作为解决方案。培训相关实施人员。

项目三：项目名称
项目简介（功能与用途）：
辽宁省电力CRM管理系统。从省级公司监控各地级市的CRM运转状况。属于典型的分布-集中式数据库系统。
后台数据库：Oracle9i/SQL Server 2000

项目难点与解决方案：
难点：从省级公司监控各地级市公司的CRM数据，由于数据库分处各市，集成商和数据库平台不同对数据集中存在很大的难度。其中的数据库涉及：SQL Server6.5-2000、Oracle8i-9i、sybase11.5。没有购买第三方软件，完全依赖数据库功能实现。

解决方案：对网络条件较差或Unix平台的地级市，采取自动ftp上传格式化文本文件，再使用Oracle的SQL Loader自动导入数据库；对网络条件较好并且数据量较少的地级市采用SQL Server 2000的DTS功能自动传输数据。
在省级公司（中央数据库）设计分区表，为了防止主键重复，对不同地区采取地区主键+地区号的复合主键策略。根据各地不同的统计规则，利用Oracle包提供的多态函数特性，实现参数多样，独立管理。对历史数据及时归档到历史数据库，保证实时数据库快速查询，缩短备份恢复时间。在SQL Server和Oracle之间建立异构数据库通讯机制。

项目成功与失败的经验归纳：
对分布集中式数据库的处理，要建立完备的文档管理，并且在对某个点集中数据前，要预估网络物理条件和需要传输的数据量大小。直接连接的数据库要规定好访问用户的权限、资源设定，防止数据集中对各点数据库的安全、性能带来影响。原来采用了SQL Server的复制/发布功能，但是由于健壮性不够，并且耗时过长，最后弃用。

你在项目中岗位与贡献：
岗位：数据集中策略设计者
贡献：对各点采用不同集中策略。评估可行性，并且应用不同数据库技术实现数据集中功能。

项目四：项目名称
项目简介（功能与用途）：
山西省电力公司MIS系统。主要用于控制管理电力设备，为管理人员提供最新的设备运营信息。
后台数据库：Oracle9i

项目难点与解决方案：
难点：数据量较大，业务功能算法比较复杂，使用PL/SQL实现比较复杂，即使满足也容易破坏算法的严谨性，同时与数据库数据交互较多。而且要求在数据库实现文件和网页的检索功能。

解决方案：由于业务实现需要堆栈、二叉树链表等高级数据结构较多，于是采用了Oracle提供的Java存储过程。虽然正确的评估了Java对象的运行需求内存，并相应的配置了Oracle的Java池。但是在Java存储过程达到一定的阀值后（根据Java对象的算法复杂程度）系统的CPU资源占用急剧升高，更新到最新的补丁也无济于事。查看Oracle的MetaLink没有找到相关答案。最后适当减少Java存储过程数量后，系统正常。
对数据库要求提供检索网页和文件的功能实现，主要依靠Oracle9i提供的UltraSearch功能。UltraSearch功能能够提供对文件和网页的检索功能，可以通过其自身的Web页面进行展现也可以自行编写展现程序。由于属于Oracle比较新的功能，Bug较多。需要至少升级到9.2.0.5才能正常使用。而且要求数据库是UTF8模式。

项目成功与失败的经验归纳：
在没有试用评估某种新功能之前就贸然用于生产系统是有很大风险的。对复杂功能的实现除非必要，不要大规模使用Java存储过程。目前新上市的SQL Server 2005所提供的.Net数据库对象也应该在压力测试通过的前提下谨慎使用。
在应用之前最好准备几种备选方案，当首选方案无法实现的情况下，采取其他方案进行弥补。

你在项目中岗位与贡献：
岗位：数据库DBA
贡献：主要负责数据库SGA参数配置，UltraSearch等新技术的配置实现。


项目五：项目名称
项目简介（功能与用途）：
鞍山市电力MIS系统。主要用于电力企业信息管理。
后台数据库：SQL Server 7.0

项目难点与解决方案：
难点：这个系统的并发性和数据量并不算大（百万级）。但是由于原来数据库设计人员过于遵循了数据库的范式理论，导致程序员在开发阶段需要频繁进行关联表操作。在数据量不大（百万级）的情况下，程序运行非常缓慢。

解决方案：通过调试较慢的存储过程和程序，发现在关联多表查询的时候，由于没有设定足够的where条件，导致查询语句产生笛卡尔积，原本应该得到百万级的记录，却返回了数亿级的重复记录。由于最后的语句进行了distinct过滤，程序开发人员没有发现在中间执行过程中的笛卡尔积问题。为查询语句加上足够的where过滤条件，消除了查询中的笛卡尔积。
笛卡尔积现象出现的根本原因是由于表设计过于分散，而且为程序开发人员开发上带来了很大的麻烦。将类似于档案表等静态信息表从3NF适当回退到2NF，冗于了需要频繁关联的字段。系统性能得到提升。

项目成功与失败的经验归纳：
数据库物理设计时一定要考虑是否能够方便前端的程序开发。应该将数据库设计和程序开发作为整体全盘考虑。
你在项目中岗位与贡献：
岗位：数据库DBA
贡献：解决Bug，修改原来的数据库设计。