1. Cloud Native System Administrator's Guide
  2. Basic System Administration of BRM Cloud Native
  3. Managing Database Partitions

6 Managing Database Partitions

Learn how to organize your Oracle Communications Billing and Revenue Management (BRM) cloud native database by using partitioned tables.

Topics in this document:

Converting Nonpartitioned Classes to Partitioned Classes

If you did not enable partitioning for one or more storable classes when you deployed BRM cloud native, you can do so after deployment. The partitioning conversion feature splits a storable class's table in the BRM database into the following partitions:

  • partition_migrate: Holds all objects created before the nonpartitioned storable classes were converted to partitioned storable classes. The BRM purge utility, partition_utils, cannot purge objects in this partition. To purge them, you must develop your own tools based on sound Oracle database management principles.

  • partition_historic: Holds nonpurgeable events created after the nonpartitioned storable classes were converted to partitioned storable classes. Nonpurgeable events should not be purged from the database.

  • partition_last: A spillover partition that is not intended to store objects you want to purge or preserve. If you do not add purgeable partitions to your tables before BRM resumes generating objects, purgeable objects created after the upgrade are stored in this partition.

To convert nonpartitioned storable classes to partitioned storable classes, perform these tasks:

  1. Add the following lines to the oc-cn-helm-chart/brmapps_scripts/loadme.sh script: 

    #!/bin/sh

cd /oms/apps/partition; perl partitioning.pl ClassName
exit 0;

    where ClassName is the name of the storable class that you want to partition, such as /product or /bill.

  2. The brm-apps-partition-cfg ConfigMap (configmap_partition_cfg.yaml) controls your conversion parameters, such as your database's name and the partition logging directory. If necessary, edit the parameters in the file and then run the helm upgrade command.

  3. Enable the brm-apps job. In your override-values.yaml file for oc-cn-helm-chart, set ocbrm.brm_apps.job.isEnabled to true.

  4. Run the helm upgrade command to update the BRM Helm release: 

    helm upgrade BrmReleaseName oc-cn-helm-chart --values OverrideValuesFile -n BrmNameSpace

    where:

    • BrmReleaseName is the release name for oc-cn-helm-chart and is used to track this installation instance.

    • OverrideValuesFile is the file name and path to your override-values.yaml file.

    • BrmNameSpace is the namespace in which to create BRM Kubernetes objects for the BRM Helm chart.

The brm_apps job runs a series of partitioning scripts that perform the conversion.

Check the log and pinlog files in the directory specified by the $PARTITION_LOG_DIR parameter in your configmap_partition_cfg.yaml file. These log files show how long each script took to run and list any errors that occurred. If any errors are reported, fix them and rerun the script.

Adding Partitions to Your Database

You can add partitions to your database by using the partition_utils utility. For information about the utility's syntax and parameters, see "partition_utils" in BRM System Administrator's Guide.

To add partitions to the database in your BRM cloud native environment:

  1. Stop the following BRM pods:

    • dm-oracle

    • cm

    • realtime-pipeline

    • batch-controller

    • rel-daemon

    • Other pods

  2. Ensure that all jobs are stopped in your BRM cloud native environment. This includes Configurator jobs, brm-apps jobs, ImportExportPricing jobs, and SyncPDC jobs.

  3. Create a restore point in your BRM database.

    For more information, see CREATE RESTORE POINT in Oracle Database SQL Language Reference.

  4. Run the partition_utils utility in test mode to check the command for enabling delayed-event partitions: 

    partition_utils -o enable -t delayed -c /event/delayed/session% -p

    The utility writes the operation's SQL statement to a partition_utils.log file without performing any action on the database.

  5. Verify that the generated SQL statement is correct in the partition_utils.log file before proceeding.

  6. Enable delayed-event partitions by running this command:

    partition_utils -o enable -t delayed -c /event/delayed/session%

  7. Run the partition_utils utility in test mode to check the command for adding partitions for 12 months: 

    partition_utils -o add -t delayed -s StartDate -u month -q 12 -f -p

    where StartDate specifies the starting date for the new partitions in the format MMDDYYYY. The start date must be the day after tomorrow or later. You cannot create partitions starting on the current day or the next day. For example, if the current date is January 1, the earliest start date for the new partition is January 3.

    The utility writes the operation's SQL statement to a partition_utils.log file without performing any action on the database.

  8. Verify that the generated SQL statement is correct in the partition_utils.log file before proceeding.

  9. Add delayed-event partitions for 12 months by running this command:

    partition_utils -o add -t delayed -s StartDate -u month -q 12 -f

  10. Restart any Configurator, brm-apps, ImportExportPricing, or SyncPDC jobs in your BRM cloud native environment.

  11. Start the following BRM pods:

    • dm-oracle

    • cm

    • realtime-pipeline

    • batch-controller

    • rel-daemon