版本问题导致Metro1000掉电后配置丢失

问题描述

B市电信一基站用Metro1000设备，在频繁掉电后网元配置丢失。

告警信息

本站无告警，对端站点有hp-uneq告警。另外，在该网元发生故障当天，对端站点发生了90余次R_LOS告警，可以判断该网元当时电源环境非常恶劣。

处理过程

将该网元的配置通过网管重新下载后，恢复正常。

根因

从黑匣子bb0.log（见附件）中可以看出该网元是在22点刚过丢的配置(网元时区为北京时区，所以bb0记录的时间为网元时间+8),(22:00加8小时=凌晨06:00)配置就已经丢失，板位信息只剩下主控上自动创建的四个板位，需从数据库中恢复的板位全部丢失。

什么会在这个时间点出现配置丢失呢？在网元时间22点时网元会做的一个动作就是数据库自动备份(M1000V3网元默认会在每天的22点时进行数据库自动备份操作)。OSP平台专家分析的结论如下：从重现出来的故障来看，并非所有数据库配置都丢失，只有产品数据库（包括逻辑板位、交叉等配置数据库）丢失了，而平台的数据库并未丢失；这是由于网元掉电起来，刚好碰到网元自动备份时间22:00，触发OSP平台对所有数据库进行自动备份，备份的流程是mdb -> drdb -> tdrdb -> fdb，网元启动时，OSP备份任务（优先级150）先进行，做 mdb -> drdb -> tdrdb ,空数据备份到 tdrdb，此时产品任务开始创建产品数据库（优先级130，优先级比OSP备份任务高，因此会抢占OSP备份任务），此时fdb还有数据，产品创建数据库从fdb中恢复出配置，然后会即时备份到drdb，因此drdb有数据；最后OSP备份任务继续执行，将空配置的tdrdb备份到fdb中，因此fdb数据丢失，并且仅仅是产品数据库丢失。

建议与总结

1、保持机房电源稳定，避免设备频繁掉电；

2、研发修改版本，修改产品软件中创建数据库的时机，不要在任务中创建，将其前移至assemble里完成。(OSP数据库备份任务是要等assemble完成以后才会开始运行，此时保证所有数据库都已创建恢复完成，这样就可以彻底解决此问题) 解决问题的软件版本预计在2011年12月前发布。