【资料名称】：OMCR 中缺失obsynt 报告问题分析

【资料作者】：A 特

【资料日期】：414

【资料语言】：中文

【资料格式】：DOC

【资料目录和简介】：

典型案例分析1/3
OMCR 报告缺失问题的处理
GSM BSS 2006 CASE 0098
作者：ISE 重庆分公司张冬
【产品类别】： G 网BSS，OMCR，A1353RA B7.2
【故障级别】： Minor
【关键字】： BSS ，OMCR，A1353RA B7.2
【故障现象】：
OMCR 中缺失obsynt 报告。
【原因分析】：
对于用户反映的obsynt 报告缺失，只是表明在OMCR 中/spool/obsynt/bss/bssname
/date 下无相应的ascii 报告，而OMCR 中缺失报告问题到底出在那一个环节，这就先要看
一下OMCR PM 报告生成过程到底是怎样的：
1． OMCR 中首先创建相关的PMC，将该信息传给BSC，由BSC 收集相关的计数器，生
成相关的文件；
2． BSS OSI-CPR 整点后生成相应的pmres 文件，比如110 报告有类似PMRES110.58A
的名字，028 报告有类似PMRES-28.58A 的名字；
3． 整点2－3 分钟左右，相应的PMRES 文件会传到OMCR /alcatel/var/share/mpm 目
录下，它的命名格式如下：
"BSS_file_name".”BSC_num”."BSS_name"."file_creation_date"."file_creation_time"."
sequence_num"."BSS_version "
4． OMCR 根据相应的配置文件，将/mpm 下的二进制文件转换成/obsynt 目录下相应的
ASCII 文件。
看了上面的生成过程，对处理omcr 上报告缺失的问题就有了一个基本的思路。以下就
是针对具体的问题类型进行介绍，在各种情况下该如何处理。
【解决方法】：
1．BSS OSI-CPR 中有pmres 文件，OMCR 中无pmres 文件
根据上面对OMCR PM 报告生成过程的介绍，当用户反映没有PM 报告时，他们通常都
是指OMCR 中无obsynt 报告，但到底是哪一个环节有问题呢？这就需要根据OMCR PM 报
告生成报告的过程逐个检查。在实际的问题处理中，我们经常发现在BSS OSI-CPR 中有
pmres 文件，但在OMCR 的/alcatel/var/share/mpm 下无相应的pmres 文件，这个时候，
通过OMCR 的bssim trace 文件，我们都会发现有类似如下方面的信息：
2005/12/26 20:03:48:bssim:comm2):INTEG:COMM: sent ACTION request (8661)
2005/12/26 20:03:48:bssim:comm2):INTEG:COMM: received ACTION result (8657)
2005/12/26 20:03:48:bssim:comm2):INTEG:COMM: Got a complete response (8657)
2005/12/26 20:03:48:bssim:bssimaccess:(1):The FTAM transfer has been rejected :
fcp: Unable to connect to filestore NO MORE RETRY
2005/12/26 20:03:48:bssim:bssimentitycom:(1):
E R R O R : pmResObsTransferRequestReport (FTAM pb) --> status =
{ -- SEQUENCE OF --
{ -- SEQUENCE --
errorOriginator omc (2),
omcError { -- SEQUENCE --
component bssim (1),
errorCode BssimStatus::ftamTranferRejected (4545),
basicErrorInformation { -- SEQUENCE OF --
string qianjiang_bsc4,
string fcp: Unable to connect to filestore NO MORE RETRY,
string /alcatel/var/share/ftam//PMRES-18.92A.26,
发生这种情况，一般都是BSS OSI-CPR 当时由于某种原因，处理不过来，造成相关的
pmres 文件无法传给OMCR。对于现在B7 的情况下，这种情况一般只会出现一次后，在下
一个整点后一般都会恢复，对于这种少量的缺失，只要将该pmres 文件copy 到OMCR 中
/alcatel/var/share/ssd 中相关的目录下，然后根据omcr 中pmres 文件的命名规则修改文件
名，再cp 到/alcatel/var/share/mpm 目录下就可。因为过一会儿，OMCR 就会自动处理。
如果某个BSC 连续几个小时出现这种情况，不能自动恢复。在这种情况下，就需要切换
OSI-CPR，如果切换还是不能解决问题的话，就需要插拔这两块OSI-CPR，一般来讲，插拔
OSI-CPR 一般都能解决这种问题。只是插拔时，为了保证OMCR 与BSC 的链接不中断，先
插拔备用的OSI-CPR，过10 分钟后，再插进去，然后再切换OSI-CPR。如果在同一个小时，
同一个AGENT 的好几个BSC 都出现上述情况，这个时候就要检查BSSCOMM 的FTAM 重
传次数的参数是否被修改。对于在同一个小时同一个AGENT 的好几个BSC 都出现BSS
OSI-CPR 中有pmres 文件，OMCR 中无相应的pmres 文件（重庆X-LARGE 的OMCR 就曾
经每半个月出现一次） 时， 将/alcatel/omc3/bsscomm/conf/param.cfg 中
maxNbOfFtamRetrans 由2 改为7 后，这种现象几乎就不会再发生了。
2． BSS 中无pmres 文件，OMCR 中无pmres 文件。
在实际的维护中，我们经常发现这种情况：BSS OSI-CPR 中无pmres 文件，OMCR 中也无pmres 文件。这个时候我们通过OMCR 的bssim trace 文件会发现，pmres 文件本身没
有传到OMCR 中，但BSS OSI-CPR 中又将该pmres 文件删掉了（如果pmres 文件被传到
OMCR 后，正常情况下也应该删掉）。这种情况一般都只会偶尔出现一次，等到下一个整点
后就会恢复。如果连续几个小时都出现这种情况，处理方法同1，即切换OSI-CPR 或者插
拔OSI-CPR。问题一般可解决。
3．BSS 中无pmres 文件，OMCR 中有pmres 文件
有时候，我们也遇到在BSS 的OSI-CPR 中无pmres 文件，OMCR 的/alcatel/var/share
/mpm 目录下有相应的pmres 文件，可是却没有ASCII 报告。在这种情况下，如果所有的
BSC 都没有ASCII 报告的话，就多半是OMCR 的ASCII 码输出有问题。这时就要通过PM
Admin 的管理模块进行ASCII output 的enable 操作，具体步骤如下：
PM Admin->输密码dba 两次->Administration->Start MPM Administration->输密码
dba 一次－》Options->ASCII Output->enable.
还有一种情况就是，部分BSC 的ASCII 没有输出。然而当我们查看OMCR中/metrica
/npr/logs 目录下的obsynt.audit 文件，发现有部分BSC 的报告输出目录（目录就是日期）
是在很久以前的一个日期，根据这个目录找到相应的文件，查看其unix 修改时间，我们发
现与出报告的日期完全吻合，说明这些报告不是没有，而是输出日期不对。而这个问题本身
也是由于其二进制文件的内容有问题造成的。在这种情况下，需要对对应的BSC 的PMC 进
行LOCK/UNLOCK 操作。Obsynt.audit 的文件内容类似如下：
[9899] Thu May 11 00:07:43 2006 Processing
/metrica/npr/spool/bss/obsynt/B7/TYPE_1130-#-15-#-cqsesn001-#-10May2006-#-23:0
0-#-00:00-#-A1-#-S.lif.
[9900] Thu May 11 00:07:44 2006 Processing
/metrica/npr/spool/bss/obsynt/B7/TYPE_1130-#-24-#-cqsesn001-#-10May2006-#-23:0
0-#-00:00-#-A1-#-S.lif.
[9901] Thu May 11 00:07:44 2006 Processing
/metrica/npr/spool/bss/obsynt/B7/TYPE_1130-#-16-#-cqsesn001-#-10May2006-#-23:0
0-#-00:00-#-A1-#-S.lif.
[9902] Thu May 11 00:07:45 2006 Processing
/metrica/npr/spool/bss/obsynt/B7/TYPE_1130-#-25-#-cqsesn001-#-10May2006-#-23:0
0-#-00:00-#-A1-#-S.lif.
[9903] Thu May 11 00:07:45 2006 Processing
/metrica/npr/spool/bss/obsynt/B7/TYPE_1130-#-26-#-cqsesn001-#-10May2006-#-23:0
0-#-00:00-#-A1-#-S.lif.
4．BSS 主用OSI-CPR 文件中文件异常，且无法删除。
在维护中，我们还遇到一个情况就是BSC 的主用OSI-CPR 的文件只有一个莫名其妙的
文件，没有类似PMHF 之类的文件。而且该文件无法删除，整点之后也没有报告。后来将该
OSI-CPR 切换后，报告输出正常，该OSI-CPR 拔出来10 分钟后再插入后，硬盘内的文件恢
复正常5．BSS OSI-CPR 中文件不更新。
有时我们还遇到BSC OSI-CPR 中文件不更新。当然这种情况也比较少。遇到这种情况，
如果是所有的BSC 均如此，那就可能是创建的PMC 有问题，可能是有人误操作修改了PMC。
如果是个别BSC，就很有可能是这个BSC 的PMC 被人LOCK 掉了。
总的来说，对于报告缺失的问题，主要考虑报告的二进制文件是否生成并传到OMCR
中，OMCR 中的二进制文件是否正常以ASCII 码的方式输出到相应的目录。在日常维护中
我们处理得最多得情况就是上述1、2 两种情况，绝大多数情况都是插拔OSI-CPR。因此平
常要加强对OSI-CPR 的维护，要及时清除OSI-CPR 中无用的文件，及时消除一些频繁翻转
的告警，减轻OSI-CPR 的负荷。