Guide to Troubleshooting ZXG10-OMCR (V2.0) Performance
Data Loss
ZTE Corporation
Legal Information
Copyright © 2006 ZTE CORPORATION.
The contents of this document are protected by copyright laws and
international treaties. Any reproduction or distribution of this document or any
portion of this document, in any form by any means, without the prior written
consent of ZTE CORPORATION is prohibited. Additionally, the contents of this
document are protected by contractual confidentiality obligations.
All company, brand and product names are trade or service marks, or
registered trade or service marks, of ZTE CORPORATION or of their respective
owners.
This document is provided “as is”, and all express, implied, or statutory
warranties, representations or conditions are disclaimed, including without
limitation any implied warranty of merchantability, fitness for a particular
purpose, title or non-infringement. ZTE CORPORATION and its licensors shall
not be liable for damages resulting from the use of or reliance on the
information contained herein.
ZTE CORPORATION or its licensors may have current or pending intellectual
property rights or applications covering the subject matter of this document.
Except as expressly provided in any written license between ZTE
CORPORATION and its licensee, the user of this document shall not acquire
any license to the subject matter herein.
The contents of this document and all policies of ZTE CORPORATION,
including without limitation policies related to support or training are subject
to change without notice.
Preface
Troubleshooting the ZXG10-OMCRV (2.0) performance data loss is one of
the most important jobs of GSM-BSS system. This document describes
precautions for troubleshooting performance data loss, introduces steps of
troubleshooting common problems, and lists some typical cases.
Contents
Chapter 1 Performance Data Configuration................................................................................1
1.1 Performance Index Formula Configuration of Different Operators.......................................1
1.2 System Configuration for Supporting Multi-Band Report.....................................................1
1.3 Configuration of Related Path for Performance Report Data Access and Backup................2
1.4 Configuration for Automatic Performance Data Deletion.....................................................2
1.5 Configuration of Performance Middle Table Automatic Update...........................................3
1.6 Configuration of Performance Statistics Cell........................................................................4
Chapter 2 Common Performance Data Table..............................................................................5
2.1 Measurement Data Table.......................................................................................................5
2.2 Report Data Table..................................................................................................................6
Chapter 3 Report and Handling Mechanism of Performance Data...........................................7
Chapter 4 Common Performance Problems and Solutions.........................................................9
4.1 Zero Traffic Found in Some Time Segments.........................................................................9
4.2 No Multi-Band Report Data Found in Performance Report................................................10
4.3 Data Accumulated Under Background Server Directory.....................................................10
4.4 Report Wizard Initialization Failure when Exporting Excel from Performance Analyzer...11
4.5 Statistics Report Unable to be Generated Through Performance Analyzer.........................12
4.6 TOP Tree Unable to be Obtained in Performance Analyzer................................................13
Chapter 1 Performance Data Configuration
The performance configuration file is: $OMCHOME\CONF\pmcfg.ini
一.1 Performance Index Formula Configuration of Different Operators
Currently, OMCR supports three types of performance index formula: China
Mobile, Chine Unicom, and Pakistan customization as follows:
# This session defines the difference of performance index in different companies.
# CompanyType represent company type, 1: China Mobile, 2:China Unicom , 3:PakTel
[COMPANYINFO]
CompanyType = 1
一.2 System Configuration for Supporting Multi-Band Report
#0-P900 1-E900 14-PE900=P900+E900 2-DCS1800 3-R900 4-1900 7-850 15-Sum
#if set PE900 then the P900 and E900 must both be set or not set, otherwise the system is wrong
#15-sum is not need to set, it add by system by default
[FREQINFO]
NEEDFREQ = 0
FREQNUM = 3
FREQ1 = 14
FREQ2 = 2
FREQ3 = 7
NEEDFREQ: whether multi-band is supported.
0, multi-band report output is not supported, default value.
1, multi-band report output is supported.
FREQNUM: number of multi-bands. If the value is n, then there are n FREQ
below.
Specification of frequency band type in pmcfg.ini is shown in Table 1.
Table 1 Specification of Frequency Band Type in pmcfg.ini
Frequency band type value Meaning
FREQ=0 Common 900 frequency band
FREQ=1 Extended 900 frequency band
FREQ=2 1800 frequency band
1
Frequency band type value Meaning
FREQ=3 Rail 900 frequency band
FREQ=4 1900 frequency band
FREQ=7 850 frequency band
FREQ=14 P900+E900 frequency band
一.3 Configuration of Related Path for Performance Report Data Access and Backup
[BAFINFO]
LocalMPLogFilePath = /export/home/omc/tmp/mplog
LocalMeasFilePath = /export/home/omc/tmp/pmmeas
NeedBackup=0 NeedMpLog=1
[DATABAKUPINFO]
HistoryDataFilePath = /export/home/omc/tmp/pmhist
ImpDataFilePath = /export/home/omc/tmp/pmhist
LocalMeasFilePath: path of saving performance data file reported by BSC
NeedBackup: whether backup and dump of performance database should be
implemented
HistoryDataFilePath: path of saving backup performance data
ImpDataFilePath: path of saving imported files
一.4 Configuration for Automatic Performance Data Deletion
# BasicTruncBeforeMonth = 1 ,represent data before one month in basic table will be deleted
# BasicTruncMonthsLen = 3 , represent 3 months' continuous data in basic table will be
deleted
# MidExportBeforeDays = 330 ,represent data before 300 days in mid-table will be exported
# MidDeleteBeforeExportDays = 30 ,represent data before (MidExportBeforeDays+30) days
in # mid-table will be deleted
# OtherTransBeforeDays = 15 ,represent data before 15 days will be deleted in other tables
BasicTruncBeforeMonth = 2
BasicTruncMonthsLen = 3
MidTruncMonthsLen = 3
CommTruncMonthsLen = 3
MidExportBeforeDays = 330
MidDeleteBeforeExportDays = 30
OtherTransBeforeDays = 15
2
一.5 Configuration of Performance Middle Table Automatic Update
# This session defines parameters about making middle data automatically
# PmHistSychrMaxDays represent the maximum days of each update
[MIDDATAINFO]
PmHistSychrMaxDays = 2
RPTUPDATE = 1
VALIDRECORDNUM = 3
# 1-wait(default) 2-ignore 3-prompt
UPDATESTYLE = 1
PmUpdateBeforeDays = 2
PmHistSychrMaxDays: representing number of days of which the basic
table’s data is updated to the middle table at the fifth minute of each time
segment. For example, on 10:05 of Jan. 12th, 2005, data of two time segment
s is updated:
Data of 9: 00-10: 00 of the day (Jan. 12th)
If data of 9: 00-10: 00 of the day before (Jan. 11th) is illegal, update
data of this time segment.
RPTUPDATE = 1: representing whether an update should be implemented
immediately after illegal data is found in the time segment when generating
statistics report.
UPDATESTYLE = 1: representing update mode when several update tasks
are implemented simultaneously (1: wait; 2: ignore; 3: prompt)
VALIDRECORDNUM = 3: number of valid records, which is a flag to judge
if data of the time segment is valid. The granularity of the system basic
measurement is 15 minutes, thus each hour has four basic measurement data
records; considering the link quality, three or more records received each hour
by a cell is taken as the default standard, and in such cases, the system
evaluates the basic measurement data of the time segment is valid.
PmUpdateBeforeDays = 2: representing that the system will check whether
data of PmUpdateBeforeDays days is legal on around 0:15 of each day. If the
data is illegal, then update all illegal data of those time segments.
一.6 Configuration of Performance Statistics Cell
# This session defines cell type of data which is counted into report form
# TYPE=0 represent all of cells which are lining up
# TYPE=1 represent all of working cells
3
# TYPE=2 represent all cells
[CELLTYPE]
TYPE=1
TYPE=0: only counting line-up cells.
TYPE=1: only counting working cells. Do not count if the line-up state is set
in radio parameters.
TYPE=2: counting all cells.
4
Chapter 2 Common Performance Data Table
Note:
Tables in bold form are common tables.
2.1 Measurement Data Table
Names of each measurement data tables and corresponding database table
names are shown in Table 2.
Table 2 Measurement Data Table
Name Database Table Name
Basic measurement table pBasicM
BTS measurement table pBtsM
Cell radio measurement table pCellRadioM
Radio access measurement table pRadioAccessM
SDCCH measurement table pSdcchM
TCH measurement table pTchM
SAPI3 measurement table pSapi3M
RMM assignment measurement table pRmmIndM
RMM call drop measurement table pRmmDropM
Handover reason measurement table pHoReasonM
Handover common measurement table pHoCommonM
Handover synchronization mode measurement table pHoSynM
Paging number measurement table pPageNumM
Abis interface signaling statistics measurement table pAbisSignalM
Radio resource availability measurement table pResourceAvailM
A interface signaling statistics measurement table pASignalM
A interface assignment, call drop, and handover statistics
measurement table pAIndHoDropM
SCCP connection and terrestrial circuit resource availability
measurement tablepSccpAndCicM
LAPD link measurement table pLapdM
SCCP link measurement table pSccpM
Processor load measurement table pMpLoadM
Q3 cell BTS measurement table
Module basic measurement table pModuleM
5
Name Database Table Name
Hardware availability measurement table pHwAvailM
PS basic measurement table pGprsBasicM
NS sub-layer measurement table表 pGprsNsM
BSSGP measurement table pGprsBssGpM
NSE performance measurement table pGprsPageM
Traffic statistics measurement table pGprsChM
Resource management measurement table pGprsResourceM
Handover statistics measurement table pHoCellM
Carrier basic measurement table pTrxBasicmM
Upper level NM basic measurement table pmsBasicM
HR measurement table phrm
2.2 Report Data Table
Names of each report data table and corresponding database table names are
shown in Table 3.
Table 3 Report Data Table
Name Database table name
Basic measurement middle table Pm_mid_table
PS basic measurement middle table Pm_mid_gtable
Upper level NM basic measurement middle table Pm_mid_mstable
Traffic daily table Pm_mid_day
Common measurement CELL-level middle table Pm_mid_cell
Common measurement BSC-level middle table Pm_mid_bsc
Common measurement NSE-level middle table Pm_mid_nse
Common measurement NSVC-level middle table Pm_mid_nsvc
Common measurement MODULE-level middle table Pm_mid_module
6
Chapter 3 Report and Handling Mechanism of Performance Data
Note:
The report and handling mechanism of performance data described in this
document is based on BSSV2.52.04.
Handling mechanism of different versions may differ.
1. Normally, BSC reports the performance data in form of messages to
OMCR, OMCR saves received messages in files and takes 15 minutes
as the granularity to put performance data files into the basic database.
2. If the foreground and the background are disconnected, then BSC
writes the performance data in a file under the directory measure and
reports it to OMCR after communication becomes normal. The
performance data is saved under the directory measure of BSC per
15M a file until the MP hardware is full.
3. On the server, the performance data is saved under corresponding
directory according to module No. and BSCID. For example,
performance data of BSCID=01 and ModuleID=02 is saved under
the directory $OMCHOME\tmp\pmmeas\BSC01\moudele02, under
which there are three subdirectories (FTP, PROC, and RPT). The
performance data is saved under FTP temporarily; if problems are
found in performance data handling, then put the file under PROC; if
performance data is normal, put the file under RPT.
4. If ORACLE/DB2 and performance database are all normal, the system
will save DAT files obtained from RPT directory of the background
server to basic tables.
5. Save basic table data of the previous hour to middle table at the tenth
minute every hour (delay is possible due to different versions).
Meanwhile, check whether data of the same time segment of
PmHistSychrMaxDays-1 days before has been imported to middle
table; or check if the number of records of an hour is less than
7
VALIDRECORDNUM (the default value is 3): if it is, import data of
the previous hour to the middle table.
6. Check data of previous PmUpdateBeforeDays days at 2:00 in the
morning every day. If data is illegal, update the data.
7. If abnormal case occurs and data has been saved to basic table but not
to the middle table, then trigger an operation of importing data from
the basic table to the middle table (only for this statistics time
segment) during generating performance report through the
performance analyzer. During generating the report, the system will
automatically implement the operation of importing basic table data to
middle table, thus the generating time will be lengthened.
8. The history data query in performance management involves data
retrieved from the basic table. The basic unit of data is 15 minutes, i.e.
the statistics data is the report that takes 15 minutes as the time unit.
9. Generating performance report through the performance analyzer
involves data retrieved from the middle table. The basic unit of data is
one hour, i.e. the statistics data is the report that takes one hour as the
time unit.
8
Chapter 4 Common Performance Problems and Solutions
4.1 Zero Traffic Found in Some Time Segments
【Fault description】
It is found on the site during generating daily traffic report that traffic of some
time segments is 0.
【Fault handling】
Enter the performance analyzer to generate the performance report of
the time segment
Enter the command window to execute PMDR. For example, the
following statement indicates updating data of 10:00 – 12:00 of Dec.
23rd.
Pmdr:2005-12-23,10-00-00:2005-12-23,12-00-00:0;
【Fault analysis】
The performance data handling mechanism shows that the performance data
file is imported to Pbasicm table first. Normally, the system automatically
initiates the task of updating middle table at the fifth minute of each time
segment and updates middle table data. There are two middle tables:
p_mid_table and p_mid_day. To accelerate data handling, the daily traffic
report data is directly retrieved from p_mid_table. If abnormal case occurs in
the system in a certain time segment (such as disconnection between the
foreground and background), then after the system becomes normal, the
performance data file has been imported to the basic table but the middle table
updating task hasn’t been implemented. In such a case, data can be imported
to the middle table only after the task of updating middle table is triggered
again.
【Fault solution】
Initiate a task of updating middle table manually.
4.2 No Multi-Band Report Data Found in Performance Report
【Fault description】
9
The China Unicom configuration data retrieved from the performance
analyzer only contains that of 900M and no 1800M is found.
【Fault analysis】
The fault is caused by not setting multi-band parameter in the performance
configuration file. The setting differs in different versions.
【Fault solution】
OMCRV2.52.04A or OMCRV2.80.01F version
# CompanyType: representing the commissioning type. 0: China Mobile; 1: China Unicom.
Need1800Rpt: representing 1800M report format displayed by China Unicom is needed.
[COMPANYINFO]
CompanyType = 1
Need1800Rpt = 1
OMCRV2.52.02E version
Modify the configuration file. Please modify the following two
parameters in pmcfg.ini on the server.
#add for multi freqband report
#0-P900 1-E900 14-PE900=P900+E900 2-DCS1800 3-R900 4-1900 7-850 15-Sum
#if set PE900 then the P900 and E900 must both be set or not set, otherwise the system is wrong
#15-sum is not need to set, it add by system by default
[FREQINFO]
NEEDFREQ = 1 FREQNUM = 3
FREQ1 = 14
FREQ2 = 2
FREQ3 = 7
4.3 Data Accumulated Under Background Server Directory
【Fault description】
No performance data of the time segment is found in the performance
analyzer.
Count the basic measurement data of the time segment in performance
management, and no relevant data is found.
Enter the directory OMCHOME\tmp\pmmeas\bscXX\moduleXX\proc
and find *.err file.
10
【Fault handling】
Check if database table space and index table space are full through database
monitor. If they are not full, analyze the returned DIF log, and the DIF log
printing level is required to be 5.
【Fault analysis】
Fault reasons include that Oracle/db2 is running abnormally, or performance
database table space and index table space are full. Obtain the detailed fault
reason according to the DIF log.
【Fault solution】
1. Check the performance table space and index table space. If they are
full, expand their sizes according to the server disk size or delete
relevant performance data and recreate index.
(Note: After deleting data by running the command delete, the occupied
space size displayed will not change, but the released space can be
utilized again.)
2. Since there are various forms of abnormal Oracle running and the
handling is complex, it is advised to return the obtained on-site DIF
log to ZTE Mobile Department to analyze it, and restart Oracle on the
site.
3. After ORACLE/DB2 database becomes normal, move the *.err file
under proc directory to rpt directory and rename the *.err file to be
*.dat file, and waits for the system to automatically import it to the
basic table.
4.4 Report Wizard Initialization Failure when Exporting Excel from Performance Analyzer
【Fault description】
The system prompts report wizard initialization failure when the performance
analyzer exports EXCEL.
【Fault analysis】
The fault is possibly due to c:/winnt/system32/ZXG_RepGuide_V20.ini being
damaged, or the Windows user having no Excel authority.
【Fault solution】
Delete the file c:/winnt/system32/ZXG_RepGuide_V20.ini, and log on as an
appropriate Windows user.
11
4.5 Statistics Report Unable to be Generated Through Performance Analyzer
【Fault description】
The disconnection fault has been existed for several days. After the system
becomes normal, relevant reports cannot be generated through the
performance analyzer.
【Fault handling】
View the basic table and find data of corresponding time segments, which
indicates successfully importing data to performance basic table.
【Fault analysis】
The middle table data has been legalized.
According to the performance configuration file, the system usually legalizes
seven days’ data after the seven days pass and assumes the disconnected data
cannot be reported.
To solve the problem, execute the update command (PMDR) for the middle
table data.
【Fault solution】
Enter the command window to execute the PMDR command. For example,
the following statement indicates updating data of 10:00 – 12:00 of Dec. 23rd
Pmdr:2005-12-23,10-00-00:2005-12-23,12-00-00:0;
The following is the command format of updating the middle table. Take the
time range from 11th to 21st for example:
PMDR:2003-01-11,00-00-00:2003-01-21,00-00-00:0;
Note: the last digit is the middle table type:
0, representing pm_mid_table;
1, representing pm_mid_day (24-hour traffic report)
2, representing GPRS report
4.6 TOP Tree Unable to be Obtained in Performance Analyzer
【Fault description】
The system prompts that the TOP tree cannot be obtained during performance
report statistics, but other function windows are running normally.
【Fault analysis】
12
The customized performance report’s name contains illegal character (such as
“,”), which causes abnormity to occur when the name being analyzed at the client.
【Fault solution】
Enter SQLPLUS to delete illegal customized reports in the RPTEMPLATE
table, restart the client, and the problem is resolved.
13
Top Related