This chapter describes how to configure an Oracle Communications Billing and Revenue Management (BRM) system with In-Memory Database (IMDB) Cache Manager.
Before you read this chapter, you should be familiar with:
IMDB Cache Manager. See "Using Oracle IMDB Cache Manager".
Oracle IMDB Cache concepts and architecture. See Oracle In-Memory Database Cache User's Guide.
You can configure IMDB Cache Manager in the following ways.
To configure IMDB Cache Manager to use the transaction consistency feature:
Ensure that the transaction consistency feature is enabled. See "Enabling the Transaction Consistency Feature".
Specify how long to keep transactions in an Active status after an error. See "Specifying How Long to Keep Transactions Active after an Error".
For more information, see "About Committing Transactions in Both Oracle IMDB Cache and the BRM Database".
When you install IMDB Cache Manager, transaction consistency is automatically enabled.
When enabled, IMDB Cache DM can perform operations on both Oracle IMDB Cache and the BRM database in a single transaction. This guarantees that the data will be consistent across both data sources.
When disabled, BRM can perform read-write operations when the data spans both data sources. However, the data will be inconsistent if one of the transactions fail.
You specify whether transaction consistency is enabled by editing the dm_trans_consistency_enabled entry in the IMDB Cache DM configuration file.
Note:
The active and standby IMDB Cache DM instances must have the same configuration settings in the dm_tt pin.conf file. In particular, the number of IMDB Cache DM back-end process must be the same.To enable the transaction consistency feature, perform the following for each IMDB Cache DM instance:
Open the IMDB Cache DM configuration file (BRM_home/sys/dm_tt/pin.conf) in a text editor.
Set the dm_trans_consistency_enabled entry to 1:
- dm dm_trans_consistency_enabled 1
Setting this entry to 1 enables the transaction consistency feature. This is the default.
Setting this entry to 0 disables the transaction consistency feature.
Set the dm_restart_children entry to 1:
- dm dm_restart_children 1
Setting this entry to 1 specifies to replace child processes that have stopped. This prevents the system from losing DM processes because of transient failures over time. This is the default.
Setting this entry to 0 specifies to not replace child processes that have failed.
Save and close the file.
Restart the IMDB Cache DM instance.
When an error occurs during a transaction, the Oracle Global Transaction waits, by default, for 3600 seconds (or 1 hour). You can increase or decrease the wait time by modifying the dm_trans_timeout_in_secs entry in the IMDB Cache DM pin.conf file. You should base the wait time on how long it would take your system to recover from a failure or a node switchover. The minimum wait time is 10 seconds, and the maximum wait time is 5,184,000 seconds (or 2 months).
Note:
For information about the dm_xa_trans_timeout_in_secs entry, see "Changing the XA Transaction Timeout Period" in BRM JCA Resource Adapter.To specify how long to keep Oracle Global Transactions in an Active status after an error, perform the following for each IMDB Cache DM instance:
Open the IMDB Cache DM configuration file (BRM_home/sys/dm_tt/pin.conf) in a text editor.
Set the dm_trans_timeout_in_secs entry to the appropriate value:
-dm dm_trans_timeout_in_secs value
where value specifies the amount of time, in seconds, to keep the global transaction in an Active state after an error.
Save and close the file.
Restart the IMDB Cache DM instance.
To configure BRM to perform event searches in both Oracle IMDB Cache and the BRM database:
Ensure that the union search feature is enabled. See "Enabling Union Searches for Events".
Specify a timeout value for batch searches. See "Specifying the Timeout Value for Batch Polling Operations".
If necessary, customize any external applications to perform batch polling. See "Customizing External Applications for Real-Time Union Searches".
If necessary, customize any external applications to perform union searches during batch rating. See "Customizing External Applications for Batch Polling Operations".
For more information, see "About Searching for Usage Events in Oracle IMDB Cache-Enabled Systems".
When the union search feature is enabled, BRM finds usage events by searching both Oracle IMDB Cache and the BRM database.
When the union search feature is disabled, BRM searches for usage events in either Oracle IMDB Cache or the BRM database, depending on the residency type.
You specify whether union search is enabled by editing the tt_unionsearch_enabled entry in the IMDB Cache DM configuration file.
To enable union searches, perform the following for each IMDB Cache DM instance:
Open the IMDB Cache DM configuration file (BRM_home/sys/dm_tt/pin.conf) in a text editor.
Set the tt_unionsearch_enabled entry to 1:
-dm tt_unionsearch_enhabled 1
Setting this entry to 1 enables union searches. This is the default.
Setting this entry to 0 disables union searches.
Save and close the file.
Restart the IMDB Cache DM instance.
When performing union searches during batch operations, BRM ensures that all recently created and modified usage events have been propagated from Oracle IMDB Cache to the BRM database by doing the following:
Retrieving the list of events that must be propagated from Oracle IMDB Cache.
Polling the BRM database until all the events from the list appear in the database.
To prevent IMDB Cache DM from entering an infinite loop during the database polling process, you must specify a polling timeout value.
To specify a timeout value for batch polling operations, perform the following for each IMDB Cache instance:
Open the IMDB Cache DM configuration file (BRM_home/sys/dm_tt/pin.conf) in a text editor.
Set the dmtt_unionsearch_poll_timeout entry to the appropriate value:
-dm dmtt_unionsearch_poll_timeout value
where value specifies the amount of time to wait, in milliseconds, before aborting the search procedure.
Save and close the file.
Restart the IMDB Cache DM instance.
If your BRM system uses an external application, you must configure it to perform union searches during real-time rating. To do so, customize your external application to pass the following input flist field in the call to the PCM_OP_SEARCH, PCM_OP_STEP_SEARCH, PCM_OP_GLOBAL_SEARCH, and PCM_OP_GLOBAL_STEP_SEARCH opcodes:
PIN_FLD_FLAGS field set to SRCH_UNION_TT. For example:
0 PIN_FLD_FLAGS INT[0] SRCH_UNION_TT
If your BRM system uses an external application, you must configure it to perform batch polling operations. To do so, customize your external application to execute the fm_utils_poll_tt function as part of the fm_utils.so library.
This function polls the BRM database to determine whether it has received all of the batch-rated events from Oracle IMDB Cache.
Void
fm_utils_poll_tt(
cm_nap_connection_t *connp,
int32 flags,
pin_flist_t *s_flistp,
pin_flist_t **o_flistpp,
pin_errbuf_t *ebufp)
Flags indicates the polling type. No flag indicates multi-node polling, and the PCM_OPFLG_SEARCH_ONE_PARTITION flag indicates single-node polling. The default is multi-node polling.
s_flistp is a pointer to the input flist. The input flist must use the following format:
0 PIN_FLD_POID POID [0] 0.0.0.1 /poll -1 0 0 PIN_FLD_ARGS ARRAY [1] allocated 20, used 2 1 PIN_FLD_ARG_TYPE ENUM [0] 0 1 PIN_FLD_CLASS_NAME STR [0] "/event"
o_flistpp is a pointer to the output flist. The output flist must use the following format:
0 PIN_FLD_POID POID [0] 0.0.0.1 /poll -1 0 0 PIN_FLD_MOD_TIME STR [0] "1298951268" 0 PIN_FLD_PROC_STATUS INT [0] 0
Note:
In the PIN_FLD_PROC_STATUS field, a value of 0 indicates that the data in the BRM database is synchronized with Oracle IMDB Cache. A value of -1 indicates that the data in the BRM database is out-of-sync with Oracle IMDB Cache.ebufp is a pointer to the error buffer.
If your Oracle IMDB Cache system includes logical partitions, you must customize any external applications to perform the following:
Retrieve data from multiple logical partitions. See "Retrieving Data Across Logical Partitions".
Search for data across multiple logical partitions. See "Searching for Data Across Logical Partitions".
For more information, see "About Finding Data in Logical Partitions".
Any external application that retrieves data from your BRM system must specify when to retrieve data from only one logical partition and when to retrieve data from multiple logical partitions.
By default, the PCM_OP_READ_OBJ and PCM_OP_READ_FLDS opcodes automatically retrieve data from one logical partition only. To retrieve data from multiple logical partitions, you must customize your external application to pass the PCM_OPFLG_SEARCH_PARTITIONS flag in the opcode call.
For example, for C applications:
PCM_OP(ctxp, PCM_OP_READ_OBJ, PCM_OPFLG_SEARCH_PARTITIONS, input_flistp, &return_flistp, ebufp);
For example, for Java applications:
FList output = conn.opcode(PortalOp.READ, PortalContext.OPFLG_SEARCH_PARTITIONS, input);
Any external application that performs a search on your BRM system must specify when to search all logical partitions in a schema and when to search only one logical partition in a schema. To do so, you pass a flag in the call to the search opcodes.
The flag to send and the scenarios in which to pass the flag depends on whether the opcode call is made inside or outside of a transaction:
Inside of a transaction: By default, IMDB Cache DM searches only the current logical partition when a search is executed inside of a transaction.
To customize your external application to request a search across all logical partitions in a call inside a transaction, pass the PCM_OPFLG_SEARCH_PARTITIONS flag in the call to the search opcode.
For example, for C applications:
PCM_OP(ctxp, PCM_OP_SEARCH, PCM_OPFLG_SEARCH_PARTITIONS, input_flistp, &return_flistp, ebufp);
For example, for Java applications:
FList output = conn.opcode(PortalOp.SEARCH, PortalContext.OPFLG_SEARCH_PARTITIONS, input);
Outside of a transaction: By default, IMDB Cache DM automatically searches across all logical partitions when a search is executed outside of a transaction.
To customize your external application to request a search on only one logical partition in a call outside of a transaction, pass the PCM_OPFLG_SEARCH_ONE_PARTITION flag in the call to the search opcode.
For example, for C applications:
PCM_OP(ctxp, PCM_OP_SEARCH, PCM_OPFLG_SEARCH_ONE_PARTITION, input_flistp, &return_flistp, ebufp);
For example, for Java applications:
FList output = conn.opcode(PortalOp.SEARCH, PortalContext.OPFLG_SEARCH_ONE_PARTITION, input);
Table 22-1 lists the BRM search opcodes that support global processing searches in IMDB Cache-enabled systems.
| Opcode | Description |
|---|---|
|
PCM_OP_SEARCH |
Searches the database and returns all of the results simultaneously. |
|
PCM_OP_STEP_SEARCH PCM_OP_STEP_NEXT PCM_OP_STEP_END |
Searches the database and returns the results in discrete chunks. Use this opcode when searching a single schema. You start a step search by calling the PCM_OP_STEP_SEARCH opcode, which initiates a step search and retrieves the first set of results. Then, you call the PCM_OP_STEP_NEXT opcode for each subsequent set of results. At the end of the search, you call the PCM_OP_STEP_END opcode to retrieve the last set of results. You pass the flag in the call to the PCM_OP_STEP_SEARCH opcode only. |
|
PCM_OP_GLOBAL_SEARCH |
Searches for data across multiple schemas and returns all of the results simultaneously. |
|
PCM_OP_GLOBAL_STEP_SEARCH PCM_OP_GLOBAL_STEP_NEXT PCM_OP_GLOBAL_STEP_END |
Searches for data across multiple schemas and returns the results in discrete chunks. You start a global step search by calling the PCM_OP_GLOBAL_STEP_SEARCH opcode, which initiates a step search and retrieves the first set of results. Then, you call the PCM_OP_GLOBAL_STEP_NEXT opcode for each subsequent set of results. At the end of the search, you call the PCM_OP_GLOBAL_STEP_END opcode to retrieve the last set of results. You pass the flag in the call to the PCM_OP_GLOBAL_STEP_SEARCH opcode only. |
For more information about:
The BRM search opcodes, see "Searching for Objects in BRM Databases" in BRM Developer's Guide.
Calling opcodes, see "Calling PCM Opcodes" in BRM Developer's Guide.
To enable you to successfully run BRM reports on an IMDB Cache-enabled system, the IMDB Cache Manager installer automatically creates an event table, a temporary table, and a table view for each of the following objects:
/event/activity/content
/event/activity/telco
/event/session/dialup
/event/session/telco
/event/session/telco/gsm
/event/session/telco/gprs
/event/session/telco/gprs/master
/event/session/telco/gprs/subsession
/event/session/telco/imt
/event/session/telco/pdc
You must generate temporary tables and views for any other event tables in your system with residency type 301 or 302 by running the create_temp_tables_proc() stored procedure. For example, you run the stored procedure whenever you perform the following tasks:
Create custom event tables with residency type 301 or 302.
Install any BRM optional manager and want to run its associated report.
To configure your custom and optional manager event tables for BRM reports:
Log in to SQL*Plus as the pin user.
Run the following stored procedure:
call create_temp_tables_proc()
You must configure BRM to store reservations in /balance_group objects, which are created in the subscriber cache group. To do so, set the balance_coordinator CM configuration file entry to 1.
Because Oracle IMDB Cache does not support migration of local tables across grid members, /reservation_list cannot be used to track reservations for resource sharing groups. For this reason, it is recommended to set balance_coordinator to 1 in an IMDB Cache-enabled system so that reservations are tracked in /balance_group objects.
To configure BRM to store reservations in /balance_group objects:
Open the CM configuration file (BRM_home/sys/cm/pin.conf) in a text editor.
Set the balance_coordinator entry to 1:
- cm balance_coordinator 1
Save and close the file.
On the system where IMDB Cache DM is installed, set the stacksize limit to unlimited.
To set the stacksize limit:
Log on to the system where IMDB Cache DM is installed.
Enter the following command:
limit stacksize unlimited
Verify the stacksize limit by entering the following command:
limit stacksize
Database schema status determines whether a database schema or logical partition is available for account creation. Databases can be set to open, closed, or unavailable. For more information, see "How Accounts Are Assigned to the Logical Partition".
To change the status of a database schema or logical partition, edit the STATUS entries in the config_dist.conf file and then use the load_config_dist utility to load the distribution information into the primary database schema.
To set or change the database schema or logical partition status:
Go to the BRM_home/apps/multi_db directory and open the config_dist.conf file in a text editor.
Change the values in the STATUS entries:
DB_NO = "0.0.0.1" ; # 1st database schema configuration block PRIORITY = 1 ; MAX_ACCOUNT_SIZE = 100000 ; STATUS = "OPEN" ; DB_NO = "0.1.0.1" ; # 1st database schema configuration block with logical partition PRIORITY = 1 ; MAX_ACCOUNT_SIZE = 100000 ; STATUS = "OPEN" ; DB_NO = "0.0.0.2" ; # 2nd database schema configuration block PRIORITY = 2; MAX_ACCOUNT_SIZE = 50000 ; STATUS = "OPEN"; DB_NO = "0.1.0.2" ; # 2nd database schema configuration block with logical partition PRIORITY = 1; MAX_ACCOUNT_SIZE = 50000 ; STATUS = "OPEN";
Note:
If your system contains multiple database schemas and logical partitions, create a new set of entries for each additional database schema and each logical partition.Save and close the file.
Verify that the pin_config_distribution utility is not running.
Go to the BRM_home/apps/multi_db directory and run the load_config_dist utility.
Caution:
The load_config_dist utility overwrites existing distributions. If you are updating distributions, you cannot load new distributions only. You must load complete sets of distributions each time you run the load_config_dist utility.Stop and restart all CMs.
Database schema priority determines when customer accounts are created on a particular database schema relative to other database schemas. BRM assigns accounts to an open database schema with the highest priority number.
If all database schemas have the same priority, BRM chooses an open database schema at random each time it assigns accounts. This distributes accounts evenly across all database schemas.
Oracle recommends assigning:
Different priorities to each database schema.
The same priority to all logical partitions within a database schema.
Note:
If your system contains multiple database schemas and multiple logical partions, create a new set of entries for each additional database schema and logical partition.To set or change a database schema's priority:
Go to the BRM_home/apps/multi_db directory and open the config_dist.conf file in a text editor.
Edit the PRIORITY entries.
In the following example, BRM creates accounts on database schema 0.1.0.2 because it has the highest priority setting of all open database schemas.
DB_NO = "0.0.0.1" ; # 1st database configuration block PRIORITY = 1 ; MAX_ACCOUNT_SIZE = 100000 ; STATUS = "OPEN" ; DB_NO = "0.1.0.1" ; # 1st database configuration block with logical partition PRIORITY = 1; MAX_ACCOUNT_SIZE = 100000 ; STATUS = "OPEN" ; DB_NO = "0.0.0.2" ; # 2nd database configuration block PRIORITY = 2; MAX_ACCOUNT_SIZE = 50000 ; STATUS = "OPEN" ; DB_NO = "0.1.0.2" ; # 2nd database configuration block with logical partition PRIORITY = 1; MAX_ACCOUNT_SIZE = 50000 ; STATUS = "OPEN"; DB_NO = "0.0.0.3" ; # 3rd database configuration block PRIORITY = 3; MAX_ACCOUNT_SIZE = 50000 ; STATUS = "CLOSED" ; DB_NO = "0.1.0.3" ; # 3rd database configuration block with logical partition PRIORITY = 1; MAX_ACCOUNT_SIZE = 50000 ; STATUS = "OPEN"
Save and close the file.
Verify that the pin_config_distribution utility is not running.
Caution:
The load_config_dist utility overwrites all distributions that are already in the database. If you are updating distributions or adding new ones, beware that you cannot load only the new and changed distributions.Go to the BRM_home/apps/multi_db directory and run the load_config_dist utility.
Note:
The load_config_dist utility requires a configuration file.Stop and restart all CMs.