4 Installing and Configuring BRM for Account Migration
Learn how to install and configure software required for account migration with the Oracle Billing and Revenue Management (BRM).
Topics in this document:
System Requirements
The system requirements for account migration consists of the following:
General Software Requirements
Before installing AMM, you must install:
-
Oracle 12c database software. You must also install the following Oracle 12c components:
-
JServer
-
PL/SQL
-
SQL*Plus
-
-
PERL libraries and the JRE required for installing BRM components.
-
Multidatabase Manager. See “Installing a Multischema System" in BRM Installation Guide.
Software Requirements for Account Migration Manager
AMM is available for Oracle databases and the Linux and Solaris operating systems. For information on disk space requirements for the Linux, and Solaris operating systems, see “Disk Space Requirements" in BRM Installation Guide.
If you plan to use AMM software for account migration, you must also install:
-
Java Development Kit
Installing AMM
The instructions in this section assume that you have two BRM installation machines and two database schemas in your multischema environment as shown in Figure 4-1.
Installing AMM involves the following general steps:
Configuring All Primary and Secondary Database Schemas
Before you can install AMM, you must configure your primary and secondary database schemas for account migration.
First, ensure that you assigned unique database instance names to each schema in your system:
-
Open the tnsnames.ora file in a text editor.
-
If necessary, assign a unique database instance name to each schema. For example, for the first schema:
Alias1 = (DESCRIPTION = (ADDRESS = (PROTOCOL= TCP)(Host=DatabaseHost1Name)(Port= 1521)) (CONNECT_DATA = (SID = DatabaseSID1)) )
For the second schema:
Alias2 = (DESCRIPTION = (ADDRESS = (PROTOCOL= TCP)(Host=DatabaseHost2Name)(Port= 1521)) (CONNECT_DATA = (SID = DatabaseSID2)) )
-
Save and close the file.
Then perform the following steps on each database schema in your multischema system:
-
Using SQL*Plus, log in to the database schema as the SYSTEM user and grant database linking privileges to the BRM user pin:
% sqlplus system/password@databaseAlias SQL> grant create database link to pin; Grant succeeded.
-
Verify that JServer is installed on your system:
SQL> SELECT object_name, object_type FROM all_objects WHERE object_type = 'PACKAGE' and object_name = 'DBMS_JAVA';
If JServer is installed on your system, you receive the following:
OBJECT_NAME OBJECT_TYPE ------------------------ ----------- DBMS_JAVA PACKAGE
If JServer is not installed, you receive the following:
no rows selected
-
Install JServer if it is not already installed on your system:
-
Add the following entry to the Oracle initSID.ora file ($ORACLE_HOME/dbs/initSID.ora) for the schema's database instance:
java_pool_size=20971520
-
Restart Oracle so that the schema's database instance is initialized with your changes.
-
Install JServer manually by running the Oracle initjvm script:
% sqlplus sys/password@databaseAlias SQL> @$ORACLE_HOME/javavm/install/initjvm.sql
For information, see your Oracle documentation.
-
-
Modify the entries listed in Table 4-1 in the Oracle initSID.ora file ($ORACLE_HOME/dbs/initSID.ora) of the schema's database instance:
Table 4-1 initSID.ora Entries
Entry Description global_names
Specifies whether a database link is required to have the same name as the database schema to which it connects. Set this to False.
utl_file_dir
Specifies the location of the Oracle utl_file. Set this to a writable directory for the user oracle.
-
Restart Oracle so that the schema's database instance is initialized with your changes.
Installing the AMM Software on the Primary Installation Machine
Note:
If you already installed the product, you must uninstall its features before reinstalling them.
To install AMM, perform the following steps on the primary installation machine:
-
Install AMM. See “Installing Individual BRM Components" in BRM Installation Guide.
-
Verify that the BRM_home/setup/scripts/pin_multidb.conf file contains accurate information about each database schema in your system. The pin_amt_install script uses the information in this file to set up your AMM environment.
-
For optimal performance, store your AMM job management tables and indexes in their own physical tablespaces. Map the following entries to four separate physical tablespaces by modifying the BRM_home/setup/scripts/pin_tables.values file:
$PIN_CONF_TBLSPACE14 $PIN_CONF_TBLSPACE15 $PIN_CONF_TBLSPACEX16 $PIN_CONF_TBLSPACEX17
See "Database Configuration and Tuning" in BRM Installation Guide.
-
Log in as user pin, go to the BRM_home/setup/scripts directory, and run the pin_amt_install script:
# su - pin % cd BRM_home/setup/scripts % perl pin_amt_install.pl
-
Verify that installation was successful by checking the AMM installation log file (BRM_home/setup/scripts/pin_amt_install.log).
-
Restart the BRM server.
Configuring Your Oracle DM to Check for Invalid Objects
During account migration, the AMM software marks all migrated objects in the source database schema as invalid. To prevent BRM applications from accessing these objects, you must configure your Oracle Data Manager (DM) to check for invalid objects during account searches.
Note:
If you do not make this change, BRM applications retrieve duplicate data from your source and destination database schemas. For example, if an account is migrated from schema 0.0.0.1 to schema 0.0.0.2, the application retrieves the account object from both schemas.
To configure your system to check for invalid objects, perform the following on every machine containing an Oracle DM:
-
Add the following line to the BRM_home/sys/dm_oracle/pin.conf file:
- dm dm_nul_poid_db_chk 1
-
Restart dm_oracle so that your Oracle DM is initialized with your changes.
Connecting AMM to Your Database Schemas
During installation, the Installer stores the configuration data, such as the database schema connection details and the number and configuration of your AMM Controllers, in the Oracle wallet. AMM retrieves the data from the Oracle wallet. However, if the configuration entries are also stored in the AMM Infranet.properties file, AMM retrieves the data from the AMM Infranet.properties file. Use the Oracle wallet to provide the information necessary for AMM, such as passwords, to access the data for the accounts in your system.
For more information viewing and storing the configuration entries in the Oracle wallet, see the “About the Oracle Wallet" section in BRM System Administrator's Guide.
Configuring Database and AMM Mover Information for Multischema Systems
Verify that the AMM Infranet.properties file contains a set of 0.0.0.x entries for each database schema in your system. For example, if you have three database schemas in your system, the file should contain a set of entries prefixed by 0.0.0.1, a set prefixed by 0.0.0.2, and a set prefixed by 0.0.0.3. Also, update the BRM wallet in the primary schema to include the user passwords for all the secondary schemas. Example 4-1 shows the entries for a system with two database schemas.
Verify that the Infranet.properties file contains information on the AMM Mover associated with each database schema. If a schema contains more than one AMM Mover, make sure to update the Infranet.properties file accordingly.
Example 4-1 Example Configuration Information for Multischema Systems
# # primary database schema # 0.0.0.1_user_name=pin57204 0.0.0.1_instance_name=futt11 0.0.0.1_primary=true # AMT mover 0.0.0.1_mover_log_file_dir=unknown 0.0.0.1_mover_log_file_flag=N 0.0.0.1_grp_srch_log_file_dir=unknown 0.0.0.1_grp_srch_log_file_flag=N # # secondary database schema # 0.0.0.2_user_name=pin57204m2 0.0.0.2_instance_name=futt11m2 0.0.0.2_primary=false # AMT mover 0.0.0.2_mover_log_file_dir=unknown 0.0.0.2_mover_log_file_flag=N 0.0.0.2_grp_srch_log_file_dir=unknown 0.0.0.2_grp_srch_log_file_flag=N #
Configuring AMM Controller Definitions
The installer creates a set of Controller_1 entries for setting up one AMM Controller in the AMM Infranet.properties file and populates them with default values, as shown in Example 4-2.
Example 4-2 AMM Controller Definitions
# controller definitions # controller_1_log_directory=/export/BRM_home/apps/amt controller_1_port_number=18566 controller_1_server=slc00qhm controller_1_thread_count=2 controller_1_syslog_priority=7 controller_1_event_generation=false controller_1_concurrent_job_number=20 controller_1_hold_period=120 controller_1_amt_queue_owner_name=pinq controller_1_amt_queue_name=ifw_sync_queue_amt #
Access the Oracle wallet and verify that the entries are as required.
If you require more than one AMM Controller, determine the optimal number of AMM Controllers for your system. Make sure that you provide the optimal number of threads for each AMM Controller in your system. See "About Using Multiple AMM Controllers" for more information.
For the additional controllers, create a set of Controller_2 entries, Controller_3 entries, and so on in the Infranet.properties file.
Specifying Schema Alias Information for Multischema Systems
When you use multischema systems, the database layer of your BRM system consists of one primary schema and one or more secondary schemas in a single database. As a result, the schema alias is the same for both schemas.
Access the Oracle wallet and enter an alias for the secondary schema in the file.
Example 4-3 shows the entries for a multischema system:
Example 4-3 Example Alias Information for Multischema System
# # Connection entries for the Primary Database Schema 0.0.0.1_user_name=pin 0.0.0.1_instance_name=Schema1Alias 0.0.0.1_primary=true 0.0.0.1_mover_log_file_dir=./mover/log 0.0.0.1_mover_log_file_flag=y # Connection entries for the Secondary Database Schema 0.0.0.2_user_name=pin 0.0.0.2_instance_name=Schema2Alias 0.0.0.2_primary=false 0.0.0.2_mover_log_file_dir=./mover/log 0.0.0.2_mover_log_file_flag=y
AMM Infranet.properties File Parameters
Table 4-2 shows the parameters used in defining the AMM Infranet.properties file.
Table 4-2 AMM Infranet.properties Values
Entry | Value | Description |
---|---|---|
0.0.0.x_user_name |
String |
Specifies the Oracle user name for the specified database schema. |
0.0.0.x_instance_name |
String |
Specifies the SQL*Net database alias name you assigned in the tnsnames.ora file. |
0.0.0.x_primary |
true or false |
Flag that indicates whether the database schema is the primary schema. For the primary schema, set this to true. For all secondary schemas, set this to false. |
0.0.0.x_mover_log_file_dir |
Path name |
Specifies the directory of the AMM Mover log file on the specified database schema. Important: This path must match the path specified in the utl_file_dir entry of the initSID.ora file. |
0.0.0.x_mover_log_file_flag |
Y or N |
Specifies whether you want the AMM Mover to create log files on the specified database schema. |
0.0.0.x_grp_srch_log_file_flag |
Y or N |
Specifies whether you want AMM to create a log file for the account group stored procedure. Note: The stored procedure finds all account group members related to a specific account. |
0.0.0.x_grp_srch_log_file_dir |
Path name |
Specifies the directory for the account group stored procedure log file. |
controller_N_log_directory |
Path name |
Specifies the directory in which to create the AMM Controller log file. |
controller_N_port_number |
Integer > 1024 |
Specifies the TCP/IP port number for the connection between the pin_amt utility and the AMM Controller. Each AMM Controller instance requires a unique port number. |
controller_N_server |
String |
Specifies the host name of the machine that runs the AMM Controller. |
controller_N_thread_count |
Positive integer |
Specifies the number of AMM Controller processing threads. For optimal performance, the number of AMM Controller threads should be 1 to 2 times the number of CPUs on the destination schema that are dedicated to AMM. |
controller_N_syslog_priority |
1 (low) through 7 (high) |
AMM Controller log message priority threshold. Messages with a lower priority are suppressed. |
pin_amt_log_directory |
Path name |
Specifies the path to the pin_amt log file. |
controller_N_event_generation |
true or false |
Specifies whether the AMM Controller migrates accounts when ECE is running. This configures AMM to notify ECE when accounts are migrated. The default is false. |
controller_N_concurrent_job_number |
Positive integer |
Specifies how many jobs the AMM Controller starts concurrently. The default is 20. Note: This entry is required only if the controller_N_event_generation entry is set to Y. |
controller_N_hold_period |
Positive integer |
Specifies how long the AMM Controller waits, in minutes, before it starts to migrate accounts. This provides time for your ECE to process any events targeted for accounts that are being migrated. The default is 120. Note: This entry is required only if the controller_N_event_generation entry is set to Y. |
controller_N_amt_queue_owner_name |
String |
Specifies the user that created the acknowledgment queue. Note: This entry is required only if the controller_N_event_generation entry is set to Y. |
controller_N_amt_queue_name |
String |
Specifies the name of the acknowledgment queue. The AMM Controller dequeues ECE acknowledgment events from this queue. Note: This entry is required only if the controller_N_event_generation entry is set to Y. |
infranet.login.type |
1 or 0 |
Specifies whether AMM requires a user name and password to log in to the Connection Manager (CM).
Note: This entry is required only if the controller_N_event_generation entry is set to Y. |
publish_migrated_objects |
String |
Specifies the storable classes whose objects are stored in the MIGRATED_OBJECTS_T cross-reference table. You can list multiple storable classes by using a comma (,) as a delimiter. For example: /service,/billinfo,/payinfo. Note: This entry is required only if you integrate AMM with your external application using Oracle Application Integration Architecture (Oracle AIA) in a multischema environment. |
Configuring AMM for Additional Database Schemas
You must reconfigure the AMM software whenever you add a database schema to an existing multischema system.
To configure AMM for additional database schemas, perform the following procedure on the primary installation machine:
-
Delete all existing account migration jobs in the queue:
% pin_amt -d JobID
-
Log in as user pin and run the pin_amt_install.pl script:
# su - pin % cd BRM_home/setup/scripts % perl pin_amt_install.pl
This script reinstalls the job management tables on your database schemas.
Configuring AMM for New Custom Tables
AMM migrates data to and from the tables listed in the AMM data dictionary. This list includes all BRM tables and any custom tables that were on your system when you installed AMM. If you add any tables after you install AMM, you must update the AMM data dictionary.
To update the AMM data dictionary, perform the following on your primary installation machine:
-
Log in as user pin and go to the BRM_home/setup/scripts directory:
% su - pin % cd BRM_home/setup/scripts
-
Run the pin_amt_install.pl script with the -m parameter:
% perl pin_amt_install.pl -m
This script updates the AMM data dictionary tables (AMT_META_DATA_T and AMT_POID_TYPE_MAP_T) on all database schemas in your system.
Tuning Your Database for Optimal Account Migration Performance
To tune your database for optimal account migration performance:
-
Use cost-based optimization.
-
Set the number of Oracle rollback segments to approximately two times the number of AMM Controller threads. Multiple rollback segments enable Oracle to automatically allocate one rollback segment for each transaction.
-
Set the transactions_per_rollback_segment parameter in the $ORACLE_HOME/dbs/initSID.ora file to a small number. For best results, set it to 1 or 2.
-
Set the initial size for the rollback segment to twice the total data volume of the account batch. You can estimate the account batch data volume by multiplying the average number of events per batch with the batch size.
Note:
Use the EVENT_T and major child tables, such as EVENT_BAL_IMPACTS_T, to determine the average number of events per batch. Typically, 90% of the account batch data volume can be attributed to event data.
-
Set the optimal size for the rollback segments to twice the initial size.
-
Set the next size for the rollback segments to half the initial size.
-
Set the maximum number of extends to unlimited.
For more information, see your Oracle documentation. For information on additional ways to tune your database for AMM, contact your Oracle BRM representative.