33 Installing and Configuring BRM for Account Migration

This chapter explains how to install and configure software required for account migration with the Oracle Billing and Revenue Management (BRM).

Before you read this chapter, you should be familiar with BRM, multischema, and Account Migration Manager (AMM) concepts and architecture. See the following topics:

System Requirements

The system requirements for account migration consists of the following:

General Software Requirements

Before installing AMM, you must install:

Pipeline Manager Requirements

If you plan to migrate accounts when the Pipeline Manager is running, you must also install the following BRM software:

Software Requirements for Oracle IMDB Data Manager

If you have installed Oracle IMDB Data Manager, you must install:

  • Oracle TimesTen 32-bit client software required to run the pin_amt utility:

    • TimesTen 11.2.2.3.0 client (compatible with Oracle TimesTen In-Memory Database and Oracle In-Memory Database Cache 11g Release 2)

    • TimesTen 11.2.1.9.0 client (compatible with Oracle TimesTen In-Memory Database and Oracle In-Memory Database Cache 11g Release 1)

    For information on installing Oracle TimesTen 32-bit client software, see Oracle TimesTen In-Memory Database Installation Guide.

  • Oracle TimesTen 64-bit client software required to run the pin_amt_tt utility:

    • TimesTen 11.2.2.3.0 client (compatible with Oracle TimesTen In-Memory Database and Oracle In-Memory Database Cache 11g Release 2)

    • TimesTen 11.2.1.9.0 client (compatible with Oracle TimesTen In-Memory Database and Oracle In-Memory Database Cache 11g Release 1)

    For information on installing Oracle TimesTen 64-bit client software, see Oracle TimesTen In-Memory Database Installation Guide.

Software Requirements for Account Migration Manager

AMM is available for Oracle databases and the HP-UX IA64, Linux, AIX, and Solaris operating systems. For information on disk space requirements for these 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 (JDK 6)

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

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

  5. Configuring the TimesTen JDBC Driver Jar file for BRM

  6. Configuring the load_pin_uniqueness Utility for Oracle IMDB Cache

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=DatabaseHostName)(Port= 1521)) 
(CONNECT_DATA = (SID =DatabaseSID)) )

    For the second schema:

    Alias2 = (DESCRIPTION =  (ADDRESS = (PROTOCOL= TCP)(Host=DatabaseHostName)(Port= 1521)) (CONNECT_DATA = (SID =DatabaseSID)) )

  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/manager@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) of 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/change_on_install@databaseAlias
SQL> @$ORACLE_HOME/javavm/install/initjvm.sql

      For information, see your Oracle documentation.

  4. Modify the entries listed in Table 33-1 in the Oracle initSID.ora file ($ORACLE_HOME/dbs/initSID.ora) of the schema's database instance:

    Table 33-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 have already installed the product, features that are already installed cannot be reinstalled without uninstalling them first. To reinstall a feature, uninstall it and then install it again.

To install AMM, perform the following steps on the primary installation machine:

  1. Log in as user pin and make sure the following environment variables listed in Table 33-2 are set correctly in the .cshrc or .profile file:

    Table 33-2 AMM Environment Variables

    Environment Variable Description

    PATH

    Make sure this includes the path to SQL*Plus and Xterm.

    DISPLAY

    Set this to WorkstationName:0.0.

    Note: You must set this variable to have the AMM software open an Xterm window that displays the AMM Controller's status in real time.

    PIN_HOME

    Specifies the directory where BRM is installed. The default is /opt/portal/7.5.

    ORACLE_HOME

    Specifies the directory where Oracle is installed.

  2. Download the software to a temporary directory (temp_dir).

    Important:

    • If you download to a Windows workstation, use FTP to copy the .bin file to a temporary directory on your UNIX server.

    • You must increase the heap size used by the Java Virtual Machine (JVM) before running the installation program to avoid ”Out of Memory” error messages in the log file. See "Increasing Heap Size to Avoid 'Out of Memory' Error Messages" in BRM Installation Guide.

  3. Go to the directory where you installed the Third-Party package and source the source.me file.

    Caution:

    You must source the source.me file to proceed with installation, otherwise ”suitable JVM not found” and other error messages appear.

    Bash shell:

    source source.me.sh

    C shell:

    source source.me.csh

  4. Go to the temp_dir directory and enter this command:

    7.5.0_AccountMigrationMgr_platform_32_opt.bin

    where platform is the operating system name.

    Note:

    You can use the -console parameter to run the installation in command-line mode. To enable a graphical user interface (GUI) installation, install a GUI application such as X Windows and set the DISPLAY environment variable before you install the software.

  5. Follow the instructions displayed during installation. The default installation directory for AMM is opt/portal/7.5.

    Note:

    The installation program does not prompt you for the installation directory if BRM or AMM is already installed on the machine and automatically installs the package at the BRM_home location.

  6. Go to the directory where you installed the AMM package and source the source.me file:

    Bash shell:

    source source.me.sh

    C shell:

    source source.me.csh

  7. Go to the BRM_home/setup directory and run the pin_setup script.

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

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

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

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

  12. Restart your BRM processes. For information, see "Starting and Stopping the BRM System".

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.

