30 Managing a Multischema System

This chapter provides guidelines to help you manage an Oracle Communications Billing and Revenue Management (BRM) multischema system.

Before you read this chapter, you should be familiar with how BRM works. See "BRM System Architecture" in BRM Concepts.

For more information about monitoring and maintaining a BRM system, see "Monitoring and Maintaining Your BRM System".

Important:

Multischema functionality is an optional component, not part of base BRM. For information on installing a multischema system, see "Installing a Multischema System" in BRM Installation Guide.

About Multischema Systems

Multidatabase Manager is an optional feature that supports multiple database schemas in a single BRM installation. A multischema system lets you distribute your customer accounts among several schemas, providing increased storage capacity. For an overview, see "A BRM Multischema Production System" in BRM Installation Guide.

You can run billing and invoicing utilities against each schema. For more information, see "Setting Up Billing to Run in a Multischema Environment" in BRM Configuring and Running Billing and "Configuring the Invoice pin.conf for Multiple Database Schemas" in BRM Designing and Generating Invoices.

The following are the main administrative tasks for a multischema system:

Using Pipeline Manager with Multiple Database Schemas

When you use Multidatabase Manager, you run an instance of Pipeline Manager for each BRM database schema. The following types of data must be managed:

  • Account data: When account data changes in a database, the Account Synchronization Data Manager (DM) sends the data to Pipeline Manager. The DAT_Listener module map file specifies which Pipeline Manager instance the data is sent to.

  • CDR data: Before a call details record (CDR) file is processed, the Pipeline Manager FCT_AccountRouter module separates CDRs by BRM database schemas and sends the CDRs to the appropriate Pipeline Manager instance.

Figure 30-1 shows how FCT_AccountRouter manages incoming CDRs:

Figure 30-1 FCT_AccountRouter CDR Management

Description of Figure 30-1 follows
Description of ''Figure 30-1 FCT_AccountRouter CDR Management''

Converting a Single-Schema System to a Multischema System

To convert a single-schema system to a multischema system, see "Installing a Multischema System" in BRM Installation Guide.

Note:

For multischema systems, Oracle recommends installing the BRM database in an Oracle Real Application Clusters (Oracle RAC) system.

Preparing to Manage a Multischema System

Before working with your multischema system, verify that the PERL5LIB environment variable is a system variable and contains BRM_home/perl/lib/5.8.0.

Adding a BRM Installation Machine to a Multischema Environment

If you already have a multischema system configured and you want to configure an additional BRM installation machine to run a CM in a multischema environment:

  1. Download and install the Third-Party software package on the new machine.

    See "Installing the Third-Party Software" in BRM Installation Guide.

  2. Download and install the BRM software on the new machine.

    See "Installing BRM on a Secondary Installation Machine" in BRM Installation Guide.

  3. Download and install Multidatabase Manager on the new machine.

    Caution:

    Do not run the pin_multidb.pl script, which reconfigures your entire multischema system.

    See "Installing Multidatabase Manager on the Primary Installation Machine" in BRM Installation Guide.

  4. Configure the BRM software by editing the pin_setup.values file.

    Important:

    In the pin_setup.values file, make sure that the following database parameters are set up correctly: 
    $SETUP_DROP_ALL_TABLES = "No"; 
$SETUP_INIT_DB = "No";

  5. Run the pin_setup script.

Adding Database Schemas to a Multischema System

