This chapter describes how to migrate data from an Oracle Communications Billing and Revenue Management (BRM) system to an Oracle In-Memory Database (IMDB) Cache-enabled BRM system.
Note:
The information applies to customers who have created accounts on a BRM system before IMDB Cache Manager was installed; it does not apply to customers performing a new BRM installation whose original system setup includes IMDB Cache Manager.Before you read this chapter, you should be familiar with:
BRM architecture.
IMDB Cache Data Manager.
Oracle IMDB Cache.
For more information, see "BRM System Architecture" in BRM Concepts.
If you have an existing BRM system, to use BRM with Oracle IMDB Cache, you must install IMDB Cache Manager and migrate your data on a BRM system to an Oracle IMDB Cache-enabled BRM system.
Migrating your BRM system to an Oracle IMDB Cache-enabled system includes:
Preparing existing account data (created in your BRM system before using an Oracle IMDB Cache environment) for an Oracle IMDB Cache-enabled BRM environment.
Migrating accounts from your BRM database to Oracle IMDB Cache logical partitions.
Migrating a BRM TIMOS environment to the Oracle IMDB Cache environment
For an overview of the tasks required to migrate your BRM system to an Oracle IMDB Cache-enabled system, see "Overview of the Migration Process".
For information on how the migration process works, see the following:
For information on how core BRM is modified after you install IMDB Cache Manager, see "Changes to BRM after Installing IMDB Cache Manager".
When you migrate to an IMDB Cache-enabled system, the following BRM processes cannot coexist with IMDB Cache Manager:
Oracle DM
IMDB Cache DM replaces the Oracle DM.
Important:
During BRM 7.5 installation, the CM and Oracle DM are required and started up automatically by the pin_setup process.When you configure a BRM system with IMDB Cache Manager, configure the CM to connect only to IMDB Cache DM.
TIMOS DM
The functionality of IMDB Cache Manager and the Oracle IMDB Cache replaces the functionality of the TIMOS DM and the TIMOS DM reference object cache (ROC). If you have a BRM system with TIMOS DM, you must stop the TIMOS DM, CM, and Oracle DM processes before you perform certain phases of the upgrade.
This section explains how BRM and IMDB Cache Manager migrate the data in your BRM system to a BRM system with IMDB Cache Manager.
The Portal object ID (POID) of fields in a BRM system is in the format 0.0.0.Schema_No. The POID of fields in a BRM system with IMDB Cache Manager is in the format 0.LogicalPartition_No.0.Schema_No.
When the accounts in your BRM system migrate to a BRM system with IMDB Cache Manager, the upgrade process updates the POID to include the Oracle IMDB Cache logical partition number of the logical partition into which the accounts are migrated.
The load_pin_uniqueness utility:
Sets and updates the logical partition number in the /uniqueness object POID that is stored in the BRM database so that it can be used later by the tt_load.sql script to load the data into IMDB Cache.
Populates the /uniqueness table with uniqueness data for the accounts in your BRM system.
Finds out which logical partition the accounts fit into and then updates the account POID database numbers in the /uniqueness table.
After load_pin_uniqueness figures out how to distribute the accounts among the logical partitions, the tt_load.sql script uses the data in the /uniqueness table to determine the Oracle IMDB Cache data stores in which to load the subscriber data for the accounts and loads the subscriber data.
Note:
You run the load_pin_uniqueness utility only if you must migrate accounts that were created on a BRM system that was not IMDB Cache-enabled. After your accounts are migrated, you do not need to run this utility again.Before accounts from your BRM system can be distributed among the logical partitions of Oracle IMDB Cache, they must be assigned to logical partitions.
The load_pin_uniqueness utility assigns the accounts from your BRM system to the logical partitions as follows:
Finds accounts that are not updated in the /uniqueness table.
Obtains the maximum account size and the current account size of the logical partition that the accounts may go into.
Considers the maximum account size and the current account size of each logical partition and attempts to distribute accounts equally among logical partitions.
If the logical partition reaches the limit, the remaining accounts are not distributed.
Checks whether all the logical partitions of a schema can accommodate all the accounts of that schema.
If all of the logical partitions of a schema cannot accommodate all of the accounts of that schema, throws an error message.
Distributes accounts of a schema across all the logical partitions of the schema.
The BRM database and Oracle IMDB Cache do not store the logical partition number in the POID fields of their data. IMDB Cache Manager stores the logical partition number in its run-time memory. For the CM and its associated Facilities Modules (FMs) to know in which logical partition an account resides, the IMDB Cache DM does the following for all POID fields:
Clears the logical partition number from the POID
Writes the POID database numbers to the storage media
Gets the POID database numbers from the storage media
Updates the POID database numbers with the logical partition number in its memory
Sends the resulting POID database numbers, which now include the logical partition number (of the current residing logical partition), to the CM
The IMDB Cache DM updates the POID fields with the logical partition number for all fields that store POIDs, including fields that store POIDs in string format.
During billing, BRM migrates a parent account to the logical partition where the child account resides. After billing, BRM migrates the parent account and its related instances back to its original logical partition to avoid having a load imbalance among logical partitions. BRM uses the /uniqueness object for account lookup to obtain the logical partition number of the parent account and move it back to that logical partition.
Frequent migration of accounts between logical partitions can degrade performance. For improved performance, Oracle recommends you load all hierarchical accounts into one logical partition.
Important:
If you are migrating from a legacy billing system, you must first migrate your data from the legacy system to BRM 7.5 before you begin the migration process to Oracle IMDB Cache.If you have an existing BRM system, you perform a functional and technical upgrade to migrate to a BRM system that is Oracle IMDB Cache-enabled as follows:
Install BRM 7.5.
Stop the Connection Manager (CM) and Oracle Data Manager (DM) processes.
If you are migrating from a BRM TIMOS environment, stop the TIMOS DM.
Set up your Oracle IMDB Cache environment.
Install IMDB Cache Manager.
Start the IMDB Cache DM and CM processes.
Truncate or clean up the /uniqueness objects.
Note:
This is applicable in a multischema environment only.Restart the IMDB Cache DM process.
Stop the config_pin_distribution process.
Run the load_pin_uniqueness utility.
Configure the IMDB Cache DM, CM, and load_pin_uniqueness utility for migration. See "Configuration Entries Required for Migration".
Prepare accounts for distribution. See "Preparing Accounts for Distribution into IMDB Cache Logical Partitions".
Migrate from a TIMOS environment to an IMDB Cache environment. See "Migrating a BRM TIMOS Environment to an IMDB Cache Environment".
Load subscriber data into the IMDB Cache data stores. See "Loading Subscriber Data into the Oracle IMDB Cache Data Stores".
To configure your IMDB Cache DM, CM, and load_pin_uniqueness utility for migrating BRM data:
Open the IMDB Cache DM configuration file (BRM_home/sys/dm_tt/pin.conf) in a text editor.
Add the following entry:
- dm poids_in_string_format_list
PIN_FLD_ACCOUNT_NO,PIN_FLD_ITEM_POID_LIST,PIN_FLD_EVENT_POID_LIST,PIN_FLD_NEXT_ITEM_POID_LIST,PIN_FLD_GL_REPORT_POID_LIST
This entry updates the POID fields with the Oracle IMDB Cache logical partition number.
Save and close the file.
Open the CM configuration file (BRM_home/sys/cm/pin.conf) in a text editor.
Add the following uniqueness_login entry:
- cm uniqueness_login 1
Add the following use_legacy_uniqueness_population entry:
- fm_cust use_legacy_uniqueness_population 0
Add the following primary_db entry:
- cm primary_db 0.0.0.1 / 0
Save and close the file.
Open the load_pin_uniqueness utility configuration file (BRM_home/apps/multi_db/pin.conf) in a text editor.
Add the following is_timesten entry:
- load_pin_uniqueness is_timesten 1
Add the following per_schema_node_info entry:
- load_pin_uniqueness per_schema_node_info DB_NO:DB_NO
where:
DB_NO:DB_NO is the per-schema logical partition information.
For example:
If the schema 0.0.0.1 has three logical partitions (0.0.0.1, 0.1.0.1, and 0.2.0.1), the entry is:
- load_pin_uniqueness per_schema_node_info 0.0.0.1:0.1.0.1:0.2.0.1
Add the following entry:
- load_pin_uniqueness -g
The -g parameter assigns all the group accounts to the same node. If you do not specify this parameter, group accounts are considered as nongroup accounts and the distribution follows the round-robin method.
Save and close the file.
To prepare your existing account data for migration and distribution into available Oracle IMDB Cache logical partitions:
Run the load_pin_uniqueness utility.
You must run load_pin_uniqueness as described in "Installing IMDB Cache Manager".
Stop and restart the CM.
Verify that the /uniqueness object was loaded by using the Object Browser or by using the robj command with the testnap utility.
Your data is ready to be loaded into the Oracle IMDB Cache data stores. See "Loading Subscriber Data into the Oracle IMDB Cache Data Stores".
This section describes configuration procedures you must follow if you use a BRM system with TIMOS DM.
To migrate a BRM TIMOS environment to an Oracle IMDB Cache environment:
Stop the CM.
Stop TIMOS DM.
Stop the Oracle DM.
Open the BRM_home/sys/cm/pin.conf file in a text editor.
Set the dm_pointer entry to point to the IMDB Cache DM host name and port number.
- cm dm_pointer 0.0.0.1 ip DMTT_Host Port
where DMTT_Host is the IMDB Cache DM host name.
Note:
You must remove the TIMOS entry and add the IMDB Cache DM host name and port number.Start the IMDB Cache DM.
Start the CM.
Run the load_pin_uniqueness utility.
Note:
The transient objects are not migrated.To load subscriber data from the BRM database into the Oracle IMDB Cache data stores:
Run pin_tt_schema_gen, which generates the schema and load SQL files.
Connect to Oracle IMDB Cache using ttIsql.
Run the tt_load.sql script against the appropriate Oracle IMDB Cache logical partition.
For detailed instructions, see "Generating the BRM Cache Group Schema".
This section describes changes made to the base BRM 7.5 release after you install IMDB Cache Manager.
After you install IMDB Cache Manager (the if_tt_enabled flag is enabled), the opcode modifications listed in Table 25-1 occur:
Table 25-1 Opcode Modifications for IMDB Cache Manager
| Changed Opcode | Changed Opcode Flow in an Oracle IMDB Cache Environment |
|---|---|
|
PCM_OP_ACT_FIND |
Uses the /uniqueness object to obtain account and service data for a given account login. Performs uniqueness lookup in a single schema environment. Does not perform global search in a single schema environment. |
|
PCM_OP_CUST_COMMIT_CUSTOMER |
Updates the /uniqueness table. |
|
PCM_OP_CUST_MODIFY_CUSTOMER |
Updates the /uniqueness table. |
|
PCM_OP_CUST_SET_LOGIN |
Updates the /uniqueness table. |
|
PCM_OP_CUST_MODIFY_SERVICE |
Updates the /uniqueness table. |
|
PCM_OP_CUST_DELETE_ACCT |
Updates the /uniqueness table. |
|
PCM_OP_TCF_AAA_AUTHORIZE |
Uses the /uniqueness table for service lookup in a single schema environment. |
|
PCM_OP_TCF_AAA_REAUTHORIZE |
Uses the /uniqueness table for service lookup in a single schema environment. |
|
PCM_OP_TCF_AAA_STOP_ACCOUNTING |
Uses the /uniqueness table for service lookup in a single schema environment. |
After you install IMDB Cache Manager (the if_tt_enabled flag is enabled), the utility modifications listed in Table 25-2 occur: