2 Service Management and Control

This chapter explains the management and control of the Convergent Charging Controller product.

Service Management and Control Overview

The Convergent Charging Controller solution is a group of programs, or applications that runs on both Oracle Linux and database.

A familiarity with Oracle Linux and Oracle database concepts and commands is necessary to fully understand the management and control of the applications that make up the whole solution.

Convergent Charging Controller concepts

A concept to think about when considering service management is solution redundancy.

The Convergent Charging Controller solution uses both the N+1 and 2N concepts to increase service reliability and greatly reducing the chances of a complete Service outage. These redundancy approaches are used in the following ways:

SLC usage

The SLC (an SCP in signaling terms) nodes handle network traffic in an N+1 configuration.

All nodes independently handle traffic at the same time. In the case of node failure, or service interruption, the remaining node(s), have the extra capacity to handle the increased load of the unavailable node (up to the projected peak traffic load).

VWS usage

The VWS nodes work in the more traditional 2N, or hot standby, configuration. This consists of a logical pair of servers running in a primary and secondary node configuration that are constantly updating and synchronizing themselves.

In the case of node failure or service interruption to the primary node, the secondary node provides instant and uninterrupted backup until the primary node is back in service.

SMS usage

The default installation of SMS node does not provide high availability. For more information about high availability, see Convergent Charging Controller High Availability Operations Guide.

Management and control methods

There are two main methods of service management and control of Convergent Charging Controller components:

  • Service managed applications
  • Daemon is a core UNIX process (PID=1) that spawns all other processes. The /etc/inittab file controls the init daemon and can be used to manage running applications.
  • For Linux, the systemctl daemon spawns all other process. The /etc/systemctl file controls the service daemons and can be used to manage running applications.
  • SLEE managed applications

SLEE is a computing term and stands for Service Logic Execution Environment. The Convergent Charging Controller SLEE manages a group of applications that can communicate with each other while efficiently sharing resources.

Note:

  • All the Convergent Charging Controller servers have some components that are managed by the init daemon.
  • Only the SLC and VWS servers have components that are managed by the SLEE.

init Daemon Management

The init daemon process "is the default primordial user process" on a UNIX system (see $ man init information).

Backwards compatibility

For backwards compatibility, init also starts and restarts general processes according to rules specified in the /etc/inittab file and the start/stop scripts defined in the legacy /etc/init.d and /etc/rc?.d directories (see $ man page for inittab and init.d).

inittab file

Convergent Charging Controller uses the inittab file to manage and control a number of its daemon processes. All Convergent Charging Controller init managed processes are configured during the installation process to be run when the server is in run-level 3 or 4 (rstate). 

$ man inittab 
...skipped... 
The inittab file is composed of entries that are position dependent and have the 
following format: 
id:rstate:action:process

Convergent Charging Controller process identification

The easiest way to identify the Convergent Charging Controller process which are managed by init is to search (grep command) for the "IN" string in the /etc/inittab file, which will list the process startup scripts. 

$ grep "IN" /etc/inittab
sms1:34:respawn:su - smf_oper -c "exec /IN/service_packages/SMS/bin/smsAlarmRelayStartup.sh >> 
/IN/service_packages/SMS/tmp/smsAlarmRelay.log 2>&1" > /dev/null 2>&1 0<&1 
sms2:34:respawn:su - smf_oper -c "exec /IN/service_packages/SMS/bin/smsNamingServerStartup.sh >> 
/IN/service_packages/SMS/tmp/smsNamingServer.log 2>&1" > /dev/null 2>&1 0<&1 
...skipped...

Tip: The general naming convention format of the process startup scripts is the name of the running process with "Startup.sh" on the end:

Format: process_name Startup.sh

Example: smsAlarmRelayStartup.sh

Process running checking

To check if the process is running you use the UNIX ps command (process status – see $ man ps information) and search for the process name.

$ ps -ef | grep smsAlarmRelay
smf_oper   941     1   0   
Oct 04 ?          55:53 /IN/service_packages/SMS/bin/smsAlarmRelay -e -u / 
smf_oper  3554  3205   0 22:04:09 pts/1       0:00 grep smsAlarmRelay 
$

It is worthwhile becoming familiar with the Convergent Charging ControllerConvergent Charging Controller processes managed by init.