To add one or more database schemas to a multischema system:

  1. Add a schema to your Oracle RAC system.

    For more information, see the following:

  2. Download and install the Third-Party software package on a new secondary installation machine.

    See "Installing the Third-Party Software" in BRM Installation Guide.

  3. Install BRM on the new secondary installation machine.

    See "Installing BRM on a Secondary Installation Machine" in BRM Installation Guide.

  4. Verify that the new secondary installation machine can connect to the new database schema.

    See "Verifying Access between Secondary Installation Machine and Secondary Schemas" in BRM Installation Guide.

  5. Configure the pin_multidb.conf file on the primary installation machine for the new schema.

    See "Configuring the pin_multidb.conf File on the Primary Installation Machine".

  6. Run the pin_multidb.pl script on the primary installation machine.

    See "Running pin_multidb.pl on the Primary Installation Machine" in BRM Installation Guide.

    Note:

    During this procedure, when you run pin_multidb.pl -i, you are prompted to configure the Oracle DM on the new secondary installation machine to use schema qualifications. For more information, see "Setting Up Schema Qualifications" in BRM Installation Guide.

Configuring the pin_multidb.conf File on the Primary Installation Machine

To configure the new secondary database schema, perform the following procedure on the primary installation machine:

  1. Open the BRM_home/setup/scripts/pin_multidb.conf file in a text editor.

  2. Modify the following parameters to indicate which database schema instances you are adding to the system.

    • $PIN_MD_SECONDARY_START_INST

    • $PIN_MD_SECONDARY_END_INST

    For example, if your system contains three secondary database schemas (0, 1, and 2) and you are adding two schemas, set $PIN_MD_SECONDARY_START_INST to 3 and $PIN_MD_SECONDARY_END_INST to 4. That tells the pin_multidb.pl script to configure secondary database schemas based only on $PIN_MD_SECONDARY*[x] arrays 3 and 4 and to ignore arrays 0, 1, and 2:

    $PIN_MD_SECONDARY_START_INST    = "3";
$PIN_MD_SECONDARY_END_INST      = "4";

  3. Modify the following entries for each new schema, making sure you do the following:

    • Create a set of $PIN_MD_SECONDARY*[x] entries for each schema you add to the system.

    • Update the array number (x) to the appropriate value.

    • Update the database number for the secondary database schema.

    • Update the secondary database schema alias.

    • Update the host name of the secondary DM machine.

    • Update the DM port number for the secondary database schema.

                                        #-------------------------
                                    # Secondary db information
                                    #-------------------------
$PIN_MD_SECONDARY_DBNO     [0] = "0.0.0.3";
$PIN_MD_SECONDARY_OWNER    [0] = "pin";
$PIN_MD_SECONDARY_PASSWD   [0] = "pin";
$PIN_MD_SECONDARY_DBNAME   [0] = "pindbhostname";
$PIN_MD_SECONDARY_HOSTNAME [0] = "server3";
$PIN_MD_SECONDARY_PORT     [0] = "11952";       # dm port 
                                    #-------------------------
                                    # Secondary db information
                                    #-------------------------
$PIN_MD_SECONDARY_DBNO     [1] = "0.0.0.4";
$PIN_MD_SECONDARY_OWNER    [1] = "pin";
$PIN_MD_SECONDARY_PASSWD   [1] = "pin";
$PIN_MD_SECONDARY_DBNAME   [1] = "pindbhostname";
$PIN_MD_SECONDARY_HOSTNAME [1] = "server4";
$PIN_MD_SECONDARY_PORT     [1] = "11953";       # dm port

  4. Save and close the file.

Setting Database Schema Status

Database schema status determines whether a schema is available for account creation. Schemas can be set to open, closed, or unavailable:

  • Open: Open schemas are available for account creation.

  • Closed: Closed schemas are not used for account creation under most circumstances. Accounts are created in a closed schema only if an account's parent, branded, or sponsoring account belongs to that schema or if all schemas are closed. If all schemas are closed, Multidatabase Manager chooses a closed schema at random in which to create accounts and continues to create accounts in that schema until a schema becomes open. To limit the number of accounts created in a schema, you can manually change the schema's status to closed, or you can have Multidatabase Manager automatically change it to closed when the schema reaches a predefined limit.

  • Unavailable: Unavailable schemas are not used for account creation unless the schema contains an account's parent, sponsoring, or branded account.

To change a schema's status, 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.

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.

