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
Configuration

Performance

Data

The performance configuration file is: $OMCHOME\CONF\pmcfg.ini

1.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

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

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

1.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

1.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

1.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

tables 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: 0010: 00 of the day (Jan. 12th)

If data of 9: 0010: 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.

1.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
# 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.

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

pAIndHoDropM

measurement table
SCCP connection and terrestrial circuit resource availability

pSccpAndCicM

measurement table
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

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

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

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.

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 hasnt 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

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 reports 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