Monitoring Your BRM System

2 Monitoring Your BRM System

Learn how to monitor your Oracle Communications Billing and Revenue Management (BRM) system.

Topics in this document:

Monitoring Hardware and Operating Systems

To monitor your system using standard tools, use monitoring utilities such as vmstat, sar, and top on UNIX.

On Solaris systems, use sysdef to find information about kernel parameter settings. This is especially useful for determining if per-process shared memory, file descriptor, or thread limits are adequate. pmap is useful for separating memory usage into total, resident, shared, and private.

Checking the Number and ID of a BRM Process

You can check the number of processes running for the CM or a DM. The number should match the number specified in the configuration file (pin.conf) for that component. If not, the processes either did not start or have stopped. You can also look at the process ID (PID) for each process.

Enter the following command:

ps -ef | grep process

The system shows each process and its ID.

For example, to show the processes running for the Paymentech DM, enter the following command:

ps -ef | grep dm_fusa

Checking the Version Numbers of Components

You can check the version numbers of all BRM components installed on a machine by using the viewInventory.sh script.

The following information for each component and patch installed on a machine are available in the Oracle_home/inventory/registry.xml, where Oracle_home is the directory in which the Oracle products are installed:

Distribution name
Feature-sets name
Feature status
Version number
Installation time

For example:
```
<feature status="installed" name="BRMServer" version="12.0.0.1.0">
   <sessions>
      <session id="1" date="2018-09-08T18:53:47.492-07:00" action="install"/>
   </sessions>
</feature>
```
Note:

Use this file or script whenever you are working with Oracle Technical Support to help them re-create your system environment and troubleshoot your problems.

Checking BRM Component Version Numbers

To check which BRM components are installed on your machine, go to the Oracle_home/oui/bin directory and run the viewInventory.sh script:

sh viewInventory.sh

BRM displays the versions of all products installed on your machine.

Note:

The viewInventory.sh script does not display information about the uninstallation of any BRM component. Only installation information is displayed.

Dumping Business Parameters in XML Format

To dump BRM business parameters (/config/business_params objects) in XML format, use the pin_cfg_bpdump utility. For more information about business parameters, see "business_params Reference".

You can use the output as input to another application or utility, such as a diagnostic application. You can also direct the XML output to a file. For example, to direct the output to a file named myfile.xml in the same directory in which the utility is run, enter the following command:

pin_cfg_bpdump > myfile.xml

For each /config/business_params object, the utility outputs a <RESULTS> element that supplies identifying information about the object. The <RESULTS> elements include a <PARAMS> element for each parameter they include. A <PARAMS> element provides the parameter description, name, type, and value.

To dump business parameters by using the pin_cfg_bpdump utility:

Go to the BRM_home/diagnostics/pin_cfg_bpdump directory.
Run the following command:
```
pin_cfg_bpdump
```
To direct the output to a file, use the following syntax:
```
pin_cfg_bpdump > file_name
```
where file_name is the name of a file in the same directory in which the utility is run.

Monitoring Global Transactions

The DBA_2PC_PENDING view stores detailed information about each Pending global transaction.

DBA_2PC_PENDING is a static data dictionary view in the BRM database. To enable Oracle DM processes to access this view, your system administrator must grant read privileges to the BRM database user.

Table 2-1 describes the columns in the DBA_2PC_PENDING view.

Table 2-1 DBA_2PC_PENDING View Description

Column Name	Description
LOCAL_TRAN_ID	For extended architecture (XA) transactions, specifies the branch qualifier element of an XA transaction ID (XID), which uniquely identifies the local BRM database branch of the XA transaction.
GLOBAL_TRAN_ID	For XA transactions, specifies the global transaction ID element of an XID, which uniquely identifies the XA transaction.
STATE	Specifies the transaction's state, which can be one of the following values: Collecting: Applies only to the global coordinator or local coordinators. The node is currently collecting information from other database servers before it can decide whether it can prepare. Prepared: The node has prepared and may or may not have acknowledged this to its local coordinator or transaction manager with a prepared message. However, no commit request has been received. The node remains prepared, holding any local resource locks necessary for the transaction to commit. Committed: The node (any type) has committed the transaction, but other nodes involved in the transaction may not have done the same. That is, the transaction is still pending at one or more nodes. Forced commit: A pending transaction can be forced to commit at the discretion of a database administrator. This entry occurs if a transaction is manually committed at a local node. Forced rollback: A pending transaction can be forced to roll back at the discretion of a database administrator. This entry occurs if this transaction is manually rolled back at a local node.
MIXED	YES means that part of the transaction was committed on one node and rolled back on another node.
TRAN_COMMIT	Specifies the transaction comment or, if transaction naming is used, the transaction name.
HOST	Specifies the host machine name.
COMMIT#	Specifies the global commit number for committed transactions.