Caution:

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. See "Starting and Stopping the BRM System".

Connecting AMM to Your Database Schemas

During installation, the AMM installer generates an Infranet.properties configuration file that specifies how to connect to your database schemas and the number and configuration of your AMM Controllers. The installer populates the connection parameters in the Infranet.properties file with values from your multischema pin_multidb.conf file and provides default values for setting up one AMM Controller. Use the Infranet.properties file to provide the information necessary for AMM to access the data for the accounts in your system.

Configuring the AMM Infranet.properties File

To configure the AMM Infranet.properties file, perform the following on the primary installation machine:

  1. Go to the BRM_home/sys/amt directory and open the Infranet.properties file in a text editor. BRM_home is the directory in which you installed BRM components.

    Note:

    The content of the Infranet.properties file conforms to the Java properties file conventions. Options are key-value pairs separated by the equal sign (=). For example, 0.0.0.1_user_name=pin and 0.0.0.1_primary=true.

  2. Verify that the configuration entries reflect your environment. When checking the Infranet.properties file, make sure it contains the following:

  3. Save and close the file.

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. Example 33-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 33-1 Example Configuration Information for Multischema Systems

#
# primary database schema
#
0.0.0.1_user_name=pin57204
0.0.0.1_user_password=&aes|08|0D5E11BFDD97D2769D9B0DBFBD1BBF7EED4E2DD0A43B0DE9BBE19D80ECB2FCF27A
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_user_password=&aes|10|0D5E11BFDD97D2769D9B0DBFBD1BBF7EE481DCC10889074E6ADE3DC873FEA13819
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 33-2.

Example 33-2 AMM Controller Definitions

# controller definitions
#
controller_1_log_directory=/export/pin7204/opt/portal/7.5/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 Infranet.properties file 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 AMM Infranet.properties file and enter an alias for the secondary schema in the file.

Example 33-3 shows the entries for a multischema system:

Example 33-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_user_password=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_user_password=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

Enabling the Unloading of Cache Groups from the Source Oracle IMDB Cache

This verification is necessary if you use Oracle IMDB Cache Manager in your system.

Verify that the timesten_enabled parameter is set to true in the AMM Infranet.properties file as shown below:

#Parameter to indicate if timesten is used or not.
timesten_enabled=true

This setting enables the pin_amt utility to unload the cache groups associated with accounts selected for migration from the source Oracle IMDB Cache.

Specifying Access Information for the Source Oracle IMDB Cache

If you use an Oracle IMDB Cache Manager, specify the access parameter for the source Oracle IMDB Cache. If the accounts are migrating from more than one Oracle IMDB Cache, make sure you specify the access parameter values for each source Oracle IMDB Cache involved in the migration.

The AMM Infranet.properties file must contain valid entries for each of the following parameters:

  • timesten_node_<Node Index>_user

  • timesten_node_<Node Index>_pwd

  • timesten_node_<Node Index>_dsn

  • timesten_node_<Node Index>_db_id

where <Node Index> identifies the logical partition where the accounts currently reside. Table 33-3 provides a description of the parameters.

Example 33-4 shows the access parameters defined when accounts are migrating from two logical partitions in a cache grid.

Example 33-4 Access Parameter Definitions for Two Logical Partitions

timesten_node_1_user=pin57204
timesten_node_1_pwd=pin57204
timesten_node_1_dsn=tt_lp1
timesten_node_1_db_id=0.0.0.1
 
 
timesten_node_2_user=pin57204
timesten_node_2_pwd=pin57204
timesten_node_2_dsn=tt_lp2
timesten_node_2_db_id=0.1.0.1

AMM Infranet.properties File Parameters

Table 33-3 shows the parameters used in defining the AMM Infranet.properties file.

Table 33-3 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_user_password

String

Specifies the Oracle user password 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 your pipelines are running. This configures AMM to notify Pipeline Manager 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 pipelines to flush any EDRs 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 pipeline 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.

infranet.connection

String

Specifies the full URL for connecting to the primary CM.

  • For a type 1 login, the URL must include a user name and password. You must specify the service name and service POID (”1”), but the CM determines the database number. For example:

    pcp://root.0.0.0.1:password@hostname:12009/service/pcm_client

  • For a type 0 login, the URL requires a full POID, including the database number.

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.

