第2部分第7章軟件系統(tǒng)使用維護

第七章監(jiān)控中心的軟硬件維護第一節(jié)硬件與傳輸設備的維護一、檢查服務器供電電源市電停電時是否能保證服務器不掉電。若供電電源不能保證服務器的正常運行，請及時維護。服務器的供電必須使用不間斷電源，通常使用整流器48V逆變或UPS電源。采取這種供電方式時，電池組是并在電源上的，市電停后，一般不會出現(xiàn)電池無法供電的情況。但為預防突發(fā)情況，必須進行此項測試。測試時將服務器上運行的所有應用程序退出，包括操作系統(tǒng)和數(shù)據(jù)庫管理軟件，并推出到服務器可關機的模式下，此時人為切斷市電進行測試。如果電池未能切換成功導致掉電，也不會損壞服務器的軟件和硬件。二、檢查傳輸設備工作狀態(tài)可通過觀察設備指示燈來判斷設備的運行狀況。傳輸資源是否有不通或不穩(wěn)定的現(xiàn)象。若全部不通，請檢查公共部件及設備，如集線器，路由器遠程存取服務器等；若個別局不通，請按順序檢查網(wǎng)線是否插好，連線是否有松動現(xiàn)象，檢查接入設備是否正常，若都是好的，請有關部門人員協(xié)助檢查線路。詳細操作，請參考有關設備手冊。傳輸資源是否穩(wěn)定可以根據(jù)日常維護的積累。例如，哪些局經(jīng)常通信中斷，每月中斷5次以上的可以視其傳輸不穩(wěn)定。第二節(jié)數(shù)據(jù)庫、服務器及應用軟件系統(tǒng)維護一、服務器和數(shù)據(jù)庫系統(tǒng)服務器是否有剩余空間的信息提示。若有請及時利用數(shù)據(jù)管理軟件進行數(shù)據(jù)備份并利用數(shù)據(jù)庫調測工具刪除數(shù)據(jù)。詳細操作可參考相關數(shù)據(jù)庫管理軟件操作說明。檢查數(shù)據(jù)庫剩余空間，以此判斷寫入量是否正常、是否有突發(fā)的大量寫入?？梢允褂脭?shù)據(jù)庫調測工具來進行歷史數(shù)據(jù)分析和數(shù)據(jù)庫運行狀態(tài)檢查。詳見數(shù)據(jù)庫調測工具使用方法。二、應用軟件系統(tǒng)1、各工作站是否通訊正常。檢查系統(tǒng)有無出現(xiàn)較高頻率的工作站通訊中斷告警。如有可從兩個方面檢查。一個是端局工作站是否正常，另一方面，檢查傳輸是否穩(wěn)定。2、遠程啟動前置機測試。在業(yè)務臺上進行遠程啟動前置機操作，保證緊急情況下前置機能夠被正常的啟動，以便迅速排除前置機死機等故障。三、病毒檢查計算機病毒的檢查。定期檢查計算機病毒可以有效的防止系統(tǒng)發(fā)生突然故障，而導致的措手不急?？梢园惭b諸如瑞星殺毒軟件、KILL98等防止、清除病毒的軟件。第三節(jié)艾默生PSMS常見故障處理（一）業(yè)務臺和數(shù)管臺1、監(jiān)控模塊中實時數(shù)據(jù)刷新速度很慢【問題描述】從業(yè)務臺進入監(jiān)控模塊查看某端局的實時數(shù)據(jù)，進入后信號處于未知狀態(tài)，要等待幾分鐘后，信號值才被刷新，信號變?yōu)橛行顟B(tài)，有時長達5分鐘?！驹蚍治觥浚?）為了降低端局數(shù)量，在配置時將二十多個基站合成一個端局，于是造成每個端局的信號量很大，而業(yè)務臺發(fā)控制命令讓前置機上送實時數(shù)據(jù)的單位是端局，于是每次前置機需要上送上千條的實時數(shù)據(jù)；（2）前置機與監(jiān)控中心的傳輸是通過撥號方式進行通訊的，帶寬很窄（19.2K），數(shù)據(jù)傳輸很慢；這樣，要傳輸?shù)臄?shù)據(jù)量很大，傳輸速率又很低，于是導致數(shù)據(jù)刷新很慢?！窘鉀Q方法】（1）將端局減小，可以幾個基站合成一個端局，從而減少每次前置機上報的實時數(shù)據(jù)量；（2）改善傳輸通道，增加帶寬；（3）減少每個基站配置中的不重要信號，從而減少整個系統(tǒng)的信號量。2、SC與SS告警內容不一致【問題描述】系統(tǒng)運行一段時間后，在SC有許多未結束告警和已結束告警無法確認掉；在對應SS查看這些告警時，發(fā)現(xiàn)這些都已經(jīng)被移到歷史告警表中，從而導致SC的這部分告警永遠存在?！驹蚍治觥繉τ赟C和SS告警數(shù)據(jù)的一致性系統(tǒng)一直無法保證，特別是告警數(shù)據(jù)，每一條告警可能被分成三步上送到SC，第一步是告警產(chǎn)生；第二步是告警結束；第三步是告警確認；（其中，二、三步可能調換）如果在這三步中的第一步就丟失了復制數(shù)據(jù)，則在SC丟失該告警，如果在第二、三步丟復制數(shù)據(jù)，則是告警無法結束或結束告警無法確認。隨著三級結構的增多和系統(tǒng)運行時間的增長，SC和SS告警數(shù)據(jù)的一致性問題將越來越突出?！窘鉀Q方法】方法1可以通過如下步驟去同步SC與SS的告警：步驟1在確認SC與各個SS連接都正常的情況下，刪除SC當前告警表中2個小時前的告警，假設當前時間是2000-02-2211:50:00，使用SQL語句（deletefromRunAlarmMsgewhereStartTime<"2000-02-2210:00:00"）；步驟2通過SC業(yè)務臺連接到某個SS，執(zhí)行SQL語句（select*intotempAlarmfromRunAlarmMsgewhereStartTime<"2000-02-2210:00:00"）；注意，where條件中的時間"2000-02-2210:00:00"要與步驟1條件中的時間"2000-02-2210:00:00"一致；步驟3將步驟2生成的表tempAlarm中的數(shù)據(jù)倒到文本文件中，在命令行使用命令（bcpdatabase_name..tempAlarmoutalarm.txt-Sserver_name-Uuser_name-Ppassword-c），其中斜體部分需要根據(jù)具體SS的數(shù)據(jù)庫名和用戶情況替換；步驟4將步驟2生成的臨時告警表tempAlarm刪除，使用SQL語句（droptabletempAlarm）步驟5將步驟3生成的文本文件alarm.txt中的告警數(shù)據(jù)倒入SC當前告警表中，在命令行使用命令（bcpdatabase_name..RunAlarmMsgeinalarm.txt-Sserver_name-Uuser_name-Ppassword-c），注意：該處的server_name和database_name是SC數(shù)據(jù)庫的；步驟6對每個SS重復步驟2~步驟5；步驟7將SC業(yè)務臺告警模塊卸載，然后重新加載；方法2如果SC告警SS告警頻繁出現(xiàn)不一致現(xiàn)象，并且局方對此問題很重視或會影響驗收，甚至市場時可以考慮將PSMS435升級到PSMS436，在PSMS436的業(yè)務臺中已做了SC與SS的告警同步處理。3、前置機通訊中斷告警【問題描述】前置機通訊中斷告警【原因分析】首先，需要判斷前置機通訊中斷是否是因為網(wǎng)絡通訊中斷引起的，至于判斷方法可以在前置機通訊中斷時在業(yè)務臺Ping前置機，如果是網(wǎng)絡問題則找網(wǎng)管了解網(wǎng)絡情況；其次，在確定不是網(wǎng)絡本身中斷后，在業(yè)務臺報表模塊查詢系統(tǒng)告警，觀察前置機通訊中斷時間及時間間隔，可能有兩種情況，一是很多前置機在晚上0點左右總出現(xiàn)通訊中斷告警；另一種可能是前置機通訊時好時壞，每次通訊中斷時間很短，一般不超過一分鐘就恢復通訊；對于第一種情況，是由于前置機在晚上0點左右需要上報前一天的統(tǒng)計數(shù)據(jù)，由于前置機較多或部分前置機上報信號量較大，導致數(shù)據(jù)庫表鎖，上報統(tǒng)計數(shù)據(jù)效率降低；對于第二種情況，如果前置機真正中斷或重啟，至少需要3~5分鐘，因此可以斷定前置機運行是正常的，而通訊中斷應該是由于業(yè)務臺判斷前置機報到超時引起的，即前置機的超時時間設的太短?！窘鉀Q方法】（1）對于網(wǎng)絡本身中斷引起的前置機通訊中斷告警，解決網(wǎng)絡存在問題；（2）對于在晚上0點左右的通訊中斷，可以通過將存儲過程spro_staticsdata_report升級成PSMS435補丁版或以后的版本；（3）對于前置機通訊時好時壞，在業(yè)務臺的工作站管理中將通訊中斷頻繁發(fā)生的前置機的超時時間改為180秒；但需要注意的是，如果不修改配置中的工作站超時時間，在下次刷新配置時又會出現(xiàn)同樣的問題，因此，建議在每次修改配置時都從數(shù)據(jù)庫中下載，然后再修改刷新數(shù)據(jù)庫，已保證數(shù)據(jù)庫中的配置是最新的。4、業(yè)務臺出現(xiàn)“數(shù)據(jù)庫空間不足，剩余XXk字節(jié)”的告警【問題描述】在業(yè)務臺出現(xiàn)“數(shù)據(jù)庫空間不足，剩余XXk字節(jié)”的告警，但通過sp_helpdb查看該數(shù)據(jù)庫，發(fā)現(xiàn)該數(shù)據(jù)庫還有XXM剩余數(shù)據(jù)空間。【原因分析】數(shù)據(jù)管理臺在檢測到數(shù)據(jù)庫的剩余數(shù)據(jù)空間小于（數(shù)據(jù)庫總數(shù)據(jù)空間*安全因子/100）時就會產(chǎn)生該告警。但告警信息中的“剩余XXk字節(jié)”的單位k是錯誤的，應該是M(兆)才對，該錯誤在PSMS436中已修改；另外，數(shù)據(jù)管理臺的INI文件DbBackup.ini中的安全因子SafeFactor缺省值為25，該值設置較大，例如某數(shù)據(jù)庫數(shù)據(jù)空間為2G，那么當數(shù)據(jù)剩余空間小于500M時就會產(chǎn)生數(shù)據(jù)庫空間不足告警，因此，建議在發(fā)現(xiàn)有該告警的數(shù)據(jù)管理臺上將安全因子減小，只要不低于10就可以了?！窘鉀Q方法】（1）退出數(shù)據(jù)管理臺；（2）打開數(shù)據(jù)管理臺的INI文件DbBackup.ini，將安全因子SafeFactor減小到10；（3）重新運行數(shù)據(jù)管理臺。（二）服務器和數(shù)據(jù)庫1、服務器在異常掉電后操作系統(tǒng)無法啟動【問題描述】服務器在異常掉電后，操作系統(tǒng)不能啟動?！驹蚍治觥糠掌髟诋惓嚯姾笫褂脖P被損壞，NT啟動時ScanDisk不能通過?！窘鉀Q方法】（1）在確認操作系統(tǒng)無法恢復后（如果有緊急恢復盤，可用緊急恢復盤恢復系統(tǒng)），重新安裝NT操作系統(tǒng)；（2）備份原數(shù)據(jù)庫的MASTER設備、系統(tǒng)存儲過程設備；（3）重新安裝SYBASE，但不創(chuàng)建數(shù)據(jù)設備和日志設備，也不創(chuàng)建應用數(shù)據(jù)庫；（4）在控制面板的服務里停掉Sybase，將原來備份的數(shù)據(jù)庫的MASTER設備、系統(tǒng)存儲過程設備拷貝到新安裝Sybase的對應目錄下覆蓋新的MASTER設備、系統(tǒng)存儲過程設備；（5）啟動Sybase來恢復原數(shù)據(jù)庫中的數(shù)據(jù)。注意：該方法只能恢復數(shù)據(jù)庫設備所在硬盤扇區(qū)沒有被損壞的情況；如果數(shù)據(jù)庫設備所在硬盤扇區(qū)被損壞，可能會導致數(shù)據(jù)庫無法正?；謴?，這時就只有通過磁盤修復工具修復硬盤，如果能修復，則直接重裝整個數(shù)據(jù)庫，如果不能修復，則只有格式化硬盤后再重裝整個數(shù)據(jù)庫。2、做大事務操作導致數(shù)據(jù)庫日志滿【問題描述】對數(shù)據(jù)庫做需要記錄日志的操作（update、delete或insert）時，系統(tǒng)提示數(shù)據(jù)庫日志已滿，等待日志空間恢復信息?！驹蚍治觥?.數(shù)據(jù)庫選項“trunclogonchkpot”沒有設置，導致數(shù)據(jù)庫日志累計，是數(shù)據(jù)庫日志空間滿；2.數(shù)據(jù)庫的日志空間太小，做一個較大的事務就導致數(shù)據(jù)庫日志空間不足；【解決方法】步驟1使用SQL語句“sp_helpdbdatabase_name”查看數(shù)據(jù)庫database_name中的日志使用情況，如果確實是日志滿，則繼續(xù)以下步驟；步驟2使用SQL語句“dumptrandatabase_namewithtruncate_only”清除數(shù)據(jù)庫database_name中的日志；步驟3重復步驟1，如果數(shù)據(jù)庫database_name的剩余日志空間已恢復，則跳到步驟5執(zhí)行，否則進行步驟4操作；步驟4使用SQL語句“dumptrandatabase_namewithno_log”直接截斷數(shù)據(jù)庫database_name的日志，使數(shù)據(jù)庫database_name的日志空間釋放；步驟5檢查數(shù)據(jù)庫日志空間，如果小于100M，則增加數(shù)據(jù)庫設備，擴展數(shù)據(jù)庫日志空間到200~300M。3、復制服務通訊經(jīng)常中斷【問題描述】（1）復制服務器在數(shù)據(jù)庫重啟或服務器重啟后，長時間不能自動恢復數(shù)據(jù)復制，導致SS的告警等數(shù)據(jù)不能復制到SC；（2）復制服務器與數(shù)據(jù)庫通訊一會兒正常，一會兒中斷?！驹蚍治觥繉τ诂F(xiàn)象1，首先通過Ping判斷SC與SS的網(wǎng)絡是否中斷，如果網(wǎng)絡中斷，需要找網(wǎng)管，如果網(wǎng)絡正常，則查看復制服務器的版本，如果是PSMS435補丁版以前的版本，可以通過升級復制服務器來解決；對于現(xiàn)象2，首先通過Ping或其它工具判斷SC與SS之間的網(wǎng)絡是否穩(wěn)定，如果不穩(wěn)定，則找網(wǎng)管了解情況；如果很穩(wěn)定，則查看復制