Stop and Start Processes

Restart the Convergent Charging Controller service daemons in all the nodes:

For Solaris:

init q

or use terminate commands to terminate the Convergent Charging Controller service daemon

For Linux:

/IN/bin/OUI_systemctl.sh

Changing the run level

At times it may be necessary to stop all the Convergent Charging Controller init managed processes at once. You can manually edit the inittab file and comment out all the Convergent Charging Controller processes but this can be fiddly, takes time and can be prone to error.

The quickest and easiest way to stop all the processes is to simply lower the run-level of the server to state 2 (multi-user). This instructs the init daemon to stop any of its managed processes, specified in the inittab file, that are not configured to run in this level (the rstate field).

The start and stop scripts in the /etc/rc rstate .d directories will also run.

As mentioned earlier the Convergent Charging Controller processes are configured to run in either states 3 or 4 so that when the init 2 command is run (instructs the init daemon to move into run-level 2), then init will automatically terminate all its managed processes that are not configured to run in this new level.

To automatically restart these stopped processes again, you move back into run-level 3 with the init 3 command.

You must be super-user to change the server run-level.

Generally speaking you would only ever want to do use this method during platform maintenance, be it either; application, database, or server related interventions.

Example - updateLoader

Follow these steps to stop and start the updateLoader process.

  1. Become the root user, enter:
    $ su – root 
Password: ******* 
Sourcing /etc/profile.ORA
  2. Check the updateLoader process is running, enter:
    ps -ef |grep update
