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

• Installing AMM

• Configuring AMM for Additional Database Schemas

• Configuring AMM for New Custom Tables

• Tuning Your Database for Optimal Account Migration Performance

System Requirements

The system requirements for account migration consists of the following:

• General Software Requirements

• Software Requirements for Account Migration Manager

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.

Figure 4-1 Installing AMM

Description of "Figure 4-1 Installing AMM"

Installing AMM involves the following general steps:

1. Configuring All Primary and Secondary Database Schemas

2. Installing the AMM Software on the Primary Installation Machine

3. Configuring Your Oracle DM to Check for Invalid Objects

4. Connecting AMM to Your Database Schemas

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:

1. Open the tnsnames.ora file in a text editor.

2. 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)) )

3. Save and close the file.

Then perform the following steps on each database schema in your multischema system:

1. 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.

2. 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

3. Install JServer if it is not already installed on your system:

   1. 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

   2. Restart Oracle so that the schema's database instance is initialized with your changes.

   3. 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.

4. 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.

5. 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:

1. Install AMM. See “Installing Individual BRM Components" in BRM Installation Guide.

2. 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.

3. 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.

4. 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

5. Verify that installation was successful by checking the AMM installation log file (BRM_home/setup/scripts/pin_amt_install.log).

6. 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:

1. Add the following line to the BRM_home/sys/dm_oracle/pin.conf file:

   - dm dm_nul_poid_db_chk 1

2. 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). 1 specifies that AMM must provide a user name and password. 0 specifies that AMM uses a “trusted" login that comes through a CM Proxy, for example, and does not require a user name and password in the properties file. 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:

1. Delete all existing account migration jobs in the queue:

   % pin_amt -d JobID

2. 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:

1. Log in as user pin and go to the BRM_home/setup/scripts directory:

   % su - pin
   % cd BRM_home/setup/scripts

2. 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.