//文章由紫金桥软件公司张工提供
   今天心情好象比往天要好些，可能是因为数据转储功能已经投用。刚到办公室，桌上电话又急促地响了起来。通过来电显示我知道，电话是天然气生产指挥系统（这个系统是基于紫金桥实时数据库创建的）用户打来的，我急忙接起电话。电话那端的用户说话还是很平静的，但是平静中已露出稍许的不耐烦了，催问着：“你们的数据转储断线恢复功能还没投用       吗？我们报表中的数据怎么还是异常值呢？”。我问明了是哪个大队、哪个岗位及哪几个数据量后，说明我会尽快查找原因，就放下了电话。坐在座位上，我不仅很是奇怪，怎么还会这样呢？又不仅想起这几周来发生的事情。
   几周前天然气生产指挥系统进入了联合试用阶段，我们将系统的各个环节按着正式运行方式重新设置了一遍：
   1．服务器所有远程数据源都启用断线恢复功能（自动恢复网络故障期间前置数采机保存的历史数据），指定恢复时限为1天；
   2．将所I/O连接的数据源故障时的处理方式设置为“系统故障值”；
   3．在前置数采机将数据恢复文件大小设置为500MB。
  一切准备就绪，就等着一次测试成功。
   可是当我第二天上班时，就象今天早上一样，用户告诉在系统中有很多异常值。我们认真的检查了整个系统，系统中是有些数据显示为异常值。接着我们查看了远程数据源的状态，发现有些数据源是处于故障状态的（网络是利用原有环境，环节太多，经常出现故障）。分析异常数据点与数据源的关系，我们发现这些异常的数据点都是来源于故障数据源。我们向用户说明了原因，并说明当网络正常后数据就会恢复正常，用户认可了我们解释。
   可是又过了一天，用户又打来电话，“我们已查看了系统状态，现在大部分数据源都正常，为什么数据没有自动恢复？”。我们比对了一下服务器与前置数采机的历史数据，发现数据已经得到恢复。与用户再次勾通后，才知道是报表中的数据没有自动恢复。这时我们才认识问题是出在我们的数据转储工具上，因为报表中的数据是通过数据转储工具得到的。
   数据转储工具是紫金桥实时数据库的一个适用工具，可以用来将紫金桥实时数据库中的实时数据或历史数据转储到关系数据库，以方便用户在关系数据库中进行二次开发。它可以自动转储实时数据，但历史数必须手动转储。
   确定问题后，我告诉用户，可以用手动方式将缺少的数据从历史数据转储过去。可是用户又提出了异议，网络故障这么多，且有这么多数据源，手动恢复怎么处理的过来。想到40几个远程数据源，又这么差的网络，让用户手动恢复确实不可能。
   我决定对数据转储工具进行改进升级，那就增加断线自动恢复功能。断线自动恢复工作原理是：在转储时对被转储数据点的状态进行判断，如果数据点为异常就将其列入恢复对象；当数据状态变为正常后（服务器上历史数据将会从前置数采机得到恢复），转储程序再将紫金桥实时数据库的历史数据转存到关系数据库的数据表中。
   经过这几周的编程和测试，我们才将其应用到实际系统中。在此期间，我们还增加一些特殊情况处理，如：转储程序进行时有数据需要恢复，但这时由于系统维护需要程序重新启动，这时可以确保这部分乃可以得到有效恢复。
   回想到这些，也使我有点怀疑：“难到我们程序还不够严密，还有些情况没有考虑到吗？”。于是我根据用户提供的信息，对系统进行检查。首先，查对了关系数据库中对应的数据，确认数据确实为异常值；其次，根据大队和岗位信息，我确定了远程数据源，并且查对了数据源的状态，发现数据源是故障状态。
   查到这里我又有点放心了，远程数据源为故障状态，数据当然为异常值，数据也不可能得到恢复。我向用户说明原因，用户说，他们会检查相关网络。
两小时后，网络恢复正常，数据也得到有效恢复。数据转储断线自动恢复成功！我为我们软件又一进步高兴！。