smf_oper   850     1   0   Oct 04 ?           0:22 
/IN/service_packages/SMS/bin/updateLoader -nodeid 301 
root 19354 19349   0 22:34:08 pts/1       0:00 grep update
  3. Edit (use your preferred text editor) the /etc/inittab file and comment out (add the # character to beginning of line) the updateLoaderStartup.sh entry and save the change. 
    vi /etc/inittab
...skipped... 
#scp5:34:respawn:su - smf_oper -c "exec 
/IN/service_packages/SMS/bin/updateLoaderStartup.sh >> 
/IN/service_packages/SMS/tmp/updateLoader.log 2>&1" > /dev/null 2>&1 0<&1 
[Esc] 
:wq 
"/etc/inittab" 36 lines, 3045 characters
  4. Tell init to reread the inittab file: 
    init q
  5. Check the updateLoader process has stopped:
    ps -ef | grep update 
root 19431 19349   0 22:40:06 pts/1       0:00 grep update
  6. Edit the /etc/inittab file and remove the # from the updateLoaderStartup.sh entry and save the change: 
    vi /etc/inittab 
...skipped... 
scp5:34:respawn:su - smf_oper -c "exec 
/IN/service_packages/SMS/bin/updateLoaderStartup.sh >> 
/IN/service_packages/SMS/tmp/updateLoader.log 2>&1" > /dev/null 2>&1 0<&1 
[Esc] 
:wq 
"/etc/inittab" 36 lines, 3045 characters
  7. Tell init to reread the inittab file: 
    init q
  8. Check the updateLoader process has started and is running again: 
    ps -ef |grep update
smf_oper 19475     1   0 22:42:43 ?           0:00 
/IN/service_packages/SMS/bin/updateLoader -nodeid 301 
root 19566 19349   0 22:42:45 pts/1       0:00 grep update

Example - smsMaster

Follow these steps to restart the smsMaster process.

  1. Check the smsMaster process are running:

    Become the root user, enter: 

    
$ su – root 
Password: ******* 
Sourcing /etc/profile.ORA

    Note:

    The second (Process ID or PID) and third columns (Parent PID or PPID) of the output. The PPID of 1, on the the first line, denotes it as the init process and the smsMaster process is a child process. The second smsMaster listed is child process of the first one as it's PPID matches the first lines PID.
  2. As the smsMaster process owner (smf_oper) terminate the process with the kill command (signal the process to stop running, or exit):
    $ kill  978

    Note:

    As PID 978 is the parent process, the child process will inherit the SIGTERM signal (kill command's default signal (either; -TERM, or –15 switch)) from it's parent. It would be okay to specify both PIDS. Using the SIGTERM signal is best practice as it allows the child and parent processes to cleanup and close files before terminating itself. The super-user root has global ownership permissions allowing it to send signal to any process.
  3. Check that the init daemon has instantly restarted the smsMaster process:
    $ ps -ef | grep smsMaster 
smf_oper  6173     
1   0 00:23:06 ?           0:01 
/IN/service_packages/SMS/bin/smsMaster -c 
smf_oper  6188  6173   1 00:23:06 ?           0:24 
/IN/service_packages/SMS/bin/smsMaster -c 
smf_oper  6800  3205   0 00:41:09 pts/1       0:00 grep smsMaster
    Tip: If either of the previous smsMaster processes are still listed then this may indicate that the process is hung or stuck and may need a more forceful shutdown signal. If this is the case then the SIGKILL signal (either; -KILL or -9 switch) is recommended. 
    $ kill -9 978 1299

SLEE Management

The SLC and VWS servers have components that are managed by the Convergent Charging Controller SLEE. Even though the services run on both these platforms are completely different, the concepts for how they are controlled are exactly the same.

In a nutshell, the SLEE provides a common environment for multiple different service logic applications to run in and simultaneously manage and communicate events between themselves in an orderly way, while interfacing with multiple external networks and/or applications.

SLEE control

Control of the SLEE is managed by a utility called SLEE Control and the command to use it is slee-ctrl.

The slee-ctrl tool provides the ability to stop, start, or restart the SLEE and, among other things, will verify that all SLEE processes were started, or have actually been stopped.

Basically it is a wrapper script that provides the user with extra checks and protection from causing issues. It still calls the SLEE start and stop scripts, all the while avoiding the pitfalls that inexperienced operators may have.

slee-ctrl simplifies SLEE control:

  • Only one command name to remember.
  • No need to remember which UNIX user you must be (it will remind you if it's wrong).
  • One valid SLEE_USER must be configured and only this user or super-user root can run the start, stop, or restart commands.
  • Do not need to remember the location or names of the SLEE start and stop scripts.
  • Do not have to be in the /IN/service_packages/SLEE/bin directory to run the command.
  • Verifies that all SLEE instance processes are terminated when the stop command issued.
  • Verifies that no other SLEE instance processes are running when the start command issued.
  • List the current process status of SLEE applications.
  • Access to the SLEE check command which displays internal SLEE resource usage.
  • Provides an audit trail by logging a history of when slee-ctrl commands were run.

slee-ctrl modes of operation

The slee-ctrl tool has two modes of use:

  • Command line
  • Interactive session mode

Documentation for slee-ctrl is in the form of a manual page. It is recommended that you read this to understand the full capabilities of the tool (enter man slee-ctrl ). Also try entering slee-ctrl help on the command line for a full list of valid commands.

Example VWS start up

To start the VWS SLEE on the command line, enter:


$ su – ebe_oper 
Password: 
$ slee-ctrl start 
SLEE Control: v,1.0.11: script v,1.21: functions v,1.48: pslist v,1.118 
[ebe_oper] slee-ctrl> start  
Info: slee_ctrl_lock_file: lock file created for "start" command. 
Info: slee_ctrl_start: Verifying that no SLEE processes are running... 
Info: slee_ctrl_start: 20101027-03:40:03 GMT: Running SLEE sleeStartup... 
The SLEE will be up and running shortly. . . . . . . . . .  ------------------------ Wed Oct 27 03:40:14 GMT 2010 -------------------------- 
C APP  USER      PID PPID    STIME COMMAND 
1 SLEE ebe_oper 7739    1 03:40:04 /IN/service_packages/SLEE/bin/timerIF 
16 SLEE ebe_oper 7755    1 03:40:04 /IN/service_packages/E2BE/bin/beVWARS 
1 SLEE ebe_oper 7756    1 03:40:04 /IN/service_packages/E2BE/bin/beSync 
1 SLEE ebe_oper 7769    1 03:40:04 /IN/service_packages/E2BE/bin/beServer 
4 SLEE ebe_oper 7778    1 03:40:05 /IN/service_packages/E2BE/bin/beGroveller 
1 SLEE ebe_oper 7781    1 03:40:05 /IN/service_packages/SLEE/bin/replicationIF 
1 SLEE ebe_oper 7785    1 03:40:05 /IN/service_packages/DAP/bin/dapIF 
1 SLEE ebe_oper 7786    1 03:40:05 N/service_packages/E2BE/bin/beEventStorageIF
1 SLEE ebe_oper 7787    1 03:40:05 N/service_packages/E2BE/bin/beServiceTrigger 
1 SLEE ebe_oper 7788    1 03:40:05 service_packages/CCS/bin/ccsSLEEChangeDaemon 
1 SLEE ebe_oper 7789    1 03:40:05 /IN/service_packages/SLEE/bin//watchdog 
total processes found = 29 [ 29 expected ] 
================================= run-level 3 ================================== 
Info: slee_ctrl_lock_file: lock file deleted for "start" command.

Example SLC stop

To stop the SLC SLEE in session mode, enter:

$ su – acs_oper 
Password:  
$ slee-ctrl 
SLEE Control: v,1.0.11: script v,1.21: functions v,1.48: pslist v,1.118 
User acs_oper; session [16893]; terminal pts/2; started Wed Oct 27 03:41:57 GMT 2010 
The following variables are set and will be used to run the SLEE. 
SLEE_USER    acs_oper 
SLEE_SCRIPT  /IN/service_packages/SLEE/bin/slee.sh 
SLEE_CONFIG  /IN/service_packages/SLEE/etc/SLEE.cfg 
SLEE_LOG     /IN/service_packages/SLEE/tmp/SLEE.log 
Type help at prompt for valid commands. 
[acs_oper] slee-ctrl> stop 
Type "yes" if you are sure: yes 
Info: slee_ctrl_lock_file: lock file created for "stop" command. 
Info: slee_ctrl_stop: 20101027-03:42:40 GMT: Running SLEE stop.sh... 
Oct 27 03:42:40 stop(17106) SleeRoot::shutdown()=9 sleeRoot.cc@883: SLEE Shutdown 
SLEE: Using shared memory offset: 0xc0000000 
SleeRoot: Shutting Down... 
SleeRoot: SIGUSR1 Watchdog (PID 14290). 
SleeRoot: Disable all services... 
SleeRoot: ...done 
SleeRoot: Send management end to all interfaces... 
SleeRoot: ...done 
SleeRoot: Send management end to all applications... 
SleeRoot: ...done 
SleeRoot: Wait to allow service/application completion... 
SleeRoot: ...done 
SleeRoot: Kill all interfaces... 
SleeRoot: SIGKILL Interface (PID 14262). 
...skipped... 
SleeRoot: SIGKILL Interface (PID 14289). 
SleeRoot: ...done 
SleeRoot: Kill all applications... 
SleeRoot: SIGKILL Application (PID 14251). 
...skipped... 
SleeRoot: SIGKILL Application (PID 14261). 
SleeRoot: ...done 
SleeRoot: Delete semaphore manager. 
SleeRoot: Delete shared memory. 
SleeRoot: All Done. 
Info: slee_ctrl_clean: cleaning SLEE shared memory and semaphores... 
Info: slee_verify_stop: Verifying all SLEE process(es) have stopped... 
Info: slee_verify_stop: No running SLEE processes found. 
Info: slee_verify_stop: /IN/service_packages/ACS/.slee_file deleted. 
Info: slee_ctrl_lock_file: lock file deleted for "stop" command. 
[acs_oper] slee-ctrl> quit 
$

Note:

In session mode you are prompted to type in yes if you want to stop or restart the SLEE. This safety check is not enforced when run from the command line.

Example VWS smf_oper restart

To restart the VWS SLEE as the smf_oper user, enter:

$ slee-ctrl restart 
SLEE Control: v,1.0.11: script v,1.21: functions v,1.48: pslist v,1.118 
[smf_oper] slee-ctrl> restart  
Error: slee_ctrl_confirm_user: You must be SLEE_USER [ ebe_oper ], or super user, to run 
"restart" command. 
$

Example stopped processes check

To check the status of the SLEE stopped processes, enter:

[acs_oper] slee-ctrl> status

  
------------------------ Wed Oct 27 03:53:26 GMT 2010 -------------------------- 
C APP  USER       PID PPID    STIME COMMAND 
6 SLEE acs_oper 17509    1 03:51:20 /IN/service_packages/ACS/bin/slee_acs 
1 SLEE acs_oper 17511    1 03:51:20 /IN/service_packages/SLEE/bin/capgw 
1 SLEE acs_oper 17512    1 03:51:20 /IN/service_packages/RAP/bin/rap 
1 SLEE acs_oper 17513    1 03:51:20 /IN/service_packages/LCP/bin/locApp 
1 SLEE acs_oper 17514    1 03:51:20 /IN/service_packages/ACSUSC/bin/slee_acs 
1 SLEE acs_oper 17515    1 03:51:20 /IN/service_packages/UIS/bin/ussdgw 
1 SLEE acs_oper 17516    1 03:51:20 /IN/service_packages/SLEE/bin/timerIF 
1 SLEE acs_oper 17517    1 03:51:20 /IN/service_packages/SLEE/bin/alarmIF 
1 SLEE acs_oper 17518    1 03:51:20 N/service_packages/ACS/bin/acsStatsLocalSLEE 
1 SLEE acs_oper 17519    1 03:51:20 /IN/service_packages/SLEE/bin/replicationIF 
1 SLEE acs_oper 17520    1 03:51:20 /IN/service_packages/E2BE/bin/BeClient 
1 SLEE acs_oper 17525    1 03:51:20 /IN/service_packages/OSD/bin/osdInterface 
1 SLEE acs_oper 17529    1 03:51:21 /IN/service_packages/SCA/bin/sca 
1 SLEE acs_oper 17533    1 03:51:21 /IN/service_packages/RIMS/bin/rims 
1 SLEE acs_oper 17536    1 03:51:21 /IN/service_packages/XMS/bin/xmsTrigger 
4 SLEE acs_oper 17537    1 03:51:21 /IN/service_packages/SLEE/bin/m3ua_if 
1 SLEE acs_oper 17543    1 03:51:21 /IN/service_packages/SLEE/bin/mapGenIF 
1 SLEE acs_oper 17546    1 03:51:21 N/service_packages/SLEE/bin/xmlTcapInterface 
1 SLEE acs_oper 17548    1 03:51:21 /IN/service_packages/SLEE/bin//watchdog 
0 SLEE acs_oper process not found: vssp 
total processes found = 27 [ 28 expected, 1 not found ] 
================================= run-level 3 ==================================

Note:

The vssp process has not be found in this example indicating that it is not running. A further manual check for the vssp process could be made using the UNIX ps command to verify the output. 
$ps -ef | grep vssp 
acs_oper 19976  1586   0 03:59:29 pts/2       0:00 grep vssp 
$

Example monitor SLEE resources

To monitor the internal SLEE resource usage with check, enter:

[acs_oper] slee-ctrl> check 1 5 

SLEE: Using shared memory offset: 0xc0000000 
04:16:29        Dialogs Apps    AppIns  Servs   Events  Calls 
[70000] [30]    [251]   [30]    [207062]        [25000] 
04:16:29        70000   24      240     16      207051  25000 
04:16:30        70000   24      240     16      207051  25000 
04:16:31        70000   24      240     16      207051  25000 
04:16:32        70000   24      240     16      207051  25000 
04:16:33        70000   24      240     16      207051  25000 
[acs_oper] slee-ctrl>

Note:

The check command is a separate SLEE utility located in /IN/service_packages/SLEE/bin directory. Use check -h to see a brief description of usage. For more detail on the check utility refer to the SLEE Technical Guide.

Corrupt memory symptom

If the SLEE's shared memory becomes corrupted, for whatever reason, you may find, when you try stopping the SLEE, it will be unresponsive.

As a rule of thumb, if it takes longer that 15 seconds to stop the SLEE, it is quite likely to have hung. You need to press Ctrl C to return to the command line prompt.

If you come across this scenario, use the slee-ctrl stop abort command. This will send a terminate signal (kill -TERM) to any running SLEE processes, wait 3 seconds, then send a kill signal (kill -KILL) to any remaining SLEE processes still running (if any). For example: 

[ebe_oper] slee-ctrl> stop abort

Always try the stop command first before trying the stop abort command.

Run levels

The servers that have the SLEE component installed are configured with an /etc/rc3.d start script and /etc/rc1.d stop script.

This means that on boot up the server should come up and automatically move to a state where it can handle traffic without operator intervention. You may notice that unlike the init managed processes the SLEE will not be stopped in run-level 2. This is done to prevent any unnecessary stopping of the SLEE that could cause interruption to live traffic.

Run the following scripts to change the behavior:

For Linux:

# find /etc/system.d /etc/rc?.d -name \*slee 
/etc/system.d/slee 
/etc/rc1.d/K01slee 
/etc/rc3.d/S99slee 
#

Note:

If reconfiguring these rc scripts then you must follow this rule: The SLEE must be started after the database and must be stopped before the database. If the SLEE is not stopped before the database then the database shutdown will be unresponsive due to SLEE processes having open shadow connections.

Database Management

The database is an integral part of the Convergent Charging Controller solution and the majority of the Convergent Charging Controller applications have a dependency on it being available before they are able to start.

The solution design has the SMS database as the master data store. The SLC and VWS databases are replicated nodes containing the same data, or in some cases subset of data, that the primary SMS node contains.

Currently this is a Convergent Charging Controller specific application and is often simply referred to as replication.

Note:

The VWS database also has its own set of special tables (BE_% tables) that are not part of the replicated set of SMS tables. The VWS BE_% tables contain a near real-time persistent store of billing data.

Oracle System IDs

This table shows the unique instance names or Oracle System IDs (ORACLE_SID) of each server database.

Server Oracle SID
SMS SMF
SLC SCP
VWS E2BE

Database verification

The simple way to verify the database is okay and that the Convergent Charging Controller processes can connect to it is to start a sqlplus session, enter: 

$ su – smf_oper 
Password: 
$ sqlplus / 
SQL*Plus: Release 12.1.0.2.0 - Production on Wed Apr 26 21:00:41 2016 
Copyright (c) 1982, 2014, Oracle.  All Rights Reserved. 
Connected to: 
Oracle Database 12c Release 12.1.0.2.0 - 64bit Production 
SQL> quit 
Disconnected from Oracle Database 12c Release 12.1.0.2.0 - 64bit Production 
$

The database on each server component is configured to start at boot time by the init daemon when the Server passes through run-level 2 using the /etc/rc2.d/S99oracle script.

Note:

As discussed earlier, the Convergent Charging Controller processes are configured to start in run-level 3. This ensures that the database is available before the Convergent Charging Controller processes start. It also has the added advantage that going to run-level 2 stops the Convergent Charging Controller processes but does not shut down the database.

Shadow connections

If the database needs to be shut down for maintenance, before this can happen, all connections to the database (often referred to as shadow connections) must be disconnected first.

This means that all the Convergent Charging Controller processes (init and SLEE managed) must be shut down.

An easy way to check for shadow connections to the database (without connecting to the database) is using the UNIX ps command. Enter: 

 $ ps -ef | grep oracle.*LOCAL  
oracle  1116     1   0   Oct 04 ?           
0:00 oracleSCP (LOCAL=NO) 
oracle  1106     1   0   Oct 04 ?           0:29 oracleSCP (LOCAL=NO) 
oracle 19564     1   0   Oct 25 ?           0:00 oracleSCP (LOCAL=NO) 
oracle 17552     1   0 03:51:21 ?           0:00 oracleSCP (LOCAL=NO) 
oracle  1110     1   0   Oct 04 ?           0:00 oracleSCP (LOCAL=NO) 
...skipped... 
$

Note:

The Parent PID (PPID) are always 1 for shadow connections and in this example the process name, oracleSCP, shows the SID of the database indicating it is a SLC server.

Database startup

Follow these steps to start the database (and listeners) and Convergent Charging Controller components. This is simply a reverse of the database shutdown procedure.

  1. Start the database by using one of the following methods:

    Method 1

    $ su - 
Password: 
For Solaris:
 $ /etc/init.d/oracle start 
For Linux: 
$ /etc/systemctl.d/oracle start 
Starting Oracle:  
Sourcing /etc/profile.ORA 
LSNRCTL for Linux: Version 19.0.0.0.0 - Production on 05-MAR-2025 14:23:05 
Copyright (c) 1982, 2014, Oracle.  All rights reserved. 
Starting /u01/app/oracle/product/11.2/bin/tnslsnr: please wait... 
TNSLSNR for Linux: Version 19.0.0.0.0 - Production 
System parameter file is /u01/app/oracle/product/11.3/network/admin/listener.ora 
Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=testslc)(PORT=1521))) 
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(PORT=1521))) 
STATUS of the LISTENER ------------------------ 
Alias                     
Version                   
LISTENER 
TNSLSNR for Linux: Version 19.0.0.0.0 - Production 
Start Date                27-OCT-2010 23:13:59 
Uptime                    0 days 0 hr. 0 min. 0 sec 
Trace Level               off 
Security                  ON: Local OS Authentication 
SNMP                      OFF 
Listener Parameter File   /u01/app/oracle/product/11.3/network/admin/listener.ora 
Listening Endpoints Summary... 
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=testslc)(PORT=1521))) 
Services Summary... 
Service "SCP" has 1 instance(s). 
Instance "SCP", status UNKNOWN, has 1 handler(s) for this service... 
The command completed successfully 
Sourcing /etc/profile.ORA 
Processing Database instance "SCP": log file 
/u01/app/oracle/product/11.3/startup.log 
# 
* Note: another valid db startup method is

    Method 2

    Change to the oracle user and run the dbstart command, as follows:

    $ su – oracle

    $ dbstart $ ORACLE_HOME

    as above...

  2. You would expect to see the following running database processes:
    $ ps -ef | grep ora_ 
