下载文档第一篇：传输专线业务故障简易处理小结-王中玲
传输专线业务故障简易处理小结
作者：阿盟客响中心 王中玲
在我们日常的维护工作过程中，大客户专线业务经常回出现例如闪断、线路丢包等故障现象，此类故障一般还不容易判断故障点在哪里。在此，分析此类故障在日常维护过程中的小经验，以供大家共同学习参考。
(一)闪断现象
1．传输网络有别于局域网，它由许多个传输系统共同组成，用户开 通的电路经过若干个传输网元设备和光缆线路。传输系统之间具 备一定的保护机制，出现线路或设备故障时将产生切换保护动作，该保护动作将产生瞬间中断的现象，为此，按国际惯例SDH/MSTP 电路可用性设置在≥99.99%。每次保护瞬断的时间50ms，但由于这个过程，会导致用户路由器端口协议会有中断的情况，引起用户端路由器协议需要重新协商，会造成电路在路由器上显示有瞬断的情况。2．当出现闪断现象后，客户首先要记录瞬断时间和时长，统计瞬断 是否规律性发生。如果闪断是偶尔出现的状况，说明电路仍然处 于正常运行，暂时无需报障；如果频繁出现可进行以下简易预处 理。
3．检查用户端机房内线路经过的路径上是否出现新增强电场干扰。4．检查接线是否松脱，可以拨动、整理一下线缆及接头，如果是由 于松动导致的，必然再次产生一个瞬断。
(二)线路丢包
1．SDH/MSTP 以太网专线丢包率要求<0.01％，客户可以通过ping 测 试，发送10000 个64 字节的数据包，观察丢包是否超出指标范围。2．首先检查是否线路负载过高导致丢包。对于2M 以下电路来说，该 现象比较常见，2M 电路提供下载速率大约在230KByte/s，折算后 实际带宽约1.8M，当流量过大的情况下，例如发送Email 附件、下载等应用几乎耗尽所有带宽，导致丢包。客户首先要登录出口 设备路由器或交换机，查看端口当前的流量大小，请在业务流量 较小的情况下进行测试。
3．线路质量导致丢包。由于线路、接头暴露在自然环境中，随着时 间的推移将产生不同程度的氧化或阻抗增大现象，这是一种自然 现象。如果排除因流量过载的情况，用户可以自行清理一下线路 的接头位置，排除线路接头原因外，则需要运营商协助共同排查。(三)线路误码增加
1．时钟失步导致误码。对于SDH 线路均提供线路时钟，客户端的接 入设备的端口一般需要配置时钟源是线路时钟。业务开通后，即 使时钟不同步线路仍然能正常运行，但随着时间的增长，链路两 侧的设备就会出现时钟失步现象，导致端口CRC 校验错不断增加。2．线路过长，电信号劣化误码。双绞线最大传输距离为100 米，细 缆传输距离小于185 米，粗缆最大传输距离为500 米。客户对于 距离过长的线路可以通过缩短距离解决。
3．线路是否被损伤，被挤压，特别注意光纤线路的不能弯曲。对于 光纤要求弯曲半径要尽量大,在施工时光纤弯曲半径要大于20 倍 光缆直径，静态弯曲半径不小于10 倍光缆直径（对圆形光缆）。
以上简单介绍了数字专线的几种常见故障的处理原则，仅供参考。
第二篇：传输及动力故障处理简易教材
一、传输部分
传输故障现象及处理方法： 传输及动力故障处理简易教材
1、基站退服，主设备传输板上的告警会红灯长亮，光线路复用终端机（PDH）上有告警（一般为“收无光”、“收失步”、“2M中断”亮红灯）。该类故障一般为传输线路中断故障，基本流程如下图： 首先在基站内DDF架上做电路环回（两端都环），会出现3种情况：
1）本端不通，这时应检查基站内的传输线路，主要检查站内DDF架至机柜间传输的接头和光端机。
2）本端通、对端通，这时应该检查DDF架的2M线的连接头是否有损坏。
3）本端通、对端不通，说明从DDF架到机柜的传输是通的，再进行下一步的环路检查，到ODF架上做光路环回（两端都环）：
1）本端不通，这时检查ODF架至DDF架之间的传输线路及接头。因为上一步环路检查为DDF架至机柜的传输是通的，如果在这里不通，说明从ODF架至DDF架之间的传输有故障。
2）本端通、对端通，这时主要应检查连接尾纤的法兰头，传输放直的时候传输中断，但两端都环起来后两端都通的话，一般为尾纤连接处（法兰头）损坏，所以平时在拔插尾纤的时候一定要小心，不要将法兰头里的瓷损坏了。
3）本端通、对端不通，说明从ODF架至DDF架之间的传输是通的，目前检查结果为基站内部的传输线路都是好的，现在从基站往外检查，下一步环路检查：在传输节点机房（或155M）做电路（2M）环回：（注意：在传输节点（或155M）最好只做电环）
1）本端不通，这时应检查从节点机房数字分配架至基站ODF架之间的传输。
2）本端通、对端通，这种情况应检查数字分配架上2M头、2M头的连接处是否有松动及2M线是否完好正常。
3）本端通、对端不通，说明从节点机房数字分配架至基站ODF架的传输的通的，那么再进行下一步的环路检查：2.5G机房做电路环回（若传输从155M直接连接到BSC方面，则请求BSC方面传输部门协助）：
1）本端不通，因为上一步检查结果为节点机房数字分配架至基站间的传输是通的，所以这时本端不通就应该检查从2.5G机房至节点机房之间的传输线路。
2）本端通、对端通，这时应该检查2.5G机房里线路的2M头、2M头的连接处是否有松动及2M线是否完好正常。
3）本端通、本端不通，说明从2.5G机房至基站的传输线路是通的，再下一步检查就需要BSC方面传输部门的配合。
2、基站频繁退服，自动恢复，过一段时间又退服，极不稳定。主设备COBA上的指示灯正常，光线路复用终端机上有告警（一般为“10-3/10-6”亮绿灯）。该类故障一般为误码率过高。误码率高的出现可能有几种：
1）尾纤头污染，可以用酒精、棉球擦洗
2）2M头里有很小的地方连接（短路），重做2M线头可以解决。
3）传输途中有的连接头松动，接触不良，建议将所有传输接头紧一遍。
3、基站传输是通的，但信令不通，这种情况一般为在传输线路中某一段有环回。检查方法：从基站开始往上逐步检查传输经过的地方，看有没有环回现象。特殊情况本站和对端光端机因如停电等原因掉死需两端重启。
例：
202_年12月26日，孝昌王店山基站退服，抢修人员赶到基站后发现市电正常，站内所有设备均无告警，但所有CU无法工作。检查传输时，将2M断开主设备COBA上ABIS1亮红灯，光端机也告警，本端环回后告警清除，说明站内传输正常。但联系监控方面，发现对端的2M不管是断开还是环回，监控中心显示该站的传输一直是通的，但信令不通，由此故障定位为传输途中有环回。经过逐步排除，查出原因为传输部门在孝南陡岗传输节点机房（王店山传输从陡岗基站过）施工时将王店山的传输线路做了环回。后电话联系，经传输部门处理后基站恢复。
二、动力部分
1、市电停电，供电部门由于某种原因导致的市电停电。当蓄电池的电量快供应完时，一般基站会出现局部断电的现象。所以当一个基站出现 如小区退服的情况，应先确认是否有市电，在确认市电正常的情况下再进一步判断是否为合路器损坏等故障。（基站没有环境监控，并且供电部门也不确定是否停电的情况下，建议抢修时带上油机）
2、市电缺相，由于某种原因正常市电的三相电缺一相，或者两相电的情况平时很可能发生。这时如果基站的整流模块的数量太少（1块），正好整流模块所在槽位是缺相的槽位就很可能造成市电中断，电池放电，最终导致基站退服。所以平时巡检时应该将基站开关电源的整流模块数量配齐为3块。
例：孝昌周巷基站退服，抢修人员赶到基站后检查为设备系统电压过低导致退服，但机房内有市电（周巷基站机房为和电信共用），经过数字万用表测量，本来380V的三相电缺一相，周巷基站开关电源的整流模块因为损坏了一块（已拆走），只剩下一块，刚好开关电源上第一槽位为市电缺的那一相，所以导致无交流电通过开关电源，蓄电池放电完后基站退服，将整流模块换到第二槽位后开关电源供电正常，基站恢复。后将领回的整流模块加装进去并联系电力部门对市电检修，以防以后再次出现这样的情况。
3、市电电压不稳，如果市电电压不稳就可能造成整流模块无法正常工作，频繁关闭、启动，这样很容易将整流模块损坏。所以平时巡检时，一定要测量市电电压是否正常、稳定。
4、整流模块损坏，当整流模块损坏后，交流电无法转换为设备用的-48V的直流电，最后导致蓄电池电量放完而基站退服。所以在巡检时一定要检查整流模块是否有损坏的，如果有马上进行更换。并将整流模块数量配备3块以上，保证在一块或两块损坏后仍有备用的模块可以暂时保证基站正常工作。
5、开关电源设置问题，开关电源低压断路开关（LVDS）都应设置为自动（AUTO），如果关闭低压断路开关，当市电中断蓄电池放电到一定程度时，基站因电压过低会退服，当主设备退服后电压上升基站又会恢复，基站恢复后电压又会过低此时基站又会因电压过低退服，基站会因此间隔30分钟左右的频繁退服。
例：安陆五一小学，当时监控室人员通知说此站反复退服间隔不到30分钟，抢修人员询问当地供电所得知停电，去到基站，基站处于停电状态，发电后基站恢复并且稳定，后查看开关电源设置发现低压断路开关设置为关闭状态分析原因为电压引起基站反复退服。
第三篇：传输故障处理方法
排除传输故障的一般思路有哪些？
应该遵循一“查看”、二“询问”、三“思考”、四“动手”的思路。）查看首先到达现场后查看出现故障的现象，即查看设备的哪一部分出现故障，有何种告警产生，严重程度如何，造成多大危害等，才能透过现象看本质。2）询问观察完现象后，应询问各阶段现场人员，是何种原因造成了此故障，比如是否有人修改了数据、删除了文件、更换了电路板、停电或雷击、误操作等等。3）思考根据现场查看的现象和询问的结果等，结合自己的知识作思考、分析，判断何种原因可能引起该种故障等，作出较为正确的判断。4）动手根据前面三个步骤找出故障点，通过修改数据、更换电路板及芯片等手段解决、排除故障。
传输故障处理的方法有哪些？
1．观察分析法：
当系统发生故障时，在设备和网管上将出现相应的告警信息。通过观察设备上的告警灯运行情况，可以及时发现故障；故障发生时，网管上会记录非常丰富的告警事件和性能数据信息，通过分析这些信息，并结合 SDH 帧结构中的开销字节和 SDH 告警原理机制，可以初步判断故障类型和故障点的位置。通过网管采集告警和性能信息时，必须保证网络中各网元的当前运行时间设置和网管的时间一致。如果时间设置上有偏差会导致对网元告警、性能信息采集的错误和不及时。
2．测试法：
通过观察分析法不能解决的问题，如组网、业务以及故障信息相当复杂的情况和无明显告警和性能信息上报的特殊故障情况。可以利用网管提供的维护功能进行测试，判断故障点和故障类型。
3．拔插法：
对最初发现某种电路板故障时，可以通过插拔一下电路板和外部接口插头的方法，排除因接触不良或处理机异常的故障。在插拔过程中，应严格遵循单板插拔的操作规范。插拔单板时，若不按规范执行，还可能导致板件损坏等其它问题的发生。
4．替换法：
当用拔插法不能解决故障时，可以考虑替换法。替换法就是使用一个工作正常的物件去替换一个被怀疑工作不正常的物件，从而达到定位故障、排除故障的目的。这里的物件，可以是一段线缆、一块单板或一个设备。
5．．配置数据分析法：
在某些特殊情况下，如外界环境的突然改变，或由于误操作，可能会导致设备的配置数据遭到破坏或改变，导致业务中断等故障的发生。此时，故障定位到网元单站后，可通过查询、分析设备当前的配置数据；对于网管误操作，还可以通过查看网管的用户操作日志来进行确认。
6．更改配置法：
更改配置法更改的配置内容可以包括时隙配置、板位配置、单板参数配置等。因此更改配置法适用于故障定位到单个站点后，排除由于配置错误导致的故障。更改配置法最典型的应用是排除指针问题。
7．仪表测试法：
仪表测试法一般用于排除传输设备外部问题以及与其它设备的对接问题。
8．经验处理法
第四篇：摩天轮游戏机简易故障处理
摩天轮游戏机简易故障处理
本款电玩城游戏机设备摩天轮游戏机，通常会出现以下个几个小故障，也不是很大的故障，所以基本上也比较好解决，只要掌握了这款游戏机的大概特性，只要排除了这个字故障，其它的都是比较少见的，首先是；投币不进，检查投币器线路是否有接触不良，接好接触不良的线路，检查投币器是否有故障，换上好的投币器，检查主板是否有不良，换上好的主板。
其次是；不能出彩票，检查彩票机是否有卡票，清除被卡的彩票，检查彩票机是否有故障，换上好的彩票机，检查彩票机的线路是否有接触不良，接好接触不良的线路。
最后是；出彩票的颜色与中球的颜色不相符，检查光眼板是否有装反，正确安装光眼板，检查光眼板的线路是否有接触不良，接好接触不良的线路，检查光眼挡片是否有与白色格中间垂直，调好光眼挡片与白色格中间垂直。
针对这款摩天轮游戏机之安逸首先掌握这几个最基本的故障，就可以维护这款机器了，使用排除法，再根据出故障时的表现，我们可以分析出事哪种故障了，再一一排除故障，机器就可以正常运行了。
摩天轮游戏机简易故障处理
第五篇：APG40故障处理小结
Page １ of 9
APG40故障处理小结
从维护APG40以来，对APG40故障做了大概的统计，从统计结果看出有以下这些APG故障，下面我将对这些故障进行大概的分析及给出解决的方法： AP LOG STATISTICS 引起故障的原因：
1、AP VIRUS：APG感染病毒。
处理方法：人工DOWNLOAD更新病毒库后扫描清除病毒（如果是AP2的话，将AP2的ETRUST设置为从AP1更新病毒库），成功后用指令ACEASE手工删除告警。
2、LOGFILE/SECURITY LOGON：多次登陆AP错误告警。
处理方法：因为多次登陆输入帐号密码错误而导致,用acease消除即可.（如因帐户过期引起多次登陆输入帐号密码错误，那应通知交换室对该帐户重新定义帐户、密码，才能真正解决该故障。） AP SYSTEM ANALYSIS 引起故障的原因：
1、The object is LogicalDisk and the counter is % Free Space：硬盘空闲空间低过门限值。
处理方法：检查引起该故障的硬盘的文件，删除该硬盘的临时文件、较旧的备份文件等，并清空回收站。如删除了这些无关重要的文件后，仍无消除故障，此时可能需扩大硬盘空间（或压缩文件）来消除些故障，可打TR提交爱立信，提供解决方案。* C盘空间不足 可删C:TEMP 可删C:TEST 可删C:WINNTSYSTEM32LOGFILESMSFTPSVC1（2、3)（保留一个月的文件）
* K盘空间不足
可删K:IMAGESNODEA(保留最新一个备份文件)可删K:IMAGESNODEB(保留最新一个备份文件)
Page ２ of 9 可删K:ACSLOGSALOGLOGFILE(保留7天的文件)可删K:MCSLOGSPDS（保留7天的文件）
K盘主要文件是的网优统计文件，K盘空间不足多是网优统计文件过多所致。建议出K盘空间不足告警时，先联系网优室删除统计文件。网优统计文件所在位置：K:AESDATACDHFTP
* L盘空间不足 可删L:TEMP 可删L:FMSBACKUP 可删L:FMSDATATMP 可删L:FMSDATACPFRELVOLUMSWRELCMDHDF（保留2个月的文件）
2、The object is Security Log and the counter is %Used Space：安全记录占用空间超过门限值。
处理方法：连接PCANYWHERE到APG，检查EVENT LOG文件，删除较旧的EVENT LOG文件，直到告警消除。（如有必要，可将这些EVENT LOG备份后再删除）*Select Start | Programs | Administrative Tools | Event Viewer *In the Event Viewer select the Security log.Select Log | Security *Select Log | Clear All Events.*Select 'Yes' in the message box Clear Event Log.*备份的流程：首先要先把EVENT LOG保存到APG，一般先先保存到C:TEMP目录下，再备份到磁盘。保存到C:TEMP目录的步骤：
1、In the Event Viewer select the Security log.Select Log | Security
2、In the field 'Save in' select where to store the security log file.3、In the field 'File name', enter an appropriate
故障分析：此故障是由于AD-X吊死引起，故障处理：可以在APG40 ACTIVE NODE 做PRCBOOT后，OSS能正常联机 故障描述：APG40系统中文件无法传到OSSDESTx的问题。
故障分析：多数此类告警都可以用指令CDHLS-L 查看所有路径的OSSDESTx的传输类型和参数定义是否正确。大多数都不会有参数丢失的情况，然后用CDHVER 查看告警制定的OSS路径的状态是否OK,否则用指令CDHVER-M 人工修正使状态变为正常，消除告警。但是有的告警比较特殊例如: AP FILE PROCESSING FAULT CAUSE FILE TRANSFER FAILED TRANSFER QUEUE ALOG DESTINATION SET OSSDESTALOG Problem Data Transfer error 故障处理：先尝试着用以上常规的处理方法即指令来设法消除此告警：
1、用AFPLS –L –S ALOG查看是有ALOG文件传送失败，如有则用AFPFTI –F ALOG将传送失败的ALOG文件重传一次，传送成功故障将会消除。
2、如还是传送失败，则cdhls-l OSSDESTALOG查看此路径的所有传输参数，一切均正确。
3、用cdhver OSSDESTALOG看其状态，结果显示STATUS OK。
4、于是确认了本地交换机的设置没有问题，怀疑是到OSS的网络不通 但用指令ping 132.97.19.1来ping 对端的IP, 显示网络路径完全正常；后来注意到A3级的一个告警，是由于刚才那个A2级告警引起的：
DATA OUTPUT, AP COMMON DESTINATION HANDLING, DESTINATION FAULT DESTINATION
Page ４ of 9 OSSDESTALOG CAUSE WRITE FAILURE Problem Data The connection to the remote host lost or write access denied 再分析上面的告警要确认了是因为AP 文件没有写到OSS的权限。综上分析可以确定是对端网管的设置问题，导致ALOG文件无法正常传送。所以应及时联系对端人员(网管组)协助处理。
总结：此类问题可以从三方面来分析
1、人工重传文件。
2、本地设置和定义的参数。
3、网络是否畅通。
4、对端的参数设置。 AP PROCESS REINITIATED 引起故障的原因：
APG进程出现过重启后会出现此故障
处理方法：用指令CLUSTER RES查看所有进程状态是否”ONLINE”，如果不是则用指令（CLUSTER RES **** /ON /WAIT）将进程”ONLINE”，如进程状态为”ONLINE”，用指令ACEASE消除该告警。 AP FAULT 引起故障的原因：
1、MIRRORED DISKS NOT REDUNDANT：磁盘镜像有问题引起。
处理方法：用指令“RAIDUTIL –L LOGICAL”查看，如果地址为D0B0T0D0的RAID-1的状态为DEGRADED，则用指令“RAIDUTIL –A REBUILD D0B0T0D0”重建RAID-1。等过一段时间后，地址为D0B0T0D0的RAID-1的状态恢复正常OPTIMAL，故障消除。如果用指令“RAIDUTIL –L LOGICAL”查看所有状态均为OPTIMAL，则直接用指令ACEASE消除该告警。
2、GENERAL ERROR：AP故障引起。
处理方法：用指令ALIST查看告警列表，如有其他AP故障，先修复其他故障，然后再用指令ACEASE消除告警。
3、AP-AP LINK ALARM：一般由AP NOT REDUNDANT故障引起。
处理方法：恢复AP NOT REDUNDANT故障（详情看AP NOT REDUNDANT），如
Page ５ of 9 用指令ALIST没列出AP NOT REDUNDANT故障，可用ACEASE消除故障。
4、AP EXTERNAL LINK ALARM：一般由AP PROCESS STOPPED故障引起。处理方法：恢复AP PROCESS STOPPED故障（详情看AP PROCESS STOPPED），如用指令ALIST没列出AP PROCESS STOPPED故障，可用ACEASE消除故障。 AP NOT REDUNDENT： 引起故障的原因：
APG其中一个NODE DOWN掉引起。
处理方法：如果APG状态正常，直接指令ACEASE清除告警，如果状态不正常，按OPI流程：AP，System, Repair处理。过往处理经验大概操作：（借鉴）
1、在DOWN掉的NODE先做下一个REBOOT，看能否把NODE UP起来（做REBOOT前需用指令NET ACCOUNTS /SYNC做一下帐号同步）。
2、用指令NET START CLUSSVC重启CLUSTER RES。
3、如执行上两步都无法修复的话，可连上PCANYWHERE，查检各SERVICES的设置（特别是ACS PRC开头的），跟其他正常运作的网元对比，看是否有设置不一样，如有，改正后再做此边的REBOOT。
4、如还不能恢复，可打TR提交爱立信，提供解决方案。 AP PROCESS STOP 引起故障的原因：
进程人工停止或者遇到故障自动停止引起。
处理方法：查看该进程状态是否“ONLINE”，如该进程状态为“ONLINE”，用指令ACEASE消除该告警。如果不是则用指令CLUSTER RES *** /ON /WAIT将该进程“ONLINE”，如不成功，可对此NODE做个REBOOT解决。 IO STORAGE SPACE WARNING 引起故障的原因： IO存储空间不足引起
处理方法：CPDLIST –P查看IO文件存放的目录，用DOS命令DEL删除多余的IO文件。IO文件形如：AD-0_20041102_0005.LOG AP REBOOT
Page ６ of 9 引起故障的原因： APG重启后的事件告警。
处理方法：检查该AP状态是否为“ACTIVE”, 如不正常，则按AP NOT REDUNDENT流程处理。检查“CLUSTER GROUP”、“CLUSTER RES”是否“ONLINE”，如不正常，用指令将该进程”ONLINE”，如不成功，则按AP PROCESS STOP流程处理。检查APG恢复正常后，需用指令ACEASE消除该告警。 CP AP COMMUNICATION FAULT 引起故障的原因： CP与AP通信中断引起。
处理方法：一般重启APG或做CP SMALL可以恢复。注意：装载补丁、APG重启或CP重启期间会出现该告警。 AP ANTIVIRUS FUNCTION FAULT 引起故障的原因：
AP的NT系统的杀毒软件设定了定期更新病毒库，如果四次请求下载更新病毒库不成功则会出现告警。
处理方法：故障处理:在ap1设置eTrust软件,选Redistribution Server选项,然后APG2（计费专用）就可以通过“Redistribution Server”的方式从APG1更新病毒库。人工DOWNDLOAD流程看附件：
AP NOT AVAILABLE 引起故障的原因：
此故障通常是进程吊死OFFLINE或NODE DOWN掉起引APG不可用。处理方法：
1、指令CLUSTER RES查看各进程状态，如有进程为OFFLINE，即将进程Bring Online（CLUSTER RES *** /ON /WAIT），如不成功，做该NODE的REBOOT。
2、如还不行，可参照AP NOT REDUNDANT的故障处理。注：具体操作流程按照OPI：AP NOT AVAILABLE处理。
Page ７ of 9 AP SYSTEM CLOCK NOT SYNCHRONIZED 引起故障的原因：
1、Difference between CP and AP time exceeds 600 s-APZ alarm.There was a jump in AP/CP time：由于CP与AP之间的时钟相差600秒引起。处理方法：拔打010117，用指令CACLP核对CP时钟，同是也用AP指令time /T及date /T核对AP的时钟，并对有误差的时钟进行校正。
2、除了第一种原因处，其他原因可提交TR爱立信，提供解决方案。 AP DIAGNOSTIC FAULT 引起故障的原因：AP诊断错误
处理方法：用指令ALIST查看告警列表，看是否列出告警号为8701和告警参考数据为：C:ACSlogsUSAusa.temp.I/O error : Missing parameter，如果是，即删除文件C:ACSlogsUSAusa.temp，并做该AP的REBOOT，如不能解决或其他原因，可提交TR爱立信，提供解决方案。 BILLING，AP DISK，FILES SPACE LIMIT REACHED 引起故障的原因：
计费容量不足，通常当计费文件的大小达到或超过硬盘分配给CHARGING目录大小的80%门限值时，就会出现计费文件空间达到限制值的告警。可能会引起计费文件的丢失。
处理方法：通过减小计费文件在硬盘的保存时间来解决该告警问题，可依照OPI“APG40, Soft Function Change, Parameter,Change”进行对计费参数的修改，由于此操作涉及到计费参数修改，可申请爱立信现场支持。出现此故障，我们可先做以下预处理：
1、检查询问计费中心能否收到此网元的计费文件，如不能，即重启RDT_Server进程（Cluster res Cluster res RDT_Server /off /wait Cluster res RDT_server /on /wait）。
2、将计费文件备份到磁盘，在硬件上删除掉已备份到磁盘并传到计费中心的计费文件。
3、在紧急情况下，也可向交换室申请将计费倒到AP1上。 AUDIT LOG DEACTIVATED
Page ８ of 9 引起故障的原因： Audit Log文件被去活。
处理方法：用alogact指令激活Audit Log。
BILLING, AP OUTPUT, CONNECTION TO EXTERNAL HOST LO 引起故障的原因：
由于APG网元与省公司计费业务中心的FTP配置不一样所致，双方的接收协议存在区别，但该故障不影响计费文件的产生及接收。
处理方法：修改APG网元SecureDestinationHost的参数或计费中心修改FTP的配置参数。
FILE NOTIFICATION, AP CDH, ACKNOWLEDGEMENT NOT REC 引起故障的原因：
APG数据输出到外部系统失败，一般都为临时性故障。
处理方法：一般临时故障会自已恢复；用指令cdhver –m destination核验DEST是否正常。
CONNECTION SUPERVISION, AP CDH, CONNECTION TO REMO 引起故障的原因：同上 处理方法：同上
APG在日常维护中遇到的另类问题：
PCANYWHERE连接到APG后，点击桌面上的图标后没有反应，用显示器和键盘直接连到APG上点击还是一样，爱立信认为有可能是病毒的问题，但最后都未有结论。
处理方法：做一个reboot是可以暂时解决问题。
在做例行TEST LOAD时，文件LOAD入不成功出IO FAULT 15的结果。
处理方法：在CP模式中用ocsip看到IPNAOS的版本为CXC1060053R2B01，但是在AP模式下看到的版本为CXC1060053R2C，按照OPI流程Inter-Platform Network Software, Change对IPN进行function change后，问题解决。
曾经出现有些网元APG REBOOT后，有两个进程ACS_PRC_ClusterControl_1，ACS_PRC_EventAnalyser_1的状态为OFFLINE，将这两个进程BRING ONLINE
Page ９ of 9 的时候会引起APG40的循环REBOOT。
处理方法：此问题是Acs_prc_eventanalyser 和 Acs_prc_clustercontrol这个两个进程的参数设置有错误引起，只要修改这两项的设置就可以解决进程不能online的问题。具体是通过pcanywhere连到APG的ap1 passive node，在控制面板－SERVICES里面找到这两项进程，将其设置由原来ATUOMATIC改为Manual，并把ACS_PRC_ eventanalyser的LOG ON AS改为System Account".进行完这两步之后可以在该node重启进程。用同样的方法在ACTIVE Node完成该操作。现在APG的问题可以解决。
以后类似进程不能重启的问题可以先找一个正常的APG系统找到该进程将两者的参数设置比较一下，是否设置错误的问题。 在一边node做reboot后不能恢复的问题。
处理方法：主要是raid磁盘的问题，操作步骤是参照OPI: APG40, Node, Change。
