项目经验-许震

最新推荐文章于 2024-11-15 22:11:31 发布

best_dba

最新推荐文章于 2024-11-15 22:11:31 发布

阅读量1.1k

点赞数

分类专栏： “2006中国杰出数据库工程师评选”复选选手参赛文章集文章标签：数据库 sql server 终端 sql 网络报表

本文链接：https://blog.csdn.net/best_dba/article/details/1032466

版权

“2006中国杰出数据库工程师评选”复选选手参赛文章集专栏收录该内容

111 篇文章 0 订阅

订阅专栏

项目一：某省养路费收缴系统

项目简介（功能与用途）：

该项目由中心数据库、网站、固定终端和移动终端构成。数据库采用微软SQL Server 2000，网站使用微软IIS＋ASP搭建，移动终端使用PDA＋SQL CE版数据库。

基本功能如下：

用户可以在公路局门市交纳养路费，由门市的固定终端系统递交到中心数据库。用户可以在固定终端查询到自己的交纳信息。也可以在任何地方通过Internet查询收缴系统Web站点获得。

同时由于养路费收缴和稽查的流动性问题，若干稽查人员配备移动终端在路口、道闸进行现场检查和收费。移动终端和中心数据库采用数据库复制的方式进行同步，提前将漏缴、拖欠、滞纳信息同步到移动终端上，当在路上对怀疑车辆检查发现有漏缴、拖欠、滞纳的，即时交纳罚款，出具发票。稽查人员现场将信息记录到移动终端的SQL CE中去，晚上回到门市即将终端和中心数据库同步，同时将新的拖欠、滞纳信息同步到移动终端上。

整个复制采用一对多模型，复制模式采用合并复制，由于合并复制机制的灵活性，即解决了多个终端的冲突问题，在将来终端增多时系统也无需太大变更。

项目难点与解决方案：

养路费收缴系统的功能比较单一，所以说这个项目本身的开发没有太大的难点，一个典型的CS＋BS模式的应用而已。

难点主要集中在要实现分布式办公和移动终端，同时要满足数据同步。而且多个终端还可能存在的冲突和遗漏的问题。

而解决的关键就是应用了微软SQL Server 2000的复制技术。采用合并复制也是由于该模式比较灵活——中心数据库和多个移动终端可以双向复制。也就是说，不管用户是在门市交纳还是公路现场交纳，其交纳信息都可以同步到中心数据库和所有终端。而且考虑了移动终端当时较小的容量，复制中采用了筛选，只有漏缴、拖欠、滞纳和即将到期的信息才同步到终端。同时一天一次的同步，其数据同步潜伏期也是满足应用需求的。

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

该项目的成功经验在于灵活使用了SQL Server 2000的合并复制，达到了分布式数据库的目的，而且实现费用非常节省。

比较新颖的地方是移动终端的实现，使整个系统具有了一定的主动性，不再象传统的收费系统那样被动等待用户交纳。该系统略做修改，还可以实现上门收缴，移动办公等功能，在政府倡导人性化办公中也是有一定的应用价值的。尤其是对于当时无线办公还是非常昂贵，人员场地不足的情况下有非常大的价值。因此当该项目在省路政部门上马以后，获得了一致好评。

你在项目中岗位与贡献：

本人负责整个项目的规划、数据库系统的架构、复制模型的确定以及最终的产品选型。在整个项目的开发和实施过程中，本人一直参与其中，作为负责人和技术顾问，提供了非常重要的支持。

项目二：某医院数据库系统的抢修

项目简介（功能与用途）：

南方某市一个三甲医院数据库系统由于群集阵列的崩溃，HIS数据库系统瘫痪，需要紧急抢修。通过连续两个昼夜的紧急抢修，终于恢复正常，没有影响医院业务。

项目难点与解决方法：

该项目属于突发性紧急现场项目。由于该医院是一家市级三甲医院，每天的营业额高达200W，而由于缺乏必要的技术支持，导致HIS系统数据库崩溃，直接导致业务中断。系统采用常见的CS结构，后台是一个SQL Server 2000群集。