oracle    33     1   0 23:21:18 ?           0:01 ora_pmon_SCP 
oracle    43     1   0 23:21:18 ?           0:01 ora_ckpt_SCP 
oracle    49     1   0 23:21:18 ?           0:01 ora_mmon_SCP 
root   117 29059   0 23:43:47 pts/2       0:00 grep ora_ 
oracle    58     1   0 23:21:31 ?           0:02 ora_cjq0_SCP 
oracle    35     1   0 23:21:18 ?           0:00 ora_psp0_SCP 
oracle    51     1   0 23:21:18 ?           0:00 ora_mmnl_SCP 
oracle    47     1   0 23:21:18 ?           0:00 ora_reco_SCP 
oracle    39     1   0 23:21:18 ?           0:00 ora_dbw0_SCP 
oracle    45     1   0 23:21:18 ?           0:01 ora_smon_SCP 
oracle    37     1   0 23:21:18 ?           0:01 ora_mman_SCP 
oracle    41     1   0 23:21:18 ?           0:00 ora_lgwr_SCP
#
  3. You may verify the database instance is accepting connections:
    $ su - smf_oper -c "echo exit |sqlplus /" 
Sourcing /etc/profile.ORA 
SQL*Plus: Release 12.1.0.2 - Production on Wed Apr 26 23:48:21 2016 
Copyright (c) 1982, 2014, Oracle Corporation.  All rights reserved. 
Connected to: 
Oracle Database 11g Release 12.1.0.2 - 64bit Production 
SQL> Disconnected from Oracle Database 11g Release 12.1.0.2 - 64bit Production 
#
  4. Starting the remaining Convergent Charging Controller components should occur (dependent on SLEE rc?.d script rules) by putting the server back into run level 3.

    $ init 3

Shutting down the Server

The procedure to shut down a server is not be discussed in great detail here as System Administrators generally have their own procedures that they like to follow to do this.

What is suggested is a method that may be followed.

It is recommended that the system administrators who maintain the Convergent Charging Controller servers create and test a detailed server shutdown procedure that meets their needs.

The general steps include:

  1. Shut down the Convergent Charging Controller applications and database (as previously described).
  2. Make a connection to the server console (specific to the Server and network setup).
  3. Issue a server shutdown command to stop the operating system (for example init 0).
  4. Power server off (refer to Server documentation).

Starting the Server

The procedure to start a server can be dependent on the setup of the server and the procedures that system administrators may like to use for the servers they maintain.

Standard practice for the Convergent Charging Controller servers would be for the operating system to boot up when the server is powered on.

For Linux:

  1. Log in as the su user.
  2. Run the following command to start the Oracle database if not started already:

    dbstart

  3. Run the following command:

    /IN/bin/OUI_systemctl.sh

  4. Run the following command which starts the Oracle listener:

    lsnrctl start