1. System Administrator's Guide
  2. Managing a Multischema System
  3. Managing a Multischema System

48 Managing a Multischema System

Learn how to manage an Oracle Communications Billing and Revenue Management (BRM) multischema system.

Topics in this document:

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

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.

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.

  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 and Configuring Multidatabase Manager on the Primary Installation Machine" in BRM Installation Guide.

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

    Note:

    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.

  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 "Using testnap to Verify Access to Your 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 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 a 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 or sponsoring 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.

Note:

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" ;
SCHEMA_NAME = "pin111x" ;
  
DB_NO = "0.0.0.2" ;             # 2nd database config. block
PRIORITY = 3;
MAX_ACCOUNT_SIZE = 50000 ;
STATUS = "OPEN" ;
SCHEMA_NAME = "pin112x" ;

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

    Note:

    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 with nonpaying child units in the same schema as their paying parent bill units

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

Note:

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.

Note:

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" ;
SCHEMA_NAME = "pin111x" ;
  
DB_NO = "0.0.0.2" ;             # 2nd database config. block
PRIORITY = 3;
MAX_ACCOUNT_SIZE = 50000 ;
STATUS = "OPEN" ;
SCHEMA_NAME = "pin112x" ;
  
DB_NO = "0.0.0.3" ;             # 3rd database config. block
PRIORITY = 5; 
MAX_ACCOUNT_SIZE = 50000 ; 
STATUS = "CLOSED" ; 
SCHEMA_NAME = "pin113x" ;

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

  6. Stop and restart all CMs.

    Note:

    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.

  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.

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

Changing the Interval for Checking New Accounts

When a multischema system is installed, a time interval is set to check for new accounts in the login table and to verify that the accounts were fully created.

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_confirm_logins utility in minutes: 

    - pin_confirm_logins     frequency     10

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

    See "pin_confirm_logins" for information about the utility.

  3. Save and close the file.

  4. Restart pin_confirm_logins.

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: