Pro Sup Adm Nor 013.3.00 PDF

TM
NIMS-PrOptima
For GSM BSS 15.0
Release 1.30
The Next Generation Performance Management Solution for Wireless Operators
System Administration
Manual
v3.00
Table of Contents
CHAPTER 1 - INTRODUCTION................................................................................................................. 5
1.1. INTRODUCTORY INFORMATION .................................................................................................... 5
1.2. USERS .................................................................................................................................................... 5
1.3. CONVENTIONS .................................................................................................................................... 5
1.4. VERSION & SCOPE.............................................................................................................................. 5
1.5. PUBLICATION DATE .......................................................................................................................... 5
1.6. OTHER MANUALS............................................................................................................................... 6
1.7. COPYRIGHT INFORMATION ............................................................................................................. 6
1.8. CUSTOMER SUPPORT CONTACT INFORMATION ........................................................................ 6
CHAPTER 2 - OVERVIEW OF ALL PROCESSES .................................................................................. 7

2.1. CHAPTER INTRODUCTION ............................................................................................................... 7
2.2. PRESENTATION OF THE DIFFERENT PROCESSES ....................................................................... 7
2.2.1. Third Party processes ...................................................................................................................... 7
2.2.2. MYCOM processes ......................................................................................................................... 7
2.3. DEPENDENCIES OF NIMS-PROPTIMA PROCESSES...................................................................... 7
2.4. THE START/STOP ORDER OF THE PROCESSES ............................................................................ 8
CHAPTER 3 - THIRD PARTY PROCESSES........................................................................................... 10

3.1. CHAPTER INTRODUCTION ............................................................................................................. 10
3.2. ORACLE DATABASE ADMINISTRATION ..................................................................................... 10
3.2.1. Oracle 9 database server................................................................................................................ 10
3.2.2. Oracle startup script ...................................................................................................................... 10
3.2.3. Oracle Shutdown script ................................................................................................................. 10
3.2.4. Check the running processes ......................................................................................................... 10
3.2.5. Check the connection to Oracle..................................................................................................... 10
3.3. WEB SERVER ADMINISTRATION .................................................................................................. 11
3.3.1. TCP/IP Networking....................................................................................................................... 11
3.3.2. Web Hosting and Internet Servers................................................................................................. 12
CHAPTER 4 - MYCOM APPLICATION PROCESSES ......................................................................... 13

4.2. STARTUP SCRIPTS ............................................................................................................................ 13
4.2.1. RMI registry startup script ............................................................................................................ 13
4.2.2. NIMS-PrOptima License Manager startup script.......................................................................... 13
4.2.3. Application Server (for multidimensional calculations) startup script.......................................... 13
4.2.4. Importation Server (DAIE) startup script...................................................................................... 13
4.3. RUNNING PROCESS CHECK............................................................................................................ 14
4.3.1. Command line process check ........................................................................................................ 14
4.3.2. Application level process check .................................................................................................... 14
4.3.3. Automatic process supervision...................................................................................................... 15
4.4. SHUTDOWN SCRIPTS ....................................................................................................................... 17
4.4.1. Importation Server (DAIE) shutdown script ................................................................................. 17
4.4.2. Application Server shutdown script .............................................................................................. 17
4.4.3. License Manager shutdown script................................................................................................. 17
4.4.4. RMI registry shutdown script........................................................................................................ 17
System Administration manual NIMS-PrOptima - ref: PRO-SUP-ADM-NOR-013-3.00-EN
Copyright MYCOM International 2004
CHAPTER 5 - IMPORTATION DATABASE ADMINISTRATION (DAIE) ........................................ 19
5.2. CHECKING DATA IMPORTATION PATHS IN SYNCHRONISATION PROPERTIES FILE....... 19
5.3. CHECKING THAT IMPORTATION PARAMETERS ARE CORRECT BEFORE STARTING
IMPORTATION ............................................................................................................................................... 26
5.4. CONFIGURING SDO FILES............................................................................................................... 27
5.4.1. Configuring the Counter Mapping File ......................................................................................... 27
5.4.2. Customizing the column separators of SDO files ......................................................................... 28
5.5. STARTING THE IMPORTATION STEP BY STEP........................................................................... 28
5.5.1. Launching an importation session................................................................................................. 28
5.5.2. Checking the configuration importation........................................................................................ 29
5.5.3. Checking the performance counters importation........................................................................... 29
5.5.4. Cleaning the database and deleting all the imported data.............................................................. 29
5.6. STARTING THE IMPORTATION CONTINUOUSLY...................................................................... 30
5.6.1. Starting the continuous importation .............................................................................................. 30
5.6.2. Checking the continuous importation process............................................................................... 30
5.7. PERFORMANCE DATABASE ARCHIVING AND PURGING BY THE DAIE.............................. 32
5.7.1. Archiving ...................................................................................................................................... 32
5.7.2. Purging .......................................................................................................................................... 33
5.8. DELETING ALL DATA MANUALLY .............................................................................................. 33
CHAPTER 6 - BACKUP/RESTORE.......................................................................................................... 35
6.2. BACKUP ARCHITECTURE OVERVIEW (WHEN PERFORMED WITH VERITAS).................... 35
6.3. BACKUP STRATEGY (WITH VERITAS) ......................................................................................... 36
6.3.1. Daily incremental backup of the PrOptima data ........................................................................... 36
6.3.2. Daily incremental on-line backup of the Oracle database ............................................................. 36
6.3.3. Weekly full backup of the PrOptima data ..................................................................................... 36
6.3.4. Weekly full on-line backup of the Oracle database....................................................................... 36
6.4. RESTRICTIONS (WITH VERITAS)................................................................................................... 36
6.5. BACKUP PROCEDURE (WITH VERITAS) ...................................................................................... 37
6.6. VERITAS NETBACKUP INSTALLATION AND CONFIGURATION............................................ 37
6.6.1. Veritas NetBackup installation...................................................................................................... 37
6.6.2. Veritas NetBackup configuration.................................................................................................. 38
6.7. RESTORE PROCEDURE (WITH VERITAS)..................................................................................... 44
6.7.1. Restore scenarios........................................................................................................................... 44
6.7.2. Restoring the PrOptima data files with Veritas ............................................................................. 45
6.7.3. Restoring the Oracle backup files with Veritas ............................................................................. 45
6.7.4. Recover the Oracle database from backup files ............................................................................ 46
CHAPTER 7 - SDO RECONFIGURATION PROCEDURE ................................................................... 48

7.2. ADDING NEW SDOS IN AUTOMATIC MODE ............................................................................... 48
7.3. REMOVING SDOS FROM THE DATABASE................................................................................... 48
CHAPTER 8 - USER AND GROUP RIGHTS MANAGEMENT............................................................ 50
CHAPTER 9 - SUPERVISION CONSOLE AND SELF MONITORING .............................................. 51


9.2. SUPERVISION CONSOLE ................................................................................................................. 51
9.2.1. Launching the application ............................................................................................................. 51
9.2.2. Login ............................................................................................................................................. 51
9.2.3. Monitoring Commands ................................................................................................................. 52
9.2.4. Error messages .............................................................................................................................. 55
9.3. SELF MONITORING........................................................................................................................... 56
9.3.1. Launching the application ............................................................................................................. 56
9.3.2. Monitoring hardware resources..................................................................................................... 56
CHAPTER 10 - LIST OF ABBREVIATIONS............................................................................................. 59

Chapter 1 - Introduction
1.1. Introductory information
This document is a System Administration manual for the NIMS-PrOptimaTM system Release 1.30 corresponding
to Nortel GSM Access v15.0. This document is destined to be used by system administrators.
1.2. Users
This document is destined to be used by system administrators who administrate and upgrade the NIMS-
PrOptimaTM system.
This manual assumes that the system administrator is very familiar with Unix commands (this manual is not a
Unix tutorial). Unix tutorials can be accessed at:
⇒ http://www.unixtools.com/unixprimer.html
⇒ http://www.isu.edu/departments/comcom/unix/workshop/unixindex.html
⇒ http://www2.ucsc.edu/cats/sc/help/unix/command/index.shtml
1.3. Conventions
The typographical conventions used in this manual are the following:
• Bold face: command line sequences
• Italics boldface: answer sequences in Results of actions
• ALLCAPS: Control key sequences
• Underline: To introduce Notes, Warnings, and Results and special important words
All Unix commands indicated in this manual are assumed to be in sh Bourne shell. Please note that the use of
any other shells (e.g. csh, bash, tcsh, etc) might have an adverse affect on the use of commands that are indicated
in this manual.
To check that sh is the shell that is used, type in:
ps | grep $$
Result: This should return a line indicating the shell that is used.
1.4. Version & Scope

This document is version 3.00 of the System Administration manual and is referenced as PRO-SUP-ADM-NOR-
013-3.00-EN. The information provided in this manual is specific to the administration tasks of the various
servers and clients of NIMS-PrOptimaTM Release 1.30 (Nortel GSM BSS Access v15.0).
1.5. Publication Date

This manual has been released on 29 September 2004 and is valid until the publication of the next document in
this series.
System Administration Manual NIMS-PrOptima - ref: PRO-SUP-ADM-NOR-013-3.00-EN

Copyright MYCOM International 2004 5/59
1.6. Other Manuals

Documents that are referred to in this manual or which were used to create the information in this manual, are
listed below.
Document Reference code
Installation manual PRO-I&C-USM-NOR-008-3.00-EN
Troubleshooting guide PRO-SUP-ADM-NOR-014-3.00-EN
User Manager user manual PRO-SUP-USM-NOR-039-3.00-EN
PrOptima client user manual PRO-SUP-USM-NOR-041-3.00-EN
1.7. Copyright information

Copyright MYCOM International 1996-2004.
All rights reserved. The present document cannot be duplicated in any way without prior written consent of
MYCOM International. The information included in this document is for reader personal use only.
Trademarks: NIMSTM, PrOptimaTM and NIMS-PrOptimaTM are all trademarks of MYCOM International Inc. All
other products mentioned in this document are property of their respective owners.
1.8. Customer Support Contact information

Please contact Nortel Networks for technical support. For product and documentation issues a Service Request
should be opened. Follow regular Nortel Networks support channels.
Contact us through the web at: http://www.nortelnetworks.com
Select the Service Requests option in the Support menu, then select the region where you are located.
System Administration Manual NIMS-PrOptima - ref: PRO-SUP-ADM-NOR-013-3.00-EN

Chapter 2 – Overview of all processes
Chapter 2 - Overview of all processes

2.1. Chapter Introduction
This chapter aims at giving an overview of the different processes used by the NIMS-PrOptimaTM solution. This
solution involves third-party processes and specific processes developped by Mycom that interact with one
another. It is therefore useful for the administrator to know which are the different processes involved and which
are their inter-service dependencies.
2.2. Presentation of the different processes

