問題描述

B市電信一基站用Metro1000設(shè)備，在頻繁掉電后網(wǎng)元配置丟失。

告警信息

本站無告警，對端站點有hp-uneq告警。另外，在該網(wǎng)元發(fā)生故障當(dāng)天，對端站點發(fā)生了90余次R_LOS告警，可以判斷該網(wǎng)元當(dāng)時電源環(huán)境非常惡劣。

處理過程

將該網(wǎng)元的配置通過網(wǎng)管重新下載后，恢復(fù)正常。

根因

從黑匣子bb0.log（見附件）中可以看出該網(wǎng)元是在22點剛過丟的配置(網(wǎng)元時區(qū)為北京時區(qū)，所以bb0記錄的時間為網(wǎng)元時間+8),(22:00加8小時=凌晨06:00)配置就已經(jīng)丟失，板位信息只剩下主控上自動創(chuàng)建的四個板位，需從數(shù)據(jù)庫中恢復(fù)的板位全部丟失。

什么會在這個時間點出現(xiàn)配置丟失呢？在網(wǎng)元時間22點時網(wǎng)元會做的一個動作就是數(shù)據(jù)庫自動備份(M1000V3網(wǎng)元默認(rèn)會在每天的22點時進(jìn)行數(shù)據(jù)庫自動備份操作)。OSP平臺專家分析的結(jié)論如下：從重現(xiàn)出來的故障來看，并非所有數(shù)據(jù)庫配置都丟失，只有產(chǎn)品數(shù)據(jù)庫（包括邏輯板位、交叉等配置數(shù)據(jù)庫）丟失了，而平臺的數(shù)據(jù)庫并未丟失；這是由于網(wǎng)元掉電起來，剛好碰到網(wǎng)元自動備份時間22:00，觸發(fā)OSP平臺對所有數(shù)據(jù)庫進(jìn)行自動備份，備份的流程是mdb -> drdb -> tdrdb -> fdb，網(wǎng)元啟動時，OSP備份任務(wù)（優(yōu)先級150）先進(jìn)行，做 mdb -> drdb -> tdrdb ,空數(shù)據(jù)備份到 tdrdb，此時產(chǎn)品任務(wù)開始創(chuàng)建產(chǎn)品數(shù)據(jù)庫（優(yōu)先級130，優(yōu)先級比OSP備份任務(wù)高，因此會搶占OSP備份任務(wù)），此時fdb還有數(shù)據(jù)，產(chǎn)品創(chuàng)建數(shù)據(jù)庫從fdb中恢復(fù)出配置，然后會即時備份到drdb，因此drdb有數(shù)據(jù)；最后OSP備份任務(wù)繼續(xù)執(zhí)行，將空配置的tdrdb備份到fdb中，因此fdb數(shù)據(jù)丟失，并且僅僅是產(chǎn)品數(shù)據(jù)庫丟失。

建議與總結(jié)

1、保持機(jī)房電源穩(wěn)定，避免設(shè)備頻繁掉電；

2、研發(fā)修改版本，修改產(chǎn)品軟件中創(chuàng)建數(shù)據(jù)庫的時機(jī)，不要在任務(wù)中創(chuàng)建，將其前移至assemble里完成。(OSP數(shù)據(jù)庫備份任務(wù)是要等assemble完成以后才會開始運行，此時保證所有數(shù)據(jù)庫都已創(chuàng)建恢復(fù)完成，這樣就可以徹底解決此問題) 解決問題的軟件版本預(yù)計在2011年12月前發(fā)布。