timesten_enabled

true or false

Specifies whether Oracle IMDB Cache is used in the system. When set to true, account migration involves unloading and loading of cache groups from the cache grid before and after migration of accounts.

The default is false.

timesten_node_ <Node Index>_db_id

String

The database number for the logical partition of the Oracle IMDB Cache grid.

timesten_node_ <Node Index>_dsn

String

The data store name for the logical partition of the Oracle IMDB Cache grid.

timesten_node_ <Node Index>_user

String

The user name required to log in to the data store associated with the logical partition of the Oracle IMDB Cache grid.

timesten_node_ <Node Index>_pwd

String

The password required to log in to the data store associated with the logical partition of the Oracle IMDB Cache grid.

Sample Infranet.properties File

The following sample Infranet.properties file is for a system with the following components:

  • Two database schemas, each with an AMM Mover

  • One AMM Controller

  • Pipeline migration enabled

  • Oracle IMDB Cache enabled, two logical partitions in the cache grid, access information for the cache

Example 33-5 Sample Infranet.properties File

#
# primary database schema
#
0.0.0.1_user_name=pin57204
0.0.0.1_user_password=&aes|08|0D5E11BFDD97D2769D9B0DBFBD1BBF7EED4E2DD0A43B0DE9BBE19D80ECB2FCF27A
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_user_password=&aes|10|0D5E11BFDD97D2769D9B0DBFBD1BBF7EE481DCC10889074E6ADE3DC873FEA13819
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
#
# controller definitions
#
controller_1_log_directory=/export/pin7204/opt/portal/7.5/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
#
# pin_amt definitions
#
pin_amt_log_directory=/export/pin7204/opt/portal/7.5/apps/amt
#
# CM connection properties
#        connect string in the format
#        infranet.connection=pcp://LOGIN:PASSWORD@HOSTNAME:PORT/service/pcm_client
#     infranet.login.type=1
#
infranet.connection=pcp://root.0.0.0.1:&aes|08|0D5E11BFDD97D2769D9B0DBFBD1BBF7E5D40C305EDF3D77DF111AAB8F781E92122@slc00qhm:12204/service/pcm_client
infranet.login.type=1
 
 
#
# timesten configuration
#
 
#Parameter to indicate if timesten is used or not.
timesten_enabled=true
 
 
#Parameter to indicate the PIN HOME of target node.
target_pin_home=/export/pin7204/opt/portal/7.5
 
# The next set of parameters are for the credentials of timesten 
# datastores on the source side that would be involved in migration.
# The next 4 parameters need to be replicated for each data stores incrementing the number in the parameter name 
#
# DataStore USER, PASSWORD, DataStore Name, Database ID for the data store
#
 
 
oracle_db_pwd=pin57204
 
 
timesten_node_1_user=pin57204
timesten_node_1_pwd=pin57204
timesten_node_1_dsn=tt_lp1
timesten_node_1_db_id=0.0.0.1
 
 
timesten_node_2_user=pin57204
timesten_node_2_pwd=pin57204
timesten_node_2_dsn=tt_lp2
timesten_node_2_db_id=0.1.0.1

Configuring the TimesTen JDBC Driver Jar file for BRM

Complete this step if you use Oracle IMDB cache in your system. If you have more than one instance of BRM, you must complete this step for each instance.

To configure the TimesTen JDBC Driver Jar file for BRM:

  1. Go to the BRM_home/apps/amt directory.

  2. Copy the ttjdbc6.jar file from the TimesTen32_home/lib directory, where TimesTen32_home is the directory in which you installed the 32-bit TimesTen client application.

Configuring the load_pin_uniqueness Utility for Oracle IMDB Cache

To verify/configure the load_pin_uniqueness utility for migrating account data:

  1. Open the load_pin_uniqueness utility configuration file (BRM_home/apps/multi_db/pin.conf) in a text editor.

  2. Verify that the following is_timesten entry is present. Add the entry, if necessary:

    - load_pin_uniqueness is_timesten 1

  3. Verify that the following per_schema_node_info entry is present. Add the entry, if necessary.

    - 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

  4. Save and close the file.

What's Next?

AMM installation is now complete.

To migrate accounts while the Pipeline Manager is online, you must perform additional configuration steps. See "Configuring Your System to Migrate Accounts When the Pipeline Manager Is Running".

If your system does not use batch rating or you plan to shut down Pipeline Manager during account migration, you can begin migrating accounts. See "Using Account Migration Manager".

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.

    Tip:

    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.