NIMS-PrOptimaTM uses several processes running on its server. These can be divided into 2 main categories.
2.2.1. Third Party processes

NIMS-PrOptimaTM relies on several Third Party processes. These are the following:
• Oracle: this allows the access and the storage of relational data.
• TNS Listener: this allows the connectivity to Oracle.
• Tomcat: this is the Web server which allows the connectivity to the Web PrOptima application.
Note: These processes are normally automatically started at boot time by the script
/etc/init.d/proptima
2.2.2. MYCOM processes

NIMS-PrOptimaTM relies on MYCOM processes. MYCOM processes include several Application processes.
• License Manager: this is a license server.
• RMI Registry: allows the connectivity to the client/server process of Java. When NIMS-PrOptimaTM
Client is started, the application connects to the RMI Registry of the server to bootstrap the
connection to the MDDS server.
• MDDS: this is a calculation and request server. It is also used for Web requests.
Note: These processes are normally automatically started at boot time by the script
/etc/init.d/proptima
MYCOM processes also include the Importation process:

• DAIE: is the importation engine.
Note: DAIE administration is documented in chapter 5 Importation Database Administration (DAIE).
Note: This process can be optionally started at boot time by the script /etc/init.d/proptima.
2.3. Dependencies of NIMS-PrOptima processes

This subsection presents the inter-service (processes) dependencies.
Terminology:
When we say that service A depends on service B, it means that:
• B needs to be started before A is started, and
• A needs to be shut down before B is shut down

Note: This information must be taken into account when a service needs to be restarted (for example, when the
configuration has changed).
• The MDDS depends on Oracle, the RMI registry and the License Manager.
• The DAIE and Tomcat depend on the MDDS.
PrOptima Server
License Manager
TNS Listener Oracle
MDDS
Client
DAIE
Third Party Processes

RMI Registry
Mycom Processes
Processes relationships
Tomcat
Links between Client & Web Server PrOptima Web
PrOptima Server processes
Processes Interactions
2.4. The start/stop order of the processes

The start procedure of the different processes should be performed in the following order (this order takes into
account the inter-service dependencies):
Oracle
TNS Listener
RMI Registry
License Manager
MDDS
DAIE
Tomcat
Warning: Do NOT start the DAIE until configuration is correctly configured and tested. Refer to the
Importation Database Administration section before starting or shutting down the DAIE.
The stop procedure must be done in the reverse order of the start procedure. You should stop the processes in the
following order:
Tomcat
DAIE
MDDS
License Manager
RMI Registry
TNS Listener
Oracle
All of these 3rd party and MYCOM processes are explained in the following chapters.

Chapter 3 – Third Party Processes
Chapter 3 - Third Party Processes

This chapter describes how to manage the third-party processes used in the NIMS-PrOptimaTM solution. It is
divided into 2 main parts: the Oracle Database administration and the Web server administration.
3.2. Oracle Database Administration
3.2.1. Oracle 9 database server

