問題描述

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月前發布。