To change a schema's status, perform the following on the primary installation machine:

  1. Go to the BRM_home/apps/multi_db directory and open the config_dist.conf file.

  2. Change the values in the STATUS entries:

    Note:

    If your system contains multiple secondary database schemas, create a new set of entries for each secondary database schema.
    DB_NO = "0.0.0.1" ;             # 1st database config. block
PRIORITY = 1 ;
MAX_ACCOUNT_SIZE = 100000 ;
STATUS = "OPEN" ;
  
DB_NO = "0.0.0.2" ;             # 2nd database config. block
PRIORITY = 3;
MAX_ACCOUNT_SIZE = 50000 ;
STATUS = "OPEN" ;

  3. Save and close the file.

  4. Make sure the pin_config_distribution utility is not running.

    See "pin_config_distribution".

  5. From the BRM_home/apps/multi_db directory, run the load_config_dist utility.

    See "load_config_dist".

  6. Stop and restart all Connection Managers (CMs). See "Starting and Stopping the BRM System".

    Tip:

    To check how full your schemas are, see "Monitoring Database Space" in BRM Installation Guide.

Setting Database Schema Priorities

Database schema priority determines when customer accounts are created in a particular schema relative to other schemas. Multidatabase Manager assigns accounts to an open schema with the highest priority.

If all schemas have the same priority, Multidatabase Manager chooses an open schema at random in which to create the account. This distributes accounts evenly across all schemas. However, BRM locates accounts as follows:

  • All accounts of the same brand in the same schema

  • All nonpaying (subordinate) child accounts in the same schema as their parent accounts

  • All sponsored accounts in the same schema as their sponsoring accounts

To customize how schemas are selected, see "Creating Accounts in a Multischema System" in BRM Managing Customers.

Important:

To limit the number of accounts in your primary database schema, set your primary database schema to a lower priority than the secondary database schemas. Accounts will be created in the secondary database schemas when possible.

To change schema priorities, edit the PRIORITY 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.

Caution:

The load_config_dist utility overwrites all distributions already in the database. When adding or updating distributions, beware that you cannot load only new and changed distributions.

To change schema priorities, do the following on the primary installation machine:

  1. Go to the BRM_home/apps/multi_db directory, and open the config_dist.conf file.

  2. Edit the PRIORITY entries. In the following example, BRM creates accounts on schema 0.0.0.2 because it has the highest priority setting of all open schemas.

    Note:

    If your system contains multiple secondary database schemas, create a new set of entries for each secondary database schema.
    DB_NO = "0.0.0.1" ;             # 1st database config. block
PRIORITY = 1 ;
MAX_ACCOUNT_SIZE = 100000 ;
STATUS = "OPEN" ;
  
DB_NO = "0.0.0.2" ;             # 2nd database config. block
PRIORITY = 3;
MAX_ACCOUNT_SIZE = 50000 ;
STATUS = "OPEN" ;
  
DB_NO = "0.0.0.3" ;             # 3rd database config. block
PRIORITY = 5; 
MAX_ACCOUNT_SIZE = 50000 ; 
STATUS = "CLOSED" ;

  3. Save and close the file.

  4. Make sure the pin_config_distribution utility is not running.

    See "pin_config_distribution".

  5. From a command prompt, go to the BRM_home/apps/multi_db directory and run the load_config_dist utility.

    See "load_config_dist".

    Note:

    The load_config_dist utility requires a configuration file. See "Creating Configuration Files for BRM Utilities".

  6. Stop and restart all CMs. See "Starting and Stopping the BRM System".

    Tip:

    To check how full your schemas are, see "Monitoring Database Space" in BRM Installation Guide.

Creating Custom Tables That Are Available to All Database Schemas

You can create or modify custom tables after your multischema system is installed and configured.

