项目经验-王忠海

 项目一：刑侦综合信息系统数据库规划
项目简介（功能与用途）：
本项目是某省公安厅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的问题以前我也没有遇到过，通过查GOOGLE、Oracle官方技术支持网站metalink也没有得到合适的解决方法。最后根据alert日志的各种信息，通过重建只包含系统表空间的控制文件能够将数据库启动起来，接下来手动添加其它表空间，最终得以恢复。其间主要遇到的错误有ORA-01189、ORA-01190、ORA-00600[25012]、ORA-01192，主要的解决方法是通过重建控制文件并手动添加其它表空间，使用_allow_resetlogs_corruption和_offline_rollback_segments隐含参数来强制打开数据库。这个库恢复起来很费周折，整整折腾了将近20个小时。从这个恢复的案例上可以充分体会到备份数据的重要性。

我在项目中岗位与贡献：
从灾难中恢复数据，并进一步提高了恢复数据的能力。