IA002302 TELLIN SMS故障分析与处理ISSUE2.0.doc

IA002302TELLIN-SMS故障分析与处理Issue 2.0课程说明课程说明课程介绍为提高培训的针对性和有效性，让用户学员在培训期间既学习处理问题的方法，又学习解决问题的思路，进而提高分析问题和处理问题的能力，特开发“TELLIN 故障分析与处理”系列课程。“TELLIN 故障分析与处理”系列课程包括： IA002301 TELLIN SCP故障分析与处理 IA002302 TELLIN SMS故障分析与处理“TELLIN SMS故障案例分析”课程主要通过列举一些筛选出来的网上SMS故障案例，介绍分析、定位、排除有关常见故障的方法，并给出案例分析过程和经验总结。从而培养学员分析解决故障的思维习惯，提高学员分析问题和解决问题的能力。课程目标本课程主要目标： SMS方面常见故障的定位及处理方法相关资料TELLINSMP操作维护手册TELLINSMS技术手册1IA002302 TELLIN-SMS故障分析与处理 Issue 2.0第1章 故障案例分析第1章 故障案例分析本培训手册所收集故障案例全部来源于华为公司技术支持网站，具有一定代表性。由于网上出现的故障现象千差万别，我们只是选取了一些典型、常见的故障现象进行分析。E说明：华为技术有限公司的技术支持网站是：在此网站上，技术支持人员和用户在登录后可以浏览全部的技术案例。1.1 故障概述1.1.1 系统日常维护中的故障业务管理接入点SMAP是智能网业务管理系统SMS的人机交互界面，提供用户对智能网进行网络管理、业务管理、业务用户管理和计费管理的手段。智能网系统的日常管理和数据设定都需要通过SMAP来完成。SMAP的故障主要表现在SMAP的安装后登录不成功和日常运行异常。解决此类问题的关键是要抓住INFORMIX SDK客户端参数配置以及SMAP.INI文件中各参数的正确配置，当然SMAP与SMS网络配置是否正确也是很重要的一点。INFORMIX SDK客户端的配置包括AUTOEXEC.BAT文件中PATH路径的设置，这个参数一般是安装系统后自动生成的，但也不排除人为的破坏；另一方面就是INFORMIX数据库服务器信息（Server Information）和主机信息（Host Information）的配置，这一部分主要通过工具Informix Setnet32来设置。重点是要掌握各配置项参数的具体含义，同时需要保证这些参数与SMP侧的数据一致，否则将造成SMAP与SMP连接异常。数据配置完成以后，可以通过执行Ilogin Demo程序来检查配置的正确性，如果执行有错，可以通过返回的错误代码，执行Informix Find Error程序来定位具体故障。具体参数含义可参照TELLINSMAP操作维护培训手册相关章节的内容，在这里不再赘述。SMAP的参数配置主要保存在SMAP.INI文件中，具体数值需向SMP管理员咨询。注意必须保持SMAP连接参数与SMP的一致，否则将出现连接失败故障。 具体参数含义可参照TELLINSMAP操作维护培训手册相关章节的内容，在这里不再赘述。如果检查数据配置无误，可以检查一下网络连接方面的设置情况。可以通过互相PING对方IP地址来检查网络连接是否存在故障，如果PING不通，那么就需要检查网络连接设备和网络参数配置以排除故障。如果以上步骤还不行的话，就需要重新安装SMAP软件，一般到此可以解决问题。如果还不行，基本可以排除SMAP端故障，需要查找SMP端来定位问题所在。现在我们通过一些典型的案例分析来帮助我们进一步理解。1.2 故障案例分析1.2.1 案例一1. 故障现象描述SMP平台安装完成后，在后台安装SMAP客户端以超级用户登录系统，系统提示“SMP拒绝此NO.XXX的连接”，或“数据库访问错误”。反复多次，不成功。2. 故障原因分析SMAP登陆不成功首先应该想到有可能是informix客户端或smap.ini配置不对。另一种可能是没有在SMP上定义该SMAP终端。另外还应该想到的是尽管在SMAP的界面上登陆的用户是superadm，但与之对应的在SMP上实际进行数据库操作的UNIX用户是superman。如果该用户设置有问题，那么数据库就无法访问，SMAP也会登陆不成功。3. 处理过程描述首先检查informix客户端配置并通过运行Ilogin Demo程序验证配置没有问题，其次检查smap.ini的设置，重点检查了Datebase、SMAP_Number的配置，没有发现问题。若确认superadm用户密码是正确的，但仍然登录SMAP失败。则需要检查UNIX系统中的用户是否已经建全。在SUN机器中可以用admintool检查，在HP系统中用可以SAM检查。在该案例中发现UNIX系统中少定义了superman用户。增加superman的定义后，SMAP登录成功。4. 引发的思考由于某些原因造成SMP系统中superman、sysman、servman、subman用户没有设置或由于不知道这四个用户的作用而将其口令改掉，这将造成有关SMS系统用户管理的诸多问题，因此必须了解我们的系统中哪些用户的口令可以更改，哪些用户的口令不可更改，即便要更改，也要在相关的地方做一致性更改。否则在维护当中可能会因操作不当导致不必要的故障。1.2.2 案例二1. 故障现象描述在SMAP计费数据维护中，要将计费表“输出到文件”时提示“无法进入smp_run/temp目录”。2. 故障原因分析该操作是将数据库当中的计费表格备份到SMAP的本地。执行此操作时，在SMP上要用到一个临时目录以临时存放数据，该临时目录的路径在SMAP向SMP提交该操作请求时提供，现在反馈找不到该临时目录，应该是在smap.ini中 audiopath和temppath路径设置不正确。3. 处理过程描述根据SMP的实际环境在smap.ini中将audiopath和temppath路径设置为绝对路径后，备份计费数据表格成功。4. 引发的思考SMAP上的smap.ini中的参数由于涉及到SMP的某些操作以及SMP与SMAP之间的通信，由于SMAP直接面向用户操作，这些参数比较容易被误修改。因此这些参数的含义一定弄清楚，并知晓其重要性，不要轻易改动。1.2.3 案例三1. 故障现象SMP在一台主机SMP1上进行Informix数据库的安装配置之后，以Informix用户身份登录，并用“oninit -i”命令第一次启动INFORMIX不成功。2. 分析过程查看INFORMIX的日志文件online.log，日志文件的提示信息为：“Network driver cant bind a name to the port”，因此确定为网络配置错误。检查informix/etc/sqlhosts文件，发现其中的主机名为SMP浮动IP地址对应的名字。而只有在双机安装成功并运行后，才可将两台主机上的Inoformix的Sqlhosts配置文件中的主机名称都改为SMP浮动地址对应的名称。 故此处应为SMP1本机的主机名。3. 事故原因数据库配置不正确。4. 解决方法修改informix/etc/sqlhosts文件，修改主机名为SMP1本机的主机名。5. 注意事项安装INFORMIX数据库时，一定要遵照规范，不可按自己的意愿随意确定其中的参数。本案例中只是数据库初始化不成功，若其它参数不正确，则可能导致系统运行过程中出现异常，届时将后果不堪设想。1.2.4 案例四1. 故障现象在SMAP上加载新业务时，系统提示“service config file nonexist”。2. 分析过程加载新业务时的操作步骤为：需先将业务文件拷贝到SMP目录下的servicefile子目录下，然后执行加载命令。加载业务时，SMP将业务文件以FTP的方式拷贝到SCP上。FTP成功后，业务文件先被放在SCP的sms用户的/v20目录下，然后业务文件才被拷贝到servicerun目录下的。若FTP不成功，则/v20目录下无业务文件，所以系统提示 “service config file nonexist”。 FTP失败的原因，一般都是由于SCP上定义的sms用户的口令与SMP上定义的sms用户的口令不一致造成的。在FTP时，执行FTP命令的用户是sms组的sms用户。 在SCP上，sms用户的组为SCP。在SMP上的配置文件autoftp、.netrc和inetcfg.cfg中对于sms用户的口令定义应该与SCP上sms用户的口令一致。若不一致，将导致FTP不成功。3. 事故原因人为事故。某操作员人为安全起见，更改了SCP上的sms用户口令。4. 解决方法将SCP上的sms用户口令更正为与SMP上各配置文件中定义的sms用户口令一致。5. 注意事项有些UNIX用户的口令是不能随意更改的。更改时，需要将各个定义该用户口令的文件一并更改。1.2.5 案例五1. 故障现象为备份UNIX系统的日志文件syslog.log，某操作员使用了以下命令：mv syslog.log syslog.log.baktouch syslog.logcompress syslog.log.bak但不久后发现，UNIX不再往syslog.log中写日志，造成UNIX系统日志丢失。2. 分析过程mv syslog.log syslog.log.bak命令实际上是将syslog.log文件拷贝成syslog.log.bak后将syslog.log删除。若在操作此命令时，某进程打开了此文件，则会导致该进程不能正常写此文件，即文件不能正常关闭。虽然touch syslog.log命令新生成了一个syslog.log文件，但此文件已经非原来的syslog.log，尽管它们的名字相同。此文件不能被UNIX进程识别，故日志不能被正常写到此文件中。3. 事故原因人为事故。备份日志的方法不正确。4. 解决方法在备份日志时可采用如下方法：cd /var/adm/syslog/cp syslog.log syslog.log.baktouch aaacp aaa syslog.logcompress syslog.log.bakrm aaa用aaa文件的内容去覆盖syslog.log的内容，不影响系统其它系统对该文件的读写。5. 注意事项有些看似正确无误的命令却背后“隐藏着杀机”。在未真正了解每条命令之前，需要尽可能地对命令进行验证，以防留有“后遗症”。1.2.6 案例六1. 故障现象对于特定的主叫和被叫，智能电话接续不成功。在某些业务中系统音提示：“您无权拨叫这个号码”。 举例说明电话可以接通打不通。2. 分析过程查找该错误，需要了解计费数据的查找方法，以下列出几个注意点：1、确认在SMAP上找到了正确的局号和区号。2、区号是按照最大匹配原则的，因此，如果同时存在999，9998区号的话，09998*找到的是9998这个区号，尽管实际中该区号为999。 这一点，一定要加以注意，否则容易按照通常的思维方式进行，不能查找到错误原因。 3、确认了数据库中的计费数据设置都正确以后，请确认SCFSERVER内存中的数据和数据库的数据一致。 如果不一致，会导致某些计费数据库不可用。如果直接操纵SCP数据库中的相关表格更改计费数据，这些计费数据是不能够在SCFSERVER内存中得到更新的。要确SCFSERVER内存中的数据是否与数据库中数据是否一致： A、确认所有的计费数据设置都是通过SMAP来进行的。 B、检查SCFSERVER的日志，确认没有读取计费数据错误的日志。 如果SCPCFG.INI中关于计费数据的一些配置参数不合理，会导致部分计费数据不能够读取至内存，则在SMAP操作计费数据设置时，将会记录相应日志。4、如果还不能找到原因的话，可以试图在呼叫量不是很大的时候，在输入完被叫号码前放开SCFSERVER的计费打印信息来跟踪呼叫。在跟踪信息中提供了详细的查找计费数据的过程。 3. 事故原因计费数据中有冗余数据，即除了0999的区号外，还多了一条09998的区号。而国内计费矩阵中只有07520999的计费数据，无075209998的计费数据。4. 解决方法将计费数据中的09998区号删除。5. 注意事项计费数据的更改需要慎重而又慎重。尽量避免出现冗余数据。另外计费数据的更改一定要通过SMAP进行，而不要直接手工修改数据库中的表格。若迫不得以需要直接修改数据库中的表格，则需要重新启动SCFSERVER进程以使新数据生效。1.2.7 案例七1. 故障现象一SMP开通后不久，需要调整informix配置参数。现场工程师根据标准配置进行了一番修改，然后重新oninit，结果INFORMIX不能正常启动。而在这之前，INFORMIX是能正常启动的。2. 分析过程检查INFORMIX日志文件onling.log，其中记录了如下内容：10:28:32 Event alarms enabled. ALARMPROG = /opt/informix/etc/log_full.sh10:28:37 DR: DRAUTO is 0 (Off)10:28:37 Requested shared memory segment size rounded from 588KB to 592KB10:28:37 Informix Dynamic Server Version 7.31.UC5 Software Serial Number AAC#J96387410:28:37 Assert Failed: chunk failed sanity check10:28:37 Informix Dynamic Server Version 7.31.UC510:28:37 Who: Session(1, informixsmp1, 0, -704028648) Thread(15, main_loop(), d606e018, 1) File: rspartn.c Line: 735410:28:37 Results: Chunk 1 is being taken OFFLINE.10:28:37 Action: Restore chunk from archive. If this is a temporary dbspace chunk, drop and add the dbspace to enable it.10:28:38 See Also: /opt/informix/tmp/af.3f79ed510:28:38 I/O error, Primary Chunk /dev/vg02/rlv_rootchunk - Offline (sanity)10:28:38 Informix Dynamic Server Stopped.10:28:38 mt_shm_remove: WARNING: may not have removed all/correct segments通