主要的难点在于SQL Server 2000的数据库恢复机制比较简单，而医院由于缺乏技术实力，竟然没有进行必要的备份！同时由于长久没有维护，数据和日志文件高达近百GB。而本人接到紧急现场电话时，已经是晚上，第二天上午6点医院将开门营业，任务重，时间紧！

在没有备份情况下，要完成数据库的恢复只有采取非常规方式。医院方面首先使用了分离/附加方式，结果分离后数据库直接不能识别，为后续工作又添加了障碍。

本人首先创建一个同名数据库，然后在停止数据库服务的情况下，用原来的文件替换该数据文件，在重启后使数据库可以识别，但状态成为“只读/恢复/脱机/置疑/正在装载/紧急模式”。然后强行修改系统数据库，使状态成为可以读的状态。然后通过DBCC命令检查数据库，发现400多个数据表中大部分已经损坏，通过DTS和BCP命令都无法读取数据。因此决定使用最基本的select语句读取数据。为了避免读取数据时读到坏块，只好使用top n关键词，首先读取表中前面部分的数据。同时考虑有400多个表，一个个构造语句时间肯定来不及，因此通过系统表，调用所有用户表名称，通过VBS脚本构造了400多个SQL语句，然后在查询分析其中运行。通过一个晚上的运行，将绝大部分数据库读取并写入另一个空数据库中，通过分离附加等手段，新数据库改名上马成功接替原有数据库。

通过检查，将近有半天的数据丢失，这在SQL Server 2000无备份情况下是非常成功的。基本没有影响业务。

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

这个数据库成功恢复的主要经验在于充分使用系统数据库的信息，通过强行修改系统数据库，达到改变业务数据库的状态。通过构造特别的select语句，避开了大部分损坏数据，从而使数据导出可以进行下去。否则一旦读取坏块，不仅恢复工作要中断，甚至可能会导致进一步损坏。

而且通过读取系统数据库调出了所有用户表（要恢复的数据所在）的名称，通过VBS脚本自动构造了400多个SQL语句，为紧急抢修数据库争取了时间。

不得不说的是，对于SQL Server 2000数据库，备份还原是最主要的数据恢复手段，一定要引起重视，这个项目中数据库恢复成功，下次可能就没有这么好的运气了。

你在项目中岗位与贡献：

整个项目完全由本人实施，通过一个通宵的紧张工作，数据库恢复正常，数据抢救出来，并赶在第二天营业前使HIS系统可以工作。

由于我的努力，使医院方面避免了极大的经济损失，因此本人获得了院方领导的极高评价。

项目三：某保险公司网络监控系统

项目简介（功能与用途）：

某境外保险公司需要在公司网络上实现实时的网络浏览监控，要充分利用现有资源，而不需要额外投入。该公司使用微软的ISA Server 2004实现WEB代理，所有的网络浏览都是通过该防火墙服务器出去，因此在该服务器的日志中保存有所有的代理信息。ISA本身有非常详细的日志和报表功能，但报表不能实现实时监控，而日志虽然可以实现实时，但没有统计和人性化的界面（ISA的日志是给安全管理员进行网络排错用的，不具备可读性）。

本人利用ISA自带的MSDE（一个简化的SQL桌面引擎），通过脚本调用SQL自带的WEB输出模块——XPWEB70.DLL——将代理信息进行统计，排序，利用WEB模板转变成可读的页面形式，并且可以用计划任务定期生成或实时调用。

项目难点与解决方法：

这个项目的难点在于MSDE是一个简化的SQL引擎，没有管理界面。而且ISA在其中存储的信息是自有格式，例如IP地址的存放，不是我们熟悉的A.B.C.D这种段分十进制。还有就是ISA每一天都会产生一个新的数据表，表名包含日期也一个随即序列号，给数据库连接带来了困难。WEB输出模块的功能也非常简单，基本没有可读性。