Warning: The Oracle database server that is required for NIMS-PrOptimaTM is an embedded version of Oracle
9i Release 2.
The monitoring tasks of Oracle 9 are the usual Oracle administration tasks: monitoring of the space available in
the devices, of the rollback segments devices, of the performance, etc. Please refer to the corresponding Oracle
documentation for more information (http://www.oracle.com).
The Oracle database contains only configuration information; therefore, it does not grow rapidly if at all, and no
purging / archiving is required.
There are no tasks regarding the security management, which is done entirely in the Application Server. Oracle
users and groups are internal. They are set up at install time and do not need to change during the lifetime of the
operations.
3.2.2. Oracle startup script

After NIMS-PrOptimaTM has been installed, the Oracle server can be started using the script:
/opt/mycom/shell/oracle/oracle.sh start
3.2.3. Oracle Shutdown script

The Oracle server can be shut down using the shutdown script:
/opt/mycom/shell/oracle/oracle.sh stop
3.2.4. Check the running processes

Type the following command to check the Oracle process:
pgrep -lf ora_
Result: It should return several entries.
Type the following command to check the tnslistener process:
pgrep -lf tnslsnr
Result: It should return one or more entries.
Type the following command to check the Tomcat process.
pgrep -lf tomcat
Result: It should return several entries.
3.2.5. Check the connection to Oracle

Check that the server listens on port 1521 (the following line must reply immediately).
Type in:
telnet <servername> 1521
Result: It should return either a few lines beginning by “Trying…” or an empty window.
Note: If the connection fails, a message is displayed saying that telnet is “unable to connect to remote host” and
that the “connection is refused”.
Press CTRL + C two or more times to exit.
3.3. Web server Administration
3.3.1. TCP/IP Networking
3.3.1.1. Check the IP address of the server

Check that the server IP address is the one that MYCOM provided with the license file.
su -
ifconfig –a
Result: Entries should appear.
3.3.1.2. Check that the server can be pinged from all NIMS-PrOptima clients
From a client machine, open a prompt console and type in the following:
ping <server name>
Result: No error should be generated.
3.3.1.3. Check that the processes acting as TCP/IP servers are listening to the
expected port
To check the tomcat port used by default by the Web PrOptima application, enter the following:
telnet <server name> 8080
To check the RMI Registry port (which enables to connect to the RMI):
To check the Oracle port:
To check the JServ port:
To check the License Manager port:
Note: The expected behavior depends on the platform. One way of proceeding is to telnet to the server on any
other port (e.g. 12345), and check the output which says that the server is not listening to this port.

PrOptima Server
License Manager
38227
TNS Listener Oracle
1521
RMI Registry
Client 1099
38228 MDDS
8080 Tomcat
PrOptima Web
Web Server
DAIE
TCP/IP Ports used between Client and Servers
3.3.2. Web Hosting and Internet Servers
3.3.2.1. Rebooting and shutting down

Tomcat is launched and stopped at boot time by the script /etc/init.d/proptima. However it is possible to stop
Tomcat and restart it manually.
Log on as root and go to the shell directory:
su -
cd /opt/mycom/shell/
To restart Web server:
./restart_web.sh
3.3.2.2. Tomcat running process status check

Note: At any time, it is possible to obtain a status of the Tomcat running processes.
Log on as root
su -
Enter:
pgrep -lf tomcat
Result: It should return at least one entry.
3.3.2.3. Check logs

The tomcat logs are located in the following directory:
cd /opt/mycom/logs/web

Chapter 4 – MYCOM Application Processes
Chapter 4 - MYCOM Application

Processes
This chapter describes how to launch the NIMS-PrOptimaTM services manually and how to check that the
corresponding processes are running.
Warning: once the NIMS-PrOptimaTM processes are started, Oracle should not be shut down. If an Oracle failure
or a power failure occurs, it is then necessary to re-launch manually all processes.
4.2. Startup scripts

If you need to start the processes manually, then use the following steps in the order that is provided:
4.2.1. RMI registry startup script

This is the startup command for the RMI registry.
Login as user mycom and go to the startup scripts directory:
su – mycom
cd /opt/mycom/shell
Run the RMI Registry startup script:
nohup ./mycomrmi.sh start &
4.2.2. NIMS-PrOptima License Manager startup script

This is the startup command for the NIMS-PrOptimaTM License Manager.
su – mycom
cd /opt/mycom/shell
Run the License Manager startup script:
nohup ./mycomlicmgr.sh start &
Check the log file in /opt/mycom/logs/lic.log
4.2.3. Application Server (for multidimensional calculations) startup script

This is the startup command for the Application Server.
su – mycom
cd /opt/mycom/shell
Run the MYCOM MDDS Server startup script:
nohup ./mycommddb.sh start &
The log file is: /opt/mycom/logs/proptimaserver.<date>.log
Result: The last line should be "Rebinding done"
4.2.4. Importation Server (DAIE) startup script

This is the startup command for the Importation Server.
Warning: Do NOT start the DAIE until configuration is correctly set and tested. Refer to the Importation
Database Administration chapter (next chapter) before starting or shutting down the DAIE.


su – mycom
cd /opt/mycom/shell
Run the MYCOM DAIE Server startup script:
nohup ./mycomdaie.sh start &
Note: Refer to the Importation Database administration chapter (next chapter) for more detailed information
about the DAIE.
4.3. Running process check
4.3.1. Command line process check
4.3.1.1. Non-MYCOM processes

First check that Oracle and Tomcat are both running.
To check that Oracle is running:
Log in as root: su -
Enter ps –elf | grep ora_
Result: It should return several entries ora_xxx_NIMS
Login as oracle: su – oracle
sqlplus
Enter user-name: proptima
Enter password: proptima
Result: It allows to connect to oracle with a command line interface. You must obtain a message
saying “Connected to”:
To check that Tomcat is running:
Log in as root: su -
Enter pgrep -lf tomcat
Result: It should return at list one entry.
4.3.1.2. Status of MYCOM proprietary processes

At any moment, it is possible to obtain a status of the MYCOM running processes by entering the following:
/opt/mycom/shell/status.sh
Note: This status verification command is only valid for checking MYCOM running processes (mycomrmi,
mycomlicmgr, mycommddb, mycomdaie), but is neither valid for checking Oracle nor Tomcat running
processes.
4.3.2. Application level process check
4.3.2.1. Check using NIMS-PrOptima

Open a browser and enter you server name: http//<server name>
Click on Launch PrOptima
Result: The application launches through Java Web Start.
Then log in as a PrOptima user.
Result: A few seconds after user authentication is completed, the menus and buttons are activated.
This test ensures that the following processes are fully operational:
• oracle

• mycomrmi
• mycomlicmgr
• mycommddb
• tomcat (low level)
4.3.2.2. Check NIMS-PrOptima web

Open a browser and enter you server name: http//<server name>
Click on Launch PrOptima Web Interface
Result: The application launches through Java Web Start.
Log in as a PrOptima user.
Choose a report in the pop-up list and click on Generate
Result: After a few seconds, a report or a graph appears.
The display of the report will actually be a means to check the running of:
• Oracle
• mycomrmi
• mycomlicmgr
• mycommddb
• Tomcat (PrOptima Web)
Note: If the report fails to appear, at least one of the above processes is not running correctly.
4.3.3. Automatic process supervision

Both NIMS-PrOptimaTM process and third party process can be automatically checked by the ProcessSupervision
script.
For each process, the ProcessSupervision script checks if it is running. If the process seems to have crashed,
ProcessSupervision tries to restart the process (but if the process has been manually stopped, it does not try to
restart it). If it fails, then ProcessSupervision sends an alert mail to the NIMS-PrOptimaTM administrator account.
Note: The e-mail address that will be used by the ProcessSupervision script is configured via a specific property
that can be reached and edited via the following command lines:
cd /opt/mycom/shell
vi admin.conf
You should see the following output:
# Customizable variables
# Change the following line if mriregistry is not on the path
# Timeout before giving up on the lock file in minutes
backupTimeout=10
# Administrators who will get mail upon problem
alertRecipients=<administrator e-mail address>
mailSender=nims@localhost
Edit if necessary the alertRecipients property.
ProcessSupervision uses a configuration file, ProcessToSupervise.list, which contains the list of the NIMS-
PrOptimaTM process you want to supervise. Here is the default content of this file:
#
# This is the list of the PrOptima processes to be supervised by
ProcessesSupervision.pl
#
# Comment a process to skip it
# Uncomment a process to check it

mycomrmi.sh
mycomlicmgr.sh
mycomftpmed.sh
mycommddb.sh
# mycomdaie.sh
By default, the mycomdaie is NOT automatically checked and restarted in order to allow the administrator to
configure data importation before starting it. Furthermore, this list is ordered i.e. the mycomrmi is checked first,
then mycomlicmgr, then mycommddb. This order is important (see chapter 2.3.) and should not be modified.
ProcessSupervision also checks and restarts Oracle server, Oracle listener and Tomcat, and runs a SQL test to
complete Oracle checking.
The administrator can run ProcessSupervision manually, or schedule it with the cron unix scheduler (refer to the
cron scheduling procedure below).
4.3.3.1. ProcessSupervision: manual execution

Login as user root and go to the startup scripts directory:
su –
cd /opt/mycom/shell
Run the ProcessSupervision script:
./ProcessSupervision.pl
Result: ProcessSupervision prints the status of each process and the action eventually performed inside a
log file (/opt/mycom/logs/:ProcessSupervision.log) as in the following example:
ProcessSupervision.pl : Mon Oct 27 15:50:00 2003
ProcessSupervision.pl : Beginning processes supervision...
ProcessSupervision.pl : Checking Oracle instance NIMS...
ProcessSupervision.pl : Oracle instance NIMS OK.
ProcessSupervision.pl : Checking Oracle listener for NIMS...
ProcessSupervision.pl : Oracle listener for NIMS OK.
ProcessSupervision.pl : Testing Oracle SQL-Plus for NIMS...
ProcessSupervision.pl : Oracle SQL-Plus for NIMS OK.
ProcessSupervision.pl : All Oracle processes successfully tested !
ProcessSupervision.pl : Checking PrOptima mycomrmi.sh...
ProcessSupervision.pl : PrOptima mycomrmi.sh OK.
ProcessSupervision.pl : Checking PrOptima mycomlicmgr.sh...
ProcessSupervision.pl : PrOptima mycomlicmgr.sh OK.
ProcessSupervision.pl : Checking PrOptima mycommddb.sh...
ProcessSupervision.pl : PrOptima mycommddb.sh OK.
ProcessSupervision.pl : Checking PrOptima mycomstats.sh...
ProcessSupervision.pl : PrOptima mycomstats.sh OK.
ProcessSupervision.pl : Checking Tomcat...
ProcessSupervision.pl : Tomcat running OK.
ProcessSupervision.pl : End of processes supervision.
ProcessSupervision.pl : Mon Oct 27 15:50:05 2003
4.3.3.2. ProcessSupervision: cron scheduling

Login as user root and go to the startup scripts directory:
su –
cd /opt/mycom/shell
The user root may already have an active crontab. To check it, type in:
crontab -l
1st case: if this command returns any line, it means that root has already an active crontab. In this
case, perform the following actions:
⇒ Back up the active crontab to a file called current.crontab :
crontab -l > current.crontab
⇒ Merge the current.crontab and the mycom.crontab to a new file called merged.crontab :
cat current.crontab > merged.crontab
cat mycom.crontab >> merged.crontab

⇒ Launch the cron scheduler using the merged.crontab file:

crontab merged.crontab
2nd case: if there is no active crontab (no line returned), then simply launch the cron scheduler using
the mycom.crontab file:
crontab mycom.crontab
Result: The cron scheduler will run ProcessSupervision every week day, every five minutes. It will send
an alert mail to the NIMS-PrOptimaTM administrator account, if one of the process is down and could not
be restarted.
To stop the cron, login as root and type:
crontab -r
To check that the crontab is ready and running, login as root and type:
crontab -l
4.4. Shutdown scripts

Warning: To stop the processes, follow the same procedure as for starting processes, but:
• stop the processes in the inverse order to which they were started.
• make sure that the shutdown commands do not include the “&” symbol.
4.4.1. Importation Server (DAIE) shutdown script

This is the shutdown command for the Importation Server.
su – mycom
cd /opt/mycom/shell
Run the shutdown script:
./mycomdaie.sh stop
4.4.2. Application Server shutdown script

This is the shutdown command for the Application Server.
su – mycom
cd /opt/mycom/shell
./mycommddb.sh stop
4.4.3. License Manager shutdown script

This is the shutdown command for the license manager.
su – mycom
cd /opt/mycom/shell
./mycomlicmgr.sh stop
4.4.4. RMI registry shutdown script

This is the shutdown command for the RMI registry.
su – mycom
cd /opt/mycom/shell


./mycomrmi.sh stop

Chapter 5 – Importation Database Administration
Chapter 5 - Importation Database

Administration (DAIE)
Since data importation is a critical task, many monitoring facilities are included in the importation engine, the
DAIE. The Importation Engine can indeed be configured and managed via:
• The Importation Control Manager (ICM) which provides a user-friendly interface to perform all the
data warehousing activities and maintenance operations on an installed DAIE. The ICM is essential
for:
⇒ Manipulating metadata
⇒ Designing data importation interfaces
⇒ Importing/exporting metadata information to text files for easy versioning of the metadata
information
• Several default properties gathered in a directory called Synchronisation properties. the
PrOptima administrator can edit these properties by overloading his personal user file. He can thus
define different administration parameters e.g. the configuration of the DAIE for the report scheduler,
for the archiving and purging of the performance database etc.
This section presents the different checks that can be made to verify that the DAIE runs correctly and how to
ensure that data importation is correctly set and run. It eventually describes how to manually archive and purge
data.
5.2. Checking data importation paths in Synchronisation

properties file
This sub-section indicates the properties that should checked and edited if necessary. The administrator might
need to edit these properties to configure flatfile management (for the importation of Configuration Attributes),
report scheduling, alarm reporting, the ratios of missing values (refer to Nortel Specific lines further in this sub-
section).
Warning:
The Properties should be checked in the synchronisation.properties file containing values which are set by
default when NIMS-PrOptimaTM is delivered. These are stored in:
/opt/mycom/config/server/res/Synchronisation.properties
Warning: The Synchronisation.properties file is overwritten whenever a new version of NIMS-

PrOptimaTM is installed. If you want to keep your own configuration, the Properties must be edited in the
users directory (containing the users’ properties files). These are stored in:
/opt/mycom/data/users
To edit one or several synchronisation.properties, you must therefore:
Copy them from the
/opt/mycom/config/server/res/Synchronisation.properties file.
Paste them in the Synchronisation.properties.mycom file stored in the
/opt/mycom/data/users directory so as to proceed with your own configuration.
If this file does not exist:
⇒ Create a new file
⇒ Copy and paste the properties that need to be edited in this new file

⇒ Rename the file Synchronisation.properties.mycom

Verify and edit (if necessary) the DAIE Global Log Levels lines:
Check or complete the lines Notes
To activate/deactivate debug traces.

DebugLevel=0 0: no trace
1: trace activated
Used to filter the messages stored in the

database.
5: all messages are logged.
10: all messages except debug ones are
logged.
LogLevel=20
20: only the warnings and errors are
logged.
30: only the errors are logged.
40: only the fatal errors are logged.
Above: nothing is logged
Used to filter the messages stored in the

circular log file
5: all messages are logged
10: all messages except debug ones are
logged
LogFileLevel=20
20: only the warnings and errors are
logged
30: only the errors are logged
40: only the fatal errors are logged
Above: nothing is logged
Verify and edit (if necessary) the DAIE Retry Management lines:

Indicates whether the DAIE should store

DAIE.XML3GPP.IncrementalUpdateSu the list of already processed files or not.
pport=true This allows to avoid processing the files
again during a retry session.
ActivateDailyReImportAtMidnight= Indicates whether the daily perf data

true collection should be triggered at midnight
or not.
ActivateQuickImportModeDuringDai Indicates whether the DAIE should only

lyReImport=true process the new files during the daily perf
data re-collection or not.
Indicates whether the DAIE should also

Formula.ForceProcessingDuringPas process the time pre-aggregations and pre-
tDayReImportation=true aggregated metrics during a daily re-
import session or not.
Forces the DAIE to process only files that

have not already been processed. Can be
QuickPerfImportMode=false used as parameter of shell script
ManualIMPORT.sh to reimport in the past
without processing already processed file.
Verify and edit (if necessary) the DAIE Multithreading management lines:
To set the number of concurrent threads

that can be run during raw counter
importation.
DAIE.RawCounterImport.MaxConcurr This property indicates the number of
entThreadCount=1 simultaneous set of vendor/NE type/time
granularity that can be run.
If not set the default value is the number of
available CPUs + 1.
To set the number of counter entity threads
that can be run simultaneously for one set
of raw counter importation (raw counter
DAIE.RawCounterEntity.MaxConcurr
entThreadCount=1 with same vendor/NE type/time
granularity).
If not set the default value is the number of
available CPUs + 1.


that can be run during file parsing (set of
files that must be parsed for a specific
Xml3gpp.MaxConcurrentThread=1
counter group).
If not set the default value is twice the
number of available CPUs.
that can be run for pre-aggregation
DAIE.Formulae.MaxConcurrentThrea
dCount=1 computation.
If not set the default value is twice the
number of available CPUs.
Verify and edit (if necessary) the Nortel specific lines:
During a configuration update, the results

of a NE entity are taken into account if the
ratio of missing NEs is less than X
Config.MaxAcceptableNEDeletionRa
tio=4 percent.
Ex: if more than X percent of NEs are
missing (late files), the NEs are not
invalidated
During a configuration update, the results
of an attribute entity are taken into account
Config.MaxAcceptableAttributeDel if the ratio of missing NEs is less than X
etionRatio=4 percent.Ex: if more than X percent of NEs
are missing (late files), the attributes are
updated
During a configuration update, the NEs are
resurrected if they correspond to old
Config.AuthoriseResuscitation=fa
lse invalidated NEs.
New NEs are not created. The old one is
re-used and can be seen again in Proptima.
Hour of the day (local time) when the

Configuration.NetworkIdleHour=4 network is less busy. Used to trigger the
configuration update.
Delay before querying counter values.

Counter.DelaySecondBeforeQuery=9 Used to give some time to the external
00 datasources to upload the performance
data.

Indicates the default percentage of missing

values above which the retry mechanism is
activated for counter entities.
Ex: If this value is set to 4, it means that it
is acceptable that less than 4% of the NEs
have missing values for a counter.
If more NEs have missing values, the
DAIE will activate the retry mechanism to
try to collect data again for the same
Counter.RatioValuesMissingBefore period during the next counter importation
Retry=4 session. This mechanism has been put in
place to cope with late data.
Note: This property sets the default value
for retry activation for all the counter
entities.
This value can be overloaded entity per
entity using the ICM: menu Importation
Database/Entities/Counter Entities then
update the Reliability Ratio field of the
selected entities.
Counter.MaxNumberOfIteration=2 Default max number of retry in case to

many counter values are missing.
To recompute pre-aggregated metrics and

time aggregations after a delay (by default
6hours). This is useful to ensure that pre-
aggregated values are based on all the
Counter.DelayHourForPreAggregati collected values (even if they come during
onRecomputation=1 a retry and after the first pre-aggregation
computation).
Set this value to 0 if the DAIE should
never recompute the pre-aggregated
values.
Verify and edit (if necessary) the DAIE Flatfile Management lines:
Spare NE entries in flatfile. These entries

FlatFile.SpareNEEntriesInFlatFil are empty slots used to store performance
e=10 data for NEs that have not yet been
discovered during last configuration
importation session.

When FlatFile.SpareNEEntriesInFlatFile
is not zero, the DAIE automatically checks
old flatfiles after a new configuration
importation session to resolve the slots
FlatFile.DayPeriodToCheckForFlat corresponding to NEs that were unknown
FileNEMappingUpdate=2 at the time of the performance import
session.
These properties tell the DAIE to only
look at the flatfiles which are not older
than a specific number of days.
FlatFile.DefaultDayFlatFileDurat Number of days put by default in the

ion=2 newly created daily flatfiles.
FlatFile.DefaultWeekFlatFileDura Number of weeks put by default in the

tion=2 newly created weekly flatfiles.
Verify and edit (if necessary) the DAIE Archiving properties lines:
Archive.LessThanDayFilesetHistory Number of day history that must be kept

=21 for performance data of a time
granularity inferior to a day.
Archive.MoreThanDayFilesetHistory Number of day history that must be kept

=365 for performance data of a time
granularity superior to a day.
Purge.ArchiveDirMonitored=false Purge properties:

if Purge.ArchiveDirMonitored is set to
true, then:
Archive.DirSizeMb=1024 Archive.DirSizeMb indicates the max
size of the archive directory and
Archive.DirUsagePercentPurgeTrigger
indicates which occupation ratio should
Archive.DirUsagePercentPurgeTrigg trigger the purge of the oldest files of the
er=80 archive directory.
Note: The flatfile archiving can be precisely managed using the MDDB data Configuration tool of the ICM
application (refer to sub-section 5.5.1. MDDB flatfile set Configuration).
Edit the DAIE Alert Email Configuration, the Alarm Report Destination and the Alarm Purge lines
to configure the alarm module:
Email.Host=<local host> Enter the e-mail server name
Email.Originator=proptima_DAIE@m Enter e-mail address of alarm e-mails

ycom-int.com originator
Synchronisation.EmailReport.Coun To get an e-mail every time a counter

ter=true entity has missing values
Synchronisation.EmailReport.Conf To get a configuration importation

ig=true summary every day
Synchronisation.EmailReport.Reci Enter the e-mail address of the person

pientList=support@mycom-int.com whom the emails should be sent to
AlarmReportDestination.BasePath=
/opt/mycom/data/alarm_autogen_re Base path for the alarm reports
port
AlarmReportDestination.Path=$ne_
type/$ne_id/$calc Relative path for the alarm reports
AlarmReportDestination.Filename=
$datetime_$gran Auto-build filename for alarm reports
Number of days during which Alarm

AlarmPurge.DayCount=7 Evaluation Results will remain within the
database before being automatically
purged.
Filename of the dump file created after the

AlarmPurgeDestination.Filename=$ automatic purge. By default the value is
currentdate_purge “$currentdate_purge” but this value will be
replaced by the purge date.

AlarmPurgeDestination.Path=alarm Path of the directory that is relative to the

_purge_archive server homedir of NIMS-PrOptimaTM
Note: Two properties i.e. AlarmProcessor.Login and AlarmProcessor.Password are also used by the DAIE to
connect itself to the MDDB server during the Alarm evaluation. By default, these two properties are not
integrated in the Synchronisation.properties file since their default values are normally sufficient. These default
values are:
AlarmProcessor.Login=internal
and
AlarmProcessor.Password=
Verify and edit (if necessary) the ReportScheduler properties lines:
ReportScheduler.Login= Login properties used by ReportScheduler

to compute automatic reports.
ReportScheduler.Password= Login properties used by ReportScheduler

to compute automatic reports
ReportScheduler.DayHistory=7 Context duration, ending today
ReportScheduler.RefreshDelayMinu
tes=1 Refresh of internal cron table
5.3. Checking that importation parameters are correct before

starting importation
You SHOULD run the pre-check test utility in the ICM application before data importation (if data is
available for the time/date that you want to check).
Type in the following command lines to run the ICM:
su – mycom
DISPLAY=servername:portnumber
export DISPLAY
/opt/mycom/shell/ImportControlManager.sh
Note: By default, the login is administrator (no password)

In the ICM, select the Utilities->Pre-check Importation Setup menu item.
Type an importation date for the date for which you have available data.
Click on Start.
Note: Estimated waiting time for precheck tests: 15 minutes. If the ICM seems to be locked up, it is most likely
not the case. Check the following:
• Cursor: Move your cursor outside of the Precheck Window and it should become a clock.
• Status bar: Check the status bar in the bottom left-hand corner. If it has not advanced, then wait a few
more minutes.
WARNING: you should fix all the indicated problems, before running an importation.
5.4. Configuring SDO files

WARNING:
Since SDO configuration is a user’s customization, the Properties must be edited in the users directory, so as
to keep it even if new patches are installed.
To edit one or several synchronisation.properties, you must therefore:
Copy them from the
/opt/mycom/config/server/res/Synchronisation.properties file.
Paste them in the Synchronisation.properties.mycom file stored in the
/opt/mycom/data/users directory so as to proceed with your own configuration.
If this file does not exist:

⇒ Create a new file
⇒ Copy and paste the properties that need to be edited in this new file
⇒ Rename the file Synchronisation.properties.Nortel
5.4.1. Configuring the Counter Mapping File

The DAIE can recognize the names of the counters in the SDO performance file and associate them with known
import counters.
To do so, a mapping file must be edited to establish the correspondence between IdSubId and Q3 names or
IdSubId and custom names. This file will be imported by the DAIE whenever it is started so that new counter
names are recognized and imported.
To import the mapping file, you should perform one of the following procedures:
5.4.1.1. IdSubId counter naming mode

Check and edit (if necessary) the property SDOCounterMappingFilePath in
/opt/mycom/data/users/Synchronisation.properties.mycom:
SDOCounterMappingFilePath=/opt/mycom/data/users/<Counter Mapping
File name>
5.4.1.2. Custom counter naming mode

Check and edit (if necessary) the property SDOCounterMappingFilePath in
/opt/mycom/data/users/Synchronisation.properties.mycom:
SDOCounterMappingFilePath=/opt/mycom/data/users/<Counter Mapping
File name>
Check that the file SDOCounterMappingFilePath exists and contains all the mapping
information.
Check that the format of the file is the following:

<Custom name><# ><IdSubId name>
Example:
1107 000 0 CUM# 1107 0 CUM BSC
1109 000 0 CUM# 1109 0 CUM BSC
Note: To switch from one mode to another, the DAIE must be restarted:
cd /opt/mycom/shell
nohup ./mycomdaie start &
5.4.2. Customizing the column separators of SDO files

Different SDO file formats can be supported using the SDO.ColumnSeparator property. Indeed, the default
separators “,” can be replaced by “;” by tabs etc. Therefore, non-standard sdo files can be recognized and
processed without any problem after customization.
Example:
To customize a SDO file by changing the default separator "," by ";" the administrator should:
Stop the DAIE if it is running:
cd /opt/mycom/shell
./mycomdaie.sh stop
Go to the Synchronisation.properties.mycom file in the /opt/mycom/data/users
directory.
Insert the following lines in this file:
########## Nortel datasource configuration parameters ##########
SDO.ColumnSeparator=;
Restart the DAIE:
cd /opt/mycom/shell
5.5. Starting the importation step by step
5.5.1. Launching an importation session

Log in as user mycom:
su - mycom
Go to the shell directory:
cd /opt/mycom/shell
The DAIE can be started by one of the two following scripts:

• RestartIMPORT.sh : the DAIE will never stop (no end date). The start date used is either:
⇒ the latest valid performance importation,
⇒ OR current time if it is launched for the first time.
• ManualMPORT.sh starts the DAIE in MANUAL mode. The administrator is prompted for a start
and end date. Format for those 2 dates is: yyyyMMddHHmm (12 digits for year, month, day, hour
and minutes, e.g. 200301130520 for 13th of January 2003 at 5:20am). It will import data for this
period and will stop when the selected end date is reached.
Note: The DAIE cannot import configuration data that is pre-dated with respect to the last configuration
importation. This does not apply to previous Performance importation since they can be overwritten by new
import sessions.

5.5.2. Checking the configuration importation

Warning: to start a configuration importation, the start and end dates must be the same. (start date = end date =>
import config only).
cd /opt/mycom/shell
Run ManualIMPORT.sh script:
./ManualImport.sh
Result: A prompt asks you to set the start and end dates
Set the start and end dates to the same date.
Result: All the log messages are printed on the output. On the last lines, you should normally obtain only one
configuration import.
If some files containing data have not been found, change to the /opt/mycom/logs log file
directory and look at the logs in: Synchronisation.<date>.log.* and make sure that there
are no errors or warnings.
⇒ If necessary, correct the access paths to data in the Synchronisation.properties files (see 5.2)
⇒ If data are not present for a part of the devices to import, use the ICM to deactivate the NE
Entities and the Configuration Entities.
Note: If you need to run ManualIMPORT.sh several times for the same date, you must erase the last
configuration import session using the ICM menu Utilities->Import Sessions
5.5.3. Checking the performance counters importation

Warning: To check the Performance Counters importation, set the End date so that it is 1 hour after the Start
date (end date = start date + 1h => import config + import counter for 1 hour)
cd /opt/mycom/shell
Run ManualIMPORT.sh script:
./ManualImport.sh
Set the Start and End dates as described in the warning note.
Look at the logs and make sure that there are no errors or warnings. If there are some, correct them
with the following procedure:
⇒ Check and correct (if necessary) the access paths to data in Synchronisation.properties files(see
5.2)
⇒ If data are not present for a part of the devices to import, use the ICM to deactivate the Counter
Entities.
Run: ManualIMPORT.sh until you get no further errors or warnings.
Note: If it is the first time that you launch the importation process you should wait at least 15 or 20 minutes.
Then it will take about 1-2 minutes per 15 minutes of data.
5.5.4. Cleaning the database and deleting all the imported data
If it is necessary to get rid of an old configuration, the administrator should use the ICM Import session
visualization and deletion feature to delete from the database old configuration import session and related data.
This feature is valuable for configuration data in order to be able to re-import data with a new import date that is
farther in the past.
For the Performance data, this feature is valuable for simply deleting unwanted data.

Warning: DAIE should be stopped when using the deletion feature. Please refer to sub-section 4.3.1.
Importation Server (DAIE) shutdown script.
Select Utilities->Import Sessions in the ICM menu bar.

Result: A window appears.
Use the Walk buttons to display the date from which data will be deleted (until the end) in the View
bars.
Note: The upper bar displays Configuration data (the red vertical lines represent the importations).
The lower bar displays the Performance data (the green vertical lines represent the importations).
Click on the red vertical line in the upper bar to delete all the configuration (and performance data)
importations that must be removed after the importation date you have selected.
Click on the green vertical line in the lower bar to delete all the Performance data importations that
must be removed after the importation date you have chosen.
Note: When you delete configuration data (red line) you also automatically delete performance data.
Click on the delete from the database icon at the bottom of the dialog box.
Result: A confirmation dialog box appears.
Click on OK.
Result: Data are deleted from the date you have selected until the end.
5.6. Starting the importation continuously

Once the “troubleshooting” is achieved (see 5.4.2. Checking the configuration importation), the importation is
ready to start.
5.6.1. Starting the continuous importation

You must now start nohup ./mycomdaie.sh start &
Result: This command should display the PID (Process Identity) of the DAIE.
Note: The logs are not printed on the screen anymore, but in the log files.
5.6.2. Checking the continuous importation process
5.6.2.1. Check the status of the DAIE process manually

Check the process state of MYCOM processes by using the status command
/opt/mycom/shell/status.sh
5.6.2.2. Check the importation by using a NIMS-PrOptima report

Launch a NIMS-PrOptimaTM for PWI client in which the time context covers the start date.
Make sure that there are Network Elements in the Dimension palette.
Check that data are indeed imported continuously from the start date by the DAIE. To do so, create a
report with a time dimension member of 15 minutes.
Note: When the DAIE is catching up with all data in the “past”, you need to wait approximately 1
minute for each quarter of an hour of imported data. You should see updated data appear after re-
computation.
5.6.2.3. Check the importation using the DAIE log files

2 types of log files are generated by the DAIE:
• The administration log files that are readable by an administrator only.

• The summary log files that are in html format and that can be read by any user.
Administrator log files

The DAIE administrator log files are generated in:
/opt/mycom/logs/proptima
The format of the filename of the generated files is:
Synchronisation.<session_start_date>.log.<write_date>.<sn>
Where:
• <session_start_date> is the date when the DAIE has been started (format is
yyyyMMddHHmmss),
• <write_date> is the date when the file has been written (with same format),
• <sn> is a sequence number (in case several files are written at the same date).
The file in which the DAIE is currently writing in (if is running) is:
Synchronisation.<session_start_date>.log
The log level that determines how much details should be written in the log files is defined by the value of the
DAIE property: LogFileLevel
Every message in the log file starts with a timestamp.
Messages are of several categories:
• Message: always displayed whatever the log level. They are not necessarily problems.
• Error: problems that prevent the DAIE to fully import data (impossible connection, entire set of files
not accessible...)
• Warning: less critical problems (some missing data, duplicated identifiers...)
• Info: informative messages
• Debug: debug messages
Note: A message is displayed at each start and end of an import session (Configuration or performance).
Example of such messages:
2003-05-19 03:55:42 CEST Message SERVER>>Summary: End of importation
session ending at 2003-05-19 03:45:00 CEST. It took 42220ms - Number
of error(s): 2 - Number of warning(s): 17
Summary html log files

Summary html log files are generated at the end of any performance import session (normal session or retry
session because of missing data). They are useful to quickly check that all the counters have been correctly
collected for a particular period. When some counters report problems that have occurred, they are marked in
red, and the administrator must look at the DAIE administration log files to analyze the cause of the problems.
The files are generated in:

/opt/mycom/logs/proptima/daie/<yyyy>/<MM>/<dd>/<HHmm>/
Where: <yyyy>, <MM>, <dd>, <HHmm> are respectively the year, month, day, time (hour + minutes) of the
end date of the session.
The created filenames have the following format:
Gran<time_granularity>Prio<prio>.<timestamp>.log.html
Where:

• <time_granularity> and <prio> is the time granularity and import priority of the described
counters,
• and <timestamp> is the date when the file has been created (with format yyyyMMddHHmm).
These files start with a table summary that lists all the counter groups and gives a global status. In the specific
case of XML 3GPP counters, the number of files parsed by the DAIE is also indicated in a extra info column in
this table summary.
Then, counter group per counter group, the list of counters is displayed with a status indicating if all the expected
Network Elements have provided values, or if there are missing data.
For some counter groups linked to XML 3GPP files, the exhaustive detailed list of XML files that have been
parsed is displayed. To activate this feature for a specific counter group, the administrator must find the
corresponding counter entity using the ICM (menu Importation Database -> Layer 2 Entities -> Counter
Entities).
Then a property must be set in the DAIE properties file. This property has the following format:
EnableFileListReport.<counter_entity_name>=true
Where:
• <counter_entity_name> is the counter entity name displayed in ICM,
• and where space characters are replaced with underscores.
5.7. Performance Database Archiving and Purging by the DAIE

The DAIE automatically archives and purges the performance database each day in order to maintain a stable
database size.
Archiving is done automatically by removing the oldest data from the database and copying the corresponding
files to the archiving spool directory. This is done when new performance data have to be imported.
Two time windows can be manually configured separately: one for long-term data and one for fine-grain data.
These time windows are used for setting automatic archiving.
The archive directory can be monitored and automatically purged when it becomes too large in size.
This subsection explains how archiving and purging are performed.
5.7.1. Archiving
The automatic archiving does the following:
• Moves the oldest flatfiles (containing performance data) from the performance database into an
archive directory.
• Deletes configuration data (which are too old) from the database, (e.g. A Network Element that has
been removed from a network for a long time or very old configuration parameter data).
The default archiving directory is:
/opt/mycom/archive
Data archiving is configured by 2 synchronization properties which are stored in:
/opt/mycom/server/res
These Archiving properties are the following:
• Archive.LessThanDayFilesetHistory : this property is used to indicate the number of
historical days (in historical time) that are allowed for data whose granularity is less than a day. You
must therefore indicate the maximum number of days during which data will be kept in the
performance database (by default: Archive.LessThanDayFilesetHistory=21). Whenever
the threshold that you have set has been exceeded, the oldest data are automatically moved in the
archive directory.
• Archive.MoreThanDayFilesetHistory : this property is used to indicate the number of
historical days (in historical time) that are allowed for data whose granularity is greater than a day.

You must therefore indicate the maximum number of days during which data will be kept in the
performance database (by default: Archive.MoreThanDayFilesetHistory=365).
Logically, the archiving of data with a granularity above the day level must be performed less often
than the archiving of data with a granularity lower than the day level.
This property is also used to set a limit on the history of data in terms of configuration. For example,
if Network Elements have been withdrawn from your network for a long time, they will thus be
withdrawn from the database history.
Note: The flatfiles archived by NIMS-PrOptimaTM can be configured to contain performance data of a certain
number of days (the default parameter is two days). If you change the setting to one day you will archive
everyday. However, this parameter affects end-user performance and it should not be changed to allow daily
archiving.
Warning:
The Archive.AbsoluteArchivingDir is no more in the Synchronisation.properties file. It is now
placed in a file called Restore.properties. This property is the absolute path for reaching the archive directory.
The default directory is: /opt/mycom/data/proptima/archive
Note:
To restore the archived files into the MDDB, please refer to sub-section 5.5. Configuring and restoring the
flatfiles stored in the MDDB of the Importation Control Manager manual.
5.7.2. Purging
Warning: the purge is an emergency mechanism. It is normally the administrator’s task to archive the database
in a spool directory and to purge old data from the database.
Since purging is a user’s customization, the Properties should be edited in the users directory, so as to keep it
even if new patches are installed.
The purge is activated or deactivated in:

/opt/mycom/data/users/Synchronisation.properties.mycom
The following property must be completed by either true OR false to activate or deactivate the purge:
purge.ArchiveDirMonitored
For example: purge.ArchiveDirMonitored=true
If you indicate true, 2 other properties will be used to set the parameters of the purge:
• Archive.DirSizeMb : this property is used to indicate the maximum size of the archive
directory in terms of Mega bytes. You just have to enter the number corresponding to this maximum
size. For example, Archive.DirSizeMb=3200
• Archive.DirUsagePercentPurgeTrigger : this property is used to indicate the Mega byte
size percentage of the archive directory that must not be exceeded. For example, if you indicate:
Archive.DirUsagePercentPurgeTrigger=75 , the purge mechanism will be launched if
more than 75% of the archive directory size is used. The purge will delete all the oldest flatfiles from
the archive directory, until this directory returns to a percentage under the threshold value you have
indicated.
5.8. Deleting all data manually

The following procedure describes how to delete all imported data from the Oracle database:
su - oracle
cd /opt/mycom/config/database/
sqlplus proptima/proptima < purgeevents.sql
sqlplus proptima/proptima < purgemib.sql
sqlplus proptima/proptima < purgesessions.sql
Stop the mycom processes and oracle :

su -
/etc/init.d/proptima stop
Erase the flatfiles:
su - mycom
rm -rf /opt/mycom/data/flatfiles/*
Delete all the data that were created and used by the importation engine:
su - mycom
rm -rf /opt/mycom/data/dataimport/processed_ne/
rm -rf /opt/mycom/data/dataimport/read_files/
rm /opt/mycom/data/dataimport/query_to_retry.bin

Chapter 6 – Backup/Restore
Chapter 6 - Backup/Restore
The Backup/Restore of the NIMS-PrOptimaTM server should be done if possible with the Veritas Netbackup
solution. This Backup/Restore chapter thus describes how to perform a backup/Restore of the server with this
tool. Yet, as it is not compulsory to buy and use Veritas Netbackup, a manual Backup/Restore procedure is also
provided in this chapter.
6.2. Backup architecture overview (when performed with Veritas)
PrOptima Server
NIMS-PrOptima
1 2
Imported Oracle
network TNS flatfiles
Listener
data files
Oracle RMAN
backup files
4 4
Veritas Netbackup
Client
1 Veritas commands the DAIE to lock

importations
2 Veritas commands Oracle to perform

a self hot-backup
5
Veritas Netbackup
3 Oracle Performs a self hot-backup Server
using Recovery MANager (RMAN)
utility
4 Veritas performs a backup of

PrOptima data files and of Oracle
RMAN backup files
5 Veritas commands the DAIE to unlock

importations
Backup Server

6.3. Backup strategy (with Veritas)

The backup process is automatically managed by Veritas NetBackup Business Server 4.5 third party software:
• Veritas is scheduled to perform daily incremental backups and weekly full backups.
• Before each backup, Veritas commands the NIMS-PrOptimaTM DAIE to lock itself, and commands
Oracle to hot-backup itself.
• After each backup, Veritas commands the NIMS-PrOptimaTM DAIE to unlock itself.
Below is the detailed backup strategy.
6.3.1. Daily incremental backup of the PrOptima data

The following actions are performed at night, every week day:
• Pre-backup locking of the data importation process (DAIE)
• Incremental backup of the PrOptima data with Veritas NetBackup
• Post-backup unlocking of the data importation process
Note: The duration of these3 steps vary with the amount of data stored in the PrOptima server.
6.3.2. Daily incremental on-line backup of the Oracle database

The following actions are performed at night, every week day:
• Incremental on-line backup of all database files with Oracle RMAN utility
• Backup of these files with Veritas NetBackup
6.3.3. Weekly full backup of the PrOptima data

The following actions are performed at night, every weekend:
• Pre-backup locking of the data importation process (DAIE)
• Full backup of the PrOptima data with Veritas NetBackup
• Post-backup unlocking of the data importation process
6.3.4. Weekly full on-line backup of the Oracle database

The following actions are performed at night, every weekend:
• Full on-line backup of all database files with Oracle RMAN utility
• Backup of these files with Veritas NetBackup
6.4. Restrictions (with Veritas)

A few applications must NOT be running while the Backup/Restore process is running. These are the:
• ICM application.
• User Manager application.
If these applications are used during the Backup process, a subsequent Restore might leave the system in an
inconsistent state.
• During a backup, the DAIE is not allowed to import data (neither in the flatfiles nor in the database).
This constraint is automatically managed: when a Backup is running, the DAIE cannot be started
automatically and manually. An error message appears.
• If the DAIE is running when a Backup is started, the DAIE is paused (pre-backup). When the backup
is finished, the DAIE is resumed (post-backup).
Note: When the DAIE is paused, the process is still running. This means that another instance of the DAIE
cannot be started.
6.5. Backup procedure (with Veritas)

The backup procedure is fully automated via the Veritas NetBackup scheduler.
The administrator should check that the file BackupManagement.properties exists in
/opt/mycom/config/server/res/
The administrator should then check that the time out is equal to 120. If it is not the case, the time out must
be set to this value.
6.6. Veritas NetBackup installation and configuration
6.6.1. Veritas NetBackup installation

Warning:
• The SERVER side of Veritas NetBackup can only be installed on a Solaris SPARC computer. On the
other hand, the CLIENT side of Veritas NetBackup can be installed on both Solaris INTEL and
SPARC computers.
• The following procedure will install both SERVER and CLIENT sides of Veritas NetBackup on the
same server. In this configuration, the PrOptima server and the Backup server are the same computer.
Log in as the root user on the server:

su -
Insert the Veritas NetBackup BusinessServer 4.5 for Solaris CD-ROM into your CD-ROM drive
and change your working directory to the CD-ROM directory:
cd <your_cd_rom_directory>
Where <your_cd_rom_directory> is the path to the directory where you can access the CD-ROM.
Execute the install script:
./install
When the VERITAS Installation menu appears, choose option 1 (NetBackup). This installs both Media Manager
and NetBackup software on the server. Follow the prompts in the installation scripts:
When the installer prompts:
NetBackup and Media Manager binaries will be installed in ...
Is this okay? (y) [y,n,?,q]
Reply: n

Where do you want the ./openv/netbackup directory?
Reply: /opt/mycom/3rd_party

NetBackup and Media Manager binaries will be installed in
/opt/mycom/3rd_party/openv
and a link will be created from /usr/openv
to /opt/mycom/3rd_party/openv
Is this okay? (y) [y,n,?,q]

Reply: y

Do you want to load any other NetBackup
clients onto the server? (y) [y,n,?]
Reply: n
Then, the installer proceeds to the installation of the package.

Enter license key:
Enter your license key.
Warning: The license key is case sensitive. Furthermore, the "I" and "O" are the letters "i" and "o", not the
number "one" nor "zero" !

Evaluation NetBackup BusinesServer with Jan 6, 2003 expiration date
will be registered.
Is this OK? (y/n) [y]
Reply: y

Do you want to add additional license keys now? (y/n) [y]
Reply: n

To change these entries modify the file
/tmp/services.ov_edited.XXXXX
and enter <RETURN> when ready to continue:
Modify the file if needed and hit <RETURN>
When the Veritas Installation menu appears, choose option q (quit).
6.6.2. Veritas NetBackup configuration

Start the NetBackup Administration Console interface:
⇒ Log on to the NetBackup server as root:
su -
⇒ Set the DISPLAY variable to a display of your choice:
DISPLAY=<your hostname>:<your display number>
export DISPLAY
⇒ Allow X sessions on your host:
xhost +
⇒ Execute the following command:
/usr/openv/netbackup/bin/jnbSA &
The Veritas NetBackup login box appears on your display.

⇒ Enter the password for root.

⇒ Click Login. The Login dialog closes and the NetBackup Administration Console appears.
Click on the Getting Started icon in the main window of the NetBackup Administration Console.
Result: The Getting Started - Welcome to NetBackup window appears.
Click the Next button.
Result: The Configure Storage Device window appears, and prompts you to begin the Configure
Storage Device wizard.
6.6.2.1. Step 1 - Configure Storage Devices

Warning: It is assumed that you have correctly configured your storage devices for your Solaris machine during
the Server preparation for installation step (refer to the Installation manual). If no storage device is configured, it
is still possible to perform the backups on the hard disk.
From the Configure Storage Device window, click Next to start the Device Configuration wizard.
Result: The Welcome to the Device Configuration Wizard window appears.
Click Next to start the device detection.
Result: The Scanning Hosts window appears and displays all devices that were discovered for a
specific host.
Click Next to view the detected devices.
Result: The Backup Devices window appears.
From the Backup Devices window, confirm the list of devices displayed in this window by clicking
the Next button.
Verify that all drives are in their proper location. If you need to move a drive, select the drive and
drag it to the location.
Click Next.
Result: NetBackup begins updating the device configurations and the Updating Device Configuration
window appears. This update may take a few minutes to complete.
Click Next after the device configuration update completes.
Result: The Configure Storage Units window appears. Use this window to define storage units. If
your system does not have a tape device, you can store data on a disk by defining disk storage units.
Click Next.
Result: The Finished window appears.
Click Finish.
Result: The Getting Started- Volume Configuration window appears.
6.6.2.2. Step 2 - Configure Volumes

From the Volume Configuration window, click Next.
Result: The Welcome to the Volume Configuration wizard appears.
Warning: If you only have disk storage capability, NetBackup will skip this wizard.
Click Next to start the Volume Configuration wizard.
Result: The Getting Started - Volume Configuration window appears.
Click Next.
Result: The Select Device window appears.
Select a robot that you want to inventory, or the type of standalone drive for which you want to
configure volumes.
Warning: If you are configuring volumes for a robot, skip the following three steps:
• If you choose a standalone drive and click Next, the Standalone Media window appears.
• Select the number of volumes from the drop-down menu and click Next.

• Click Finish. The Getting Started - Catalog Backup Wizard window appears.
Click Next.
Result: The Robot Inventory window appears. This window enables you to view the results of the
inventory of the Robot/device that you previously selected.
Click Next.
Result: The Identify Cleaning Media window appears.
Click Next.
Result: If you identified one or more tapes as cleaning tapes on the Identify Cleaning Media window,
then the Robot Inventory (Cleaning Media) window will appear. This window displays the results of
NetBackup after the software updates the media manager volume configuration.
Click Next.
Result: This concludes the Volume Configuration wizard.
Warning: This wizard does not enable you to configure cleaning tapes for standalone drives.
Click Finish.
Result: The Getting Started - Catalog Backup Wizard window appears.
6.6.2.3. Step 3 - Configure the Catalog Backup

From the Configure the Catalog Backup window, click Next.
Result: The Catalog Backup wizard begins.
Click Next.
Result: If you have configured a robot and/or a standalone drive, the Media Type for the Destination
window appears. Specify if you want to back up the catalog to a tape (removable media) or to a hard
drive.
Click Next after you select your media type on the Media Type for the Destination window.
⇒ If you have configured a robot and/or a standalone drive and if you chose to back up the catalog
to a tape, the Destination Volume window appears. Select the volume that you want to use for the
backup on the Destination Volume window.
⇒ If you do not have any robots or standalone drives configured, or if you selected to back up the
catalog to a hard drive on the Media Type for the Destination page, the Pathname for the
Destination window appears. Enter the directory that you want NetBackup to use to save catalog
backups in the text field on the page.
Click Next.
Result: The Alternating Destinations window appears. Unselect the checkbox (if selected).
Click Next.
Result: The When to Back Up the Catalog window appears. From this window, select the
recommended option: After each session of scheduled, user or manual
backups and Click Next
Click Finish.
Result: This completes the NetBackup Catalog configuration wizard and the Policy Configuration
window appears.
6.6.2.4. Step 4 - Policy Configuration

From the Policy Configuration window, click Next.
Click Next to start the Backup Policy Configuration wizard. The Policy Name and Type window
appears:
⇒ In the Policy name field, type: MycomBackup
⇒ In the Policy type drop-down box, select: Standard

⇒ Click Next.
Result: The Client List window appears.
• Warning: The policy name is case sensitive and is referenced by the pre-backup and post-backup
scripts. Be careful to type it in exactly as MycomBackup.
Click Add. An Add Client dialog appears.
⇒ Enter your server hostname in the client name text field.
⇒ Select Solaris,Solaris 8 in the hardware and operating system drop-down menu.
⇒ Click the OK button to add the current computer to the list and close the dialog.
Click Next.
The Files window appears.
⇒ Click Add.
⇒ In the path name text field, enter: /opt/mycom/config
⇒ Click Add.
⇒ In the path name text field, enter: /opt/mycom/data/alarm_autogen_report
⇒ Click Add.
⇒ In the path name text field, enter: /opt/mycom/data/archive
⇒ Click Add.
⇒ In the path name text field, enter: /opt/mycom/data/backup
⇒ Click Add.
⇒ In the path name text field, enter: /opt/mycom/data/dataimport
⇒ Click Add.
⇒ In the path name text field, enter: /opt/mycom/data/flatfiles
⇒ Click Add.
⇒ In the path name text field, enter: /opt/mycom/data/sdo
⇒ Click Add.
⇒ In the path name text field, enter: /opt/mycom/data/users
⇒ Click Add.
⇒ In the path name text field, enter: /opt/mycom/logs
Click Next.
Result: The Backup Type window appears.
Select the type of backup to perform:
⇒ Check Full Backup
⇒ Check Incremental Backup
⇒ Check Cumulative backup
Click Next.
Result: The Rotation window appears.
⇒ Select 1 week for full backups
⇒ Select 1 day for incremental backups
⇒ Select 2 weeks to retain backups

Click Next.
Result: The Start Window interface appears.
⇒ Select Off hours (18:00 to 5:00)
Click Next.
Answer NO to the question Would you like to configure another NetBackup policy.
Click Next. Uncheck the line Start an immediate backup of the NetBackup server...
Click Next.
Result: This completes the creation and configuration of the policy.
Click Finish.
Result: This concludes the configuration of NetBackup.
6.6.2.5. Post-configuration steps

Modify the start windows for the Veritas scheduler:
In the navigation tree on the left side of the NetBackup Administration Console window, click on the
Policies line.
Select the MycomBackup policy and click to expand it.
Select Schedules
Double-click on Full.
Result: The Change Schedule - policy MycomBackup appears.
Click on the Start Window tab.
Click on Clear to clear the default planning.
Modify the planning :
⇒ select Modify Day: Monday - Start time: 2AM
⇒ select End Day: Monday - End time: 6AM
You should obtain the following Start Window :

click OK
Double-click on Cumulative-Inc.
Result: The Change Schedule - policy MycomBackup appears.
Click on the Start Window tab.
Click on Clear to clear the default planning.
Modify the planning :
⇒ select Modify Day: Sunday - Start time: 2AM
⇒ select End Day: Sunday - End time: 6AM
⇒ Click Duplicate
⇒ Then, click on the Monday bar on the grid and click on Delete
You should obtain the following Start Window :

click OK
Quit the NetBackup Administration Console
Once Veritas NetBackup is installed and configured, you must copy the following scripts (aimed to lock/unlock
the PrOptima DAIE and to launch Oracle RMAN backups) into their destination directory:
Log in as user root:
su -
Copy the pre-backup file to its destination:
cp /opt/mycom/shell/admin/backup/bpstart_notify.MycomBackup
/opt/mycom/3rd_party/openv/netbackup/bin/
Copy the post-backup file to its destination:
cp /opt/mycom/shell/admin/backup/bpend_notify.MycomBackup
/opt/mycom/3rd_party/openv/netbackup/bin/
Change execution rights :
chmod u+x *.MycomBackup
6.7. Restore procedure (with Veritas)
6.7.1. Restore scenarios

Depending on the kind of failure you encounter, you may need to follow one or several restore steps as described
in the following table:
Failure Restore steps Refer to

PrOptima data has been damaged/lost Restore the PrOptima data files with Veritas 6.7.2

PrOptima software has been damaged/lost Reinstall PrOptima packages Install Manual
Oracle database has been damaged/lost Restore the Oracle backup files with Veritas 6.7.3
Recover the Oracle database from backup files 6.7.4
Oracle software has been damaged/lost Reinstall Oracle Server software Install Manual
6.7.2. Restoring the PrOptima data files with Veritas

This procedure assumes that Veritas NetBackup is up and running.
Stop all the PrOptima processes:
⇒ Log in as root
su -
⇒ Stop all the PrOptima processes:
Start the Veritas NetBackup Administration Console interface:

⇒ Log in as user root
export DISPLAY
xhost +
⇒ Click Login.
Result: The Login dialog closes and the NetBackup Administration Console appears.
Backup, Archive and Restore line.
Select the Restore tab on the right side of the window.
Click on the Use Backup History to set date range icon on the right side of the Restore tab.
Result: The Date Range window appears.
In the Date Range window, select the last Full backup and, eventually, the Cumulative Incremental
backups up to the date of the files you want to restore (hold shift key to select several lines). By
default, Veritas selects the most recent Full backup and Cumulative Incremental backups. Click OK.
Click on the Directory Structure file tree on the left side of the Restore tab, to select the directories
you want to restore. You can also select individual files on the right side in the Contents of selected
directory file list.
Click on the Restore... button.
Result: The Restore files window appears.
In the Restore files window, select whether to restore the files to their original location or to a
different location and click on the Start Restore button.
Click on Yes to view the progress of the restore.
6.7.3. Restoring the Oracle backup files with Veritas

This procedure assumes that Veritas NetBackup is up and running.


⇒ Log in as root
su -
Start the Veritas NetBackup Administration Console interface:
⇒ Log in as user root
export DISPLAY
xhost +
⇒ Click Login. The Login dialog closes and the NetBackup Administration Console appears.
Backup, Archive and Restore line.
Select the Restore tab on the right side of the window.
Click on the Use Backup History to set date range icon on the right side of the Restore tab.
Result: The Date Range window appears.
In the Date Range window, select the last Full backup and, eventually, the Cumulative Incremental
backups up to the date of the files you want to restore (hold shift key to select several lines). By
default, Veritas selects the most recent Full backup and Cumulative Incremental backups. Click OK.
Click on the Directory Structure file tree on the left side of the Restore tab, to select the directories
you want to restore. To restore Oracle backup files, select the /opt/mycom/data/backup/ directory.
You can also select individual files on the right side in the Contents of selected directory file list.
Click on the Restore... button.
Result: The Restore files window appears.
In the Restore files window, select whether to restore the files to their original location or to a
different location and click on the Start Restore button.
Click on Yes to view the progress of the restore.
6.7.4. Recover the Oracle database from backup files

⇒ Log in as root
su -
Start Oracle database in "mount" mode (partial start for restoration) :
⇒ Log in as oracle :
su - oracle
⇒ Launch sqlplus utility :
sqlplus /nolog

⇒ Type in the following commands to start the database in "mount" mode :

connect / as sysdba
shutdown immediate
startup mount
exit
Restore Oracle data with RMAN utility :
⇒ Launch RMAN utility :
rman target / nocatalog
⇒ Type in the following commands to restore last backup :
run { allocate channel disk1 type disk;
restore database;
recover database;
alter database open resetlogs;
}
exit
Restart Oracle database :
/opt/mycom/shell/oracle/oracle.sh restart

Chapter 7 – SDO Reconfiguration Procedure
Chapter 7 - SDO Reconfiguration

Procedure
This chapter aims at giving the procedures to add or remove SDOs (the OMC servers where configuration data is
stored) in the NIMS-PrOptimaTM database.
7.2. Adding new SDOs in automatic mode

Warning: SDO configuration must be homogeneous since diversification is not supported (they should be either
all Q3 or all Id/subId). Please refer to sub-section 10.5.1. of the Installation Manual to configure the Counter
Mapping file. If this requirement is not respected, data will not be imported even though configuration is well
updated and NEs appear in the dimension palette.
Update the FtpMediation.properties file. Refer to sub-section “7.2.1. Editing the

FtpMediation.properties file” in the Installation manual.
Stop the FtpMediation and launch it again:
⇒ To stop the FtpMediation automatically, type in the following lines:
su – mycom
./mycomftpmed.sh stop
⇒ To launch the FtpMediation automatically, type in the following lines:
nohup ./mycomftpmed.sh start &
Result: The new SDO files are recovered on the PrOptima server. You should therefore wait roughly
5 minutes before performing the following action.
Stop and launch again the DAIE so as to force a configuration update which will import the new
SDOs.
⇒ Login as user mycom, go to the startup scripts directory and run the DAIE shutdown script:
su – mycom
cd /opt/mycom/shell
./mycomdaie.sh stop
⇒ In the same directory, run the DAIE startup script:
7.3. Removing SDOs from the database

Delete all data from the database (refer to sub-section 5.8. Deleting all data manually). This step is
actually optional but strongly recommended if you need to perform tests.
If the proptima server has not been stopped in previous step, then:
⇒ Stop proptima/oracle application :
su -
⇒ Stop the FtpMediation (refer to the previous sub-section).
Reconfigure the FtpMediation.properties file, removing the SDOs that must be removed
from the database. Refer to sub-section “7.2.1. Editing the FtpMediation.properties file” in the

Chapter 7 – SDO Reconfiguration Procedure
Installation manual to get the necessary procedure.

Result: This action will prevent the FtpMediation from recovering the files.
Delete the /opt/mycom/data/sdo/<sdo Id> directory of each SDO that must be removed, in
order to prevent the DAIE to look for it during the next importation.
Start PrOptima and Oracle again:
su -
/etc/init.d/proptima start
Start the FtpMediation (refer to the previous sub-section).
Stop and launch again the DAIE so as to force a configuration update.

Chapter 8 – User and Group Rights Management
Chapter 8 - User and Group Rights

Management
All information relevant to user and group rights for NIMS-PrOptima is indicated in the User Manager user
manual. The following topics are covered in that separate manual.
• Check database integrity
• Users and Groups
⇒ Create User
⇒ Create Group
⇒ Delete User
⇒ Delete Group
⇒ Assign User and Groups
• Features (Predefined Reports, Value Provider, Cell Item Styles, Conditional Styles, User rights,
Login action)
⇒ Edit features
⇒ Assign features to users and groups
• Manage Dimensions
• Cube dimension manager
• Tool palette hierarchy
•

Chapter 9 – Supervision console and Self monitoring
Chapter 9 - Supervision console and

Self monitoring
NIMS-PrOptimaTM is installed on a standalone server and provides the administrator with an easy way to auto-
administrate the server.
The supervision console allows the NIMS-PrOptimaTM administrator to control the connections to the NIMS-
PrOptima server. He can obtain information on the NIMS-PrOptima server very quickly e.g. the users who are
using the NIMS-PrOptimaTM application or the User Manager application etc. The administrator can list the
connections and decide to kill one or all of them.
The self monitoring allows the NIMS-PrOptimaTM administrator to monitor hardware and software resources
(CPU, memory, process etc.). Self monitoring metrics are available in the calculation palette of NIMS-
PrOptimaTM . The system administrator can associate alarms to these metrics using the standard NIMS-
PrOptimaTM alarm module, to be warned of any server problem that might occur.
9.2. Supervision Console
9.2.1. Launching the application

The application is launched by a script named usersupervision.sh that can be found in the shell
installation directory.
su – mycom
cd /opt/mycom/shell
Run the usersupervision.sh script:
./usersupervision.sh
9.2.2. Login
When started, the application will prompt for a username and a password.
By default, the user name “administrator” is the one you get after NIMS-PrOptimaTM installation. The
administrator has all the rights on the different applications.
Note: It is however possible to create alternative user names for the supervision task using the User Manager
application. To do so, create a new user e.g. supervisor and add it to the “admin” group so as to give him the
administrator’s rights.
Result: If the login process is successful the following message will be displayed:
<*> connected to rmi://Server:Port/proptimaserverUserSupervision
From now on the supervisor user can act on connections.
Figure 1: Password entered in Supervision Console application

9.2.3. Monitoring Commands
9.2.3.1. help command

The application has a built-in command help which can be obtained by typing help in the prompt.
Figure 2: General help command

Each command has an extra help entry which can be obtained by typing:
help <command>
Figure 3: help command applied to list
9.2.3.2. list commands

The list commands allow the administrator to obtain information about all the connections running on the
PrOptima server.
• list: the plain ”list” command allows the supervisor to list the current connections to a server.
Figure 4: list command
• list app: this command lists all the connections to a specific application. The administrator
just has to type this command and the application name.
Example: list app Proptima will list all the connections to the NIMS-PrOptimaTM PrOptima
front-end application. Similarly list app UserManager will list all the connections to the User
Manager application.
Figure 5: list app command
• list user: this command lists the connections for a specific user name. The administrator
just has to type this command and the user name of the user or the group for whom he wants to see
the connections.
Example: list user demo will list all the connections made by user(s) having demo as user
name.
Figure 6: list user command
• list host: this command lists the connections for a specific host. The administrator just has
to type this command and the host name.
Example: list host pink will list all the connections made by the host called pink
Figure 7: list host command

9.2.3.3. The kill commands

The kill command stops the connection(s) that are running on the PrOptima server.
• Kill <connection id>: this command disconnects the specified connection.
Figure 8: kill connection id command
• Kill all: this command disconnects all current connections.
Figure 9: kill all command

Restriction: The kill command cannot stop the connections to the Web interface. It is due to the fact that the
user is constantly re-connected via the Java servlet engine.
Warning: on the client side , the connected user will get a warning message dialog box saying that the
application is about to close. If the user tries to close the dialog box, the application will be closed anyway.
Figure 10: Warning message dialog box on PrOptima Client
9.2.3.4. The quit command

quit: the quit command closes the supervision console.

9.2.4. Error messages
9.2.4.1. Login errors

The following login error messages may occur:
• Message: “Fatal Error : Unable to authenticate user supervisor.” can
occur in one of the following cases:
⇒ the server cannot be connected for login
⇒ the combination of username/pass is not correct
• Message: “Fatal Error : The service localhost:1099/serverUserSup could not be reached !” occur
in one of the following cases:
⇒ the server is not running
⇒ the supervisor service is down for any reason
Workaround: check that the MDDS Server is running.
9.2.4.2. Command errors

The following command error messages may occur:
• Message: “<!> No connection for id=<XXX>” occurs if the specified connection is
not available
• Message “<!> Empty connection list” occurs if a kill all is requested and there
are no connections available.
Figure 11: No connection & Empty connection list errors
• Message “<!> unknown command“ occurs if an unknown command is typed in the prompt
or if a help is requested on an unknown command.

Figure 12: unknown command error
9.3. Self Monitoring
9.3.1. Launching the application

The application is launched by a script named mycomstats.sh that can be found in the shell installation
directory.
su – mycom
cd /opt/mycom/shell
Run the mycomstats.sh script:
nohup ./mycomstats.sh start &
Result: the self monitoring process is launched
To check that the self monitoring process is launched, run the following command:
./mycomstats.sh status
The following lines should appear:
mycomstats.sh [MYCOMStats] is running, PID=<PID_number>
9.3.2. Monitoring hardware resources
9.3.2.1. Monitor file

When the mycomstats process is launched, NIMS-PrOptimaTM generates one .txt which allows the
administrator to monitor the hardware and software resources.
This file is called Monitor<date>.txt where <date> is the current server's date.
Note: the date format is YYYYMMdd.
To open the Monitor<date>.txt file, perform the following procedure:

Warning: The process should have been running for at least 15 minutes
Go to the /opt/mycom/data/selfmonitor directory
Type in ls –al
Result: the directory should contain a file named Monitor<date>.txt
Note: There is one file per day

Choose the file you want to open and type in the following line:
vi Monitor<date>.txt
Result: the following lines should appear:
<server_date> <server_name> memory <counter_values>
<server_date> <server_name> process daie <counter_values>
<server_date> <server_name> process oracle <counter_values>
<server_date> <server_name> process mddb <counter_values>
<server_date> <server_name> cpu <counter_values>
<server_date> <server_name> disk /opt/mycom/data/
<counter_values>
Example:
EndDate IP Group moid DiskUsed MemorySwap MemoryFree CPUusr CPUsys CPUwt CPUidl
CPU Memory
200407120000 torr memory 1958872 93660
200407120000 torr process mdds 0.007 0.155
200407120000 torr process daie 0 0
200407120000 torr process oracle 0 0.0206363636363636
200407120000 torr cpu 0 1 0 0 98
200407120000 torr disk /opt/mycom/data/ 10716826
200407120015 torr memory 1958872 93608
200407120015 torr cpu 0 1 0 0 98
200407120030 torr memory 1958868 93560
200407120030 torr cpu 0 1 0 0 98
200407120045 torr memory 1958868 93508
200407120045 torr cpu 0 1 0 0 98
200407120100 torr memory 1958864 93460
The counters are the following:

DiskUsed MemorySwap MemoryFree CPUusr CPUsys CPUwt CPUidl CPU Memory
These counters give information about the following elements:

• Memory i.e. MemorySwap and MemoryFree, the memory size is indicated in kylobytes.
• Processes i.e. CPU and Memory, values are indicated in percentage.
• CPU usage i.e. CPUusr (CPU used by User processes), CPUsys (CPU used by System
processes), CPUwt (CPU waiting time, that is to say the lapse of time during that the CPU takes
before running) CPUidl (inactivity rate of the CPU).
• Disk i.e. Disk Used, the memory size is indicated in kylobytes.
Below is a table showing clearly the values of the counters which are used in this example:

EndDate IP Group moid DiskUsed MemorySwap MemoryFree CPUusr CPUsys CPUwt CPUidl CPU Memory
200407120000 torr memory 1958872 93660
200407120000 torr cpu 0 1 0 0 98
200407120015 torr memory 1958872 93608
200407120015 torr cpu 0 1 0 0 98
200407120030 torr memory 1958868 93560
200407120030 torr cpu 0 1 0 0 98
200407120045 torr memory 1958868 93508
200407120045 torr cpu 0 1 0 0 98
200407120100 torr memory 1958864 93460
9.3.2.2. Building reports

Self monitoring metrics are also available in the calculation palette of NIMS-PrOptimaTM. These metrics
correspond to hardware/software resources and allow the user to create reports in order to monitor the server.
To create reports, please refer to the detailed procedure in the NIMS-PrOptimaTM User manual.

Chapter 10 – List of abbreviations
Chapter 10 - List of abbreviations

Ex. Example
GPRS General Packet Radio Service
GSM Global System for Mobile communications
GUI Graphical User Interface
HTML Hypertext Markup Language
ICM Import Control Manager
MDDS Multi Dimensional Data Storage
Mgr. Manager
NE Network Element
PID Process Identity
RDB Relational Data Base
Ref Reference
URL Universal Resource Locator
UMTS Universal Mobile Telecommunications System
XML eXtended Markup Language


Pro Sup Adm Nor 013.3.00 PDF

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Pro Sup Adm Nor 013.3.00 PDF

Загружено:

Авторское право:

Доступные форматы

TM

CHAPTER 2 - OVERVIEW OF ALL PROCESSES .................................................................................. 7

CHAPTER 3 - THIRD PARTY PROCESSES........................................................................................... 10

CHAPTER 4 - MYCOM APPLICATION PROCESSES ......................................................................... 13

CHAPTER 7 - SDO RECONFIGURATION PROCEDURE ................................................................... 48

CHAPTER 8 - USER AND GROUP RIGHTS MANAGEMENT............................................................ 50

CHAPTER 9 - SUPERVISION CONSOLE AND SELF MONITORING .............................................. 51

System Administration manual NIMS-PrOptima - ref: PRO-SUP-ADM-NOR-013-3.00-EN

CHAPTER 10 - LIST OF ABBREVIATIONS............................................................................................. 59

System Administration manual NIMS-PrOptima - ref: PRO-SUP-ADM-NOR-013-3.00-EN

1.4. Version & Scope

1.5. Publication Date

System Administration Manual NIMS-PrOptima - ref: PRO-SUP-ADM-NOR-013-3.00-EN

1.6. Other Manuals

Document Reference code

Installation manual PRO-I&C-USM-NOR-008-3.00-EN

Troubleshooting guide PRO-SUP-ADM-NOR-014-3.00-EN

User Manager user manual PRO-SUP-USM-NOR-039-3.00-EN

PrOptima client user manual PRO-SUP-USM-NOR-041-3.00-EN

1.7. Copyright information

1.8. Customer Support Contact information

System Administration Manual NIMS-PrOptima - ref: PRO-SUP-ADM-NOR-013-3.00-EN

Chapter 2 - Overview of all processes

2.2. Presentation of the different processes

2.2.1. Third Party processes

2.2.2. MYCOM processes

MYCOM processes also include the Importation process:

2.3. Dependencies of NIMS-PrOptima processes

System Administration manual NIMS-PrOptima - ref: PRO-SUP-ADM-NOR-013-3.00-EN

TNS Listener Oracle

Third Party Processes

2.4. The start/stop order of the processes

System Administration manual NIMS-PrOptima - ref: PRO-SUP-ADM-NOR-013-3.00-EN

Chapter 3 - Third Party Processes

3.2. Oracle Database Administration

3.2.1. Oracle 9 database server

3.2.2. Oracle startup script

3.2.3. Oracle Shutdown script

3.2.4. Check the running processes

3.2.5. Check the connection to Oracle

Press CTRL + C two or more times to exit.

3.3. Web server Administration

3.3.1. TCP/IP Networking

3.3.1.1. Check the IP address of the server

System Administration manual NIMS-PrOptima - ref: PRO-SUP-ADM-NOR-013-3.00-EN

TNS Listener Oracle

TCP/IP Ports used between Client and Servers

3.3.2. Web Hosting and Internet Servers

3.3.2.1. Rebooting and shutting down

3.3.2.2. Tomcat running process status check

3.3.2.3. Check logs

System Administration manual NIMS-PrOptima - ref: PRO-SUP-ADM-NOR-013-3.00-EN

Chapter 4 - MYCOM Application

4.2. Startup scripts

4.2.1. RMI registry startup script

4.2.2. NIMS-PrOptima License Manager startup script

4.2.3. Application Server (for multidimensional calculations) startup script

4.2.4. Importation Server (DAIE) startup script

System Administration manual NIMS-PrOptima - ref: PRO-SUP-ADM-NOR-013-3.00-EN

Login as user mycom and go to the startup scripts directory:

4.3. Running process check

4.3.1. Command line process check

4.3.1.1. Non-MYCOM processes