To make those tables available to your secondary database schemas:

  1. Create or modify your custom table in the primary database schema by connecting to the CM on the primary installation machine.

  2. Name your table by using the following naming conventions:

    • CONFIG*

    • PLAN*

    • PRODUCT*

    • RATE*

    • UNIQUEN*

    • STRINGS*

    • CHANNEL*

    • SEARCH*

    • ZONE*_T

    • TOD*

    • FOLD*

  3. Run the pin_multidb.pl -i script as follows:

    1. Go to the BRM_home/setup/scripts directory, and run pin_multidb.pl -i:

      cd BRM_home/setup/scripts
perl pin_multidb.pl -i

    2. At the following prompt, enter y to begin configuration:

      Do you want to start the configuration now? (y/n):   y

    3. At the following prompt, enter 2 to initialize the primary database schema:

      Please enter the starting step (0-8). If you don't know, enter 0:   2

    4. Exit the pin_multidb.pl script.

  4. Run pin_multidb.pl -R to re-create all refresh groups in the secondary database schemas:

    cd BRM_home/setup/scripts
perl pin_multidb.pl -R group

    where group is the name of the group your table belongs to.

For more information, see "pin_multidb".

Synchronizing Database Schema Data Dictionaries

During normal multischema operations, the data dictionaries of the primary and secondary database schemas are updated automatically if you make the changes using the Storable Class Editor.

For information about adding, deleting, and modifying storable classes in the data dictionary, see "Creating Custom Fields and Storable Classes" in BRM Developer's Guide.

If there is a failure in making the changes to any of the secondary database schemas, the secondary database schema's data dictionary is in an inconsistent state with respect to the primary database schema. The failure is reported.

To synchronize the secondary database schema's data dictionary with the primary database schema's data dictionary, do the following on the primary installation machine:

  1. Go to the BRM_home/apps/multi_db directory, and open the pin.conf file.

  2. Verify all entries for the primary database schema.

  3. Go to the BRM_home/bin directory, and run the multi_db_synch_dd script.

    If an error occurs, the application reports it.

Synchronizing the Database Schema /uniqueness Objects

During normal multischema operations, the /uniqueness objects in the primary and secondary database schemas are updated automatically. BRM uses this object in a multischema environment to locate subscribers. It contains a cache of services and must stay synchronized with the service cache in the primary database schema.

Note:

To determine whether the /uniqueness object in a secondary database schema is out of synchronization, use sqlplus to compare the entries in the uniqueness_t database table with those in the service_t database table. There should be a one-to-one relationship.

If the database tables are not synchronized, run the load_pin_uniqueness utility on the secondary database schemas to update the /uniqueness object with the current service data (see "load_pin_uniqueness"). This utility overwrites existing /uniqueness objects in the schemas.

Note:

This utility needs a configuration (pin.conf) file in the directory from which you run the utility. For information about creating configuration files for BRM utilities, see "Creating Configuration Files for BRM Utilities".

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

  2. Make sure the pin_multidb utility is not running. See "pin_multidb".

    The pin_multidb utility calls the load_pin_uniqueness utility when you configure a multischema environment. Therefore, you must stop the pin_multidb utility before you run the load_pin_uniqueness utility.

  3. Use the following command to run the load_pin_uniqueness utility:

    load_pin_uniqueness

  4. Stop and restart the CM. See "Starting and Stopping the BRM System".

  5. Verify that the /uniqueness object was loaded by using one of the following to display the /uniqueness object:

Changing the Interval for Updating the Distribution Table

A time interval for updating the distribution table is originally set when the multischema system is installed. You can change the interval by running the pin_config_distribution utility on a different schedule. This utility governs the number of accounts in each schema.

To change the interval:

  1. Save a copy of BRM_home/apps/multi_db/pin.conf, and open the original file in a text editor.

  2. Set the desired frequency value for the pin_config_distribution utility in hours:

    - pin_config_distribution     frequency     10

    See the documentation in the pin.conf file for information about the frequency value.

    See "pin_config_distribution" for information about the utility.

  3. Save and close the file.

  4. Restart pin_config_distribution.

  5. Verify that the utility was successful by using one of the following to display the /config/distribution object: