1 Understanding Account Migration

Learn about account migration which is the process of transferring data associated with selected accounts from the source database schema to a destination schema. In Oracle Communications Billing and Revenue Management (BRM) you use Account Migration Manager (AMM) to migrate accounts.

Topics in this document:

• About Account Migration

• About the AMM Application

• AMM Process Overview

• About Distributed Transactions

• About Using Multiple AMM Controllers

• Account Migration Performance

About Account Migration

Account migration is the process of transferring data associated with selected accounts from the data's source database schema to a destination schema.

You use the AMM application to perform all account migration tasks. You provide information on the accounts to migrate and how to access the source and destination database schemas. See "About the AMM Application".

You migrate account objects to redistribute the data in the following situations:

• One BRM database schema contains significantly more or fewer accounts than other BRM database schemas (for example, when you add a schema to an existing multischema system).

• The number of events per account is significantly greater in one schema than another.

• The time it takes to complete a billing run becomes erratic.

You achieve optimal migration performance and the smallest impact on your operations if you schedule migrations for maintenance windows. If you need to migrate a large number of accounts, but your maintenance window is only a couple of hours, you can perform migrations over several days. The AMM software processes jobs in stages, enabling you to pause and resume account migration without affecting database integrity.

For information on scheduling migration, see "Automating Account Migration".

About the AMM Application

AMM is an application that migrates accounts and their associated objects from a source schema in a BRM database to a destination schema in the same database.

The AMM software migrates accounts based on the information you provide in the account search configuration file for that migration task. In this file, you specify a group of accounts to migrate based on specific criteria, such as account creation date or account status. The accounts and associated objects that meet these criteria form a job.

Jobs are processed by the AMM software through a queue system, with each job processed in the order received. To improve migration performance, AMM subdivides jobs into batches containing a configurable number of accounts.

Batches are assigned to a configurable number of threads, which process the batches in parallel. Each batch is migrated in a single distributed transaction, during which activity is prevented on the accounts in the batch. Depending on the success of the batch migration, changes to the database are either committed or rolled back.

The AMM software does not automatically remove migrated objects from the source database schema for performance reasons. Instead, it flags the migrated objects as invalid to prevent BRM applications from accessing them. You can use the AMM software to purge invalid objects from the database at any time.

AMM Process Overview

Figure 1-1 shows the AMM process overview.

Figure 1-1 AMM Process Overview

Description of "Figure 1-1 AMM Process Overview"

The account migration process can be divided into the following stages:

1. The account search configuration file containing information on the accounts to migrate and access information for the source and destination database schemas is provided as input to the pin_amt utility. See "About the Account Search Configuration File".

2. The pin_amt utility processes the account search configuration file.

3. Every account to be migrated is set up as an individual job. The jobs are divided into batches and placed in the queue. See "About the pin_amt Utility".

4. The AMM Controller allocates batches to threads and passes batches to the AMM Mover. See "About the AMM Controller".

5. The AMM Mover migrates the batch of accounts by moving the associated data from the source schema to the destination schema. See "About the AMM Mover".

About the Account Search Configuration File

The account search configuration file provides the details on which accounts to migrate, their source and destination storage locations, and the size of each batch.

You can also migrate accounts based on custom criteria. See "Creating Custom Account Search Criteria".

About the pin_amt Utility

The pin_amt utility is a standalone utility that generates account migration jobs for the AMM Controller to process. This utility can perform all its functions, such as finding accounts to migrate and submitting and enabling jobs, whether the AMM Controller is online or offline.

You use the pin_amt utility to perform the following tasks:

• Start, stop, resume, and monitor the AMM Controller

• Find all accounts in the source database schema that meet your search criteria

• Enable account migration jobs in the queue

• Delete jobs from the job management tables

• Purge invalid objects from the source schema

When you submit an account search configuration file, the pin_amt utility does the following:

1. Searches the source database schema for all accounts that meet the criteria in the account search configuration file, excluding all accounts that are part of hierarchical and sharing groups.

2. Divides the list of account POIDs into batches.

3. Populates the job management tables in the primary, source, and destination schemas with the list of account POIDs to migrate. See "AMM Job Management Tables".

4. Determines whether group migration is enabled.

   • If group migration is enabled, pin_amt proceeds with steps 5 through 10.

   • If group migration is disabled, the account search is complete. The AMM Controller can begin processing the job when the job is enabled in the queue. See "About the AMM Controller".

5. Searches all hierarchical accounts and sharing groups in the source schema for accounts that meet the search criteria.

6. Determines whether to search for and exclude accounts belonging to cross-schema sharing groups from migration.

   • When cross-schema sharing groups are disabled, pin_amt does not search for cross-schema sharing group members.

   • When cross-schema sharing groups are enabled, pin_amt finds accounts that are members of cross-schema sharing groups and excludes them from migration.

     Note:

     AMM performs a check on an account and only its immediate child account. Ensure you perform extra validation to ensure accounts picked by AMM are not part of a cross-schema sharing group.

7. When an account meets the search criteria, pin_amt finds all other accounts related to it and organizes them into an account group.

8. Determines whether the size of the account group exceeds the maximum. If it does, AMM excludes the account group from the job.

   Note:

   You specify the maximum size of an account group by using the account search configuration file. See "Creating the Account Search Configuration File".

9. Divides all members of one account group into batches. All batches in the group are assigned the same group ID and flagged as containing account group members.

10. Populates the job management tables in the primary, source, and destination schemas with the list of account POIDs to migrate. See "AMM Job Management Tables".

About the AMM Controller

The AMM Controller is a server process that checks the queue for jobs to process. By default, your system contains one AMM Controller, which processes one job at a time. For information about using multiple AMM Controllers, see "About Using Multiple AMM Controllers".

The AMM Controller processes group member and nongroup member batches in different ways:

• How AMM Controller Processes Batches with Nongroup Members

• How AMM Controller Processes Batches with Account Group Members

How AMM Controller Processes Batches with Nongroup Members

When processing batches that contain nongroup members, the AMM Controller does the following:

1. Assigns batches to threads, which run in parallel. Each thread processes one batch at a time. If there are more batches than threads, each thread must process multiple batches in sequence. You use a configuration file to configure the number of AMM Controller threads. See "Connecting AMM to Your Database Schemas".

2. Changes the batch status to IN_PROGRESS. See "About Batch Status Flags".

3. Passes the job ID, batch number, and schema qualifications to the AMM Mover on the destination database schema for processing. See "About the AMM Mover".

4. Determines whether the AMM Mover successfully migrated accounts.

   • If migration is successful, the AMM Controller commits the changes to all database schemas and changes the batch status to FINISHED. See "About Batch Status Flags".

   • If migration fails, the AMM Controller rolls back the changes and updates the batch status to FAILED. See "About Batch Status Flags".

How AMM Controller Processes Batches with Account Group Members

When processing batches that contain account group members, the AMM Controller does the following:

1. Changes the account group status to GROUP_DISABLING. See "About Group Status Flags".

2. Locks the appropriate base table records in the source database schema so that applications cannot access group member accounts during migration.

3. Marks all account group members in the source schema as invalid.

4. Determines whether all account group members were disabled in the source schema.

   • If all accounts were successfully disabled, the AMM Controller changes the account group status to GROUP_READY. See "About Group Status Flags".

   • If any accounts were not disabled, the AMM Controller changes the account group status to FAILED. See "About Group Status Flags".

5. Changes the account group status to GROUP_IN_PROGRESS.

6. Passes individual batches in the account group to the AMM Mover for processing.

   1. Assigns an individual batch in the group to a thread.

   2. Changes the batch status to IN_PROGRESS.

   3. Passes the job ID, batch number, and schema qualifications to the AMM Mover. See "About the AMM Mover".

   4. Determines whether the AMM Mover successfully migrated the batch and sets the batch status to FINISHED or FAILED.

7. Determines whether all batches in the account group migrated successfully.

   • If all batches migrated successfully, the AMM Controller enables all account group members in the destination database schema and changes the account group status to GROUP_FINISHED. See "About Group Status Flags".

   • If any batch failed to migrate, the AMM Controller changes the account group status to GROUP_FAILED. See "About Group Status Flags".

     Note:

     When an account group fails to migrate, all its accounts remain disabled in the source and destination schemas. You must fix the error and migrate the job again before your BRM system can access the accounts.

About the AMM Mover

The AMM Mover is the process that actually moves accounts from one database schema to another. Each schema contains at least one AMM Mover.

Note:

The AMM Mover performs the following functions regardless of whether a batch contains group-member or nongroup member accounts.

When the AMM Mover receives a batch, it does the following:

1. Locks the appropriate base table records in the source database schema so that applications cannot access accounts during migration.

2. Migrates the objects for an account batch from the source schema to the destination schema in a single distributed transaction. See "About Distributed Transactions".

3. Marks all migrated objects in the source schema as invalid.

4. Updates the account POIDs in the uniqueness table to reflect the account's new location. For example, if an account is migrated from schema 0.0.0.1 to schema 0.0.0.2, the account POID changes from 0.0.0.1 /account 2286 0 to 0.0.0.2 /account 2286 0.

About Distributed Transactions

The AMM software migrates each batch of accounts as a single distributed transaction by using schema qualifications. This means that changes can be made to the primary, source, and destination database schemas and then committed or rolled back in one transaction, ensuring the integrity of the database.

Figure 1-2 shows the schema qualifications for a multischema system with three database schemas, one AMM Controller, and two threads:

Figure 1-2 AMM Database Schema Connections

Description of "Figure 1-2 AMM Database Schema Connections"

About Using Multiple AMM Controllers

Note:

Implementing multiple AMM Controllers is for advanced users only. Use multiple AMM Controllers only if you understand the impact to migration performance.

Using multiple AMM Controllers enables you to process multiple account migration jobs in parallel. However, you receive performance improvements only in the following situations:

• Your system contains more than three database schemas.

• No two migration jobs use the same schema at the same time.

When multiple jobs use the same schema, as shown in Figure 1-3, migration performance degrades significantly.

Figure 1-3 Concurrent Database Use Performance Degradation

Description of "Figure 1-3 Concurrent Database Use Performance Degradation"

For more information, contact your Oracle BRM representative.

Account Migration Performance

Account migration is resource intensive and can overload your BRM system.

Signs that your system is overloaded during account migration:

• Batch processing times steadily increase, without returning to their initial processing times.

• The AMM software is processing fewer than five accounts per second.

• You receive a distributed transaction time-out error (Oracle error 2049).

• There are a high number of waits for undo segment extension and latch free operations.

If your system exhibits any of these signs, you need to tune your Oracle database. For guidelines, see "Tuning Your Database for Optimal Account Migration Performance" or contact your Oracle BRM representative.